Как измерять качество RAG-системы
Метрики поиска и ответа: покрытие, релевантность, groundedness, полнота, цитаты, отказ, права и контрольная выборка.
Коротко: RAG нужно оценивать в два слоя: нашёл ли поиск достаточные источники и поддерживает ли сформированный ответ свои утверждения этими источниками. Средняя оценка без классов ошибок скрывает критичные провалы.
Определение
Оценка RAG — воспроизводимая проверка поиска, ответа, цитат, отказа и соблюдения прав на версионируемом наборе вопросов с ожидаемыми источниками.
Когда это важно
- Демо отвечает убедительно, но качество неизвестно.
- Меняются модель, chunking или корпус.
- Система должна перейти к пользователям.
Как принять решение
| Ситуация | Что проверяем | Решение |
|---|---|---|
| Источник не найден | Корпус, запрос, chunking и ранжирование | Исправлять retrieval |
| Источник найден, ответ неверен | Контекст, инструкция и генерация | Исправлять answer layer |
| Оснований нет | Порог достаточности и отказ | Требовать уточнение или отказ |
Порядок работы
- Набор. Собрать частые, сложные, конфликтные и безответные вопросы.
- Ожидания. Указать источники, допустимые ответы и критичные ошибки.
- Прогон. Сохранять версию корпуса, модели и конфигурации.
- Разбор. Оценить классы ошибок и регрессию после изменений.
Типичные ошибки
- Оценивать только вручную выбранные вопросы.
- Смешивать качество поиска и генерации.
- Не тестировать запрет доступа и корректный отказ.
Практические рекомендации
- Храните независимый holdout-набор.
- Показывайте качество по классам риска.
- Проверяйте цитаты автоматически и выборочно вручную.
Вывод: RAG готов к работе, когда его ошибки измеримы, источники проверяемы, а регрессия видна до пользователя.
Частые вопросы
Какая метрика главная?
Зависит от цены ошибки; часто нужны recall источника и доля поддержанных утверждений.
Можно оценивать LLM?
Да как вспомогательный судья после проверки согласованности с экспертами.
Как тестировать права?
Вопросы прогоняются от ролей с разным доступом, включая попытки получить запрещённый контент.