Когда поиск уже нашёл полезные фрагменты, остаётся две задачи: уместить их в окно модели без потери фактов и не потерять тему — чтобы ответ шёл из раздела про Kubernetes, а не из случайно похожей главы про сети вообще.
Сжатие контекста в духе SARA
В литературе (в том числе работы вроде SARA — Selective and Adaptive Retrieval-augmented Generation with Context Compression) идея такая: не всё найденное одинаково важно. Практичный вариант без тяжёлых нейросетей сжатия:
- Must-keep — несколько лучших фрагментов оставляют полным текстом.
- Фон — похожие и второстепенные куски сжимают (краткое резюме), убирают явные дубликаты.
Модель не тонет в десяти почти одинаковых абзацах про Docker, но сохраняет ключевые определения. Это не «вырезать всё под лимит токенов наугад», а осознанно разделить важное и фон.
Тематический вес раздела
Запрос «Pod в Kubernetes» должен предпочитать материалы про оркестрацию контейнеров, а не любой документ, где встречается слово «pod». Простой и понятный приём: учитывать в ранжировании пересечение запроса с разделом, подразделом, метками документа (идея близка к подходам вроде MCompassRAG). Это лёгкий «компас темы», а не отдельная огромная база тем.
Как идеи стыкуются
| Шаг | Зачем |
|---|---|
| Поиск + учёт раздела | Кандидаты ближе к нужной теме |
| Проверка и добор выдачи | Слабое не идёт в ответ как есть |
| Упаковка must-keep + фон | Модель видит факты, а не шум |
Практики применения
- Заполняйте разделы и метки у материалов библиотеки — тематический сигнал живёт в структуре каталога.
- Не ждите чуда от сжатия, если в выдаче изначально нет нужных источников — сначала качество поиска.
- Если ответ «размытый», проверьте, отвечает ли система по архиву или только общими знаниями модели.
Итог: сжатие контекста бережёт факты в must-keep и убирает дубли; учёт раздела подталкивает выдачу к нужной теме — финальные штрихи умного retrieval.