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

У чат-бота з підтримкою запитують про політику компанії щодо повернення грошей, і він вигадує таку політику. Цієї політики насправді не існує, але клієнт дотримується її, і компанія змушена її виконати. Це і є проблемою галюцинацій у її найбільш дорогій формі, і вона є улюбленим темою для інтерв’ю з проектування систем, оскільки поєднує інфраструктуру ШІ з класичною архітектурою.

Чому моделі вигадують

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

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

Приклад застосування — чат-бот для підтримки клієнтів, який відповідає на запитання щодо продуктів, правил та способів усунення проблем. Він відповідає впевнено, проте іноді стверджує, що продукт має функцію, якої насправді немає, або вигадує правила. Як забезпечити, щоб його відповіді ґрунтувалися на справжній документації?

Теми, які варто розглянути у хорошій відповіді, включають:

• чому моделі створюють хибну інформацію та чому доробка параметрів недостатньо
• процес RAG: пошук контексту та подальша генерація відповідей
• векторні бази даних та семантичний пошук на основі ембеддингів

стратегії чанкінгу для розділення документів

техніки запитів, які зменшують галюцинації

керування вікном контексту в межах лімітів токенів

процеси оцінки, які контролюють якість відповідей

Як RAG зменшує галюцинації

За допомогою RAG система спочатку отримує відповідний матеріал з бази знань та вставляє його до запиту як контекст. Без цього модель вгадує на основі своїх параметрів. З цим модель читає відповідь з наданих документів. Вона все одно генерує токени, але контекст її обмежує. Якщо в документах сказано, що повернення грошей немає, модель не вигадуватиме 30-денний термін для повернення.

Векторні бази даних та ембеддинги

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

Для виконання цієї роботи використовуються чотири компоненти:

• Модель занурень. Вона перетворює текст на вектори так, щоб схожі тексти створювали схожі вектори. Серед варіантів — модель text-embedding-3-small від OpenAI з 1536 вимірами, а також моделі з відкритим кодом, як-от BGE чи E5.
• База даних векторів. Вона зберігає занурення та підтримує пошук за принципом найближчого сусіда. Серед варіантів — сервіс Pinecone з управлінням, а також Weaviate, Qdrant, pgvector (розширення PostgreSQL) та Milvus.

Пошук за допомогою ANN. Порівняння запиту з кожним збереженим вектором уповільнює процес. Алгоритми на кшталт HNSW (Hierarchical Navigable Small World) та IVF (Inverted File Index) знаходять приблизні сусіди набагато швидше — приблизно за логарифмічний час. При 10 мільйонах або більше векторів повний пошук може зайняти секунди, тоді як ANN — мілісекунди.

Переранжування. Перший етап повертає близько 20 кандидатів. Потім більш точний крос-кодер переупорядковує їх за рівнем релевантності, і лише топ-3 потрапляють до LLM. Швидке, але приблизне пошукове забезпечення, поєднане з повільним, але точним переранжуванням, забезпечує баланс між швидкістю та точністю.

Чанкування

Документ політики обсягом 50 сторінок неможливо отримати повністю, тому його потрібно розділити. Розмір чанків впливає як на точність пошуку, так і на ефективність використання вікна контексту.

• Фрагмент, який занадто малий, втрачає контекст. Наприклад, може бути написано „Предмети, пошкоджені під час транспортування, не є“, а решта речення знаходиться у наступному фрагменті, що унеможливлює моделі правильно відповісти.
• Фрагмент, який занадто великий, розбавляє корисний сигнал нерелевантним текстом та заповнює „вікно“ шумом.
• Перекриття захищає від проблем, пов’язаних із межами. Слайдуюче вікно з перекриттям 10–20 відсотків запобігає втраті інформації між фрагментами.

Хорошим стандартом для документації є розділення на розділи за заголовками, обмеження розміру фрагментів приблизно до 500–1000 токенів та перекриття сусідніх фрагментів на рівні 50–100 токенів. Кожен фрагмент має бути самодостатнім, містити повну думку.

Дизайн запиту як друга лінія захисту

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

