Коли AI гадає, а бізнес платить: як не дати системі прийняти помилкове рішення

💡 Усі статті, обговорення, новини про AI — в одному місці. Приєднуйтесь до AI спільноти!

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

Проблема: модель, що не вміє мовчати

Уявіть реальний кейс із системи комп’ютерного зору. Модель аналізує фото листка при поганому освітленні. Результат: Дуб звичайний — 36%, Дуб червоний — 34%.

З точки зору математики нейронки — все ок, вона вибрала найбільш імовірний клас. Але з точки зору бізнес-логіки — це гадання на кавовій гущі. Різниця всього у 2% означає, що модель до кінця не розуміє, що перед нею, і її внутрішня впевненість практично відсутня. Стандартна архітектура сприймає ці 36% як «остаточне рішення» і передає його далі по ланцюжку. У продакшен «улітає» топ-1 клас, хоча в реальності цей випадок варто помітити і відправити на перевірку.

Звісно, в даному прикладі мова про листки, і ціна помилки не критична — максимум хтось отримає некоректну позначку у своєму ботанічному додатку.

Але така ж ситуація може статися в медицині при діагностиці знімків там ціною може бути здоров’я або навіть життя. Тому сліпо довіряти прогнозам з неймовірно малою різницею між класами — це не просто технічний недолік, а потенційно небезпечна практика. Я впевнений, ви згодні.

Чому так відбувається? Бо класичні моделі розроблені для прогнозування, а не для оцінки власної адекватності в реальному часі. Вони ігнорують стан OOD (Out-of-Distribution) — коли вхідні дані настільки зашумлені або нові, що будь-який прогноз є ризикованим.

Чим це загрожує на практиці?

Коли система сліпо приймає рішення на основі такого AI, ми отримуємо:

· Фінансові втрати: помилкові транзакції через неправильне розпізнавання.

· Репутаційні ризики: некоректні рекомендації, що дратують клієнтів.

· Відсутність аудиту: неможливість пояснити регулятору, чому саме таке рішення було прийняте в спірній ситуації.

· Питання безпеки: у критичних сферах, як медицина , наслідки можуть бути тяжкими.

Рішення: Deterministic Controller Layer — «запобіжник» для AI

Що робити, якщо модель не вміє оцінювати власну впевненість? Найпростіший шлях — не перевчати її, а додати зовнішній «запобіжник».

DCL — це легкий шар контролю, який ставиться поверх вашої готової моделі. Його суть:

1. Не чіпає модель: ви не міняєте архітектуру, не робите ретренінг.

2. Аналізує впевненість: він дивиться не тільки на «топ-1» відповідь, а й на те, наскільки модель розгубилася (наприклад, через ентропію або різницю між топ-класами).

3. Дає рішення, а не прогноз: на основі цієї впевненості DCL видає один із статусів:

ПРИЙНЯТИ (Ok)

НА ПЕРЕВІРКУ (Risk)

ВІДХИЛИТИ (OOD)

Це дає вам три режими роботи в одній системі:

· Автоматичний: для впевнених прогнозів.

· Напівавтоматичний (Human-in-the-loop): для спірних випадків.

· Блокуючий: для явних аномалій.

Налаштування порогів для цих режимів — це бізнес-логіка, а не ML-дослідження. Ви контролюєте ризик.

Отже, ключова задача — не усунути помилки моделі (що неможливо), а впровадити в архітектуру системи механізми контролю за її впевненістю."

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

У наступному пості розберемо саму архітектуру DCL детальніше:

· Як це працює всередині: від отримання прогнозу до фінального статусу.

· Три режими роботи системи: коли автоматизувати, коли запитувати людину, а коли блокувати.

· Реальні приклади з кодом: як виглядає інтеграція такого шару в існуючий пайплайн.

· Навіщо це все: як контролювати ризики, не втручаючись у логіку самої моделі.

© 2026 Ярослав Ісаченков

Ліцензія: CC BY-NC 4.0