Точность RAG и галлюцинации: как измерять

Точность RAG — это не одна цифра, а цепочка проверок: корпус содержит верную и действующую информацию; retrieval находит нужное; ответ опирается на evidence; цитаты подтверждают claims; итог решает задачу без критической ошибки.

«Галлюцинация» без операционного определения плохо измеряется. Для RAG полезно разделить: unsupported claim, contradicted claim, wrong citation, missing material fact, stale source, no-answer failure и wrong action. Тогда понятно, что чинить — corpus, retrieval, prompt/model, policy или tool.

Короткий ответ: соберите frozen query set с gold sources, expected facts, acceptable abstention и severity. Отдельно измерьте source correctness, retrieval recall/precision/rank, claim faithfulness, citation entailment, completeness, task outcome и critical failures. Automated/LLM judges сначала сравните с human labels. Публикуйте не среднее, а breakdown по intent, source, language, difficulty и risk.

Главное за минуту

Faithfulness — поддержка context, а не гарантия истины source.
Retrieval recall отвечает, нашли ли нужное; precision — сколько шума принесли.
Цитата проверяется на entailment каждого material claim.
Полный ответ может быть неверным; faithful — неполным.
LLM-as-judge нуждается в calibration, versioning и disagreement review.
Критическая выдумка может блокировать release при хорошем среднем.
Offline eval дополняется production traces, drift и feedback.

Метод ОПОРА

О — Образцы вопросов: representative queries, expected facts, gold evidence и severity.
П — Поиск: corpus correctness, recall, precision, rank и access.
О — Опора на evidence: claims, entailment, contradiction, citations и abstention.
Р — Результат: completeness, relevance, task/action outcome и user review.
А — Аудит: calibrated judges, versions, thresholds, vetoes, monitoring и release decision.

Набор для оценки

Query card хранит intent, audience, language, date, difficulty, required/forbidden facts, gold source IDs/spans, acceptable answer/abstention, critical error и split. Включите common, rare, multi-hop, ambiguous, no-answer, stale, conflicting, unauthorized, scanned и adversarial cases.

Выделите development, validation и holdout. Не исправляйте pipeline по ответам holdout. При изменении corpus обновляйте gold через owner review, а не молча.

Корпус и источники

До retrieval проверьте: authoritative source присутствует, актуален, не дублирован конфликтной версией, имеет metadata/ACL и корректно разобран. Faithful ответ по неверному источнику всё ещё опасен.

Измеряйте ingestion lag, parse/OCR defects, missing metadata, stale rate, ACL leak и source conflict coverage. Базовая архитектура — в статье о RAG-системе.

Retrieval

Recall@k = relevant retrieved / all relevant gold; Precision@k = relevant retrieved / k. Добавьте MRR/nDCG для rank, access correctness, evidence coverage и latency. Chunk-метка может быть сложной: важнее, нашёл ли retrieval минимальную evidence set для expected claims.

Разбивайте по query class/source/language/date. Общий recall может скрыть провал в таблицах или в свежих документах.

Claims, faithfulness и цитаты

Разбейте ответ на atomic claims. Для каждого: materiality, evidence span, entailed / contradicted / not_supported, citation correct и source authority. Faithfulness = supported claims / assessable claims, но отчёт должен показывать weighted вариант и critical unsupported claims.

Статья RAGAS разделяет context quality, faithful use контекста и generation quality. ARES также оценивает context relevance, answer faithfulness и answer relevance, используя небольшой human-annotated set для коррекции automated estimates.

Ответ и task outcome

Измерьте expected-fact coverage, relevance/directness, correct abstention, instruction compliance, format/schema и human usefulness. Для workflow добавьте correct classification/tool/action, accepted edit, rework и adverse outcome. RAG может быть faithful и не решить задачу, если пропустил важное или не соблюл schema.

Метрики Amazon Bedrock разделяют retrieve-only и retrieve-and-generate evaluation и включают completeness и faithfulness. Это пример декомпозиции, а не универсальный acceptance threshold.

LLM-as-judge

Зафиксируйте judge model/version, prompt, rubric, order/randomization, temperature, repeats, parse failures и cost. Сравните с human labels: agreement по classes/severity, false-pass на critical claims и confidence intervals. Disagreement queue разбирает expert.

Руководство AWS рекомендует комбинировать automated, model-based и human evaluation и прямо отмечает, что LLM-judge может ошибаться и быть смещённым.

Пороги и вето

Метрика имеет card: definition, unit, dataset/slice, scorer, uncertainty, threshold, owner и response. Задайте minimum retrieval/evidence/task scores и вето: ACL leak, invented critical fact, wrong high-impact citation, unsafe action или неверный authoritative version.

Пороги определяет risk owner по baseline и impact. Не копируйте чужой 0,8 без семантики метрики.

Production monitoring

Логируйте query/intent, corpus/index/retriever/reranker/prompt/model versions, retrieved IDs/scores, citations, claims, answer, latency/cost, feedback, handoff и outcome с допустимым redaction. Dashboard следит за no-answer, retrieval drift, unsupported/citation defects, critical events, source freshness и slice shifts.

Новая версия проходит frozen regression до rollout. Production-инцидент пополняет eval только после review и label.

Приёмка

Принимайте corpus/source registry; query set/gold/labels/splits; pipeline versions; retrieval traces; atomic claim matrix; automated judge calibration; human disagreement results; metric cards; thresholds/vetoes; raw run exports; slice reports; monitoring/alert/runbook и release decision.

Краткий отчёт не заменяет raw evidence. Если dataset и scorer нельзя воспроизвести, «точность» не принимается.

Частые вопросы

Чем faithfulness отличается от фактической точности?

Faithfulness проверяет опору claims на переданный context. Фактическая точность дополнительно требует, чтобы source был верным и применимым.

Какая метрика самая важная?

Зависит от failure. Если gold evidence не попала в top-k, чините retrieval. Если evidence есть, но claim не поддержан, чините generation/policy. Важнее всего critical outcome.

Можно ли обойтись без gold answers?

Частично: reference-free metrics ускоряют iteration. Но для калибровки, completeness, critical facts и release нужен проверенный human set.

Сколько вопросов нужно для eval?

Нет универсальной цифры. Покройте intents, sources, risk, language и difficulty, затем оцените uncertainty метрик и стабильность вывода.

Может ли LLM сама оценить галлюцинации?

Может быть judge, но не oracle. Версионируйте rubric/model, калибруйте на human labels и вручную разбирайте critical/disagreement cases.

Как часто перезапускать eval?

Перед каждым изменением corpus/parser/chunking/embedding/retriever/reranker/prompt/model/tool и по расписанию для drift. Критический инцидент также запускает regression.

Как AI рассвет измеряет качество RAG

AI рассвет может обследовать corpus и pipeline, собрать query/gold set, настроить retrieval, claim/citation, answer/task и guardrail metrics, калибровать automated judges, провести error analysis, доработать RAG, внедрить regression, monitoring, приёмку и поддержку.

Безопасный первый шаг — выбрать один intent и source family, зафиксировать representative queries, gold evidence, expected facts, acceptable abstention, current pipeline/version и critical unsupported claim, затем провести human baseline. Обсудить задачу.

Вывод

Не спрашивайте «какая точность RAG?» без metric contract. ОПОРА связывает образцы, поиск, evidence, результат и аудит. Это показывает не только score, но и место поломки.

Сначала проверяйте источник и retrieval, затем claims/citations и task outcome. Калибруйте автоматику на human labels, учитывайте severity и не позволяйте среднему скрывать критическую выдумку.