• Роль. Фраза на кшталт "Ви — асистент з підтримки клієнтів" визначає персонажа.
• Обмеження контекстом. Інструкція відповідати лише на основі наданого контексту запобігає використанню моделлю інформації з її пам’яті.
• Механізм для ситуацій невизначеності. Запит на те, щоб модель сказала, що не може відповісти, коли у контексті відсутня інформація, є найважливішою рекомендацією. Без неї модель просто вгадує.
• Цитування джерел. Вимога наводити джерела документів змушує модель посилатися на конкретні джерела, що ускладнює створення вигадок.
• Заборона на зовнішні знання. Пряма заборона на використання інформації поза контекстом посилює правило обмеження контекстом.

Керування вікном контексту

Що робити, якщо відповідні фрагменти не поміщаються, або запит має кілька частин, які потребують багатьох фрагментів? Сучасні моделі мають великі вікна — наприклад, 128K токенів у GPT-4o та до 1M у Gemini, але заповнення їх незначним матеріалом погіршує якість відповідей. Допоможуть чотири тактики:

1. Ранжування за релевантністю. Завантажуйте десять фрагментів, впорядкуйте їх за оцінкою та додавайте від найкращих до найгірших, поки не закінчиться ліміт токенів, видаляючи спочатку найслабші.
2. Розкладання запиту. Для запиту на кшталт "Розкажіть мені про політику повернення грошей та часи доставки" розділіть його на підзапити, отримайте інформацію для кожного та відповідайте на всі у одній відповіді.
3. Узагальнення великих тем. Якщо тема охоплює багато фрагментів, нехай модель спочатку узагальнить їх та використає це узагальнення як контекст для кінцевої відповіді.

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

Повна архітектура

Узагальнюючи, основні рішення полягають у наступному:

• Семантичне розділення на фрагменти. Розділяти текст за природними межами — заголовками та абзацами, створюючи фрагменти по 500 токенів із 50-токеновим перекриттям; кожен фрагмент має бути самодостатнім.
• Двоетапне пошукове забезпечення. Пошук за допомогою ANN дає 20 кандидатів, а крос-кодер для переурочення ранжування залишає найкращі 3.
• Низька температура. Значення близько 0,2 у масштабі від 0 до 2 робить модель менш креативною та зменшує ймовірність вигадок.

Захисні механізми. Фільтр контенту перевіряє наявність особистих даних та порушень правил, перевірка посилань підтверджує, що відповідь ґрунтується на наданому контексті, а показник впевненості, отриманий на основі схожості результатів пошуку, визначає, чи слід давати відповідь чи відмовитися.

Чітка відповідь „Я не знаю“. Коли рівень впевненості у результаті пошуку опускається нижче певного порогу, бот повідомляє, що не може дати відповідь. Це найсильніший засіб захисту.

Цикл зворотного зв’язку. Оцінки користувачів у вигляді „лайк“ чи „дизлайк“ надходять у систему аналізу, яка з часом відстежує точність та рівень галюцинацій.

Що потрібно контролювати

1. Рівень галюцинацій. Частка відповідей, що містять інформацію, відсутню у наданому контексті; вимірюється за допомогою автоматизованої оцінки чи людського перегляду. Розумною метою є показник менше 1 відсотка.

Точність отримання інформації@3. Серед трьох найкращих фрагментів — скільки з них дійсно стосуються запиту. Значення нижче 70 відсотків свідчить про необхідність вдосконалення моделі ембеддингу чи процесу розділення тексту на фрагменти.

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

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

Оцінка відгуків користувачів. Середній рейтинг, отриманий за результатами оцінок «лайк» та «дизлайк», що є показником загального задоволення.

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

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

Чотири рівні захисту

Галюцинації — це не ознака поломки ШІ. Це проблема проектування. Модель без обмежень завжди віддає перевагу правдоподібності перед точністю, тому що саме до цього її навчали. Щоб вирішити цю проблему, використовують чотири рівні:

• Отримання даних. Надання релевантних документів, щоб модель відповідала на основі них, а не з пам’яті.
• Формулювання запитів. Обмеження моделі заданим контекстом, змушування її казати, що вона не знає, та вимога до наведення джерел.
• Ограничувальні правила. Фільтрація результатів, перевірка джерел та розрахунок показників впевненості, відкидання всього, що не можна підтвердити за допомогою контексту.

Відгуки. Відстежуйте частоту галюцинацій, оцінки користувачів та точність пошуку, щоб постійно покращувати базу знань та процес обробки даних.

Найважливіше правило: чат-бот, який впевнено каже «Я не знаю», значно кращий, ніж той, який впевнено вигадує відповідь.