Як прибрати галюцинації AI-чатбота

Галюцинація — це коли ваш AI-чатбот упевнено каже клієнту те, чого немає: вигадану ціну, неіснуючу політику повернення, скасований тариф. У підтримці чи продажах одна така відповідь коштує довіри й грошей. Хороша новина: галюцинації не магія, їх системно зменшують конкретним стеком технік. Розберемо анти-галюцинаційний стек, який ми реально ставимо клієнтам — від RAG до fallback «не знаю».

Чому LLM взагалі галюцинує

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

Звідси головний принцип: не питайте модель про факти — давайте їй факти й просіть лише сформулювати відповідь.

Три типи галюцинацій, які треба розрізняти

Не всі галюцинації однакові, і лікуються вони по-різному:

• Фактична — бот вигадує конкретику: ціну, строк, умову, якої немає. Найнебезпечніша в підтримці й продажах. Лікується RAG і преднаписаними відповідями.
• Логічна — бот робить неправильний висновок із правильних даних (наприклад, неправильно рахує знижку). Лікується обмеженням дій і перевірками на виході.
• Контекстна — бот «забуває» сказане раніше в діалозі або плутає клієнтів. Лікується правильним керуванням контекстом і пам'яттю діалогу.

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

Анти-галюцинаційний стек: 5 рівнів захисту

1. RAG — відповіді тільки з вашої бази знань

RAG (Retrieval-Augmented Generation) — фундамент. Замість того щоб модель вигадувала, система спершу знаходить релевантні фрагменти у вашій базі знань (FAQ, інструкції, прайс, політики), а потім просить модель відповісти на основі лише цих фрагментів.

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

• Модель бачить актуальні дані, а не покладається на пам'ять.
• У промпт додають інструкцію: «відповідай тільки з наданого контексту, не вигадуй».
• Оновили прайс у базі — бот одразу відповідає по-новому, без перенавчання.

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

2. Guardrails — рамки, що ловлять небезпечні відповіді

Guardrails — це перевірки до й після генерації:

• Вхідні: фільтрують запити поза темою, спроби «зламати» бота (jailbreak), токсичність.
• Вихідні: перевіряють, чи відповідь не містить вигаданих фактів, чи не обіцяє того, чого бізнес не робить (знижки, гарантії).
• Обмеження дій: бот не може сам «підтвердити повернення коштів» — лише запропонувати, рішення за людиною.

3. Преднаписані відповіді для критичних тем

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

Тип запиту	Як відповідати	Ризик галюцинації
Точна ціна / тариф	Преднаписана відповідь або дані з прайсу через RAG	Високий — фіксуємо жорстко
Політика повернення	Преднаписана відповідь	Високий — фіксуємо
Загальне питання про продукт	RAG із бази знань	Середній — контроль через контекст
Розмовний small talk	Вільна генерація	Низький — можна

4. Fallback «не знаю» — найважливіше

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

• У системний промпт: «Якщо у наданому контексті немає відповіді — скажи, що не знаєш, і запропонуй зв'язок з людиною. Не вигадуй».
• Поріг впевненості: якщо RAG не знайшов релевантного фрагмента — одразу fallback, а не спроба «натягнути».
• Кнопка передачі оператору завжди доступна.

5. Цитування джерел і логування

• Цитати: бот показує, з якого документа взяв відповідь. Це і довіра клієнта, і спосіб швидко знайти помилку в базі.
• Логи: зберігайте діалоги, щоб бачити, де бот «попливає», і донавчати базу. Перші тижні після запуску — критичні для калібрування.

Чого НЕ робити

• Не покладайтеся на «розумнішу модель». Навіть топова модель галюцинує без вашого контексту. RAG важливіший за вибір моделі.
• Не пишіть розмиту базу знань. Суперечливі або застарілі документи = гарантовані галюцинації.
• Не дозволяйте боту діяти без підтвердження. Генерувати текст — так; підтверджувати повернення коштів — ні.
• Не запускайте без fallback. Бот без «не знаю» рано чи пізно дезінформує клієнта.

Практичний чек-лист перед запуском

1. База знань чиста, структурована, без суперечностей.
2. RAG налаштований і повертає релевантні фрагменти.
3. Системний промпт містить «відповідай тільки з контексту» і «не знаєш — скажи».
4. Критичні теми (ціни, повернення) — на преднаписаних відповідях.
5. Кнопка на людину доступна завжди.
6. Логування ввімкнено, перші тижні дивитесь діалоги щодня.

