Оцінювання RAG: метрики retrieval, groundedness і якості відповіді

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

Будуйте eval як діагностичне дерево. Спочатку фіксуйте corpus version, query, дозволені документи та релевантність. Потім зберігайте retrieved IDs, ranks і тексти, а вже після цього — відповідь, citations та verdict graders. Такий trace дозволяє відрізнити ingestion defect від retrieval miss, reranker regression, unsupported claim і погану форму відповіді. Release gate має складатися з окремих порогів і критичних failure cases, а не з красивого середнього.

• Retrieval: чи потрапили потрібні документи або chunks у top-k і на які позиції.
• Grounding: чи підтримує контекст кожне перевірюване твердження відповіді.
• Answer quality: чи відповідь правильна, релевантна, повна й придатна для задачі.
• Operations: latency, cost, empty retrieval, timeout і stale-source outcomes.
• Safety: ACL leakage, prompt injection, unsafe citation і коректна 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 на human-labeled slice, вимірюйте agreement і стабільність на повторних runs, pin версію judge та prompt, а borderline і 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, що відмовляється без доказів, може мати нижчий superficial answer rate, але кращий контроль помилок.

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

Synthetic questions допомагають розширити покриття, але не замінюють людську перевірку: generator може створити запит, який неприродно повторює chunk і завищує retrieval score. Позначайте походження кожного case та звітуйте human, production і synthetic slices окремо. Кожен incident або підтверджений user correction має породжувати sanitized 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. Segment-level результати важливіші за portfolio average: приріст на простих FAQ не повинен приховати погіршення ACL, no-answer або багатомовних запитів.

• Missed evidence → ingestion, query, filter, embedding або retrieval investigation.
• Evidence low-ranked → reranking, hybrid weights, deduplication або top-k investigation.
• Supported context, unsupported claim → generation, context assembly або judge investigation.
• Correct answer, wrong citation → citation alignment як окремий defect.
• Good offline score, poor production outcome → dataset drift або rubric mismatch.

У CI запускайте deterministic retrieval metrics на pinned 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, а confirmed failures повертаються до eval-набору. Rollback відновлює попередні corpus, retriever, reranker і prompt versions як узгоджений bundle. Audit має показати, який набір, код, дані та graders дозволили release.