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

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

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

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

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

1) Цитата джерела: модель повертає кожну відповідь з id або номером рядка вихідного документа. Без джерела відповідає «не знаю». Галюцинації падають на ~80%.

2) Перевірка правилами: валідуємо вивід за доменними правилами до видачі — номер замовлення 8 цифр? Категорія рахунку в списку? Формат дати валідний? Ці дешеві Python-перевірки ловлять більшість.

3) Людське схвалення: ризиковані дії (повернення, підписання договору) пропонує ШІ, схвалює людина. ШІ робить ~95% сам; 5% винятків ідуть до вас на рев'ю.

Три разом: у незалежному аудиті відсоток галюцинацій падає нижче 2%.

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

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

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

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

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

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

Не всі завдання зі ШІ несуть однаковий ризик, тому й бюджет на захисні механізми не варто розподіляти порівну. Відкрита генерація — складання листа клієнту, резюмування наради, написання маркетингового тексту — залишає простір для творчості, але саме в цьому просторі й ховаються галюцинації: вигадана статистика, придумані цитати, обіцянки, яких компанія ніколи не давала. Це категорія найвищого ризику, бо немає фіксованого "правильного" результату для звірки — лише діапазон прийнятних варіантів.

Числове й фінансове вилучення даних йде відразу за нею. Отримання підсумкової суми з рахунку, розрахунок знижки, вилучення податкового номера — помилки тут тихі (число виглядає правдоподібно) і дорогі (напряму впливають на рух грошей). Юридичні та близькі до медичних твердження — договірні зобов'язання, заяви про відповідність нормам, формулювання щодо дозування чи безпеки — належать до тієї самої категорії високого ризику: помилившись один раз, ви отримуєте не незручність, а юридичну відповідальність.

На іншому кінці спектра структуроване вилучення за фіксованою схемою — розібрати резюме на ім'я/email/навички, класифікувати заявку в одну з 12 категорій, позначити транзакцію кодом продавця — має порівняно низький ризик. У моделі менше простору для вигадок, бо простір результатів обмежений і легко перевіряється механічно: можна переконатися, що категорія існує, email містить символ @, значення — один із 12 варіантів. Класифікація в невеликий закритий набір поводиться так само — навіть коли модель помиляється, вона робить це в межах визначених вами кордонів, а це принципово дешевший тип помилки.

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