Чому RAG вигадує відповіді за документами компанії і як знайти причину

RAG-система може помилитися на кількох етапах: коли документ потрапляє в індекс, коли пошук обирає фрагменти, коли з цих фрагментів складається контекст для моделі і коли модель формулює відповідь. Однаково неправильна відповідь користувачу може мати чотири різні причини. Тому діагностувати треба кожен етап окремо. Заміна моделі, векторної бази чи промпта без розуміння причини не має доведеної користі: ви змінюєте одну частину, а помилка живе в іншій.

RAG (Retrieval Augmented Generation) означає генерацію з пошуком: система спершу знаходить у ваших документах релевантні фрагменти, а потім передає їх моделі разом із питанням.

Після статті ви зможете провести діагностику власної системи за таблицею «питання, еталон, знайдені фрагменти, відповідь, причина», виміряти ефект виправлення на однаковій вибірці і налаштувати зворотний зв'язок, щоб ті самі помилки не поверталися.

Спершу визначте тип помилки

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

Факту немає в документах. Відповіді на питання в базі знань просто немає, а модель її сформулювала. Тут проблема не в пошуку, а в тому, що система не вміє чесно казати «у документах цього немає».

Застарілий документ. Факт є, але в старій версії регламенту, а нова версія або не потрапила в індекс, або існує поруч зі старою.

Неправильний пошук. Потрібний фрагмент існує в індексі, але пошук його не повернув або повернув серед великої кількості нерелевантних фрагментів.

Неправильний висновок. Модель отримала правильний фрагмент, але відповіла не за ним: змішала з іншим, пропустила умову, повторила загальне знання замість тексту документа.

Цей поділ узгоджується з методикою OpenAI щодо точності моделей. Вона розрізняє дві групи проблем RAG: пошук повернув неправильний контекст або забагато нерелевантного, який заглушує правильну інформацію, і модель отримала правильний контекст, але використала його неправильно. Для першої групи методика радить налаштовувати пошук і зменшувати шум, для другої працювати з інструкціями моделі.

Навчальний приклад: політика повернення

Приклад вигаданий. Компанія змінила політику повернення товару: раніше строк був 14 днів, тепер 30. Через тиждень після оновлення бот підтримки відповідає клієнтам «14 днів». Причина однаковою відповіддю не визначається. Розглянемо три різні збої, кожен з яких дає саме цю відповідь.

Збій 1. У індекс потрапив старий файл. Нову версію регламенту поклали в іншу папку, яку індексація не охоплює. В індексі є лише документ з 14 днями. Модель відповідає правильно за тим, що отримала. Виправлення: процес оновлення джерел. Новий документ має замінювати старий в індексі, а старий має бути видалений або позначений як недійсний.

Збій 2. Пошук повернув обидві версії без дати. В індексі є і старий, і новий документ. Пошук повертає обидва фрагменти, а в тексті фрагментів немає ні дати, ні номера версії. Модель бачить дві суперечливі цифри і обирає одну. Виправлення: метадані. Кожен фрагмент має нести дату набрання чинності і статус документа, а пошук має відфільтровувати недійсні версії до того, як фрагменти потраплять до моделі.

Збій 3. Модель отримала нову версію, але повторила старе правило. Пошук спрацював правильно, у контексті лише новий документ з 30 днями. Але модель відповіла «14 днів», наприклад тому, що відповідала із загального уявлення про типові умови повернення, а не з тексту. Виправлення: генерація. Вимагати відповідь з цитатою з наданого фрагмента, перевіряти, що число у відповіді збігається з числом у фрагменті, і тестувати цей сценарій окремо.

Три збої, три різні виправлення. Якби команда в усіх трьох випадках просто замінила модель, проблема в першому і другому залишилася б.

Перевірте вихідний документ

Діагностика починається не з моделі, а з документа, на який мала спиратися відповідь.

Версія і дата. Чи існує документ з правильною відповіддю, і чи є він чинним? Чи не лежать у джерелах кілька версій без позначки, яка з них діє?

Таблиці. Умови часто записані в таблицях: тарифи, строки, ліміти. Під час перетворення документа на текст таблиця може втратити структуру, і значення відірвуться від своїх заголовків. Відкрийте той текст, який реально потрапив в індекс, і перевірте, чи можна з нього зрозуміти, яке число до чого належить.

