РУКОВОДСТВО · ОБНОВЛЕНО 2026-10-26
Как оценить поиск в RAG отдельно от ответа модели
Практический порядок проверки retrieval до настройки промпта и замены генеративной модели.
Качество поиска в RAG проверяют по найденным документам или фрагментам до генерации ответа. Подготовьте вопросы и разметку релевантных источников, сохраните их стабильные идентификаторы и сравнивайте ранжированные результаты при одинаковом k. Recall@k показывает долю известных релевантных элементов, попавших в первые k позиций; MRR оценивает положение первого релевантного результата. Ни одна средняя метрика не заменяет разбор важных ошибок. Правильная выдача и правильный итоговый ответ — отдельные этапы проверки.
1. Соберите выборку реальных намерений
Включите точный поиск факта, вопрос с синонимами, задачу по нескольким документам и запрос без ответа в корпусе. Не составляйте все вопросы только из формулировок заголовков: такие примеры слишком удобны для поиска. Для каждого вопроса сохраните допустимые релевантные источники и объяснение разметки. Разделите набор для настройки и итоговой проверки, чтобы изменения не подгонялись только под знакомые запросы. Закрытые документы заменяйте согласованными учебными примерами при публикации отчёта.
2. Выберите документы или фрагменты
После изменения chunking один и тот же документ может разбиться на другое число частей. Если сравнивать только старые chunk ID, метрика потеряет смысл. Заранее определите единицу релевантности и связь с исходным документом. Учитывайте несколько допустимых источников одного факта и неполноту разметки. Найденный полезный фрагмент, которого нет в эталоне, требует проверки разметки, а не автоматического объявления новой системы хуже. Версионируйте корпус, вопросы и ответы поискового этапа вместе.
3. Считайте несколько показателей
Для вопроса с тремя релевантными документами нахождение двух даёт Recall@k, равный двум третям, если обе записи находятся внутри выбранного k. Если первый релевантный источник стоит третьим, вклад этого запроса в MRR равен одной трети. При отсутствии совпадения в оцениваемой выдаче вклад равен нулю. Фиксируйте используемое определение и границу k, поскольку названия метрик в разных инструментах могут трактоваться неодинаково. Не объявляйте универсальный хороший порог без требований задачи.
4. Разберите регрессии перед выпуском
Сравните результаты по категориям, языкам, длине документа и ограничениям доступа. Улучшение среднего MRR не оправдывает исчезновение нужного документа по критическому вопросу. Проверьте, что фильтр прав не пропускает закрытые данные и не удаляет разрешённые по ошибке. Затем отдельно оцените генерацию на одинаковой выдаче: это помогает отличить проблему retrieval от проблемы модели. Увеличение k допустимо только с проверкой шума, бюджета контекста и итоговой полезности ответа.
Частые вопросы
Можно ли оценить поиск без вызова LLM?
Да, если есть разметка релевантных ID и сохранённая выдача. Это проверяет retrieval, а не достоверность будущего сгенерированного ответа.
Чем Recall@k отличается от наличия одного совпадения?
Recall учитывает долю всех известных релевантных элементов. Наличие хотя бы одного — другая проверка, особенно важная разница для вопросов по нескольким источникам.
Достаточно ли одного MRR?
Нет. Он оценивает первый релевантный результат и может не показать потерю остальных необходимых документов. Смотрите покрытие и отдельные ошибки.
Нужно ли всегда повышать k?
Нет. Более длинная выдача может добавить шум и расход контекста. Подбирайте k на контрольной выборке и проверяйте полный сценарий.