Оценка качества RAG: retrieval metrics, faithfulness, citations и regression CI

Почему одна метрика не описывает RAG

Неверный ответ может появиться потому, что документ не загрузился, parser потерял таблицу, ACL отфильтровал источник, retriever не нашёл chunk, reranker опустил его, prompt проигнорировал контекст или модель придумала факт.

Средний «RAG score» не показывает слой отказа. Полезная оценка строится как воронка с отдельными доказательствами.

Карта RAG evaluation: от источника до результата

Шаг 1. Определите success contract и цену ошибки

До метрик опишите задачу: lookup одного факта, multi-hop comparison, policy answer или summary. Разные вопросы требуют разных источников и критериев.

Use case: [название]
User intent classes: [список]
Authoritative sources: [иерархия]
Required facts/answer properties: [критерии]
Critical errors: [hard limits]
Allowed abstention: [когда]
Citation requirements: [уровень]
Access-control requirements: [scope]
Latency and token budget: [SLO]
Task success and human review: [метрики]

Шаг 2. Постройте ground truth, пригодный для диагностики

Пара query/answer недостаточна. Чтобы оценить retrieval, нужны релевантные документы или chunks; чтобы оценить generation - обязательные факты и допустимые формулировки. Для нескольких корректных источников храните множество acceptable evidence.

Document-level и chunk-level relevance - разные задачи

Эксперт часто знает правильный документ, но не конкретный chunk, потому что chunking ещё меняется. Храните source spans или semantic evidence отдельно от текущих chunk IDs, затем отображайте их на versioned index.

Ingestion evaluation: нужный ответ мог не попасть в индекс

До retrieval проверьте completeness и качество парсинга. Сэмплируйте PDF, таблицы, OCR, списки, headers и metadata. Сравнивайте извлечённый текст с source.

ACL evaluation: правильный ответ не должен нарушать доступ

Высокий recall опасен, если retriever находит чужой документ. Security metrics являются hard gates и не усредняются с качеством.

Recall@k: найден ли хотя бы один необходимый источник

Recall@k измеряет долю релевантных items, попавших в первые k результатов. Для lookup иногда достаточно hit rate: найден ли любой допустимый source. Для multi-hop важна coverage всех required evidence.

Recall@k = relevant retrieved in top-k / all relevant items
Hit@k = 1, если хотя бы один required item найден
Evidence coverage@k = required facts supported by top-k / all required facts
Считайте macro average по queries и отдельно по cohorts.
Не сравнивайте числа при разных definitions ground truth.

Precision@k и context relevance: сколько шума передано модели

Увеличение k повышает шанс найти нужное, но добавляет нерелевантный текст, токены и конкурирующие факты. Precision@k - доля релевантных результатов в top-k. LLM-based context relevance оценивает семантическую полезность, но требует валидированного grader.

MRR и nDCG: насколько высоко находится полезный результат

Mean Reciprocal Rank чувствителен к позиции первого релевантного item: полезен для вопросов с одним ключевым источником. nDCG учитывает graded relevance и позиции нескольких результатов: подходит, когда chunks бывают частично и полностью полезными.

• Определите relevance grades в annotation guide.
• Считайте по query, затем агрегируйте.
• Показывайте distribution, а не только mean.
• Не используйте MRR для полноты multi-hop evidence.
• Не сравнивайте ranking при разном candidate pool без оговорки.

Chunking evaluation: тестируйте не размер, а сохранение смысла

Сравните fixed-size, structure-aware и parent-child варианты на одном ground truth. Измеряйте retrieval, context tokens и downstream answer. Хороший chunk содержит достаточный evidence и сохраняет metadata.

Hybrid search, filters и reranker: проводите ablation

Если одновременно сменить embeddings, chunking, top-k и reranker, нельзя понять источник улучшения. Ablation изменяет один компонент и фиксирует остальные.

Baseline: index A + dense retrieval + k=5.
Candidate 1: только hybrid dense+keyword.
Candidate 2: baseline + metadata filters.
Candidate 3: baseline + reranker.
Candidate 4: best retrieval + context packing.
Для каждого: Recall@k, Precision@k, MRR/nDCG,
evidence coverage, context tokens, P95 latency, cost,
ACL violations и downstream task success.

Generation correctness и completeness

Correctness сравнивает утверждения с ground truth/authoritative evidence. Completeness проверяет, покрыты ли все аспекты вопроса. Короткий верный ответ может быть неполным; полный - содержать ошибку.

Faithfulness: поддержан ли ответ retrieved context

Faithfulness отвечает не на вопрос «истина ли это вообще», а на вопрос «следует ли утверждение из переданного контекста». Ответ может faithfully повторить устаревший документ и всё равно быть business-неверным. Поэтому нужны freshness и source authority.

Citation precision, coverage и entailment

Citation precision проверяет, действительно ли cited passage поддерживает утверждение. Coverage - все ли требующие доказательства claims имеют citation. Отдельно проверяйте корректность URL, document ID и access.

Abstention: хороший RAG умеет не отвечать

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

Supported: все required facts имеют authoritative evidence.
Partially supported: ответить только доказанную часть и назвать пробел.
Conflicting: показать конфликт sources и запросить правило/уточнение.
Insufficient: явно сообщить, каких данных нет.
Out of scope: не отвечать из общих знаний, если policy требует corpus.
Оцени false answer rate и false abstain rate отдельно.

LLM judge: полезный измеритель, но не ground truth

Версионируйте evaluator model, prompt, rubric и output schema. Сравните judge с экспертами на calibration set, особенно для critical cohorts. Проверьте position bias, verbosity bias и влияние reference answer.

• Кодом проверяйте то, что проверяется кодом.
• Используйте несколько независимых критериев.
• Храните explanation для review, но не считайте её доказательством.
• Сэмплируйте disagreements на adjudication.
• После смены judge выполните backtest.
• Не используйте candidate model как единственного судью самой себя.

End-to-end task success и человеческая коррекция

Пользователю нужен не высокий recall, а решённая задача. Финальные метрики: принял ли эксперт ответ, сколько исправлял, нашёл ли источник, завершил ли workflow и не произошло ли вредное действие.

Failure taxonomy: метрика должна вести к исправлению

Каждый production incident добавляет regression case с label и owner соответствующего слоя.

Regression CI и release gates

На PR запускайте быстрый слой; nightly - полный dataset; при смене index/model - paired candidate comparison. Hard gates ACL и critical errors не компенсируются средним улучшением.

Versions: corpus/parser/chunker/embedding/index/retriever/reranker/prompt/model.
Dataset and grader versions.
By cohort:
- ingestion coverage/freshness;
- Recall/Precision@k, MRR/nDCG;
- evidence coverage and context tokens;
- correctness/completeness/faithfulness;
- citation precision/coverage;
- false answer/false abstain;
- task success, P95 latency, cost/success.
Critical failures and decision: ship/canary/stop.

Production monitoring: lineage и sampling

Trace связывает query с index version, filters, retrieved IDs/scores, reranker, context, model, citations, validators и user outcome. Content логируется только по privacy policy.

Итоговый чек-лист оценки RAG

Хорошая RAG-оценка не выдаёт один красивый балл. Она отвечает, где потерялось доказательство и какое изменение проверить следующим.