Суть
Простых эвристик (has_citations, answer_grounded) хватает для первого агента, но в проде нужны статистические пороги. Главное правило: начни с Hit Rate — если документы не находятся, остальные метрики бессмысленны.
Зачем это нужно
Каждая фаза дорожной карты RAG (см. RAG) сопровождается замером: не переходи к следующей технике, пока текущие метрики не достигли порога. Галлюцинации — главная проблема RAG в проде, их ловит Faithfulness.
Как работает (RAG Quality Dashboard)
Retrieval (поиск):
- Hit Rate @ K ≥ 0.85 — доля запросов, где релевантный документ в топ-K (recall).
- MRR ≥ 0.75 — средний обратный ранг первого релевантного.
- NDCG @ K ≥ 0.70 — качество ранжирования с учётом позиции.
Generation (генерация):
- Faithfulness ≥ 0.85 — доля утверждений ответа, подтверждённых контекстом (метрика галлюцинаций).
- Answer Relevancy ≥ 0.80 — соответствие ответа вопросу.
- Answer Correctness ≥ 0.75; Toxicity ≤ 0.05.
End-to-End:
- Context Precision ≥ 0.70, Context Recall ≥ 0.80, Context F1 ≥ 0.75.
- Noise Robustness ≥ 0.90 — устойчивость к нерелевантным данным в контексте.
Операционные: P95 Latency < 3 c, Retrieval < 200 мс, TTFT < 500 мс.
Инструменты: RAGAS (стандарт де-факто, оценка LLM-судьёй без ground truth, автогенерация eval-датасета), DeepEval, RAGChecker (Amazon, NeurIPS'24 — диагностика на уровне отдельных утверждений), TruLens; observability — Arize Phoenix, LangSmith, Langfuse (сами практики online-трейсинга retrieval — в RAG Observability). Практика: eval-датасет 50-200 вопросов с GT, offline-eval в CI/CD (~$0.05-0.20 за запрос на GPT-4o-судье, можно локальной моделью).
Пример
Две базовые retrieval-метрики на эталонном (golden) наборе {question, relevant_doc, retrieved_docs}: Hit Rate@K (попал ли релевантный документ в топ-K) и MRR (обратная позиция первого релевантного).
def compute_metrics(results, k=3):
mrr, hits = [], []
for r in results:
topk = r["retrieved_docs"][:k]
if r["relevant_doc"] in topk:
mrr.append(1.0 / (topk.index(r["relevant_doc"]) + 1)) # 1 / позиция первого релевантного
hits.append(1)
else:
mrr.append(0.0); hits.append(0)
return {"MRR": sum(mrr) / len(mrr), "HitRate@K": sum(hits) / len(hits)}
Контракт RAG-пайплайна: пороги на каждой ступени
Метрики полезны, когда на них навешены решения. Разбор по безопасности превращает набор метрик в контракт: на каждой ступени пайплайна задан порог, ниже которого следующий шаг не выполняется.
rewrite → исходный вопрос едет рядом с переписанным
(переписывание в одиночку теряет смысл оригинала)
synonym expansion → синонимы только из доменного словаря, не свободная генерация
metadata filter → фильтр по метаданным ДО векторного поиска, а не после
vector search → score_threshold ≥ 0.7; ниже — честный ответ «нет подходящих чанков»
grade before generate → faithfulness ≥ 0.8 · relevancy ≥ 0.7
ниже порога — уточняющий вопрос пользователю, НЕ генерация
Логика в том, что ошибки предыдущих ступеней доезжают до генерации и там становятся уверенной галлюцинацией. Низкий порог поиска пропускает мусор, на котором модель отвечает уверенно и неправильно.
Ключевая формулировка: grade before generate. Оценка faithfulness и relevancy делается по найденному контексту до того, как модель начала писать ответ, — иначе метрика превращается в посмертную статистику вместо гейта.
Отказ здесь тоже спроектирован: не «извините, ошибка», а уточняющий вопрос. Пользователь получает шанс переформулировать, а система не тратит вызов на заведомо плохой контекст (см. Agentic RAG).
Таксономия галлюцинаций: два класса чинятся разным
Слово «галлюцинация» покрывает два разных отказа, и метрики у них разные:
- Галлюцинации верности (Faithfulness) — несоответствие переданному контексту, логическое противоречие, выдумывание фактов сверх контекста. Приоритет номер один в корпоративном RAG. Чинится grounding-инструкцией, качеством поиска и проверкой на выходе; ловится метрикой Faithfulness.
- Галлюцинации фактичности (Factuality) — противоречие фактам внешнего мира, выдумывание несуществующих сущностей. Чинится подключением внешнего источника, а не настройкой промпта, и метрикой Faithfulness не ловится вообще: точный пересказ неверного документа даёт по ней единицу.
Практическое следствие: высокая Faithfulness не означает, что система говорит правду. Она означает, что система не отклоняется от того, что нашла (RAG Poisoning).
Чем считать: что брать на старте
Все три инструмента считают примерно одно и то же, различаются входным требованием и охватом.
RAGAS — вход с наименьшим трением: работает без ground truth, оценивая faithfulness и relevancy судьёй, и умеет сгенерировать eval-датасет из корпуса. Именно поэтому он обычно первый: размеченного набора на старте нет ни у кого.
DeepEval берут, когда оценивать надо не ответ, а поведение агента — Task Completion, Tool Correctness, Argument Correctness (DeepEval Agentic Metrics). То есть переход к нему происходит не «вместо RAGAS», а когда система из RAG превратилась в агента с инструментами.
RAGChecker уместен на разборе, а не на регрессии: он разбирает ответ на утверждения и показывает, какое из них не подтверждено, — это диагностика причины, а не число для гейта.
Практический порядок: начать с RAGAS ради датасета и двух базовых метрик, добавить агентные метрики, когда появятся инструменты, и подключать поутверждённый разбор точечно, когда непонятно, почему упала faithfulness.
Пороги для русскоязычного домена
Отдельных «русских» порогов метрик не существует, и это не пробел разборов, а свойство метрик: Recall@k и MRR считаются одинаково на любом языке, а язык влияет на достижимость значения через качество эмбеддингов и нарезки, а не на само определение метрики.
Ориентиры, называемые в русскоязычных практических разборах (2026): Recall@10 выше 0.85, MRR выше 0.5. Прирост от гибридного поиска — порядка 10-20% к Recall@10, от реранкинга — 15-25% (Hybrid Search, Reranking). Числа согласуются с общими ориентирами выше, то есть отставания русского домена как такового они не показывают.
Важнее порогов — разбивка. Главное предостережение из русскоязычной практики: можно сохранить почти всю выдачу исходного эмбеддера и всё равно плохо находить нужное на своём домене, потому что один средний скор прячет поломку в критичном срезе. Поэтому набор для замера собирают срезами, а не как однородный список: точные сущности, перефразировки, длинные разделы, таблицы, разные версии документов, вопросы без ответа в корпусе, плохо сформулированные запросы, чувствительные сценарии.
Практический размер такого набора — 100-300 кейсов, собранных из разных источников, а не сгенерированных: обезличенные реальные обращения, документация и changelog, интервью с экспертом предметной области, и лишь небольшая доля синтетики после ручной вычитки. Это тот же набор, что используется для эвалов агента (Agent Evals), и собирать его дважды не нужно.
Как устроены две базовые метрики изнутри
Пороги выше применяются к числам, механику которых полезно понимать — иначе непонятно, что именно упало.
Faithfulness — доля утверждений ответа, подтверждённых переданным контекстом:
Faithfulness = |V| / |S|
где S — все утверждения, на которые разобран ответ, V — подмножество, выводимое из контекста. Отсюда два следствия. Первое: метрика ничего не говорит о правдивости ответа во внешнем мире — она измеряет верность контексту, и ответ, точно пересказавший неверный документ, получит единицу. Второе: длинный многословный ответ проседает по метрике легче короткого, потому что каждое лишнее утверждение попадает в знаменатель.
Answer Relevancy считается обратным ходом: по сгенерированному ответу модель порождает N вопросов, на которые он мог бы отвечать, и метрика — среднее косинусное сходство этих вопросов с исходным. Механика объясняет, что именно метрика ловит: ответ не по теме и ответ-уклонение дают вопросы, непохожие на заданный, даже если текст грамотный.
Два набора порогов, и они расходятся — это не ошибка, а разные роли.
| Источник | Faithfulness | Context Recall | Назначение |
|---|---|---|---|
| Профильный разбор оценки RAG (выше в этой заметке) | ≥ 0,85 | ≥ 0,80 | Рабочий ориентир: ниже — систему нельзя показывать пользователю |
| Архитектурный конспект (издание для рынка РФ) | ≥ 0,95 в проде, шлюз в CI/CD ≥ 0,90 | ≥ 0,85 | Требование корпоративного заказчика в регулируемом контуре |
Расхождение сверено 2026-08-23 кросс-запросом по блокноту «AI»: профильный разбор по RAG действительно ставит 0,85 и 0,80, конспект — 0,95 и 0,85. Ни один из наборов не отменяет другой, но подставлять их вслепую нельзя.
Практическое правило выбора: порог задаётся ценой ошибки в вашем домене, а не переносится из чужого материала. Более жёсткий набор оправдан там, где неверный ответ имеет юридические или финансовые последствия; более мягкий — там, где ответ проверяет человек. Разница между продовым ориентиром и порогом шлюза в обоих наборах намеренная: шлюз ловит регрессию, а не гарантирует целевое качество (Agent Evals).
Связано с
Overreliance — ссылки берутся из метаданных поиска, а не из текста модели
RAG — метрики измеряют каждую фазу RAG-конвейера
Agent Evals — простые мини-метрики агента vs полный RAG-дашборд
Reranking — реранкинг оптимизируют именно по этим метрикам
RAG Observability — online-трейсинг retrieval (дополняет offline-метрики этой заметки)
DeepEval Agentic Metrics — агентный угол DeepEval (Task/Tool/Argument Correctness) vs RAG-метрики здесь