RAG объединяет поиск по внешним данным с генерацией ответа языковой моделью. Но качество такой системы нельзя надёжно оценить одним удачным запросом: поиск может не найти нужный документ, а модель — неверно пересказать найденный. Чтобы оценить качество RAG на своих данных, разделите проверку на две части: выясните, извлекаются ли полезные фрагменты, и проверьте, подтверждается ли ими ответ.
Ниже — практический способ собрать небольшой воспроизводимый тест без универсального бенчмарка и без оценки «кажется, работает». Он подходит для внутренней базы знаний, документации продукта или корпуса инструкций. Главный результат — не одна магическая цифра, а понимание, какой компонент стоит исправлять.
Что именно измеряет тест RAG
Вопрос к RAG-системе проходит несколько этапов: пользователь формулирует запрос, поиск ранжирует фрагменты, система отбирает контекст, а модель составляет ответ. Ошибка на любом шаге может выглядеть одинаково для пользователя — ответ неверный или неполный, — но требует разных исправлений.
Полезно различать три вопроса:
Нашёл ли поиск нужный материал? Это задача извлечения и ранжирования.
Опирается ли ответ на найденный контекст? Это задача генерации с учётом источников.
3. Дал ли ответ нужную информацию? Это задача полноты и соответствия запросу.
BEIR — набор для сравнения моделей поиска по разным задачам и доменам — показывает, почему результаты на одном поисковом датасете не гарантируют одинакового качества в другом. Для прикладной системы собственные запросы и документы важнее абстрактной оценки на чужом корпусе.
Соберите эталонные вопросы до изменения системы
Начните с 30–100 запросов, которые отражают реальные сценарии пользователей. Если логов пока нет, составьте вопросы по структуре базы: простые фактические, составные, синонимичные и такие, для которых ответа в документах нет.
Для каждого запроса сохраните:
- формулировку вопроса;
- один или несколько документов, которые действительно содержат ответ;
- необходимый фрагмент или краткую опорную формулировку;
- допустимый ответ либо ключевые пункты ответа;
- пометку, если в корпусе ответа нет.
Например, для документации API вопрос может звучать так: «Какой заголовок нужен для повторного запроса после ограничения частоты?» Эталон должен ссылаться на конкретную страницу и фиксировать требуемое поле или правило. Не записывайте эталон только как готовый ответ: без ожидаемого документа вы не сможете отделить сбой поиска от ошибки генерации.
Не включайте в тест исключительно очевидные вопросы, совпадающие словами с заголовками. Добавьте варианты с другой формулировкой, сокращениями и несколькими условиями. Отдельная группа вопросов без ответа помогает проверить, умеет ли система воздержаться от догадки.
Как оценить качество RAG на своих данных: начните с поиска
Сначала измерьте retrieval отдельно от генерации. Для каждого запроса сравните документы, которые система вернула, с документами из эталона. Важны не только наличие правильного результата, но и его позиция в ранжированном списке.
Две простые метрики:
- Recall@k — доля запросов, для которых среди первых *k* результатов есть нужный документ. Показывает, находит ли поиск источник вообще.
- MRR (Mean Reciprocal Rank) — среднее обратное место первого релевантного результата. Если правильный документ чаще стоит выше, MRR растёт.
Пусть для пяти вопросов правильный документ оказался на позициях 1, 2, 5, отсутствовал и 1. Recall@3 будет 3/5: подходящий источник присутствовал в первых трёх результатах для трёх запросов. MRR рассчитывается по обратной позиции первого релевантного результата: (1 + 1/2 + 1/5 + 0 + 1) / 5 = 0,54.
Это демонстрационный расчёт, а не характеристика какой-либо модели. Если эталонный документ не попадает в выдачу, перенастройка системного промпта обычно не решит проблему. Проверьте разбиение документов на фрагменты, фильтры метаданных, поисковый запрос и настройки ранжирования.
BEIR использует разнообразные задачи поиска и метрики ранжирования; его документация и код полезны как ориентир для сравнения подходов. Но небольшой внутренний набор не становится эквивалентом BEIR: он отвечает на более узкий вопрос — как конкретная конфигурация ведёт себя на вашем корпусе и запросах.
Проверьте, что попало в контекст модели
Релевантный документ в выдаче ещё не означает, что модель получила нужный отрывок. Между поиском и генерацией могут быть фильтрация, ограничение числа фрагментов, дедупликация или усечение контекста.
Для каждой тестовой записи сохраняйте не только список результатов поиска, но и фактический контекст, переданный модели. Затем вручную разберите неудачные случаи:
- нужного фрагмента нет среди результатов;
- документ найден, но полезный отрывок не попал в контекст;
- фрагмент разрезан так, что пропало условие или определение;
- в контекст попали противоречащие друг другу версии;
- контекст содержит ответ, но модель его игнорирует.
Такое журналирование делает причину ошибки проверяемой. Меняйте по одному компоненту за раз — например, размер фрагмента или число результатов — и повторяйте тот же тестовый набор. Если одновременно поменять индекс, промпт и модель, будет трудно понять, какое изменение повлияло на результат.
Оцените полноту и опору ответа на источники
После проверки поиска переходите к ответам. Здесь полезно разделить полноту и обоснованность. Ответ может содержать верное утверждение, но пропустить важное ограничение; или перечислить все нужные пункты, но добавить неподтверждённую деталь.
Ragas описывает метрики для разных компонентов RAG, включая показатели, связанные с релевантностью контекста и ответом. Такие метрики помогают автоматизировать первичный разбор, но не заменяют эталон и выборочную ручную проверку. Например, оценка, где другая языковая модель выступает судьёй, зависит от её собственных ошибок, формулировок критериев и выбранного эталона.
Для небольшого набора начните с ручной шкалы:
- Полнота: присутствуют ли все обязательные части эталонного ответа?
- Обоснованность: подтверждается ли каждое существенное утверждение переданным контекстом?
- Соответствие: отвечает ли текст на заданный вопрос, а не на соседнюю тему?
- Воздержание: отказывается ли система уверенно отвечать, когда в базе нет ответа?
Оценивайте эти критерии по отдельности. Один общий балл скрывает различия: например, система может почти всегда отвечать по найденному документу, но регулярно пропускать второе условие из запроса.
Воспроизводимый тест: зафиксируйте конфигурацию и повторите прогон
Чтобы сравнение имело смысл, сохраняйте вместе с результатом теста версию корпуса и конфигурацию системы:
- версию или дату снимка документов;
- модель эмбеддингов и настройки индекса;
- способ разбиения на фрагменты;
- параметры поиска и число результатов;
- версию генеративной модели;
- инструкции, переданные модели;
- фактические найденные фрагменты и ответы.
Затем прогоните один и тот же набор после изменения компонента. Сравните не только средние метрики, но и список запросов, где результат изменился. Улучшение Recall@k может сопровождаться ухудшением ответа, если в контекст стало попадать больше нерелевантного текста.
Документация OpenAI по evals рекомендует строить оценки вокруг определённых задач и критериев, а не полагаться на единичные примеры. Для RAG это означает, что тестовый набор и правила оценки следует держать отдельно от конкретного промпта и проверять повторно после обновлений.
Разберите ошибки по типу, а не только по числу
Таблица ошибок с категориями часто полезнее одного итогового показателя. Для каждого провала назначьте наиболее ранний этап, на котором возникла проблема:
| Наблюдение | Вероятный участок для проверки |
|---|---|
| Нужного документа нет в выдаче | Индекс, формулировка запроса, фильтры |
| Документ найден, нужного отрывка нет | Разбиение на фрагменты, ранжирование |
| Ответ противоречит переданному тексту | Инструкции, генерация, неоднозначный контекст |
| Ответ неполон, хотя все данные есть | Формат задачи, извлечение обязательных пунктов |
| Система отвечает при отсутствии источника | Правило воздержания и обработка пустого контекста |
Это не диагноз автоматически: одна и та же ошибка может иметь несколько причин. Но классификация помогает выбирать следующий эксперимент вместо случайного переписывания промпта.
Если система должна работать с инструкциями, где важны исключения и условия, включите в набор вопросы на их совместное применение. Если она ищет по часто обновляемой базе, добавьте запросы, где старый и новый документы расходятся, и заранее определите, какая версия считается актуальной.
Ограничения автоматических оценщиков
Оценщик на основе LLM может ускорить разметку большого числа ответов, но его выводы нельзя принимать за независимое доказательство качества. Он способен пропустить тонкое условие, предпочесть многословный ответ или засчитать правдоподобное утверждение, которого нет в источнике.
Используйте автоматическую оценку для сортировки и поиска подозрительных примеров. На старте вручную проверьте хотя бы выборку ответов, включая случаи с высокой и низкой оценкой. Особенно важны вопросы с отрицанием, датами, числовыми ограничениями, несколькими документами и отсутствующим ответом.
Документируйте критерии так, чтобы два человека могли применить их к одному ответу сходным образом. Если оценки регулярно расходятся, проблема может быть не в системе RAG, а в неоднозначном эталоне или слишком расплывчатой рубрике.
Что проверить перед выводом о качестве
Перед тем как сравнивать версии, убедитесь, что тест не подменяет реальную эксплуатацию:
- вопросы похожи на реальные запросы, а не только на формулировки документации;
- эталонные источники действительно содержат ответ и актуальны;
- в наборе есть сложные и неразрешимые запросы;
- измеряются отдельно поиск, переданный контекст и ответ;
- конфигурация и корпус зафиксированы для повторного прогона;
- автоматические оценки выборочно проверены вручную.
Начните с анализа десяти худших случаев: откройте запрос, результаты поиска, фактический контекст и ответ. Этот разбор обычно быстрее показывает, что исправлять — индекс, разбиение, фильтрацию или генерацию. Не переносите число из небольшого внутреннего теста на другие корпуса: оно описывает только выбранные данные, вопросы и конфигурацию.