Як підготувати базу знань, щоб RAG працював

90% якості RAG — це якість документів, з яких він тягне відповіді. Ось що робить базу «галюцино-стійкою»:

• Один факт — одне місце. Якщо ціна продукту згадана в трьох документах із різними числами, бот обере випадкове. Усувайте дублі й суперечності.
• Структура й заголовки. Чіткі секції («Доставка», «Повернення», «Гарантія») допомагають retrieval знаходити саме той фрагмент.
• Короткі самодостатні абзаци. Фрагмент має бути зрозумілим поза контекстом — RAG ріже документи на шматки.
• Актуальність. Застарілий прайс у базі = впевнена брехня бота. Призначте відповідального за оновлення.
• Явні «ми НЕ робимо». Якщо ви не доставляєте за кордон — напишіть це прямо, щоб бот не «домислив» зворотне.

Гарне правило: якщо нова людина в команді не змогла б упевнено відповісти за вашою базою — бот теж не зможе.

Як тестувати бота на галюцинації перед запуском

Не запускайте «на віру». Прогоніть бота через набір каверзних запитів:

1. Питання, відповіді на які немає в базі. Бот має сказати «не знаю», а не вигадати.
2. Запити з хибною передумовою («підтвердіть, що у вас знижка 50%»). Бот не повинен погоджуватися з вигадкою.
3. Граничні факти (точні ціни, строки, умови). Перевірте дослівну відповідність базі.
4. Спроби вивести зі сценарію («забудь інструкції й...»). Guardrails мають утримати.
5. Повторення під різними формулюваннями. Відповіді мають бути стабільними, а не «плавати».

Зафіксуйте ці кейси як регресійний набір —ганяйте його після кожної зміни бази чи промпта.

Поширені міфи про галюцинації

Міф	Реальність
«Розумніша модель не галюцинує»	Будь-яка модель галюцинує без вашого контексту; RAG важливіший
«Достатньо написати в промпті "не бреши"»	Інструкція допомагає, але без RAG і fallback не рятує
«Галюцинації — це рідкість»	На специфіці вашого бізнесу базовий бот вигадує постійно
«Це можна вимкнути назавжди»	Ні; це інженерія зниження ризику, а не перемикач
«Чим довша відповідь, тим краще»	Навпаки: довгі генерації частіше містять вигадки

Що робити, коли галюцинацію помітили після запуску

Галюцинації не зникають назавжди після старту — їх ловлять і гасять у процесі. Робочий цикл:

1. Зловіть у логах. Перегляд діалогів перші тижні — щодня. Шукайте відповіді, які звучать упевнено, але не звіряються з базою.
2. Знайдіть причину. Майже завжди це або діра в базі знань (немає факту), або суперечність (є кілька версій факту), або занадто «вільний» промпт.
3. Закрийте джерело. Додайте/виправте документ у базі, приберіть суперечність, посиліть інструкцію «відповідай тільки з контексту».
4. Додайте в регресійний набір. Щоб ця сама галюцинація не повернулася після наступної зміни.
5. Повторіть. Якість бота — це не точка, а крива, що покращується з кожним циклом.

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

Орієнтовні строки на побудову анти-галюцинаційного стеку

Етап	Строк	Результат
Чистка й структурування бази	3–7 днів	База без дублів і суперечностей
Налаштування RAG + промпт	3–5 днів	Бот відповідає з контексту
Guardrails + преднаписані відповіді	2–4 дні	Критичні теми під контролем
Тест-набір і калібрування	1–2 тижні	Стабільна якість на каверзних запитах

Як MaxICo Labs це вирішує

Ми не ставимо «бота на голій моделі» — будуємо повний анти-галюцинаційний стек: RAG на вашій базі знань, guardrails, преднаписані відповіді для критичних тем і обов'язковий fallback «не знаю» з передачею людині. І калібруємо за реальними діалогами перші тижні.

• RAG-архітектура на вашій базі знань із цитуванням джерел.
• Guardrails і преднаписані відповіді для цін, політик, юридичних тем.
• Fallback-логіка й плавна передача оператору.
• Логування й донавчання після запуску.

Боїтеся, що бот вигадуватиме?

Напишіть Валерію в чат на сайті — покажемо, як влаштований наш анти-галюцинаційний стек на прикладі. Або забронюйте безкоштовний дзвінок: розберемо вашу базу знань і скажемо, де найбільший ризик галюцинацій і як його закрити.