Скани. Якщо документ є зображенням, текст з нього отримують розпізнаванням. Помилки розпізнавання переходять у відповіді. Перевірте розпізнаний текст саме тих сторінок, які стосуються проблемного питання.

Суперечності. Іноді два чинні документи справді суперечать один одному: регламент відділу і загальна політика компанії. Власник джерел має усунути суперечність; до цього система повинна позначити конфлікт і передати питання людині, а не довільно обирати правило.

Права доступу. Чи має система доступ до потрібного документа? Перевірте, чи має поточний користувач право на документ. Якщо права немає, коректна поведінка — не розкрити документ; такий випадок не виправляють розширенням доступу лише заради повноти відповіді.

Якщо на цьому етапі виявилося, що потрібного факту в індексі немає або він спотворений, далі можна не йти: жодне налаштування пошуку чи моделі цього не виправить.

Перевірте пошук і складання контексту

Якщо документ правильний і в індексі є, наступне питання: чи знайшов його пошук і чи дійшов знайдений фрагмент до моделі в придатному вигляді.

Пошук

Для проблемного питання подивіться, які фрагменти повернув пошук, у якому порядку і з якими оцінками схожості. Відповідь на три питання:

1. Чи є потрібний фрагмент серед результатів? Якщо ні, проблема в пошуку: у тому, як документ розбито на фрагменти, у формулюванні запиту, у налаштуваннях пошуку.
2. На якій він позиції? Якщо потрібний фрагмент є, але на десятому місці після дев'яти нерелевантних, у контекст він може не потрапити через обмеження кількості фрагментів.
3. Чи не заглушений він шумом? Методика OpenAI окремо називає ситуацію, коли забагато нерелевантного контексту заглушує правильну інформацію і спричиняє вигадані відповіді.

Складання контексту

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

• Обрізання. Знайдено десять фрагментів, а в запит потрапили п'ять. Чи був серед них потрібний?
• Втрата метаданих. Дата і статус документа були в індексі, але не потрапили в текст, який бачить модель.
• Позиція в довгому контексті. Дослідження Lost in the Middle (2023) на двох задачах, пошуку відповіді в кількох документах і пошуку значення за ключем, показало U-подібну залежність. Якість була найвищою, коли потрібна інформація стояла на початку або в кінці контексту, і помітно падала, коли вона була посередині. Автори зазначають, що спад зберігався навіть для моделей, спеціально створених для довгого контексту. Це результат для досліджених на той момент моделей і задач, а не характеристика всіх сучасних моделей. Але це аргумент перевірити на вашій системі, чи впливає позиція фрагмента на відповідь.

Практичний спосіб перевірки: збережіть повний текст, який система відправила моделі для проблемного питання, і прочитайте його очима. Чи можна з нього, без будь-яких інших знань, дати правильну відповідь? Якщо потрібного факту там немає, система не має достатньої джерельної підстави для відповіді, навіть якщо модель випадково вгадає її.

Перевірте генерацію

Якщо правильний фрагмент дійшов до моделі в придатному вигляді, а відповідь неправильна, проблема в генерації.

Метод перевірки простий і трудомісткий: зіставте кожне значуще твердження відповіді з текстом наданих фрагментів. Значущими вважаються числа, строки, умови, винятки, назви документів. Для кожного визначте одне з трьох:

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

Спотворені і непідтверджені твердження вказують на проблеми генерації. Типові виправлення: чіткіша інструкція відповідати лише за наданим текстом і казати, коли відповіді немає; вимога цитувати фрагмент; перевірка формату відповіді кодом; окремі тести на числа і строки. Методика OpenAI для проблем такого типу радить спершу працювати з інструкціями, а донавчання розглядати, якщо приклади покращують точність.

Інструкція «відповідай лише за документами» корисна, але не гарантує результату. Її дію треба вимірювати так само, як будь-яке інше виправлення.

Таблиця діагностики

Нижче таблиця для навчального прикладу з політикою повернення. Її ж можна використовувати як шаблон для власних помилок.

