Модель вигадує тоді, коли потрібного факту немає у вхідних даних, а відповідь від неї все одно чекають. Це передбачувана поведінка, і працювати з нею варто як з окремим класом операційного ризику: знати, де він виникає, скільки коштує помилка і хто перехоплює її до того, як вона дійде до клієнта.
Коротко
- Галюцинація ШІ - це відповідь, яка звучить правдоподібно, але спирається на факт, якого у вході не було. Модель продовжує текст найімовірнішим способом і на місце відсутнього факту ставить щось схоже на факт.
- Найчастіше вигадуються саме ті дрібниці, від яких залежать гроші: ціни, номери накладних, дати, кількості, суми, цитати з договору.
- Ризик росте в трьох ситуаціях: факту немає в розмові, факт загубився серед іншого матеріалу, або питання поставлене так, що чесна відповідь "у мене цього немає" виглядає провалом.
- Керувати цим можна: давати моделі джерело, вимагати посилання на рядок або файл, дозволяти відповідь "у даних цього немає" і звіряти результат контрольною цифрою.
- Усе, що йде клієнту або рухає гроші, перед відправкою звіряє людина з першоджерелом.
Як це виглядає в листуванні з клієнтом
Типова ситуація в невеликому інтернет-магазині. Клієнт пише в Telegram: "Скільки зараз коштує набір для кави на двох і де моя посилка?" Менеджер копіює питання в чат з моделлю, додає прайс, який лежав під рукою, і просить скласти ввічливу відповідь. За десять секунд готовий текст: набір коштує 1 240 гривень, посилка вже в дорозі, ось номер накладної, отримання очікується в четвер.
Текст гарний. Тон доброзичливий, номер накладної має правильну кількість цифр і правильний початок, ціна виглядає цілком ринковою. Менеджер відправляє. Через годину клієнт повертається: трек у службі доставки не знаходиться, а на сайті той самий набір коштує 1 490. Цього набору в прайсі взагалі не було, бо прайс лишився з минулого місяця, а накладну на замовлення ще навіть не створили.
Жодна з цих цифр не прийшла з даних магазину. Модель їх склала. І найнеприємніше в цій історії те, що з погляду самої моделі нічого надзвичайного не відбулося: вона зробила рівно те, для чого створена. Правильна відповідь у цій ситуації була б коротшою і менш гарною: ціни на цей набір у наданому прайсі немає, номера накладної в даних теж немає, треба перевірити на сайті і в кабінеті доставки. Така відповідь нікого не вразить, але вона не підводить ні менеджера, ні клієнта.
Що сталося зі ста тридцятьма укриттями
Те саме я бачив у зовсім іншому масштабі. Цього літа одна з команд, з якими я працюю над впровадженням, збирала міський геопортал з даними про укриття. Робота йшла в одній довгій розмові з моделлю: вивантаження, уточнення, нові файли, правки полів, знову уточнення. На початку модель рахувала точно. Через кілька годин команда попросила назвати кількість укриттів у вивантаженні, і модель відповіла: 25. У таблиці їх було 130.
Відповідь зовсім не виглядала як помилка. Число прийшло з коротким поясненням, у тому самому впевненому тоні, що й усі попередні правильні відповіді. Розбіжність помітили лише тому, що керівник проєкту пам'ятав порядок величини і здивувався, куди поділися сто з гаком укриттів. Коли почали розбиратися, з'ясували: на той момент більша частина таблиці вже випала з поля зору моделі. Чому довга розмова витісняє дані, окрема тема. Тут важливо інше. Модель не бачила 130, завдання вимагало числа, і вона дала число.
Між магазином і геопорталом різниця лише в масштабі. В обох випадках від моделі чекали конкретного факту, а факту перед нею не було.
Чому модель заповнює порожнечу
Щоб говорити про це предметно, треба на хвилину заглянути всередину. Мовна модель, яка стоїть за ChatGPT, Claude чи Gemini, навчена продовжувати текст. Вона прочитала величезну кількість листування, документів, таблиць і відповідей і знає, як зазвичай виглядає продовження. На питання "скільки коштує" в текстах далі йде число з валютою. На питання "де посилка" далі йде номер і дата.
Коли потрібне число є у вході, тобто в тому, що ви дали моделі в цій розмові, вона бере його звідти. Коли числа немає, механізм лишається тим самим: модель підставляє найправдоподібніше продовження. Вона знає формат накладної, знає, скільки приблизно коштують подібні товари, знає, як звучить впевнена відповідь менеджера. Форма в неї є. Факту немає. Так і народжується галюцинація: правдоподібний вихід без опори на факти у вході.
Звідси дві речі, які варто запам'ятати. Перша: за замовчуванням модель не позначає, яку частину відповіді вона взяла з ваших даних, а яку склала сама. Тон однаковий в обох випадках. Друга: чим конкретніше питання, тим конкретніша вигадка. Загальну пораду модель переказує з мінімальним ризиком, а ціну, номер чи суму скласти найлегше, бо саме тут текст вимагає точності, якої у вході немає.
Мені цей механізм знайомий з попереднього життя. Вісімнадцять років на фінансових ринках навчили мене одному питанню до будь-якого аналітичного звіту: звідки ця цифра. Цільова ціна акції без розрахунку під нею виглядає так само солідно, як і обґрунтована. Відрізнити їх можна тільки одним способом: попросити показати розрахунок і джерела. З моделлю працює те саме питання, і ставити його треба системно, а не тоді, коли щось уже здалося підозрілим.
Галюцинація як робочий ризик
Часто галюцинацію обговорюють як дефект, який розробники ось-ось виправлять. Я дивлюся на неї інакше. Нові моделі вигадують рідше, але механізм продовження тексту лишається в основі, і нуль тут недосяжний так само, як нуль помилок в обробці платежів. У банку такі помилки ніхто не лікує раз і назавжди. Їх описують, вимірюють, ставлять ліміти й контрольні точки. Галюцинація належить до того самого класу: операційний ризик з відомими умовами виникнення.
Умов три. Перша: факту немає у вході. Модель відповідає з пам'яті там, де потрібні ваші дані, як із прайсом минулого місяця. Друга: факт є, але загубився серед іншого матеріалу, як у геопорталі. Третя: питання сформульоване так, що відповідь "не знаю" виглядає провалом. Коли менеджер пише "дай клієнту точну ціну і трек", модель чує завдання видати ціну і трек, а звірку з даними вона сама собі не ставить.
На цьому місці мене часто питають, чи допоможе дорожча модель або підключений пошук в інтернеті. Для загальних знань допоможе частково. Для ваших внутрішніх фактів майже ні, бо ціни вашого магазину сьогодні вранці і номера накладної на вчорашнє замовлення немає ні в навчальних текстах моделі, ні у відкритому інтернеті. Ці факти живуть тільки у ваших таблицях, у вашій обліковій системі і в кабінеті служби доставки. Розумніша модель без доступу до них вигадує елегантніше, і відрізнити таку вигадку від правди стає ще важче. Тому перше питання до будь-якої відповіді з цифрою звучить однаково для всіх моделей: чи був цей факт у тому, що модель отримала на вході. Якщо був, можна просити посилання на рядок. Якщо не був, відповідь треба вважати чернеткою, навіть коли вона виглядає бездоганно.
Другий вимір ризику - ціна помилки. Вигадана ідея для назви акції коштує нуль: ви її відкинете. Вигадана ціна в листуванні з клієнтом коштує різниці в грошах і шматка довіри. Вигадана кількість укриттів на міському порталі коштує рішень, які люди ухвалюватимуть, спираючись на нього. Правило я формулюю так: чим дорожча помилка, тим вищий стандарт опори на джерело. Для чернеток достатньо уважного читання. Для всього, що йде клієнту, в рахунок, у договір чи в публічні дані, потрібне джерело у вході, посилання на нього у відповіді і звірка людиною.
Мій висновок з обох історій такий: модель вигадує передбачувано, у тих самих місцях і з тих самих причин, тому цей ризик закривається процесом, а надія на наступну версію моделі його не закриває. Компанія, яка знає, де в неї живуть ціни, треки й суми і звідки модель має їх брати, отримує від ШІ швидкість без неприємних сюрпризів. Компанія, яка покладається на впевнений тон відповіді, рано чи пізно відправить клієнту накладну, якої не існує.
Що робити далі
- Випишіть факти, які модель у вашому бізнесі ніколи не має складати сама: ціни, залишки, номери накладних, строки доставки, суми рахунків, умови договорів. Цей перелік і показує, де саме потрібна перевірка.
- Для кожної розмови, де звучать такі факти, давайте моделі актуальне джерело: сьогоднішній прайс, вивантаження статусів доставки, таблицю замовлень. Джерело у вході важить більше за будь-яку пам'ять моделі.
- Додайте в промпт дві вимоги. Для кожної цифри вказувати, з якого файлу чи рядка вона взята. Якщо потрібного факту в наданих даних немає, писати: "у даних цього немає". Так чесна відповідь перестає виглядати провалом і стає нормальною частиною роботи.
- Звіряйте результат контрольною цифрою. Перед аналізом попросіть модель назвати, скільки рядків чи позицій вона бачить у файлі, і порівняйте з тим, що знаєте самі. Якби в геопорталі поставили це питання першим, 25 замість 130 вискочили б одразу.
- Відповідь з ціною, треком чи сумою менеджер відправляє клієнту тільки після звірки з першоджерелом. Модель готує чернетку, людина натискає кнопку відправки.
Про цей матеріал
Текст спирається на практику впровадження ШІ в невеликих компаніях і командах, з якими я працюю. Історія з геопорталом узята з реальної робочої сесії, усі деталі, за якими можна впізнати проєкт, прибрані. Приклад з інтернет-магазином узагальнений з типових ситуацій, які я регулярно бачу в листуванні з клієнтами. Я Михайло Пацан, вісімнадцять років працював на фінансових ринках, а тепер допомагаю підприємцям упроваджувати ШІ і навчаю цього керівників.