Главное
Не сводите оценку RAG к мнению «ответ выглядит хорошо». Сначала проверьте retrieval на эталонных вопросах, затем grounding и цитаты, после — полезность ответа, отказ при нехватке данных и permission-тесты. Каждый слой должен иметь отдельную причину ошибки.
У RAG есть неприятная особенность: красивый ответ может скрывать сразу несколько разных ошибок. Нужный документ не найден, найден не тот фрагмент, ответ опирается не на контекст, цитата ведёт не туда, а доступы нарушены. Если всё это свести к общему впечатлению «выглядит нормально», система будет деградировать незаметно.
Поэтому оценка RAG должна разделять retrieval, grounding, citations, usefulness и access control. Такой подход поддерживается и техническими рекомендациями NIST по generative AI, и практикой production-RAG систем.
Сначала проверяйте retrieval
Если нужный документ не попал в top-k, дальнейшая оценка стиля ответа мало что даст. На этом слое полезен небольшой эталонный набор вопросов с ожидаемыми источниками и ручная проверка попадания фрагмента.
В корпоративных знаниях часто важнее не abstract relevance, а попадание в один разрешённый и актуальный документ. Поэтому recall и reviewed passage hit обычно полезнее, чем усреднённая метрика по всем текстам.
Grounding и citations — отдельные проверки
Даже правильный retrieved chunk не гарантирует корректный ответ. Модель может додумать шаг, склеить две версии инструкции или указать ссылку на соседний, но недостаточный источник. Проверяйте утверждения по пунктам: что именно сказано, где это подтверждается и достаточно ли доказательства для бизнес-задачи.
- Ответ подтверждается найденным контекстом, а не общей вероятностью модели.
- Цитата ведёт на тот же источник и тот же смысловой фрагмент.
- При нехватке данных система отказывается или явно маркирует неполноту ответа.
Полевой пример: контрольный прогон из 100 вопросов
В RAG-помощнике ГрГМУ мы использовали зафиксированный набор из 100 вопросов и экспертную рубрику качества. В одном датированном контрольном прогоне 99 ответов получили оценку «отлично», один — «хорошо», проблемных ответов не было.
Эти числа описывают только конкретную версию базы, конфигурации и набора. Это не «99% accuracy» модели и не гарантия для будущих вопросов. Полезное доказательство здесь — воспроизводимая процедура: сохранить вопросы, разрешённые источники, роли, версии компонентов, оценки и причины ошибок, а затем повторить прогон после изменения retrieval, prompt, модели или данных.
- Не переносить результат одного набора на все пользовательские запросы.
- Публиковать распределение оценок и критические ошибки, а не только среднее.
- Добавлять новые реальные ошибки в versioned regression-набор.
Критическая ошибка не должна растворяться в среднем score
Для production-RAG полезно иметь release gate: утечка доступа, неверная цитата в чувствительном процессе или уверенный ответ без доказательств должны блокировать релиз независимо от общего среднего балла. Именно так оценка остаётся инженерным инструментом, а не витриной для демо.
Сравнение
Минимальная карта оценки RAG
| Слой | Вопрос | Практический сигнал |
|---|---|---|
| Retrieval | Найден ли нужный источник? | Recall@k или ручная проверка попадания |
| Grounding | Подтверждается ли ответ контекстом? | Pass/fail по утверждениям |
| Citation | Ведёт ли ссылка к нужному фрагменту? | Точность и полнота цитат |
| Usefulness | Решает ли ответ задачу пользователя? | Рубрика или парное сравнение |
| Access | Не попал ли запрещённый источник? | Permission test по ролям |
Что проверить
Как собрать контрольный набор
- Включить частые, редкие, неоднозначные и устаревшие вопросы.
- Для каждого вопроса указать допустимые источники и ожидаемый отказ.
- Отдельно добавить запросы без ответа в базе знаний.
- Проверить роли с разными правами на один и тот же вопрос.
- Повторять набор после изменения chunking, индекса, модели или prompt.
Как мы подходим к задаче
CENTURY сначала исправляет retrieval и доступы. Настройка стиля ответа не компенсирует неверный документ, а общий score не должен скрывать утечку прав или ошибочную цитату.