Почему RAG нужно оценивать по слоям

Если проверять только финальный ответ, невозможно понять, где появилась ошибка: нужный документ не нашли, выбрали плохой chunk или модель неверно использовала хороший контекст. Поэтому retrieval и generation нужно оценивать отдельно.

Golden dataset

Соберите набор реальных вопросов с ожидаемыми источниками и эталонными фактами. Для каждого кейса храните query, релевантные документы, допустимые ответы и важные негативные примеры.

Метрики retrieval

Минимальный набор: recall@k, precision@k, MRR или nDCG. Для production полезно также измерять долю запросов, где нужный источник вообще попал в top-k.

Context relevance

Даже если правильный документ найден, лишние chunks увеличивают шум. Оценивайте, сколько переданного контекста реально помогает ответить на вопрос, и следите за token budget.

Faithfulness

Ответ должен опираться на переданный контекст. Проверяйте, подтверждается ли каждое ключевое утверждение retrieved sources и не добавляет ли модель неподтверждённые факты.

Answer correctness

Отдельно измеряйте, насколько ответ решает задачу пользователя. Здесь полезны deterministic checks, domain rules, human review и LLM-as-a-judge с фиксированной rubric.

Hard negatives

Добавляйте похожие, но неправильные документы. Они показывают, умеет ли retriever различать близкие сущности, версии продукта, даты и конфликтующие источники.

Chunking и reranking

Сравнивайте chunk size, overlap, embedding model, hybrid search и reranker как независимые параметры. Меняйте один фактор за раз и сохраняйте результаты экспериментов.

Проверяйте свежесть

Для меняющихся данных golden set должен содержать timestamp и expected source version. Иначе система может показывать хороший offline score на устаревших документах.

Production metrics

Логируйте query, retrieved document IDs, rank/score, token counts, latency, model version и citations. Это связывает offline evals с реальными инцидентами.

Regression gates

Перед релизом задайте минимальные thresholds: например, recall@k не падает, faithfulness выше целевого уровня, p95 latency и cost остаются в бюджете.

Практический checklist

  • Golden queries из production.

  • Expected source IDs и факты.

  • Retrieval metrics отдельно от generation.

  • Hard negatives.

  • Faithfulness и answer correctness.

  • Эксперименты chunking/reranking.

  • Freshness checks.

  • Cost и latency.

  • Regression suite в CI.

  • Трассировка источников в production.

Вывод

Хорошая RAG evaluation показывает не только, правильный ли ответ, но и почему он получился. Разделение retrieval, context quality и generation превращает RAG из непрозрачной демо-системы в управляемый production pipeline.