Галюцинації ШІ: Чому це трапляється і як AI-інженери “лікують” моделі
RAG, промпти, верифікація та інші інструменти для надійності системи
У травні 2023 року адвокат Стівен Шварц подав до федерального суду Нью-Йорка документ, який назавжди увійде в історію як застережна історія про AI. Захищаючи свого клієнта у справі проти авіакомпанії Avianca, він використав ChatGPT для пошуку релевантних судових прецедентів. AI впевнено надав йому список з шести судових рішень.
Проблема? Жодна з цих справ не існувала. Коли Шварц попросив ChatGPT підтвердити ці справи, AI з упевненістю надав вигадані витяги з рішень, повні правдоподібними деталями.
Ця історія – симптом фундаментальної властивості великих мовних моделей. Навіть найсучасніші LLM галюцинують у 3-27% випадків. Для бізнесу це означає фінансові втрати, операційний хаос та навіть юридичну відповідальність.
Тут на сцену виходить AI engineering – дисципліна, яка перетворює хаос LLM на надійні системи. У цій статті ми розберемо арсенал AI engineering-спеціаліста для боротьби з галюцинаціями – від архітектурних патернів до роботи з промптами.
Що таке галюцинації та чому вони виникають
AI галюцинації – це не просто помилки. Це випадки, коли модель генерує переконливий, але хибний контент з такою ж упевненістю, як і правдиву інформацію. Їх є кілька типів.
Типи галюцинацій
- Фактичні галюцинації. Вигадані факти, які можна перевірити: неправильні дати, несправжні дослідження, помилкові цифри. Небезпечні тим, що звучать авторитетно і їх легко прийняти за правду.
- Контекстні галюцинації. Ігнорування наданого контексту: відповідь про продукт Б замість А, приклад на Python замість JavaScript, використання даних Q1 у звіті про Q3. Критично для RAG-систем, де модель має працювати строго з наданими документами.
- Конфабуляції. Модель додає правдоподібні деталі, які органічно вписуються в наратив, але є вигаданими. Наприклад, "експертні" деталі про смерть Шекспіра або мотивації історичних персонажів, яких ніхто не документував. Їх найважче виявити, бо вони логічно "заповнюють пробіли".
Чому моделі галюцинують
LLM – це не бази знань, а системи передбачення наступного токену. Коли ви запитуєте про дату заснування Tesla, модель не "шукає" факт, а статистично передбачає найімовірнішу послідовність токенів.
Можна уявити це у форматі гри:
Столиця України – легко, столиця Мавританії – складніше, і ви вгадуєте щось, що звучить приблизно правильно. Так працює LLM, але з мільярдами параметрів. Коли інформації недостатньо або вона суперечлива, модель все одно генерує щось правдоподібне – і це може бути хибним.
Також, є конфлікт між креативністю та точністю. У LLM, параметр temperature (0.0-1.0) контролює варіативність відповідей. Низький – детерміновані відповіді, високий – креативні. Але навіть при низькому temperature модель може галюцинувати без надійних даних. А високий temperature збільшує ризик конфабуляцій і модель активніше "імпровізує".
Зрештою, не варто забувати й те, що моделі вчаться на інтернеті, де є:
- Суперечлива інформація
- Застарілі дані ( а модель "заморожена" у часі тренування)
- Fictional контент (книги, сценарії, які модель може сплутати з фактами)
- Низькоякісні джерела (як от форуми)
- Навмисна дезінформація.
Якщо 100 джерел помиляються, а 10 правильні – модель статистично обере "більшість".
Архітектурні підходи як спосіб уникнути галюцинацій
Архітектурні підходи – це фундамент надійної AI системи. Їх є декілька.
RAG
RAG, або ж Retrieval-Augmented Generation – це найпопулярніший метод боротьби з галюцинаціями. Замість того, щоб покладатися на "пам'ять" моделі, він надає їй доступ до перевіреної бази знань. Працює це за принципом: пошук → контекст → генерація.
- Пошук – система шукає релевантну інформацію у вашій базі знань (документація, статті, специфікації)
- Контекст – знайдені документи додаються до промпту.
- Генерація – модель відповідає на основі наданого контексту, а не своєї "пам'яті".
Для прикладу чудово підійде HR-бот, який так поширений у компаніях. Уявімо, що він відповідає на питання про внутрішні політики компанії. Без RAG, модель вигадуватиме ці політики, в той час як з RAG, процес відрізняється:
Зібрати HR документи → розбити на chunks по 300 токенів → створити embeddings → зберегти у vector DB → при запиті шукати top-5 chunks → генерувати відповідь із джерелами
Як результат, модель видаватиме відповідь, на кшталт "Згідно з Employee Handbook 2026, ви маєте 10 sick-leave-ів. [Джерело: p.23]"
Fine-tuning для специфічних доменів
Fine-tuning – це "навчити модель спеціалізації". Цей підхід ідеальний, якщо у вас є специфічний домен з унікальною термінологією (медицина, право), вам потрібен консистентний стиль відповідей, а точність – критична.
Втім, варто памʼятати, що fine-tuning на вузькому домені може погіршити загальні здібності моделі. Як лікар, що спеціалізується на кардіології, може "забути" інше.
Щоб не плутатись, основні trade-offs виглядають так:
- Вартість. RAG дешевше ($50-200/міс), fine-tuning дорожче ($100-1000+)
- Час. RAG – дні, fine-tuning – тижні
- Результат. RAG – гнучкість і легкість оновлень, fine-tuning – вища точність на специфічних завданнях.
Гібридні підходи
Найкращі результати дає комбінація підходів.
1. RAG + fine-tuning. Fine-tuned модель розуміє домен, RAG додає свіжі факти.
2. Multiple Model Verification. Кілька моделей перевіряють відповіді одна одної. Так, наприклад, існує:
- Паралельна верифікація (дві моделі відповідають і їх відповіді порівнюються)
- Checker модель (одна генерує, друга перевіряє)
- Ensemble (кілька моделей генерують, а ми шукаємо консенсус).
3. Confidence scoring. Модель оцінює свою впевненість. Якщо впевненість нижче порогу у 70%, модель просить уточнення або ескалює до людини.
Prompt engineering: Як запитувати правильно?
Правильно сформульований промпт може драматично знизити галюцинації навіть без зміни архітектури. Для цього, є кілька підходів:
- Chain-of-thought prompting – примушуємо модель "думати вголос"
Коли модель пояснює хід думок крок за кроком, вона рідше галюцинує. Кожен крок має бути логічним продовженням попереднього. Магічна фраза: "Let's think step by step" – активує chain-of-thought. Ефективно для математики, логіки, аналізу.
- Few-shot examples – показуємо, що хочемо бачити
Замість описувати — покажіть приклади. Модель навчається на патернах. Навіть кілька прикладів дають стабільніші результати, адже показують формат, рівень деталізації, граничні випадки.
- Constraining outputs – обмеження формату
Чим менше свободи, тим менше галюцинацій. Скажімо, якщо задати загальне питання про погоду у Києві, модель може вигадати температуру. Якщо ж просити модель відповідати лише сонячно/хмарно/дощ/сніг/невідомо – вона ймовірніше використовуватиме фактичні дані.
- Explicit instructions – "якщо не знаєш – скажи"
За замовчуванням моделі намагаються "допомогти" навіть без впевненості. Дозвольте визнавати незнання.
Structured outputs та їх роль
Структуровані виходи – строго визначений формат. Це драматично знижує галюцинації. Робити це, знову ж, можна різними способами.
1. Валідація у JSON форматі
Такий output легко валідувати, модель не може "піти в сторону", а невідоме поле – null замість вигадок.
Витягни дані у JSON:
Текст: "Іван Петренко, 32 роки, розробник у Києві"
Схема:
{
"name": string,
"age": number,
"profession": string,
"city": string
}
2. Function calling для детермінованих результатів
Модель викликає функцію з параметрами замість генерації фактів. Так, вона не генерує факти, а отримує їх через API і параметри валідуються.
# Користувач: "Яка погода у Києві?"
# Модель викликає: get_weather(city="Київ")
# Система → реальні дані через API
# Модель форматує: "У Києві 15°C, хмарно"
3. Template-based generation
Шаблони з placeholder'ами – модель заповнює, але не може змінювати структуру. Це дає більше консистентності, контролю і менше свободи моделі.
Email шаблон:
---
Тема: [тема]
Шановний/на [ім'я],
[основний текст — 2-3 речення]
[заклик до дії]
З повагою, [підпис]
---
Verification layer: Системи перевірки
Навіть найкращі промпти не гарантують 100% точності. Verification layer – "страхова сітка", яка ловить галюцинації перед користувачем.
Automated fact-checking
- Cross-referencing з базами знань. Автоматично перевіряємо кожен факт, звіряючи з надійними джерелами.
1. Модель: "Київ засновано у 482 році"
2. Система виділяє: [Київ, заснування, 482]
3. Cross-reference з Wikipedia/БД
4. Результат: ✓ Підтверджено / ⚠️ Суперечить / ? Не знайдено
- Source citation requirements. Вимагаємо завжди вказувати джерело. Немає джерела = відповідь відкидається.
- Automated contradiction detection. Перевіряємо, чи не суперечить відповідь сама собі або контексту. Це критично для фінансових звітів, медичних рекомендацій, юридичних документів.
Multi-model consensus
- Використання кількох моделей для верифікації. "Інакша думка" від іншої моделі може виявляти галюцинації першої.
Query: "Коли засновано Tesla?"
GPT-4: "2003" (confidence: 0.9)
Claude: "2003" (confidence: 0.85)
Gemini: "2004" (confidence: 0.6)
Група "2003": 1.75 → Winner ✓
Якщо ж консенсусу немає, відповідь може позначитись "uncertain". Далі, або залучаються додаткові моделі, або питання ескалюється до людини.
На завершення
Важливо розуміти, що галюцинації – не баг, а фіча. Їх не виправити ніяк, адже це фіча LLM. Від того, питання не "Як зробити модель досконалою?", а "Як побудувати надійну систему з недосконалою моделлю?".
Справжній AI Engineer будує системи, яким довіряють мільйони, які працюють стабільно і стають розумнішими з часом. Галюцинації не зникнуть, але з правильним підходом вони не заважають створювати цінність. Саме це, та ще купу всього іншого вивчають студенти курсу AI Engineering.
