Що таке галюцинації та чому вони з'являються
Галюцинація в LLM - це генерація інформації, яка звучить правдоподібно, але є неправдивою або необгрунтованою. Це не "помилка" у сенсі аварії системи, а радше наслідок роботи мовних моделей. LLM не "знає" нічого так, як знає база даних. Вона передбачає найімовірніший наступний токен на основі статистики навчання. Коли в промпті з'являється питання, на яке модель не має доброго покриття в навчальних даних, вона генерує відповідь, яка звучить найімовірніше. Часто вона правильна. Інколи ні.
Типові сценарії галюцинацій у бізнес-застосуваннях:
- Цитування неіснуючих судових рішень або статей законів під час юридичних консультацій
- Вигадування назв функцій, класів або бібліотек під час генерації коду
- Надання неправильної статистики або дат у звітах
- Вигадування контактів, адрес, номерів телефонів
- Перемішування фактів щодо різних компаній або осіб з подібними назвами
Шар 1: ґрунтування (RAG)
Найефективніша окрема техніка зниження галюцинацій - це ґрунтування, тобто надання моделі конкретних документів або даних як контексту, з якого вона повинна черпати відповіді. Класичний RAG (Retrieval-Augmented Generation) виглядає так:
- Питання користувача → пошук найвідповідніших фрагментів документів (vector search у базі pgvector / Qdrant / Milvus)
- Фрагменти + питання → промпт з інструкцією "відповісти виключно на підставі нижченаведених документів"
- Відповідь моделі → верифікація, що вона містить цитати або посилання на джерела
RAG чітко обмежує галюцинації в застосунках типу "відповісти на питання про нашу базу знань". Не усуває їх повністю: модель все ж може "інтерпретувати" документи недопустимим чином. Тому потрібні наступні шари.
Шар 2: самоспівність та ансамбль
Самоспівність полягає в тому, щоб поставити одне й те саме питання кілька разів (або кільком різним моделям) та порівняти відповіді. Співні відповіді означають високу довіру. Розбіжні - це сигнал про те, що тема є невизначеною.
Практична варіація: запитайте Claude Sonnet, Llama 70B та Bielika про одне й те саме. Якщо всі три повертають одну й ту ж саму кількість, дату чи факт, відповідь, ймовірно, правильна. Якщо вони відрізняються, справу перебирає людина або дорожчий модель (Opus). Цей шаблон, реалізований у 8-рівневому маршрутизації LLM, поєднує зменшення витрат з покращенням достовірності.
Шар 3: оціночні трубопроводи
Виробнича реалізація LLM без оціночної труби - це як написання коду без тестів. Конкретні метрики:
- Вірність: чи відповідає відповідь наданим документам. Вимірюється другим моделлю AI (LLM-as-judge) або бібліотекою типу RAGAS, deepeval.
- Релевантність відповіді: чи відповідає відповідь питанню користувача.
- Точність контексту: чи повернув пошук найкращі фрагменти (якість vector search).
- Оцінка ґрунтовності: відсоток тверджень у відповіді, для яких можна вказати джерело у контексті.
Кожен новий збірка програми на основі LLM має проходити набір оціночних питань із відомим ґрунтовним фактом (наприклад, 50-500 питань). Прикладовий поріг, обраний для кожної реалізації: вірність нижче 90%? Розгортання заблоковано.
Шар 4: обмежувачі та валідация вихідних даних
Guardrails — це правила перевірки виводу LLM до того, як він потрапляє до користувача. Приклади:
- Schema validation: вивід мусить відповідати певній схемі (JSON Schema, Pydantic). Галюцинації типу «вигадані поля» виявляються механічно.
- Forbidden patterns: виявлення та блокування недопустимих шаблонів (PII без маскування, фінансові дані поза контекстом, потенційно шкідливі контенти).
- Citation enforcement: кожне фактичне твердження мусить мати посилання на джерело. Якщо модель не посилається, відповідь відхиляється.
- Numeric range validation: числа у виводі перевіряються на відповідність сенсу (наприклад, ціна > 0, дата ≤ сьогодні, процент у діапазоні 0-100).
- Cross-reference check: порівняння виводу з базою фактів (наприклад, KRS, словник цитат законів).
Бібліотеки: Guardrails AI, NeMo Guardrails, instructor (для schema enforcement). Власна реалізація часто простіша та дешевша в підтримці.
Шар 5: human-in-the-loop
Для застосунків високого ризику (правові, медичні, фінансові, кадрові рішення) шар human-in-the-loop є необхідним. Моделі AI не приймають остаточне рішення. Вони підтримують людину. Конкретні шаблони:
- Чернетка + перегляд: AI генерує першу версію документа або відповіді, людина перевіряє та приймає перед відправленням.
- Поріг довіри: відповіді з низьким рівнем довіри (із самоузгодженості або з явного питання про впевненість) автоматично потрапляють до людини.
- Випадковий вибірковий контроль якості: наприклад, 5-10% усіх відповідей LLM (поріг підбирається індивідуально для кожного впровадження) аудитується вручну, незалежно від рівня довіри. Це базова метрика якості у часі.
- Зворотній зв'язок: користувач може позначити помилкову відповідь; система вчиться та покращує пошук, промпти, параметри.
Вимірювання: як знати, що redukcja працює
Виробничі метрики для постійного моніторингу:
- Коефіцієнт галюцинації: відсоток відповідей, класифікованих як галюцинація під час ручної оцінки (випадковий вибірковий контроль). Прикладна мета, підібрана індивідуально для кожного впровадження: нижче 2% для бізнес-критичних застосунків.
- Рейтинг зворотного зв'язку користувача: відсоток користувачів, які позначили відповідь як помилкову.
- Рейтинг ескалації: відсоток запитів, переданих людині. Занадто низький (нижче 5%) свідчить про те, що система пропускає невпевнені випадки. Занадто високий (вище 30%) означає, що система не надає автоматизаційної цінності.
- Оцінка вірності у регресійних тестах: місячний тренд.
- Час до виправлення: від виявлення галюцинації до впровадження виправки (кращий пошук, новий бар'єр, тонке налаштування).
Висновки для рішень
Галюцинації можна керувати, але це вимагає інвестицій в оборонну архітектуру на кількох рівнях. Компанії, які впроваджують LLM без цієї архітектури, рано чи пізно зіштовхнуться з серйозним інцидентом: публікацією неправильної інформації клієнту, неправильним рішенням на підставі вигаданих даних, шкодою для репутації. Вартість побудови повного захисного стека (RAG + evaluation + guardrails + human-in-the-loop) є помітною, але меншою частиною вартості самого впровадження LLM. Для продуктивних застосувань це необхідна інвестиція. Наслідки пропуску асиметричні: зазвичай знехтування нічого не коштує, доки не коштує катастрофічно.