# Оценка качества RAG

> Оценка RAG: метрики ретривера и генератора по отдельности, faithfulness, context precision — что мерить на собеседовании.

Раздел: [RAG: поиск + генерация](https://ml-book.com/s/rag/) · Страница темы: https://ml-book.com/t/rag-eval/ · Обновлено: 2026-09-16 · Источник: ml-book.com, учебник делается сообществом

## Интуиция

Ответ RAG-системы плох. Почему? Вариантов ровно два: либо поиск не принёс нужный фрагмент (генератору не из чего отвечать — он честно скажет «не знаю» или, хуже, нафантазирует), либо фрагмент пришёл, а модель им не воспользовалась или переврала. Это разные болезни с разным лечением: первую чинят чанкингом, моделью эмбеддингов и гибридным поиском, вторую — промптом, выбором LLM и форматом контекста. Единая метрика «хороший ответ / плохой ответ» смешивает обе болезни в кашу.

## Метрики ретривера

Для оценки поиска нужен золотой сет (golden set): пары «вопрос → релевантные чанки», размеченные руками. Дальше считаем:

- **Recall@k** — главная метрика: доля вопросов, для которых релевантный чанк попал в топ-k выдачи. Если его нет в контексте, генератор бессилен.
- **Precision@k** — какая доля из k подтянутых чанков действительно релевантна: показывает, сколько мусора едет в контекст.
- **MRR** (mean reciprocal rank) и **nDCG** — учитывают позицию: релевантный чанк на первом месте ценнее, чем на пятом.

`recall@k = (вопросы, где релевантный чанк в топ-k) / (все вопросы)`

## Метрики генерации

- **Faithfulness / groundedness** — опирается ли ответ на переданный контекст или содержит выдуманные утверждения. Именно эта метрика ловит галлюцинации.
- **Answer relevance** — отвечает ли текст на заданный вопрос (можно быть верным контексту, но отвечать не о том).
- **Полнота** — использованы ли все нужные факты из контекста.

Считать их руками дорого, поэтому применяют [LLM-as-judge](https://ml-book.com/t/llm-evals/): сильная модель сверяет каждое утверждение ответа с контекстом. Помни про её систематические ошибки (biases): любовь к длинным ответам, позиционные предпочтения, снисходительность к «своим» текстам. Готовые фреймворки — RAGAS и подобные, но многие команды пишут своих судей: свой домен — свои критерии.

> **💡 Ключевая мысль**
>
> Если ответ плох — сначала смотри retrieval. По опыту большинство провалов RAG — это «нужного чанка не было в контексте», а не «модель плохо сгенерировала».

> 🎛 Интерактивная визуализация — на странице темы: https://ml-book.com/t/rag-eval/

Прогони eval при k=1: recall 40%, и faithfulness ровно такой же — там, где поиск принёс не тот чанк (Q2 нашёл «Обмен товара» вместо «Возврата»), модель уверенно галлюцинирует. Подними k до 3 — recall 100%, галлюцинации исчезли *сами*, хотя генератор никто не трогал. А теперь k=5: recall остался 100%, но faithfulness просел — в контекст Q4 заехал устаревший чанк «Оплата (архив 2019)», и генератор цитирует отменённые правила. Узкое место сместилось с retrieval на generation.

## Процесс: регрессии и онлайн-сигналы

Оффлайн-оценку гоняют как регрессионные тесты — при *каждом* изменении пайплайна: поменяли чанкинг, модель эмбеддингов, промпт, версию LLM — прогнали золотой сет, сравнили метрики с прошлым запуском. Без этого улучшение одного куска незаметно ломает другой: например, более крупные чанки подняли faithfulness, но уронили recall.

В проде добавляются онлайн-сигналы: явный фидбек пользователей (лайки/дизлайки), доля ответов «не знаю», доля эскалаций на человека, повторные переформулировки одного и того же вопроса. Рост доли «не знаю» при стабильном трафике — типичный ранний симптом деградации ретривера: например, в базу залили документы нового формата, которые чанкер режет в кашу.

> **⚠️ Подводный камень**
>
> End-to-end метрика «доля хороших ответов» без покомпонентной разбивки — ловушка: она говорит, ЧТО стало хуже, но не ГДЕ. Команды неделями крутят промпт генератора, когда на самом деле ретривер не находит нужные чанки. Сначала recall@k ретривера, потом faithfulness генератора — в этом порядке.

> **🎤 На собеседовании**
>
> - «Как оценить качество RAG-системы?» — раздельно: ретривер (recall@k, precision@k, MRR/nDCG на золотом сете) и генератор (faithfulness, answer relevance через LLM-as-judge).
> - «Ответы плохие — что проверишь первым?» — retrieval: чаще всего нужного чанка просто нет в контексте.
> - «Что будет, если сильно увеличить k?» — recall вырастет, но в контекст поедет мусор: faithfulness и точность ответов могут упасть, латентность и стоимость вырастут.
> - «Какие проблемы у LLM-as-judge?» — предпочтение длинных ответов, позиционный bias, снисходительность к текстам похожего стиля; лечится калибровкой на человеческой разметке.

## Связанные темы

- [Что такое RAG и зачем он нужен](https://ml-book.com/t/rag-basics/)
- [Гибридный поиск и реранкинг](https://ml-book.com/t/hybrid-rerank/)
- [Чанкинг и подготовка данных](https://ml-book.com/t/chunking/)
- [Эмбеддинг-модели: как их обучают](https://ml-book.com/t/embedding-models/)

---

Интерактив, тест из 12 вопросов и карточки терминов — на странице темы: https://ml-book.com/t/rag-eval/
Весь учебник в markdown: https://ml-book.com/llms-full.txt · Оглавление для агентов: https://ml-book.com/llms.txt