Метрики качества RAG: recall, faithfulness и релевантность
Продвинутое3 минРедакция Innovialabs
Коротко
Оценивайте RAG в два слоя: метрики поиска (recall@k, MRR) показывают, нашёлся ли нужный контекст, а метрики генерации (faithfulness, answer relevance) — правильно ли модель им воспользовалась. Разделение сразу показывает, где искать проблему.
Коротко: почему метрики нужно разделять
RAG состоит из двух частей: поиска (retrieval) и генерации (LLM). Плохой ответ может появиться по двум разным причинам: нужный документ не нашёлся или модель его нашла, но исказила. Одна общая оценка «ответ хороший/плохой» не говорит, что чинить.
Поэтому метрики считают по слоям: сначала качество найденного контекста, затем качество ответа относительно этого контекста.
Метрики поиска
Для них нужен тестовый набор: вопрос и список документов (или чанков), которые действительно содержат ответ.
| Метрика | Что показывает |
|---|---|
| Recall@k | Есть ли хотя бы один нужный документ в топ-k |
| Precision@k | Какая доля из топ-k действительно релевантна |
| MRR | Насколько высоко стоит первый правильный документ |
| nDCG@k | Качество ранжирования с учётом степени релевантности |
| Context precision | Много ли «шума» попало в контекст для LLM |
Пример подсчёта recall@k и MRR:
def recall_at_k(retrieved, relevant, k):
return int(any(doc in relevant for doc in retrieved[:k]))
def reciprocal_rank(retrieved, relevant):
for i, doc in enumerate(retrieved, start=1):
if doc in relevant:
return 1 / i
return 0.0
Средние значения по всему тестовому набору — это ваши recall@k и MRR.
Метрики генерации
Здесь оценивается ответ модели:
- Faithfulness (верность контексту) — все ли утверждения ответа подтверждаются найденными фрагментами. Низкое значение означает галлюцинации.
- Answer relevance — отвечает ли ответ на заданный вопрос, а не на соседний.
- Correctness — совпадает ли ответ с эталонным, если эталон есть.
- Citation accuracy — ссылается ли модель на те фрагменты, откуда взяла факт.
Как считать метрики генерации
Ручная разметка надёжна, но дорога. На практике используют LLM-as-a-judge:
- Разбейте ответ на отдельные утверждения.
- Для каждого спросите модель-судью: подтверждается ли оно контекстом? Ответ — да или нет.
- Faithfulness = доля подтверждённых утверждений.
Чтобы судье можно было доверять:
- Дайте ему чёткие критерии и бинарные решения вместо шкалы от 1 до 10.
- Проверьте его на небольшой выборке, размеченной людьми, и посмотрите, насколько оценки совпадают.
- Используйте фиксированный промпт и модель, иначе результаты разных прогонов несравнимы.
Существуют готовые библиотеки для оценки RAG, но логику метрик стоит понимать самостоятельно, чтобы правильно читать результаты.
Диагностика: где именно сбой
| Recall поиска | Faithfulness | Вероятная причина | Что делать |
|---|---|---|---|
| Низкий | Любой | Нужный контекст не находится | Чанкинг, эмбеддинги, гибридный поиск |
| Высокий | Низкий | Модель выдумывает поверх контекста | Промпт, инструкции цитировать, другая модель |
| Высокий | Высокий, но ответ не по теме | Плохая answer relevance | Переписывание запроса, промпт |
| Высокий, но низкий context precision | Падает | Слишком много шума в контексте | Реранкер, меньше k |
Как построить процесс оценки
- Соберите тестовый набор из реальных вопросов пользователей, включая сложные и «без ответа».
- Добавьте вопросы, на которые система должна честно сказать «не знаю».
- Запускайте оценку при каждом изменении: модели, промпта, чанкинга, поиска.
- Меняйте одну вещь за раз, иначе не поймёте, что повлияло.
- Читайте плохие примеры глазами — цифры показывают где, а примеры — почему.