# Галюцинації AI-агента — що робити, коли агент бреше

> Практичний owner-плейбук handling-у галюцинацій у production-агентах. Чотири першопричини, чотири мітигації, і як Plan → Fact → Gap ловить невидимий drift до того, як це коштуватиме клієнта.

- Автор: Ярослав Максимович (Founder & CEO, AI Advisory Board)
- Опубліковано: 2026-05-08
- Оновлено: 2026-10-26
- Джерело: https://aiadvisoryboard.me/uk/blog/ai-agent-hallucination-handling

Якщо ви власник, чий AI-агент щойно впевнено процитував клієнту неіснуючу refund-політику — вітаю в клубі. Галюцинації — не баг, який можна патчити; це властивість технології, і питання не "як прибрати", а "як стримати".

## TL;DR

- Галюцинації — систематичні, не випадкові: чотири першопричини, з якими можна працювати.
- Фікс — не лише кращі промпти; це grounding (RAG), guardrails, ескалація та observability разом.
- Klarna відкотила повністю-AI customer-service агента в 2025 тому, що ескалація була повільною, а не тому, що агент галюцинував більше за очікуване.

## Що таке "галюцинація"

Галюцинація — коли LLM-агент видає контент, що звучить упевнено й правдоподібно, але фактологічно невірний, вигаданий або суперечить джерелу. У продакшені найбільш руйнівні — не очевидні (їх ловлять), а тонкі: трохи неправильна сума інвойса, "майже-правильна" refund-політика, summary дзвінка, що неправильно атрибутує рішення.

> **Визначення:** Галюцинація — output LLM, поданий упевнено, але не заземлений у вхідних даних чи перевірних фактах. Відрізняти від "модель не знає" — галюцинації трапляються навіть з правильними даними.

## Чотири першопричини (і як це виглядає)

### 1. Відсутній контекст

В агента немає правильних даних — він вигадує правдоподібне. Найчастіше і найлегше виправити.

Виглядає як: "Refund — 5-7 робочих днів", коли реальна політика — 14 днів.

### 2. Конфліктний контекст

Кілька джерел, що сперечаються. LLM обирає одне (часто найдовше або найновіше) без позначки конфлікту.

Виглядає як: відповідає по FAQ v3 з 2023, хоча v5 теж у retrieval.

### 3. Goal drift

Задача агента двозначна — вирішує трохи іншу проблему. Часто "корисно, але не те".

Виглядає як: клієнт питає "можу скасувати?", агент пояснює загальний процес — а клієнт питав про конкретну non-cancellable підписку.

### 4. Впевнена екстраполяція

Агент узагальнює конкретний кейс до універсального ствердження. Найважче ловити — звучить розумно.

Виглядає як: "так, ваша гарантія покриває залиття водою" — бо агент бачив гарантії, що покривають, а ваша — ні.

## Чотири-шаровий стек мітигацій

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

### Шар 1: Grounding (правильний RAG)

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

> **Визначення:** RAG (Retrieval-Augmented Generation) — патерн, де агент дістає релевантний контекст з перевіреної бази до відповіді й бажано цитує.

### Шар 2: Guardrails

Механічні правила, що ловлять очевидно поганий output. "Якщо агент називає суму — вона має бути в джерелі". "Якщо цитує політику — вона має існувати в базі". Це не LLM-judged, а детерміновані перевірки.

### Шар 3: Ескалація

Низька впевненість, висока неоднозначність, високі ставки — передавайте людині. Stanford 51-deployment study: escalation-routing дає ~71% productivity gain проти ~30% у approval-routing. Klarna в 2025 відкотилась саме тому, що ескалація була повільною, коли потрібна була.

### Шар 4: Observability

Логуйте кожен prompt, retrieval, tool-call, output. Семплте 1-5% output-ів щодня для людського QA — не щоб перевіряти агента, а щоб ловити drift. Так ловиться goal drift і впевнена екстраполяція, які guardrails пропускають.

## Manager scan (2-minute digest example)

Для власника, що наглядає за одним чи кількома агентами в проді, щоденний моніторинг — три рядки на агента. Plan → Fact → Gap працює тут так само, як для людських команд.

- **Plan:** "Support-агент має deflect-ити 60% tier-1 тікетів, ескалювати 40%, з <2% factual errors."
- **Fact:** "Вчора: 71 тікет. 58% deflect, 42% ескалація, 4% позначені QA як factual error."
- **Gap:** "Error rate подвоївся. 3 з 4 помилок — агент вигадав discount, якого нема. У базі знань стара промо-дата з Q3 2025."

Цей трійник по всіх агентах — ваш денний AI-ops digest. Він каже, що галюцинаційна проблема вариться — зазвичай ще до клієнтів.

> **Tool tip (AIAdvisoryBoard.me):** Галюцинації рідко прилітають одним драматичним інцидентом — вони приходять як drift, який ви не помічаєте 2 тижні. Діагностика **Plan → Fact → Gap** автоматично показує цю прогалину — для кожного агента й кожної команди — щойно factual error rate, escalation rate чи output volume почали відхилятися від плану, ви бачите це наступного ранку. Без цієї лінзи проблеми галюцинацій ростуть мовчки. З нею — тріажуються за 24 години.

