Діагностика збоїв RAG: карта етапів та оцінювач обґрунтованості на рівні тверджень
Визначте місце збою у конвеєрі RAG, а потім створіть оцінювач обґрунтованості LLM, який перевірятиме твердження по одному та підтверджуватиметься за допомогою людських оцінювачів за допомогою коефіцієнта kappa.
Джерела: How to Diagnose RAG Failures with a Groundedness Judge
Коли бот RAG починає давати неправильні відповіді
Розгортання додатку RAG — це не кінець роботи, тим більше у продакшені. З часом він починає давати неправильні відповіді, і першою проблемою є знаходження причини. У системі є щонайменше сім місць, де може статися прихована несправність: розділення на частини, створення ембеддингів, пошук інформації, переурочування результатів, формування контексту, генерація тексту та запит, який їх об’єднує. Погана кінцева відповідь майже нічого не розкриває про те, у чому саме виникла проблема. Деякі інженери витрачали тиждень на оптимізацію запиту для генерації, коли причиною була помилка у розділенні на частини.
Існує досить механічний спосіб локалізації несправностей. Після цього виникає друга проблема — вимірювання рівня обґрунтованості в масштабі, адже читання кожного транскрипту стає нездійсненним після етапу підтвердження концепції. Штучний інтелект, що діє як суддя, може виконати цю роботу, але у суддів також є власні способи виникнення несправностей, які так само легко залишити непоміченими, як і помилки RAG, які вони мають виявляти. Обидві частини розглянуті нижче: відстеження несправностей до їхнього джерела та створення судді обґрунтованості, якому можна довіряти.
Спочатку знайдіть зламаний посилання
Конвеєр RAG — це ланцюг, і першим завданням є визначення того, яке посилання зламалося, перш ніж хтось буде редагувати запит. Наведена нижче схема є основою для локалізації проблеми. Вона не є вичерпною та може бути розширена для відповідності певній системі та сценарію використання.
Порядок є навмисним: спочатку виправляється процес пошуку інформації, а потім — її генерація. Інженерія запитів не може виправити вікно контексту, яке ніколи не містило потрібних фактів. Команди часто працюють у зворотному порядку, переписуючи системний запит п’ять разів, тоді як алгоритм перецінювання знижує значимість того фрагмента тексту, який мав би бути важливим. Недорогі рішення з великим ефектом, такі як краще розділення тексту на частини чи гібридний пошук, мають йти перед дорогими варіантами, як-от налаштування алгоритму перецінювання чи повторна підготовка моделі.
Три реалістичні симптоми показують, як використовується ця схема:
- Відповіді надаються впевнено, хоча документи зовсім не стосуються теми. Це не є процесом пошуку, оскільки не існує нічого релевантного для отримання інформації. Це помилка генерації чи утримання від відповіді: модель не вважає відповідь „У мене немає цього“ прийнятною.
- Бот надає правдоподібну, але застарілу інформацію. Проблема майже ніколи не полягає у розділенні на частини. Індекс застарів, оскільки документи змінилися, а ніхто їх не перезавантажив.
- Запити, що потребують одного факту, працюють, проте будь-які запити, що вимагають двох фактів з двох документів, зазнають невдачі. Це проблема з пошуком, характерна для багатоетапних запитів, адже один процес пошуку не може знайти два елементи, кожен з яких суттєво відрізняється від запиту.
Наступним кроком є отримання фактично знайденого контексту для прикладу з невдачею та його прочитання перед будь-якими змінами. Якщо факту немає, проблема у пошуку. Якщо він є, а модель все одно робить помилку, проблема у генерації тексту. Ця перевірка може заощадити кілька днів.
Що означає обґрунтованість
Читання транскрипцій підходить лише для кількох випадків, але є марним для тисяч. Тут вступає в справу суддя з ШІ, зокрема той, хто контролює обґрунтованість, що також називається вірністю. Його запитання полягає у тому, чи кожне твердження в відповіді можна прив’язати до чогось у отриманому контексті.
Одна тонка деталь одразу спричиняє плутанину: обґрунтованість та правильність — це різні речі. Правильна відповідь може бути необґрунтованою, наприклад, коли модель знала факт з процесу навчання, а не з документів. Обґрунтована відповідь може бути хибною, якщо отриманий уривок був застарілим або неправильним. Під час оцінки RAG саме обґрунтованість є ключовим показником, адже вона вказує на те, чи належним чином відбулося пошук інформації, незалежно від якості основних документів.
Суддя на рівні тверджень
Одне запитання, яке просить оцінити рівень обґрунтованості від 1 до 5, здається розумним, але насправді майже безполезним. Воно дає число без жодних пояснень, а саме оцінювання повних відповідей — це саме та сфера, де ШІ проявляють непослідовність. Набагато краще розділити відповідь на окремі твердження та перевірити кожне з них окремо.
У початковому запитанні вказана роль системи, яка представляє модель як оцінювача обґрунтованості, наводиться запитання, отриманий контекст та сформована відповідь, причому заздалегідь зазначається, що завдання не полягає у визначенні того, чи є відповідь загалом правдивою. Далі проситься виділити твердження та перевірити кожне з них окремо відносно контексту, надаючи для кожного вердикт та відповідний фрагмент тексту з підтвердженням.
SYSTEM:
You are a groundedness evaluator. You will be given a QUESTION, a CONTEXT
(retrieved passages), and an ANSWER generated by an AI assistant. Your job
is NOT to judge whether the answer is true in general, or well-written, or
relevant — only whether it is fully supported by the CONTEXT.
Do the following:
1. Decompose the ANSWER into a list of atomic claims (each claim = one
discrete factual statement, not a compound sentence).
2. For each claim, decide:
- SUPPORTED: directly stated or reasonably entailed by CONTEXT
- CONTRADICTED: conflicts with CONTEXT
- UNSUPPORTED: not addressed by CONTEXT at all (NOT the same as "false")
3. Quote the exact span of CONTEXT used as evidence for each claim
(or "none" if UNSUPPORTED/CONTRADICTED).
4. Give a one-sentence rationale per claim.
5. groundedness_score = (# SUPPORTED) / (# total claims).
Be strict: a claim that adds specificity not in CONTEXT (context says "a
discount applies," answer says "a 20% discount applies") is UNSUPPORTED.
Return valid JSON only:
{
"claims": [{"claim": "...", "verdict": "...", "evidence_span": "...", "rationale": "..."}],
"groundedness_score": 0.0,
"num_claims": 0
}
QUESTION: {question}
CONTEXT: {context}
ANSWER: {answer}
Деякі дизайнерські рішення потрібно формулювати чітко, оскільки вони спочатку не є очевидними:
- Оцінювання на рівні тверджень. Одного загального балу важко діагностувати. Вердикти для кожного окремого твердження точно показують, яке з них не витримало перевірки, що має значення, коли хтось мусить усунути первинну причину.
- Обов’язковий діапазон доказів. Вимога до судді наводити підтримуючий текст змушує його ґрунтувати вердикти на доказах, а не на ймовірності, а також дозволяє людському рецензенту швидко перевірити рішення, не перечитуючи весь контекст.
- НЕ ПІДТРИМУЄТЬСЯ проти СУПЕРЧИТЬСЯ. Суперечка з доказами та просто відсутність підтримки — це два різні види невдач із різними способами вирішення. Об’єднання їх у одну позначку „погано“ втрачає діагностичну деталізацію.
- Чітке завдання дотримуватися суворості. Судді ШІ схильні до пом’якшення рішень у межових випадках, особливо коли відповідь звучить правдоподібно, а прохання про суворість зменшує цю тенденцію.
Перевірка судді порівняно з людьми
Це крок, який завжди ігнорується, але саме він визначає, чи має значення все інше: суддю необхідно перевірити порівняно з людьми, перш ніж довіряти йому.
Процес простий. Візьміть від 100 до 200 прикладів, нехай людина окремо оцінить обґрунтованість, а потім обчисліть ступінь згоди за критерієм Коена-Каппи. Чиста точність вводить в оману, коли більшість відповідей є обґрунтованими, адже суддя, який завжди пише «обґрунтовано», має високі оцінки, але є безцінним. Також перевірте типові упередження судді:
- Упередження через позицію: чи змінюється вердикт, якщо змінити порядок контекстових уривків?
- Упередженість через зайвість: чи віддає суддя перевагу довшим відповідям, незалежно від того, чи справді вони мають кращу підставу?
- Упередженість через самопреференцію: якщо суддя належить до тієї ж родини моделей, що й генератор, він може більш прихильно оцінювати результати цієї родини.
- Зміна у м’якості оцінок: чи поступово зменшується згода протягом тижнів у міру змін моделі судді чи версії запиту?
Низьке значення каппи в одній категорії є ознакою необхідності корекції критеріїв оцінювання для цієї категорії. Це не означає, що система RAG там не працює належним чином. Люди постійно плутають ці два поняття, і в наступному розділі буде розглянута ця різниця.
Читання панелі керування як оператор
Уявіть собі панель керування, розділену за типами запитів. Правильна позиція — це позиція оператора, а не спостерігача за табло оцінок.
Загальний середній показник демонструє незначне зниження, що може вводити в оману. По окремих рядках показники виглядають так.
- Простий пошук фактів залишається стабільним та високим як щодо обґрунтованості, так і щодо узгодженості. І система, і суддя вважають його простим у використанні. Однак окремо він нудний, але зниження показників свідчитиме про проблему на базовому рівні: індексування, отримання даних чи формулювання запиту суддею, а не про проблеми з міркуваннями чи неоднозначністю.
- Багатоетапний підхід та порівняння значно погіршилися. При κ=0.71 збіг є лише помірним, тому шум у довгих відповідях, які ускладнюють їх розкладання, може пояснювати частину цього явища. Перш ніж стверджувати про наявність регресії, візьміть п’ять невдалих записів та перевірте, чи обидві частини відповіді знаходяться в контексті. Якщо надійшла лише одна частина, це проблема зі знаходженням та запам’ятовуванням інформації, адже однократне густе пошукове знаходження часто пропускає два факти, які не схожі на запит; рішенням є розкладання запиту або використання кількох запитів, а не корекція формулювання запиту. Якщо обидві частини надійшли, але порівняння все одно провалюється, причиною є синтез, при цьому основним підозрюваним є ефект „втрати посередині“: модель орієнтується на першу частину та надає другій занадто мало значення.
- Цифрові та фінансові показники показують κ=0,52. Це слабка згода, проте це найсильніший сигнал у таблиці, оскільки це означає, що суддю тут ще не можна вважати надійним. Для судді-ШІ справжня еквівалентність чисел є дуже складною: „20%“, „приблизно п’ята частина“ та „знижка 20 доларів з товару вартістю 100 доларів“ — це одне твердження в різних формулюваннях. Розумним рішенням є залишити систему RAG у спокої, поки не буде визначений критерій оцінювання, адже праця над ненадійними цифрами марнує технічний час.
- Політичні та процедурні показники залишаються стабільними та нормальними, як і у першому рядку, але з іншої причини: відповіді зазвичай походять з одного добре структурованого документа та не потребують синтезу з кількох. Якщо ці показники погіршуються, проблемою зазвичай не є логіка міркувань. Ймовірніше, що список із номерами розділений на частини, через що модель має кроки 1–3 та вигадує кроки 4 та 5.
- Поза межами дослідження потребує першого виправлення, хоча n=20 робить його найменшою частиною. При κ=0.90 оцінювач тут дуже надійний, адже виявити вигадану відповідь без підтримуючого контексту набагато простіше, ніж оцінити тонкі числові чи багатоетапні твердження. Саме ця надійність робить зниження рівня достовірності правдоподібним, і це найнебезпечніша проблема в таблиці. Система перейшла від правильного визнання „Я не знаю“ до вигадування відповідей із впевненістю, що гірше, ніж неправильна цифра, оскільки за тоном це нерозрізнємо від правильної відповіді. Існує дві ймовірні причини: по-перше, процес пошуку повертає схожі але не ідентичні уривки, які модель сприймає як дозвіл на відповідь; по-друге, нещодавня зміна запиту чи самої моделі могла тихо видалити інструкцію щодо утримання від відповіді. Почніть з оцінок схожості, отриманих під час пошуку, для цієї частини. Якщо вони знаходяться близько до рівня шуму, а модель все одно відповідає, це означає, що бракує бар’єра порогу релевантності перед генерацією.
Метод у п’яти кроках
Уся процедура зводиться до наступного:
- не довіряйте сумарним показникам
- перевіряйте надійність судді перед тим, як довіряти оцінці
- розділяйте на категорії
- на основі фактичних даних припускайте, на якому етапі виникла проблема
- визначайте пріоритети за критичністю та рівнем впевненості, а не за тим, який показник змінився найбільше
Практичні поради для нових оцінювачів
- Кожна оцінена відповідь коштує додаткового виклику LLM. При великому обсязі роботи оцінюйте лише зразки, а не все, та розподіляйте їх за категоріями запитів, щоб рідкісні, але критичні випадки не були заглушені численними простими запитами.
- Поновлюйте перевірку коефіцієнта каппа щоразу, коли змінюється модель судді або її запит. Будь-яка зміна створює нового суддю.
- Суддя, пристосований до числових особливостей чи специфічної термінології певної доменної сфери, не автоматично підходить для іншої, тому калібрування потрібно проводити окремо для кожної доменної сфери, а не один раз для всього.
Усі приклади та ілюстрації тут мають ілюстративний характер та не взяті з реальної продуктивної системи. Ця структура фреймворку та запитів є розумною відправною точкою.
Де це закінчується
Вищенаведений матеріал охоплює підхід до локалізації помилок, різницю між обґрунтованістю та правильністю, механізм оцінки на рівні тверджень та крок калібрування, який багато хто ігнорує. Залишається одне обмеження: усе це передбачає наявність одного чистого блоку отриманого контексту. Це припущення не спрацьовує, коли система використовує інструменти, поєднує кроки отримання інформації чи обґрунтовує свої рішення на основі власних проміжних результатів, як це роблять агентні системи. Визначення обґрунтованості без наявності окремого блоку контексту для перевірки та відповідна коректація механізму оцінки є окремою проблемою.
Пов’язана література
- Практичні нотатки: Де навчитися створювати RAG з нуля у 2026 році: курси та — Детальний огляд Практичних нотаток: Де навчитися створювати RAG з нуля у 2026 році: курси та: контракти, перевірки та місця для вставки коду для команд, які впроваджують цю модель.
- RAG з LangChain з нуля: завантажувачі, чанки, ембеддинги, оцінка — Крок за кроком створення системи запитань та відповідей до документів: завантаження файлів, розділення на чанки, ембеддинги, етапи індексування та пошуку, а також способи оцінки якості пошуку та відповідей.