Оценка качества RAG: тестовый набор, источники и метрики

Раздел

RAG и базы знаний

Сложность

сложная

Обновлено

2026-05-19

Короткий ответ

Оценка качества RAG нужна, чтобы понять не “нравится ли ответ”, а где именно система ошибается: не нашла источник, нашла не тот фрагмент, неправильно использовала источник, выдумала факт, не отказалась без данных или показала документ без прав. Без такой диагностики RAG выглядит убедительно, но остается непроверяемым.

Начните с тестового набора из 100-200 реальных вопросов. Для каждого вопроса укажите правильный источник, ожидаемый смысл ответа, критичные ошибки и ситуацию, когда система должна отказаться. Потом проверяйте retrieval и generation отдельно.

Что именно оценивать

RAG состоит из нескольких частей:

Если смотреть только итоговый ответ, вы не поймете причину ошибки. Может быть плохая модель, плохой chunking, устаревший документ или неправильный фильтр прав.

Тестовый набор

Соберите вопросы из реальной работы:

• обращения поддержки;
• вопросы сотрудников;
• поисковые запросы по wiki;
• тикеты;
• письма клиентам;
• типовые ошибки;
• спорные случаи.

Для каждого вопроса добавьте:

• правильный источник;
• допустимые фрагменты;
• ожидаемый ответ или критерий;
• запрещенные утверждения;
• признак, что нужен отказ;
• роль пользователя.

Тестовый набор должен включать вопросы без ответа. Иначе RAG научится красиво отвечать всегда, даже когда данных нет.

Метрики retrieval

Проверяйте поиск отдельно:

• есть ли нужный документ в top-1, top-3, top-5;
• не выбран ли устаревший дубль;
• не смешаны ли похожие темы;
• сохраняется ли заголовок и структура;
• учитываются ли права доступа;
• хватает ли соседнего контекста.

Если нужного источника нет в найденных фрагментах, модель почти обречена. Не лечите это prompt-ом. Нужно исправлять корпус, индексацию, chunking, embeddings, reranking или фильтры.

Метрики generation

Для ответа важны:

• faithfulness: ответ следует источнику;
• completeness: ответ закрывает вопрос;
• answer relevance: нет лишнего текста;
• citation quality: источник показан понятно;
• refusal quality: отказ корректен;
• format correctness: ответ в нужном формате.

Автоматические метрики помогают отслеживать регрессии, но на старте нужен ручной review владельцев знаний. Юрист, продукт, поддержка или бухгалтер видят ошибки, которые модель-оценщик может пропустить.

Права и безопасность

Добавьте тесты на права:

• пользователь без доступа спрашивает закрытый документ;
• вопрос формулируется косвенно;
• закрытый документ похож на открытый;
• источник доступен только одной группе;
• документ архивный, но релевантный;
• пользователь просит “не показывать источник”.

RAG не должен использовать закрытый документ даже для “обобщенного” ответа. Фильтрация должна работать до передачи контекста модели.

Регрессии

RAG ломается не только при смене модели. Регрессии появляются после:

• обновления корпуса;
• изменения chunking;
• смены embeddings;
• добавления reranker;
• изменения prompt;
• настройки прав;
• загрузки новых форматов документов.

После каждого такого изменения прогоняйте тестовый набор. Иначе улучшение одной темы может сломать другую.

План проверки

1. Соберите 100-200 вопросов.
2. Разметьте источники и критерии.
3. Добавьте вопросы без ответа и вопросы на права.
4. Прогоните retrieval отдельно.
5. Прогоните generation отдельно.
6. Разберите ошибки по типам.
7. Исправьте корпус, поиск или prompt.
8. Повторяйте после каждого обновления.

Не ждите идеального score. Важнее понимать, какие ошибки допустимы, какие блокируют запуск и кто отвечает за исправление.

Чеклист

• Есть тестовый набор реальных вопросов.
• Есть вопросы без ответа.
• Есть проверки прав доступа.
• Retrieval и generation оцениваются отдельно.
• Источники проверяются на свежесть.
• Ошибки классифицируются по причинам.
• Автоматические метрики дополнены ручным review.
• Тесты гоняются после обновления корпуса и prompt.

FAQ

Можно ли оценивать RAG только LLM-судьей?

Не стоит. LLM-судья полезен для масштаба, но критичные темы требуют ручной проверки владельца знаний.

Что важнее: precision поиска или качество ответа?

Сначала поиск. Если нужный источник не найден, ответ будет случайным или неполным.

Сколько вопросов нужно для старта?

Для пилота достаточно 100-200 хороших вопросов. Важно, чтобы они покрывали реальные темы, отказы и права.

Что читать дальше?

Начните с архитектуры RAG системы и страницы поиск по документам с ИИ.