## Copy-paste triage template

Коли інцидент репортнутий:

```
Incident ID: ____________________
Agent: __________________________
Repored by: _____________________
Affected user: __________________

1. Що сказав агент (verbatim)?
   _______________________________________

2. Що було коректно?
   _______________________________________

3. Гіпотеза першопричини (одне):
   [ ] Missing context
   [ ] Conflicting context
   [ ] Goal drift
   [ ] Confident extrapolation

4. Аудит джерела:
   - Чи правильна відповідь є в базі знань? y/n
   - Коли востаннє оновлювалася? _________

5. Мітигація:
   [ ] Оновити дані-джерело
   [ ] Додати guardrail-перевірку
   [ ] Затягнути retrieval prompt
   [ ] Знизити confidence threshold для ескалації
   [ ] Інше: _______________________________

6. Комунікація постраждалому:
   _______________________________________
```

## Погано vs добре

**Поганий дизайн (схильний до галюцинацій)**:

- Без цитування джерел
- Один глобальний system prompt на все
- Confidence threshold не виставлений
- Ескалація як "nice to have"

**Добрий дизайн (стійкий)**:

- Кожне фактологічне твердження цитує джерело
- Retrieval скоупається під тип запиту
- Confidence threshold видимий і tunable
- Ескалація як основний шлях з owner-ом і SLA

## Micro-case (що змінюється за 7-14 днів)

Профсервісна фірма на 150 людей крутить client-facing агента знань. 1-й тиждень: 4-6% відповідей містять factual errors при QA. Вмикають три зміни — обовʼязкове цитування, guardrail, що блокує output з числом, якого нема в джерелі, і знижують escalation threshold з 0.6 до 0.75. За 7 днів error rate падає до ~1%. За 14 — <0.5%. Escalation rate тимчасово росте з 8% до 22% (через нижчий поріг), повертається до ~12%, коли промпти й retrieval покращуються. Customer-complaint count на агента — нуль на 3-му тижні.

> **Note on this case:** Цей приклад ілюстративний — типові патерни для компаній 30-500 людей, не один названий клієнт. Цифри округлені, не гарантії.

> **Tool tip (AIAdvisoryBoard.me):** Проблеми галюцинацій — це проблеми менеджменту, замасковані під технічні. Технічні фікси (RAG, guardrails, escalation) відомі; failure-pattern — ніхто в компанії не моніторить fact-vs-plan delta агента щодня. AIAdvisoryBoard.me крутить цей моніторинговий цикл за вас — по кожній команді, агенту, дню — показуючи **Plan → Fact → Gap** щойно поведінка агента відхиляється від обіцяного. 7-денна діагностика показує, що "пливе" до того, як це помітять клієнти.

## Що НЕ виправляє галюцинації

- **Більша модель** — допомагає скромно; розрив між сьогоднішньою flagship-моделлю і торішньою — реальний, але малий. Не заміна grounding.
- **"Креативніші" промпти** — prompt engineering на маржі; структурні фікси (RAG, guardrails) — на порядок вищі.
- **Сказати "не галюцинуй"** — має малий позитивний ефект, легко переоцінити. Модель не може надійно сказати, коли галюцинує.
- **Fine-tuning** — корисний для тону й формату, скромно для factual reliability у SMB-кейсах.

## FAQ

**Чи "human in the loop" на кожен output?**
Тільки коли вартість помилки висока. Клієнтські фінансові/юридичні відповіді — так. Внутрішній first-draft листа — ні. Калібруйте за ставками, не за принципом.

**Як часто семплити для QA?**
Старт — 5% output-ів щодня, осідаємо на 1-2% при стабільності. Сенс семплу — ловити drift, не валідувати агента end-to-end.

**Чи розв'яже це наступне покоління моделей?**
Ні. Стане менше, але це артефакт того, як LLM працюють. Плануйте, ніби галюцинації постійні; калібруйте зусилля по тому, що дійсно покращується.

**Юридична експозиція?**
Залежить від юрисдикції і сектора. EU AI Act жорстко з high-risk (біометрія, кредит, employment); споживацькі агенти в retail/SaaS — стандартне consumer-protection. Чітке "це AI-асистент" + задокументована ескалація — базова лінія.

## Підсумок

Галюцинації — не дефект для виправлення, а властивість для управління. Grounding — щоб не було найчастіших; guardrails — щоб ловити очевидні; ескалація — для high-stakes; observability — щоб ловити drift раніше клієнтів. Власники, які програють цьому, ті, хто вирішив, що це "технічна проблема", і перестав міряти її як щоденну ops-метрику.

Наступний крок: оберіть одного production-агента. 7 днів логуйте Plan → Fact → Gap по hallucination rate. Дійте на gap.

Якщо хочете систему, що автоматично щодня показує Plan → Fact → Gap по всій компанії — подивіться, як працює 7-денна діагностика: [https://aiadvisoryboard.me/?lang=en](https://aiadvisoryboard.me/uk)

---

Цитуючи, посилайтесь на https://aiadvisoryboard.me/uk/blog/ai-agent-hallucination-handling. Більше статей: https://aiadvisoryboard.me/uk/blog