RAG: як оцінювати якість відповідей (golden set)

З команда впровадила RAG, перше демо виглядає чудово, керівництво задоволене. Потім, через шість тижнів у продакшені, хтось змінює структуру документів у базі знань. Якість відповідей падає. Ніхто не помічає протягом двох тижнів, бо немає жодного регресійного тесту. Це сценарій, який ми бачимо в кожному третьому першому впровадженні.

Оцінка RAG — це не академічне доповнення. Це єдиний метод, який відрізняє «система відповідає» від «система відповідає правильно». Нижче описано, як її побудувати, які метрики використовувати та як підтримувати якість протягом усього життєвого циклу системи.

Тестування REST API просте: надсилаєш запит, порівнюєш відповідь зі схемою. RAG має три незалежні джерела помилок, які потребують окремих метрик.

Помилка retrieval. Система отримала фрагменти, що не відповідають запитанню. Генеративна модель має хороший контекст, але неправильний. Відповідь може звучати переконливо і бути повністю помилковою.

Помилка faithfulness. Система отримала релевантні фрагменти, але модель витягла з них неіснуючу інформацію або додала власну параметричну інформацію. Це класична галюцинація навіть при правильному retrieval.

Помилка relevance. Система отримала правильні фрагменти, модель згенерувала текст, що випливає з цих фрагментів, але відповідь не адресує фактичне запитання користувача. Трапляється, коли запитання неоднозначне або коли база знань має тематичні прогалини.

Юніт-тести API не виявляють жодної з цих помилок. Потрібні окремі метрики для кожного рівня.

Golden set — це контрольований набір пар вхід-очікуваний-вихід, який створюється один раз, підтримується в актуальному стані та запускається автоматично. Мінімальні вимоги для продакшену:

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

Формальні запитання поза доменом (ті, на які база знань не повинна відповідати) також мають бути в golden set. Оцінка RAG без негативних тестів не вимірює, чи система правильно відмовляється відповідати.

Оцінка RAG зводиться до трьох чисел, які потрібні на дашборді.

Faithfulness вимірює, чи відповідь випливає з наданих фрагментів. Шкала 0-1. Значення 1 означає, що кожне твердження в відповіді має підтвердження в хоча б одному з фрагментів контексту. Значення 0 означає, що модель відповіла з власної параметричної інформації, ігноруючи контекст.

Необхідне значення для продакшену: вище 0,85. Нижче цього порогу система регулярно генерує інформацію поза базою знань.

Context relevance (релевантність контексту) вимірює, який відсоток отриманих фрагментів є змістовно корисним для відповіді на запитання. Низька context relevance при високому faithfulness — класичний симптом занадто широкого retrieval: модель вірна контексту, але контекст непотрібний. Вимагає виправлення reranking або параметрів пошуку.

Answer relevance вимірює, чи відповідь адресує фактичне запитання. Ця метрика незалежна від faithfulness: відповідь може бути вірною фрагментам, але не відповідати на те, про що запитували. Особливо важлива при багатоаспектних або неоднозначних запитаннях.

Четверта метрика, яку ми додаємо в кожен проєкт: «не знаю» rate — відсоток запитів, при яких система правильно відмовилася відповідати через відсутність релевантних фрагментів. Занадто низький показник вказує на те, що guardrails занадто ліберальні і система галюцинує замість ескалації.

Є два практичні способи вимірювання якісних метрик: LLM-as-judge та оцінка експерта домену. Кожен метод має своє застосування.

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

Калібрування LLM-as-judge: візьміть 100 пар із golden set і оцініть їх вручну (експерт домену), потім оцініть тим самим набором LLM-as-judge. Кореляція Пірсона вище 0,8 між оцінкою людини та моделлю — це поріг, при якому можна довіряти автоматичній оцінці на великих обсягах.

Оцінка експерта домену повільна та дорога, але необхідна як еталон. Мінімальна рекомендація: раз на два тижні випадкові 30-50 пар із продакшену оцінюються експертом. Цей зразок підтримує калібрування LLM-as-judge та виявляє деградацію, яку автоматичні метрики не бачать.

Оцінка кінцевого користувача (thumbs up/down, коротке опитування) — найпростіший спосіб збору сигналу, але вимірює враження, а не змістовність. Користувачі дають високий рейтинг відповідям, впевненим стилістично, навіть якщо змістовно вони помилкові. Доповнюйте її, не замінюйте.

Golden set має цінність лише тоді, коли запускається регулярно та автоматично. Цикл регресії для RAG:

При кожній зміні бази знань. Додавання нових документів, видалення застарілих, зміна структури чанків — кожна з цих дій може змінити результати retrieval для існуючих запитань. Golden set, запущений після зміни, виявляє регресії перед виходом у продакшен.

При зміні конфігурації моделі або reranker. Оновлення моделі ембедінгів, зміна параметрів reranking, зміна порогу faithfulness у guardrails — кожне з цих налаштувань впливає на метрики. Без регресійного тесту не зрозуміло, в якому напрямку.

Щотижня на вибірці з продакшену. Незалежно від змін інфраструктури, реальні запити користувачів можуть виявити деградацію, невидиму на golden set (запитання поза доменом, нові типи запитів). Автоматична вибірка 50 розмов із продакшену, оцінена щотижня LLM-as-judge, доповнює golden set сигналом із реальності.

Поєднання цих підходів із пов'язаним процесом версіонування бази знань описує стаття оновлення знань RAG та версіонування.

Оцінка RAG — це не лише питання технічної якості. Для систем, що обробляють персональні дані або працюють у зоні високого ризику, слід оцінки є частиною документації, необхідної за AI Act.

Мінімальні вимоги з боку відповідності:

