Як оцінювати систему RAG: метрики ретрівалу, faithfulness та golden set

Регулярно спостерігаємо один і той самий момент: команда впроваджує асистента на базі RAG, хтось повідомляє, що «бот вигадує», і починається пошук винуватця. Чи це модель галюцинує, чи просто не отримала потрібного фрагмента в контексті? Без роздільного вимірювання обох шарів ця дискусія закінчується вгадуванням. Оцінка RAG — це не одна цифра, а два набори метрик, об'єднані спільним тестовим набором, які разом показують, де саме система дає збій.

Система RAG має два компоненти, які можуть виходити з ладу незалежно. Ретрівал може не знайти потрібний фрагмент — тоді генерація не має шансів, бо модель не бачить того, чого не отримала. Або ретрівал надасть правильний контекст, а модель все одно відповість не по суті, проігнорує його чи додасть факти зі своєї пам'яті. Це дві різні несправності та два різні плани виправлень.

Тому вимірюємо їх окремо. Якість семантичного пошуку оцінює, чи потрапляють потрібні фрагменти високо в контекст. Якість відповіді оцінює, чи дотримується модель того, що отримала. Лише поєднання обох дає картину end-to-end. Поширена помилка — дивитися виключно на кінцеву оцінку відповіді: коли вона падає, незрозуміло, чи винен ретрівал, чи генерація, тому виправлення хаотичні.

Шар пошуку вимірюємо тими самими інструментами, що й чистий ретрівал. Recall@k показує, який відсоток очікуваних фрагментів потрапив у топ k результатів, наданих моделі. Це метрика покриття — якщо потрібного фрагмента немає в контексті, навіть найкраща модель не згенерує правильної відповіді, а лише вигадає. Тому recall@k для RAG важливіший, ніж для пошукової системи, де користувач сам переглядає список.

Precision@k показує, який відсоток наданих фрагментів був дійсно релевантним. Низька точність означає, що ми засмічуємо контекст — модель отримує шум, зростає вартість токенів і ризик, що вона вхопиться за нерелевантний фрагмент. На практиці балансуємо обидва: ширше k підвищує recall, але знижує точність. MRR доповнює, наскільки високо опиняється перший релевантний результат, що буває важливим, коли хочемо надати моделі менше контексту.

Цифри в колонці «поріг» — це діапазони, які ми спостерігали в проектах з польськими корпоративними документами, а не універсальні константи — сприймайте їх як точку калібрування. Методологію вимірювання самого ретрівалу ми розвиваємо в статті про те, як вимірювати якість ембедінгів. Коли recall занадто низький, найчастіші важелі — це зміна стратегії chunking та додавання гібридного пошуку BM25 плюс вектори.

Другий шар — це якість самої відповіді за умови, що контекст уже є. Ключова метрика — faithfulness (обґрунтованість): чи кожне твердження у відповіді можна підтвердити фрагментом з наданого контексту. Вірна відповідь не додає фактів поза матеріалом — саме таке додавання є класичною галюцинацією. Faithfulness вимірюємо, розбиваючи відповідь на окремі речення-твердження та перевіряючи, чи кожне з них має опору в контексті.

Друга метрика — релевантність відповіді (answer relevance): чи відповідь дійсно стосується питання, а не є правильною, але про щось інше. Третя — атрибуція джерел: чи система вказує, з якого документа походить інформація, і чи ці цитування правдиві. Атрибуція — це не прикраса, а механізм, який дозволяє користувачеві перевірити відповідь і водночас дає нам аудитований слід під час оцінки.

Галюцинації в RAG мають два різні джерела. Перше: ретрівал не надав відповіді, тому модель «додумує» з пам'яті — це дефект шару пошуку, який виявляється низьким recall. Друге: контекст був правильним, а модель все одно вийшла за його межі — це дефект генерації, який виявляється низьким faithfulness. Розділення вимірювання дозволяє одразу знати, який шар виправляти, замість «покращувати промпт», коли реальною проблемою є відсутній chunk.

Без golden set немає чого вимірювати на жодному з шарів. Для RAG golden set багатший, ніж для чистого ретрівалу, бо кожна позиція — це трійка: реалістичне питання, набір фрагментів, що становлять правильний контекст, та зразкова відповідь (або набір фактів, які правильна відповідь має містити). Питання та позначений контекст живлять метрики ретрівалу; питання, контекст та зразкова відповідь живлять метрики генерації.

