RAG Metrics

Метрики качества RAG — «дашборд» из ~12 измеримых показателей с целевыми порогами для продакшена, разбитых на 3 группы: Retrieval (нашли ли), Generation (хорошо ли ответили), End-to-End. Без них нельзя отличить рабочую систему от демо. Это продакшен-уровень поверх простых эвристик из Agent Evals.

Суть

Простых эвристик (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-метрики здесь