Я виявив, що одна метрика безпекового шлюзу (safety-gate) приховала цілодобовий збій у функції пояснень, згенерованих ШІ. Вважаючи «відхилення шлюзом» та «помилку завантаження моделі» одним і тим самим, метрика створювала хибне враження справності системи. Вона зафіксувала чотири відхилення та нуль успіхів, хоча протягом цього періоду модель взагалі не запускалася — помилка, яка могла залишити операторів без інформації про несправну систему.

Як виникла плутанина

Ця функція використовує локальну мовну модель, щоб перетворити сиру машинну логіку на зрозумілі людині речення. Безпековий шлюз (safety gate) на наступному етапі блокує будь-який результат, що порушує попередньо визначені правила. У робочому середовищі я вивів єдиний лічильник, який збільшувався щоразу, коли шлюз відхиляв речення. Коли дрон зафіксував чотири пояснення ШІ, лічильник повідомив про чотири відхилення та відсутність успішних результатів. Я сприйняв це як належну роботу шлюзу, а не як відмову самої функції.

Лічильник маскував двоступеневий збій:

  1. Модель не працює – Модель працює на тій самій машині, що й решта системи. Щоб заощадити пам'ять, хост вивантажує її після періоду бездіяльності.
  2. Тайм-аут під час перезавантаження – Коли з'явилася нова загроза, система спробувала перезавантажити приблизно два гігабайти даних моделі. Час перезавантаження перевищив тридцятисекундний ліміт очікування відповіді (timeout), тому запит перервався за тайм-аутом і повернув порожню відповідь.

Оскільки лічильник сприймав відхилення шлюзом та порожню відповідь через тайм-аут як одну й ту саму подію, дашборд показував «справний безпековий шлюз», хоча функція ШІ фактично не працювала.

Чому це важливо

У продуктах на базі ШІ безпекові шлюзи зупиняють шкідливі або безглузді результати. Оператори стежать за частотою спрацювання шлюзу як за сигналом про стан системи. Коли цей сигнал змішується з іншими, непов'язаними режимами відмови, метрика стає «тихою брехнею»: вона заспокоює, поки сервіс недоступний.

Виправлення, що повернуло видимість

Я вніс три практичні зміни:

  • Залишення моделі в пам'яті – Налаштував хост так, щоб модель залишалася в пам'яті, усунувши затримку на перезавантаження.
  • Збільшення тайм-ауту – Розширив вікно очікування відповіді, щоб обробляти випадкові повільні завантаження.
  • Розділення лічильника – Замінив єдину метрику rejected by gate на чотири окремі лічильники: accepted, rejected, empty response та no answer.

Третій крок став вирішальним. Замість одного числа, яке можна було трактувати по-різному, деталізація на чотири частини показує, чи активний безпековий шлюз, чи відповідає модель, чи запит взагалі не дійшов до моделі.

Компроміси та контраргументи

На що звернути увагу далі

Розробникам, які впроваджують компоненти ШІ, слід перевіряти будь-які агреговані лічильники, що змішують перевірки безпеки з системними збоями. Створення детального журналу історії, який фіксує шлях кожного запиту — початок завантаження моделі, оцінка шлюзом, кінцевий результат — забезпечує дані для розслідування (forensic data), необхідні для виявлення прихованих проблем.

Висновок: Одна метрика «відхилення шлюзом» може приховати непрацездатний сервіс ШІ; розділення цієї метрики на складові події розкриває правду та запобігає хибній впевненості в системі, яка насправді не працює.