Оценка RAG: метрики retrieval, groundedness и качества ответа

Надёжная оценка RAG отвечает как минимум на три разных вопроса: нашёл ли retriever нужные доказательства, опирается ли ответ на полученный контекст и решает ли он задачу пользователя. Один агрегированный score скрывает причину сбоя. Высокая groundedness не помогает, если система точно пересказывает нерелевантный chunk, а правильный ответ не доказывает качество retrieval, потому что модель могла воспроизвести факт из параметрической памяти.

Стройте eval как диагностическое дерево. Сначала фиксируйте версию corpus, query, разрешённые документы и labels релевантности. Затем сохраняйте retrieved IDs, ranks и тексты, и только после этого — ответ, citations и verdicts graders. Такой trace позволяет отличить ingestion defect от retrieval miss, regression reranker, unsupported claim и плохой формы ответа. Release gate должен состоять из отдельных порогов и критических failure cases, а не из красивого среднего.

• Retrieval: попали ли нужные документы или chunks в top-k и на какие позиции.
• Grounding: поддерживает ли контекст каждое проверяемое утверждение ответа.
• Качество ответа: является ли ответ правильным, релевантным, полным и пригодным для задачи.
• Operations: latency, cost, empty retrieval, timeout и результаты на устаревших источниках.
• Safety: ACL leakage, prompt injection, unsafe citations и корректная abstention.

Для каждого eval-запроса пометьте релевантные document или chunk IDs, желательно с graded relevance: критическое доказательство, полезный контекст и нерелевантный материал. Recall@k показывает, какую долю нужных объектов система нашла в первых k результатах; precision@k — сколько из этих результатов действительно релевантны. Mean Reciprocal Rank полезен, когда важен первый правильный результат, а nDCG учитывает порядок и разные уровни релевантности.

Связывайте метрику с UX и generator contract. Если ответ может использовать только четыре chunks, Recall@50 не описывает фактический контекст. Проверяйте document-level и chunk-level retrieval отдельно: правильный документ при неудачном chunking может выглядеть как частичный успех. Для metadata filters, tenant ACL и временных запросов добавляйте constraint correctness: релевантный, но недоступный или устаревший документ — ошибка, а не положительный результат.

Разбейте ответ на проверяемые утверждения и для каждого сохраните supported, contradicted или not-in-context вместе с конкретными source spans. Groundedness или faithfulness измеряет поддержку контекстом, но не гарантирует истинность самого источника. Отдельно проверяйте citation correctness: citation должен вести к фрагменту, который доказывает утверждение, а не просто к тематически похожему документу.

Reference-free judge полезен для широкого regression suite, но его verdict не является ground truth. Калибруйте judge на размеченном людьми slice, измеряйте agreement и стабильность повторных runs, фиксируйте версию judge и prompt, а пограничные и high-risk cases отправляйте человеку. Добавляйте негативные примеры с противоречивыми chunks, отсутствующим ответом и попытками заставить модель использовать внешние знания; иначе grader приучает команду оптимизировать только простые позитивные cases.

Answer correctness сравнивает результат с reference answer или rubric, но literal match редко достаточен для открытых ответов. Определите обязательные facts, допустимые формулировки, запрещённые claims, требуемый формат и условия abstention. Для extraction подходят field-level precision и recall; для support — resolution correctness и escalation; для research — coverage ключевых claims, provenance и представление неопределённости.

Answer relevance проверяет, ответила ли система именно на запрос, а completeness — не пропустила ли необходимые части. Не поощряйте verbosity: короткий подтверждённый ответ может быть лучше полного, но рискованного текста. Введите отдельный abstention score для запросов, которые corpus не покрывает. RAG, который отказывается отвечать без доказательств, может иметь более низкий поверхностный answer rate, но лучше контролировать ошибки.

Начните с небольшого набора вручную проверенных production-like запросов и versioned manifest. Стратифицируйте его по intent, сложности, языку, длине ответа, типу источника, freshness, ACL и стоимости ошибки. Добавьте easy lookups, multi-hop questions, ambiguous phrasing, no-answer cases, adversarial instructions внутри документов и запросы после обновления corpus. Не делите train и test случайными near-duplicates одного документа.

Synthetic questions помогают расширить покрытие, но не заменяют человеческую проверку: generator может создать query, которая неестественно повторяет chunk и завышает retrieval score. Помечайте происхождение каждого case и отдельно отчётность по human, production и synthetic slices. Каждый incident или подтверждённая user correction должна порождать очищенный regression case, если это разрешает data policy.

Если retrieval recall низкий, исследуйте ingestion coverage, chunk boundaries, query rewriting, embeddings, filters и hybrid search до изменения generator prompt. Если recall хороший, но precision или nDCG слабые, настраивайте ranking, deduplication и top-k. Если доказательства правильные, а groundedness падает, проверяйте context assembly, instruction hierarchy, claim scope и citation generation. Если groundedness высокая, а answer score низкий, проблема может быть в неполном corpus или task rubric.

Меняйте один контролируемый factor за experiment и сохраняйте retrieved snapshots для парного сравнения. Иначе одновременная замена chunking, embedding model и prompt не объяснит improvement или regression. Результаты на уровне сегментов важнее portfolio average: рост на простых FAQ не должен скрывать ухудшение ACL, no-answer или многоязычных запросов.

• Пропущенное доказательство → исследовать ingestion, query, filter, embedding или retrieval.
• Доказательство низко в rank → исследовать reranking, hybrid weights, deduplication или top-k.
• Поддержанный контекст, unsupported claim → исследовать generation, context assembly или judge.
• Правильный ответ, неверная citation → считать citation alignment отдельным дефектом.
• Хороший offline score, плохой production outcome → исследовать dataset drift или rubric mismatch.

В CI запускайте deterministic retrieval metrics на зафиксированном corpus snapshot, а model-based graders — с закреплёнными версиями, prompts и retry policy. Gate может требовать отсутствия критических ACL leaks, no-answer false confidence ниже согласованного порога, non-regression для ключевых slices и ограничений latency/cost. Конкретные thresholds устанавливайте от baseline и risk appetite собственной системы; универсального безопасного числа нет.

После canary собирайте privacy-safe traces, user corrections, citation opens, empty retrieval и escalation outcomes, но не считайте implicit click доказательством correctness. Sampling направляет сложные cases на review, а подтверждённые failures возвращаются в eval-набор. Rollback восстанавливает предыдущие версии corpus, retriever, reranker и prompt как согласованный bundle. Audit должен показывать, какой dataset, code, data и graders разрешили release.