RAG поиск стоит оценивать отдельно от ответа модели: если нужный фрагмент пропущен, формулировки запроса к модели бессильны, а если найден, но ответ плохой, причина в другом месте. Для проверки нужен небольшой набор эталонных вопросов с известными источниками, несколько простых отметок по каждому результату и порядок действий на случай нулевой выдачи, когда поиск возвращает пустоту или мусор.
Эталонные вопросы
Оценка поиска строится на эталонном наборе: вопросы, для каждого указан документ и фрагмент, где лежит правильный ответ. Без такого набора любое улучшение остаётся на уровне впечатлений.
Эталон собирает человек, знающий документы. Это скучная работа, но она окупается: набор служит и для первоначальной проверки, и для контроля после каждого изменения. Соберите вопросы так, чтобы они отражали реальные потребности пользователей, вместо формулировок, удобных для системы.
Размер набора скромный: для первого прогона хватает двух десятков вопросов, для рабочей системы сотни. Главное, чтобы каждый тип вопросов был представлен несколько раз, иначе результат по типу покажет случайность. Если эксперта для разметки найти сложно, начните с вопросов, на которые вы сами готовы отвечать, и пополняйте набор по мере появления реальных обращений.
- Реальные формулировки: берите вопросы из обращений сотрудников и клиентов, вместо собственных выдумок.
- Разные типы: фактические, процедурные, сравнительные, с ответом в нескольких документах.
- Перефразы: один вопрос в двух-трёх формулировках, чтобы проверить понимание смысла.
- Вопросы без ответа в корпусе: они проверяют нулевую выдачу.
- Для каждого: источник, фрагмент и краткий эталонный ответ.
Прототип, на котором удобно прогонять такой набор, описан в материале RAG Python: минимальный прототип и тест цитат. А подготовка самого корпуса, от которой зависит качество поиска, разобрана в статье RAG данные: подготовка корпуса и обновление.
Что измерять
Метрик в литературе много, но для практики хватает нескольких простых отметок. Их ставят по каждому вопросу вручную или полуавтоматически, а потом считают долю по набору.
Оценивать можно вручную или с помощью второй модели в роли судьи, но у второго способа есть слабое место: судья ошибается так же, как и система. Поэтому полностью автоматическая оценка требует выборочной проверки человеком, иначе вы измеряете согласие двух моделей, и это далеко от качества поиска.
| Отметка | Вопрос к результату | Что показывает |
|---|---|---|
| Найден ли источник | Есть ли нужный фрагмент среди возвращённых | Базовую полноту поиска |
| Позиция | На каком месте оказался нужный фрагмент | Качество сортировки |
| Чистота выдачи | Сколько возвращённых фрагментов относится к делу | Шум, который попадёт к модели |
| Покрытие | Достаточно ли фрагментов для полного ответа | Подходит ли число возвращаемых кусков |
| Свежесть | Из действующей ли версии взят фрагмент | Состояние корпуса, модель тут ни при чём |
Особое значение имеет позиция. Если нужный фрагмент найден, но стоит шестым, а модели передаются первые три, результат такой же, как при ненайденном. В этом случае помогает повторная сортировка, о ней мы писали в материале реранкер: повторная сортировка в RAG.
Нулевая выдача
Нулевая выдача бывает двух видов. В первом случае поиск возвращает пустой список, во втором возвращает фрагменты, далёкие от вопроса. Опаснее второй вариант: система выглядит довольной и уверенно отвечает по мусору.
Сначала разделите два случая. Если нужный документ есть в корпусе, а поиск его пропустил, перед вами ошибка поиска, и чинят её индексом. Если документа нет, перед вами пробел знаний, и закрывает его владелец документации. Смешивание этих случаев тратит время: инженер часами правит параметры, хотя требуется недостающий регламент.
- Порог сходства: слишком мягкий пропускает случайные фрагменты, слишком строгий режет верные.
- Лексика вопроса: сотрудник использует жаргон, а в документах формальные термины, и векторы расходятся.
- Пробел в корпусе: ответа действительно нет, и система обязана признать это.
- Ошибка разбиения: нужная мысль разрезана на две части, и ни одна половина на вопрос непохожа.
- Несовпадение языков: вопрос на одном языке, документ на другом, а модель эмбеддингов слаба в обоих.
Пустая выдача иногда оказывается правильным результатом, и приучить систему честно молчать так же важно, как научить её находить. Для каждого вопроса с нулевой выдачей записывайте причину из этого списка. Через неделю накопится статистика, и станет видно, что чинить в первую очередь: порог, словарь синонимов, разбиение или сам корпус. Для вопросов, на которые ответа в корпусе нет, правильной реакцией считается честное «в документах ответа найти нельзя».
Корректировка индекса
Исправление поиска идёт по одной гипотезе за раз. Менять сразу модель, порог и размер фрагмента значит потерять понимание того, что помогло.
- Прогоните эталонный набор и запишите отметки по каждому вопросу в таблицу.
- Выберите самый частый тип сбоя: ненайденный источник, плохая позиция или шум.
- Сформулируйте одну гипотезу: например, фрагменты слишком крупные или нужен словарь синонимов.
- Внесите одно изменение и пересоберите затронутую часть индекса.
- Прогоните тот же набор и сравните с предыдущим запуском по тем же отметкам.
- Оставьте изменение, если выигрыш виден и остальное работает, иначе откатите.
Фиксируйте кроме отметок ещё и конкретные примеры сбоев: вопрос, что вернул поиск, что ожидалось. Такие примеры убедительнее любой таблицы, когда нужно объяснить руководству, зачем тратить время на доработку, и пригодятся как тесты для будущих версий системы.
Выбор модели эмбеддингов тоже проверяется этим способом: пример сравнения для русскоязычных документов описан в статье Qwen3 Embedding: поиск по корпоративным документам, а гибридный поиск и другие приёмы собраны в материале про LangChain RAG.
Есть ли у вас набор вопросов для измерения качества поиска?
Контроль после изменений
Поиск портится тихо: корпус растёт, документы обновляются, модель эмбеддингов меняется. Без регулярной проверки вы узнаёте об этом по жалобам пользователей, цифр у вас нет.
Любое изменение корпуса, модели или параметров поиска проходит через прогон эталонного набора. Если отметки ухудшились, изменение откатывается или дорабатывается до выхода к пользователям.
Раз в квартал набор стоит пересматривать целиком: убирать вопросы, потерявшие смысл из-за смены регламентов, добавлять новые темы, проверять, что разметка источников по-прежнему верна. Набор без хозяина постепенно измеряет качество на прошлогодних вопросах.
- Эталонный набор живёт рядом с кодом и меняется через ревью.
- Новые типичные вопросы пользователей, на которых система ошиблась, добавляются в набор.
- Результаты каждого прогона хранятся по датам, чтобы была видна динамика.
- За набор отвечает назначенный человек, коллективная ответственность тут размывается.
Оценку поиска на вашем корпусе, с набором вопросов и разбором причин сбоев, мы строим в проектах по внедрению ИИ. Повторяйте прогон после каждой правки и записывайте итог в ту же таблицу отметок: через месяц по ней видно, какие изменения стоили усилий, а какие были напрасными.