Почніть з 50-100 реальних питань з логів асистента, звернень до саппорту або інтерв'ю з майбутніми користувачами. Питання, вигадані «за столом», занадто регулярні й не відображають мову користувача, який пише зі скороченнями та помилками. Для кожного питання позначте релевантні фрагменти контексту та запишіть зразкову відповідь — анотацію має виконувати людина, яка знає предметну область, а не мовна модель, бо саме модель тут є об'єктом оцінки.

Корпус для оцінки індексуйте тим самим пайплайном, що й продуктовий: та сама стратегія chunking, та сама модель ембедінгів, той самий розмір фрагмента. Якщо зміните щось між тестом і продакшеном, метрики перестануть бути порівнянними. Golden set варто версіонувати й ставитися до нього як до коду — він росте разом із системою, а кожна нова помилка в продакшені має повертатися до нього як новий тестовий випадок.

Оцінка offline на golden set є повторюваною та дешевою, але має сліпу зону: вимірює лише те, що передбачили. Реальні користувачі ставлять питання поза набором, у формах, які ми не вигадали. Тому offline служить для порівняння варіантів (модель A проти B, chunking 256 проти 512) і для захисту від регресії після кожної зміни, але не замінює спостереження за продакшеном.

Онлайн-оцінка працює на живому трафіку. Основою є спостережливість: логуємо питання, наданий контекст, відповідь та вказані джерела, щоб кожну відповідь можна було відтворити й зааудитувати. На цій базі рахуємо faithfulness у безперервному режимі — автоматичний суддя (LLM-as-judge) перевіряє, чи мають твердження з відповіді опору в залогованому контексті, і позначає випадки без покриття як кандидатів на галюцинації. Це сигнал, а не вирок: частина позначок потребує перевірки людиною, а вибірка йде на ручну оцінку предметної області.

Атрибуція джерел замикає цикл. Якщо кожна відповідь вказує фрагменти, на яких вона базується, верифікація галюцинацій зводиться до перевірки, чи дійсно цитовані фрагменти містять те, про що твердить модель. Розбіжність у цитуванні — сильний сигнал галюцинації. Продуктові сигнали — низький faithfulness, дизлайк, ескалація до людини — повертаємо до golden set як нові тестові випадки, замикаючи цикл offline-online. Як цей цикл виглядає для всього асистента, описуємо в тексті про моніторинг якості агента AI.

Ні. Окрема кінцева оцінка показує, що щось не так, але не скаже, чи підвів ретрівал, чи генерація. Це дві різні несправності з різними виправленнями, тому потрібно вимірювати обидва шари окремо й лише потім складати їх у картину end-to-end. Без такого розділення виправлення стають вгадуванням.

Faithfulness перевіряє, чи відповідь дотримується наданого контексту й не додає фактів поза ним — це захист від галюцинацій. Релевантність перевіряє, чи відповідь взагалі стосується питання. Відповідь може бути вірною контексту, але нерелевантною (правильною, але про щось інше), тому обидві метрики потрібні паралельно.

З нашої практики розумний старт — 50-100 пар питання-контекст-відповідь, побудованих на реальних запитах. Цього достатньо, щоб виявити явні відмінності між варіантами та регресії. Набір сприймайте як живий: кожну нову помилку в продакшені додавайте як новий тестовий випадок, тому з часом він зросте.

Так, LLM-as-judge — це практичний спосіб оцінки faithfulness у масштабі, особливо онлайн. Але сприймайте його як сигнал, а не остаточний вердикт: калібруйте суддю на вибірці, оціненій вручну, і періодично аудитуйте його рішення. Для анотації golden set (позначення правильного контексту) не використовуйте той самий тип моделі, яку оцінюєте, бо це спотворює вимірювання.

Коли відповідь вказує фрагменти, на яких вона базується, верифікація зводиться до перевірки, чи дійсно ці фрагменти містять те, про що твердить модель. Розбіжність між цитуванням і змістом фрагмента — сильний сигнал галюцинації. Атрибуція також дає аудитований слід — корисний і при оцінці, і при роботі з рекламаціями користувача.