Ловимо галюцинації ШІ: 3 запобіжники для B2B-команд

Як виглядають галюцинації ШІ в реальних B2B-воркфлоу

Галюцинація — це коли модель генерує впевнено звучну, але неправильну відповідь. У B2B зустрічається в трьох класичних формах: (1) вигадує неіснуючий номер замовлення для запиту в підтримку, (2) "цитує" дату, якої немає в договорі, при підсумуванні, (3) винаходить нову категорію при класифікації рахунків поза заданим набором.

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

Три запобіжники: джерело, правило, людина

Перевірка джерел: показуйте документ і фрагмент, що підтверджує відповідь; перевіряйте зв’язок із твердженням, а не лише наявність посилання. Відсутні або суперечливі відомості передавайте на перевірку.

Перевірка правил: код застосунку має перевіряти існування замовлення, повноваження, суму та дозволену категорію. Правильний формат не доводить достовірність.

Схвалення людиною: перед платежем, поверненням або зобов’язувальним повідомленням уповноважена особа має побачити точний результат. Зміни потребують нового схвалення. Універсального відсотка успіху немає. Тестуйте правильні, хибні й непідтверджені відповіді: недопустимий результат має блокуватися, а черга перевірки — доходити до відповідального.

Побудова процесу оцінювання перед запуском

Оцінити частоту галюцинацій "на око" неможливо — потрібен тестовий набір. Створіть еталонний набір із 50–200 реальних прикладів із відомими правильними відповідями і переконайтеся, що він охоплює крайні випадки — відсутні дані, неоднозначні запити, запити поза межами компетенції. Прогоняйте модель через нього перед кожною зміною промпту чи моделі, а не лише на етапі запуску.

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

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

Ставтеся до цього як до живого конвеєра, а не одноразового бар'єру. Щоразу, коли ви змінюєте промпт, замінюєте модель чи додаєте нове джерело документів, повторно прогоняйте оцінювальний набір і порівнюйте нові показники точності та відмов із базовим рівнем перед розгортанням. Це та сама дисципліна, що й регресійне тестування в традиційному програмному забезпеченні, — тільки тут перевіряють судження, а не логіку.

Які завдання несуть найбільший ризик галюцинацій

Ризик визначається не лише вільною чи структурованою формою тексту. Хибний бухгалтерський запис у дозволеній категорії теж може завдати шкоди. Оцініть наслідки, зворотність, чутливість даних і користувачів результату. Підготовка чернетки не повинна давати ті самі права, що звернення до клієнтів або рух грошей.