отвечает, опираясь на найденные во внешней базе фрагменты, а не только на память весов.
Ключевые тезисы
- Даёт свежие данные и ссылки на источники, снижая .
- Качество определяется в первую качеством retrieval.
- Ключевые ручки: стратегия чанкования, реранкинг, размер контекста.
Какую задачу решает
не знает ваших документов и не знает ничего после даты обучения. решает это, превращая ответ в двухшаговую процедуру: сначала поиск релевантных фрагментов в вашей базе, затем генерация ответа строго по найденному.
Инженерно это система из нескольких частей, и слабое звено определяет качество целиком. Плохо нарезали документы — поиск не найдёт нужное. Не поставили реранкер — нужный фрагмент останется на пятнадцатом месте. Не потребовали заземления — модель ответит по памяти вместо предъявленных документов. Работа над на 80% состоит из работы над поиском, а не над генерацией.
Сначала измерьте поиск отдельно от генерации: для набора реальных вопросов проверьте, попал ли нужный фрагмент в контекст (@k). Если recall низкий — проблема в поиске, и менять модель-генератор бесполезно. Порядок улучшений: 1) добавить реранкер (обычно +15–20 п.п. recall), 2) добавить BM25 рядом с поиском, 3) пересмотреть чанкинг под структуру документов, 4) дообучить на своих парах. Только когда recall выше 90%, имеет смысл заниматься и выбором генератора.
Подробный разбор
- Чанкование: разбить документы на фрагменты (обычно 200–500 с перекрытием).
- Индексация: посчитать и построить индекс, обычно вместе с BM25.
- Retrieval: найти топ-k фрагментов по запросу.
- Реранкинг: отсортировать их cross-encoder'ом.
- Генерация: подать фрагменты в с требованием отвечать только по ним и давать ссылки.
Качество почти целиком определяется retrieval. Если нужного фрагмента нет в контексте, никакая модель не придумает правильный ответ — она его сгаллюцинирует.
| Что измеряем | Метрика |
|---|---|
| Нашёлся ли нужный фрагмент | @k, |
| Насколько ответ опирается на источники | faithfulness / groundedness |
| Отвечает ли он на вопрос | answer relevance, exact match |
| Нет ли лишнего в контексте | context |
Практический минимум: собрать 50–100 реальных вопросов с эталонными фрагментами и мерить @k при каждом изменении чанкования или модели . Это дешевле и информативнее, чем оценивать финальные ответы вручную.
Где применяется
- Внутренняя база знанийОтветы по документации со ссылками на разделы.
- Поддержка клиентовАктуальные регламенты и тарифы без модели.
- Работа с длинными документамиДоговоры, отчёты, нормативы, не помещающиеся в контекст целиком.
- Разграничение доступаПрава применяются на этапе поиска: каждый видит только свои документы.
Плюсы, минусы и альтернативы
Плюсы
- Знания обновляются переиндексацией, без .
- Ответы со ссылками — их можно проверить.
- Резко снижает на фактических вопросах.
- Работает с любой моделью, включая закрытые API.
- Права доступа встраиваются естественно.
Минусы
- Качество ограничено качеством поиска.
- Много движущихся частей: индекс, , реранкер, обновление.
- Растёт и стоимость: длинный контекст оплачивается всегда.
- Плохо отвечает на вопросы, требующие обзора всего корпуса сразу.
- Требует отдельной системы оценки — иначе улучшения не измерить.
Брать, если
- Ответы должны опираться на ваши документы и быть проверяемыми.
- Знания меняются чаще, чем имеет смысл переобучать модель.
- Нужно разграничение доступа к информации.
Не брать, если
- База маленькая и целиком помещается в контекст.
- Нужен стиль или формат, а не факты.
- Вопросы требуют агрегации по всему корпусу («сколько всего договоров с условием X») — это задача для SQL, а не для поиска.
Чем заменяют
Связанные темы
Поиск, эмбеддинги и RAG
Embeddings80%
Эмбеддинги · Обработка естественного языкаПлотные векторные представления объектов, где геометрическая близость означает смысловое сходство.
Semantic Search80%
Семантический поиск · Обработка естественного языкаПоиск по смыслу, а не по совпадению слов: запрос и документы сравниваются в пространстве эмбеддингов.
TF-IDF80%
TF-IDF · Обработка естественного языкаВзвешивает частоту слова в документе на его редкость в корпусе, подавляя общеупотребительные слова.
RAG80%
RAG · Генеративный ИИПодмешивание найденных документов в контекст модели вместо хранения знаний в весах.
LLM80%
Большие языковые модели · Генеративный ИИТрансформеры-декодеры, обученные на огромных корпусах предсказывать следующий токен.
Agents80%
Агенты · Генеративный ИИLLM, которая планирует, вызывает инструменты и итеративно движется к цели.
NDCG80%
NDCG · МетрикиНормированный дисконтированный кумулятивный выигрыш: учитывает градации релевантности и позиции с логарифмическим дисконтом.
MRR80%
Средний обратный ранг · МетрикиСреднее значение 1/rank первого релевантного результата.
MAP80%
Средняя усреднённая точность · МетрикиСреднее по запросам от average precision — учитывает и релевантность, и позиции.
Precision@K80%
Точность@K · МетрикиДоля релевантных объектов среди первых K позиций выдачи.
Recall@K80%
Полнота@K · МетрикиКакая доля всех релевантных объектов попала в топ-K.
Всё, что названо в описании, разобрано здесь же или в соседней теме — переходы под каждым определением.
Чанкинг
Разбиение документов на фрагменты. Обычно 300–800 с перекрытием, но зависит от структуры текста.
Отдельная тема: RAG · Чанкование — недооценённый рычагИндексация
фрагментов в индексе плюс, как правило, полнотекстовый индекс рядом.
Разбор ниже: Устройство RAG-пайплайнаГибридный поиск
плюс BM25: первый ловит смысл, второй — точные термины и коды.
Разбор ниже: Устройство RAG-пайплайнаРеранкинг
Cross-encoder переупорядочивает топ-50 в топ-5. Обычно самый заметный прирост качества.
Разбор ниже: Устройство RAG-пайплайнаОценка RAG
Метрики отдельно для поиска (@k) и для ответа (заземлённость, полнота, отсутствие выдумок).
Разбор ниже: Как оценивать RAGПрофильная компетенция для ролей: LLM-инженер, Продуктовый инженер.
Усиливает профиль: NLP-инженер.
Спрашивают на собеседовании: Яндекс — NLP, Сбер — NLP и LLM.
Тема встречается в тесте по направлениям — ошибки приведут обратно на эту страницу.
Глава «Обработка естественного языка» последний раз правилась . Нашли ошибку — напишите.