Агент підтримки відповів на запит користувача щодо скидання двофакторної автентифікації кроками, яких просто не існує. Відповідь виглядала впевненою, HTTP-запит повернув 200 OK, затримка була в нормі, а всі графіки моніторингу залишалися зеленими.

Агент підтримки на базі ШІ згенерував галюцинацію, оскільки внутрішні перевірки, які мали б виявити помилку, так і не були запущені. Дашборди, на які покладаються інженери, повідомляли про бездоганну роботу, тоді як агент мовчки вигадував рішення.

Чому традиційні дашборди пропускають галюцинації ШІ

Більшість стеків спостережуваності (observability stacks) ставляться до ШІ-агента як до будь-якого іншого мікросервісу: один вхідний запит і одна вихідна відповідь. Вони реєструють HTTP-статус, час відповіді та кількість помилок. Вони не реєструють приховані кроки всередині запиту — пошук (retrieval) зовнішніх документів, виклики великих мовних моделей, використання допоміжних інструментів та будь-яку логіку захисних механізмів (guard-rails), що перевіряє результат.

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

Перетворення «чорної скриньки» на зрозуміле дерево

Першим кроком до надійного налагодження є відмова від сприйняття агента як монолітного виклику та початок візуалізації кожної внутрішньої операції як окремого рядка в таблиці трасування (trace table). Типовий запуск складається з:

  • Виклик агента верхнього рівня
  • Крок пошуку (retrieval), який витягує відповідну документацію
  • Кожен інференс (inference) мовної моделі, що обробляє отримані дані
  • Кожен виклик інструменту (наприклад, пошук у базі даних, API-запит)
  • Перевірки захисних механізмів (guard-rails), що забезпечують фактологічну точність або відповідність політикам

Кожен рядок фіксує мітку часу, прапорець успіху та корисне навантаження (payload), що проходило через цей крок. Завдяки такій структурі виконання перетворюється на дерево, яке можна перевіряти рядок за рядком, а не намагатися вгадати причину за фінальним результатом.

Помилка, що проскочила повз увагу

У невдалій взаємодії з підтримкою трасування виглядало так:

  1. Пошук (Retrieval) відбувся, але не повернув жодних документів.
  2. Наступний крок відбувся попри це, передавши моделі порожній контекст.
  3. Модель згенерувала відповідь, заповнивши відсутню інформацію вигаданими кроками.
  4. Система повернула 200, оскільки в конвеєрі (pipeline) не виникло винятків.

Галюцинація не була недоліком самої мовної моделі; це була відсутність захисного механізму (guard-rail) між етапами пошуку та генерації. Агент надав відповідь, навіть коли йому не на що було спиратися для обґрунтування своєї відповіді.

Прості захисні механізми, що зупиняють галюцинації

Дві конкретні зміни усунули проблему:

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

Практичний робочий процес для швидшого налагодження

  1. Трасуйте кожен внутрішній виклик — налаштуйте інструментарій агента так, щоб кожен пошук, інференс моделі та використання інструменту записували рядок у постійний лог.
  2. Зберігайте невдалі запуски — зберігайте повне трасування будь-якої взаємодії, яку користувач позначив як неправильну. Видалення таких даних для економії місця приховує інформацію, необхідну для пошуку регресій.
  3. Тегуйте запуски інформацією про версію — додавайте ідентифікатор релізу та стан будь-яких прапорців функцій (feature flags) у кожен рядок трасування. Це дозволить пов'язати новий баг із нещодавньою зміною коду.
  4. Оцінюйте якість, а не лише швидкість — додайте метрики, які вимірюють, наскільки добре відповідь відповідає інструкції та чи базується вона на знайденому контенті. Висока пропускна здатність мало що означає, якщо відповіді неправильні.
  5. Щодня переглядайте помилки — короткий регулярний огляд збережених збоїв часто виявляє закономірності (наприклад, певний тип запитів постійно повертає порожні результати пошуку) ще до того, як вони вплинуть на багатьох користувачів.

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

Ціна ігнорування внутрішніх збоїв

Коли дашборди повідомляють про успіх лише на рівні HTTP, організації розгортають агентів, які здаються надійними, але регулярно надають неправильні вказівки.

Що переглянути далі

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

Головний висновок: Зелений дашборд свідчить про те, що внутрішні механізми працюють; він не гарантує, що відповідь правильна. Відстежуючи кожен процес пошуку (retrieval), виклик моделі та перевірку захисних механізмів (guard-rail), ви перетворюєте приховані галюцинації на видимі збої, які можна виправити до того, як вони потраплять до користувача.