Колонка «Знайдені фрагменти» заповнюється з журналу системи, а не з пам'яті. Без збереження того, що пошук повернув і що потрапило в запит, відрізнити другий збій від третього неможливо.

Вимірюйте виправлення

Виправлення, яке «здається, допомогло» на трьох питаннях, може погіршити відповіді на тридцяти інших. Тому зміни вимірюють на однаковій контрольній вибірці до і після.

Контрольна вибірка. Набір питань з еталонними відповідями, які перевірили люди, що знають предмет. Методика OpenAI радить будувати набір питань з еталонними відповідями ще до оптимізації і згадує орієнтир від 20 питань для початкової роботи з інструкціями. Включіть у вибірку питання всіх чотирьох типів помилок, зокрема питання, відповіді на які в документах немає.

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

Вартість. Більше фрагментів у контексті, більша модель, додаткова перевірка відповіді збільшують вартість і затримку. Записуйте їх поруч з якістю.

Автоматична оцінка. Інструменти на кшталт Ragas пропонують оцінювати окремо три аспекти: чи знаходить пошук релевантні і сфокусовані фрагменти, чи модель використовує їх достовірно, і якість самої відповіді. Автори описують ці метрики як такі, що не потребують еталонних анотацій від людей. Це зручно для частих прогонів. У дослідженні Ragas оцінювання реалізоване через запити до LLM; це не незалежний доказ істинності. До того ж faithfulness означає відповідність наданому контексту: якщо саме джерело застаріле, висока оцінка узгодженості ще не робить відповідь правильною. Звіряйте автоматичні оцінки з еталонними відповідями і з ручною вибірковою перевіркою людьми, особливо для питань, де помилка коштує дорого: гроші, строки, юридичні умови.

Окремо про очікування. Методика OpenAI зазначає, що універсального порогу «достатньо точно» немає, і пропонує визначати цільову точність з економіки бізнесу: цінності правильних відповідей і вартості кожного типу помилки. Відсоток помилок вашої системи з зовнішнього бенчмарку не виводиться: його показує лише ваша вибірка.

Організуйте зворотний зв'язок

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

Що зберігати для кожної помилки:

• питання користувача і відповідь системи;
• фрагменти, які повернув пошук, і текст, що потрапив у запит до моделі;
• версії документів у індексі на момент відповіді;
• правильну відповідь, підтверджену відповідальною людиною;
• визначену причину: документ, пошук, складання контексту чи генерація;
• внесене виправлення і дату.

Збереження діагностичних прикладів потребує мінімізації: маскуйте персональні дані й секрети, обмежуйте доступ і строк зберігання. Для регресійних тестів за можливості використовуйте знеособлені або синтетичні копії.

Хто відповідає. Помилку в документі виправляє власник документа, а не команда, що підтримує бота. Помилку пошуку чи генерації виправляє технічна команда. Розподіліть ці ролі заздалегідь, інакше кожна скарга буде розглядатися як «бот зламався».

Як помилка стає тестом. Кожен розібраний випадок з еталонною відповіддю додається до регресійного набору. Окремо зберігайте відкладену вибірку, за якою не підбираєте налаштування: інакше багаторазова оптимізація під ті самі питання створить надто оптимістичну оцінку. Після кожної зміни системи (нова модель, нові налаштування пошуку, оновлення інструкцій) вибірку проганяють повністю. Так виправлена помилка не повертається непомітно.

Що зробити найближчим часом:

1. Зберіть від 10 до 20 реальних неправильних відповідей і віднесіть кожну до одного з чотирьох типів помилок.
2. Для кожної відкрийте текст документа в індексі, результати пошуку і повний текст запиту до моделі.
3. Заповніть таблицю діагностики: питання, еталон, знайдені фрагменти, відповідь, причина.
4. Сформуйте контрольну вибірку з еталонними відповідями, включно з питаннями без відповіді в документах.
5. Виміряйте поточний стан, внесіть одне виправлення і виміряйте знову на тій самій вибірці, з урахуванням відмов і вартості.
6. Налаштуйте збереження даних для розбору кожної нової помилки і порядок, за яким вона потрапляє в контрольну вибірку.

Часті питання