Логи оцінки повинні містити: версію моделі, версію бази знань, дату запуску тесту, результати за метриками та ідентифікатори тестових пар. Текст тестових запитів може містити PII, взяті з логів продакшену, що вимагає псевдонімізації перед включенням до golden set.

Для систем, охоплених DPIA (наприклад, HR, фінанси, охорона здоров'я), оцінка повинна включати тести на упередження: чи система по-різному обробляє однакові запитання залежно від демографічних характеристик користувача, присутніх у контексті? Результати таких тестів документуються як елемент оцінки ризику.

TTL логів оцінки: агреговані результати (метрики без тексту) можна зберігати довго як аудиторський слід. Логи з повними парами оцінки, що містять текст запитів, мають коротший TTL, адаптований до політики зберігання RODO — зазвичай 30-90 днів.

Відсутність задокументованої оцінки для системи високого ризику — потенційна прогалина під час наглядового аудиту. Human-oversight повинен мати доказ, що він був запущений, а не просто декларований.

RAGAS (Retrieval Augmented Generation Assessment) — найпопулярніший open-source фреймворк для оцінки RAG. Реалізує faithfulness, answer relevance, context precision та context recall як готові метрики. Вимагає моделі LLM для оцінювання (LLM-as-judge вбудований) і може працювати локально через OpenClaw router.

Коли RAGAS підходить: коли починаєте оцінку з нуля і хочете швидко отримати набір метрик без написання власної логіки оцінювання. RAGAS добре працює протягом перших 3-6 місяців проєкту.

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

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

Golden set, створений під час впровадження, поступово стає нерепрезентативним. Через шість місяців запитання користувачів можуть суттєво відрізнятися від тих, що є в golden set — нові тематичні області, новий тип клієнтів, змінені процеси в організації. Цей дрейф розподілу запитів — тихий вбивця якості: метрики на golden set залишаються стабільними, але реальна якість у продакшені падає.

Сигнали, що golden set потребує оновлення:

• Показник ескалації до людини зростає протягом трьох тижнів поспіль без змін у конфігурації.
• З'являється тематичний кластер у продакшені, який не має представництва в golden set (виявляється через кластеризацію ембедінгів реальних запитів).
• Відгуки користувачів містять категорії відповідей, які golden set не тестує.

Оновлення golden set — це щонайменше раз на квартал: перегляньте 200-300 продуктивних розмов, виділіть нові типи запитань, додайте до golden set і запустіть бенчмарк. Це не одноразовий проєкт, а процес.

Стаття моніторинг якості агента AI описує, як інтегрувати оцінку golden set у ширший операційний дашборд агента.

Опишіть свою систему RAG або заплановане впровадження, а модель підкаже, з яких метрик почати, як створити golden set для вашого діапазону та які ризики якості є критичними у вашому випадку (playground: PII маскуються, нульове зберігання):

Мінімум 50 пар дозволяє виявити регресії більше ніж на 10 відсоткових пунктів за якісними метриками. Для бази знань до 200 документів і вузького тематичного діапазону цього достатньо для старту. При 200 парах результати є статистично стабільними і дозволяють виявляти зміни на рівні 3-5 пунктів. Якщо база знань має кілька окремих тематичних областей, golden set повинен мати репрезентативне покриття кожної з них, навіть якщо загальна кількість пар невелика. Деталі про підготовку бази знань описує стаття як підготувати корпоративні дані під AI.

Faithfulness вимірює, чи відповідь випливає з наданих фрагментів контексту, незалежно від того, чи ці фрагменти були релевантними. Relevance вимірює, чи відповідь фактично адресує запитання користувача. Система може мати високу faithfulness (модель вірно цитує фрагменти) і низьку relevance (фрагменти не відповідають запитанню). Обидві метрики повинні вимірюватися окремо. Найпоширеніша помилка — вимірювати лише одну з них і робити висновки про всю систему. Якщо faithfulness висока, а relevance низька, проблема в retrieval, а не в генеративній моделі. Більше про пошук описує стаття семантичний пошук та ембедінги у компанії.

Запускайте його при кожній зміні бази знань або конфігурації моделі. Незалежно від змін, запускайте його щотижня на вибірці з 50 продуктивних розмов, оцінених LLM-as-judge. Для систем, що обробляють понад 1000 запитів на день, зменште інтервал до 3-4 днів. Для систем у секторах високого ризику (фінанси, охорона здоров'я, HR) кожна зміна конфігурації вимагає проходження golden set з повною документацією результатів як частини аудиторського сліду AI Act. Автоматичний запуск у CI/CD усуває ризик пропуску тесту при швидких змінах.

Без калібрування на експертній оцінці LLM-as-judge дає результати з низькою кореляцією з фактичною доменною якістю. Моделі по-різному визначають «релевантність» для різних галузей. Калібрування полягає в тому, що ви оцінюєте вручну 100 пар, оцінюєте ті ж пари через LLM-as-judge і вимірюєте кореляцію. Нижче Pearson 0,75 модель не є надійним суддею для вашого домену. Калібрування потрібно повторювати після оновлень моделі-оцінювача. Вартість цієї роботи одноразова при запуску системи і варта кожної хвилини, бо дозволяє довіряти автоматичним метрикам.

Для систем, класифікованих як високого ризику згідно з AI Act (особливо в галузях HR, фінансів, охорони здоров'я), регламент вимагає документування ефективності системи та можливості пояснення її роботи. Оцінка golden set із збереженими логами результатів є прямим доказом того, що систему регулярно контролювали. Відсутність цієї документації ускладнює доведення відповідності під час наглядового аудиту. Для систем, охоплених DPIA, додайте до процесу оцінки тести на упередження та тест відмови відповідати на запитання поза доменом. Обов'язки компаній за AI Act та RODO описує стаття AI Act та RODO 2026.