Что именно измеряет качество ответов RAG
RAG-система сначала ищет фрагменты в базе знаний, а затем использует их для генерации ответа. Поэтому оценка только финального текста не показывает, где возникла ошибка: поисковый компонент не нашёл нужное или модель неверно использовала найденное.
Для первичной диагностики разделите проверку на три вопроса:
Попали ли в результаты поиска документы, содержащие ответ?
Подтверждается ли ответ найденными фрагментами?
3. Отвечает ли текст на вопрос пользователя, не добавляя неподтверждённых деталей?
Это разные свойства. Система может найти нужный документ, но сформулировать неверный ответ. Или написать правдоподобный текст, хотя поиск вернул нерелевантные источники. Метрики retrieval и генерации следует считать отдельно, а затем проверять совместно.
Такой подход полезен при сравнении изменений в разбиении документов, эмбеддингах, reranker, системном промпте или модели. Если менять несколько компонентов одновременно, по результатам сложнее понять, что именно улучшило или ухудшило систему.
Соберите небольшой эталонный набор из реальных вопросов
Начните не с сотен искусственных запросов, а с набора, который отражает задачи пользователей. Для каждого вопроса зафиксируйте:
- сам запрос;
- ожидаемый ответ или обязательные факты;
- документы и фрагменты, где эти факты подтверждаются;
- случаи, когда корректный ответ — сообщить, что данных недостаточно.
Добавьте разные формулировки одного и того же намерения, вопросы с несколькими условиями и запросы, где ответ распределён между несколькими документами. Отдельно включите вопросы, на которые база не отвечает. Иначе система, уверенно выдумывающая недостающие сведения, может выглядеть успешной по набору, где всегда есть готовый ответ.
Эталон не обязательно должен содержать идеальную формулировку ответа. Для многих задач достаточно перечислить проверяемые факты и ссылки на источники. Например, для вопроса «Когда истекает срок действия токена и как его обновить?» эталон может требовать два факта: срок и документированную процедуру обновления. Ответ, содержащий только один из них, будет неполным.
Перед тестированием проверьте, что эталонные документы действительно входят в ту версию корпуса, на которой запускается система. Иначе ошибка тестовой инфраструктуры будет выглядеть как провал поиска.
Проверьте извлечение до проверки генерации
Для каждого запроса сохраните top-k результатов retrieval: идентификаторы документов, ранги, оценки сходства и текст фрагментов. Затем измерьте, насколько часто нужный источник оказывается среди результатов.
Простая метрика — Recall@k: доля запросов, для которых релевантный документ попал в первые k результатов. Если система использует несколько обязательных источников, заранее определите, считается ли запрос успешным при нахождении любого из них или всех необходимых.
Также полезно смотреть на MRR — средний обратный ранг первого релевантного результата. Если правильный фрагмент обычно найден, но стоит на десятой позиции, увеличение числа передаваемых модели фрагментов может временно помочь, однако повысит объём контекста и стоимость. Это сигнал исследовать ранжирование, а не просто увеличивать k.
Результаты удобно размечать на небольшом наборе вручную. Не считайте один лишь высокий similarity score доказательством релевантности: он показывает оценку конкретной модели эмбеддингов, а не подтверждение того, что фрагмент отвечает на вопрос. BEIR — один из известных исследовательских наборов для сравнения систем поиска по разным задачам; его результаты полезны как ориентир, но не заменяют тест на собственном корпусе и запросах.
Оцените ответ отдельно по опоре на источники и полноте
Для генерации заведите отдельные критерии, вместо единой оценки «хорошо/плохо»:
- Опора на контекст: подтверждаются ли утверждения предоставленными системе фрагментами?
- Полнота: присутствуют ли обязательные факты из эталона?
- Релевантность: отвечает ли текст на поставленный вопрос?
- Корректное воздержание: признаёт ли система отсутствие достаточных данных?
Если ответы сопровождаются цитатами, проверьте не только наличие ссылки, но и то, действительно ли указанное место подтверждает конкретное утверждение. Ссылка на документ в целом не гарантирует, что нужный факт есть в приведённом фрагменте.
RAGAS описывает метрики для оценки разных частей RAG-процесса, в том числе релевантности контекста, его полноты и соответствия ответа контексту. Это помогает структурировать проверку, но автоматическая оценка не является независимым доказательством качества: результат зависит от выбранной метрики, модели-судьи и формулировки задания. Сверьте несколько примеров вручную, особенно там, где автоматическая оценка расходится с ожиданиями.
Исследование RAGAS и работа по фреймворку RAGAS описывают подходы к оценке без обязательной ручной разметки каждого ответа. Для производственного решения этого недостаточно само по себе: автоматические судьи могут неверно трактовать неоднозначный запрос или принять уверенный, но неподтверждённый текст.
Запустите воспроизводимое сравнение конфигураций
Сравнивайте варианты на одном и том же наборе вопросов и с неизменными настройками генерации. Зафиксируйте версию корпуса, модель эмбеддингов, параметры разбиения, k, reranker, модель ответа и шаблон запроса. Сохраняйте не только итоговый балл, но и найденные фрагменты и полный ответ.
Минимальный эксперимент может выглядеть так:
Выбрать 30–50 репрезентативных запросов и указать для каждого релевантные документы.
Запустить текущую конфигурацию и сохранить top-k, ответ и ссылки.
3. Изменить один компонент — например, размер фрагмента или reranker.
4. Повторить тот же запуск на прежнем наборе.
5. Сравнить Recall@k, полноту ответов, ошибки опоры на источники и долю корректных отказов.
6. Вручную разобрать все ухудшившиеся случаи и несколько улучшившихся.
Размер набора здесь — стартовая практическая эвристика, а не гарантия статистической значимости. Для надёжного сравнения увеличивайте набор и следите за разбросом по типам запросов. Не объединяйте в одну цифру вопросы по разным разделам корпуса, если их сложность и последствия ошибки существенно отличаются.
Документация OpenAI по evals полезна как пример организации повторяемых оценок: задайте тестовые случаи, критерии и сохраняйте результаты запусков. Независимо от платформы принцип тот же — без фиксированного набора и версий сравнение «до и после» трудно воспроизвести.
Используйте ошибки, чтобы найти слабое звено
Разделите неудачные ответы на классы:
- нужного документа нет среди top-k;
- нужный материал найден, но теряется при ранжировании;
- контекст найден, но модель пропускает часть условий;
- ответ добавляет сведения, которых нет в источниках;
- система отвечает, хотя должна воздержаться;
- цитата ведёт к источнику, который не подтверждает утверждение.
Каждый класс подсказывает следующую проверку. При пропуске документа проверьте покрытие корпуса, разбиение и запрос поиска. При плохом ранге сравните retrieval с reranker. Если фрагмент найден, но модель игнорирует условие, проверьте формат контекста и инструкцию. При неподтверждённых утверждениях добавьте тесты на опору ответа и проверьте поведение при пустом или противоречивом контексте.
Не лечите все ошибки увеличением числа фрагментов. Более широкий контекст может принести нужный документ, но одновременно добавить шум, дубли и противоречия. Измеряйте качество при нескольких значениях k и отслеживайте задержку и расход токенов: улучшение полноты может сопровождаться ростом стоимости.
Проверьте устойчивость на изменениях корпуса и неизвестных вопросах
Оценка быстро устаревает, если документы регулярно обновляются. Сохраняйте дату или версию корпуса и добавляйте тесты на свежие материалы: устаревший фрагмент может конкурировать с актуальным и приводить к ответу, который когда-то был верен.
Включите в набор дубликаты, конфликтующие версии документа и запросы с неверной предпосылкой. Например, если пользователь спрашивает о функции, которой в документации нет, ожидаемым результатом должно быть аккуратное указание на отсутствие подтверждения, а не догадка по аналогии.
Перед изменением системы проверяйте несколько групп отдельно: обычные вопросы с прямым ответом, составные запросы, запросы без ответа в базе и запросы к обновлённым документам. Средний балл может скрыть ухудшение именно на случаях, где ошибка наиболее заметна пользователю.
Что зафиксировать перед внедрением изменений
Для следующего цикла тестирования сохраните исходный набор запросов, эталонные факты и источники, версии компонентов, параметры поиска и генерации. Рядом с агрегированными метриками храните примеры конкретных ошибок. Так команда сможет понять не только изменилось ли качество, но и для каких запросов оно изменилось.
Перед тем как принять новую конфигурацию, проверьте три вещи: не упал ли Recall@k, подтверждаются ли ключевые утверждения ответов найденным контекстом и умеет ли система отказываться при нехватке данных. Если улучшение видно только в автоматической оценке, а ручная проверка примеров его не подтверждает, считайте результат предварительным и расширьте набор тестов.
