Чому 90% надійності ШІ — це катастрофічно мало: пояснює Карпаті

«Коли ви бачите демо, і щось працює у 90% випадків, це лише перші дев’ять». — Андрей Карпаті

Концепція “маршу дев’яток” (March of Nines) описує типову реальність промислового впровадження: досягти 90% надійності можна за допомогою якісного прототипу, але кожен наступний відсоток, що наближає до абсолютної надійності, вимагає непропорційно великих інженерних зусиль. Для корпоративних команд саме ця відстань між “зазвичай працює” та “функціонує як надійне програмне забезпечення” визначає успіх впровадження штучного інтелекту.

Математика наростаючої складності в “марші дев’яток”

«Кожна нова дев’ятка вимагає однакових зусиль». — Андрей Карпаті

Агентні робочі процеси, де ШІ виконує складні послідовності дій, схильні до кумулятивного накопичення помилок. Типовий корпоративний процес може включати: розпізнавання намірів, вилучення контексту, планування, один або декілька викликів інструментів, валідацію, форматування та запис у лог. Якщо робочий процес складається з n кроків, і кожен крок має ймовірність успіху p, то наскрізна ймовірність успіху становить приблизно p^n. У 10-кроковому процесі кінцева надійність катастрофічно падає через збої на окремих етапах. Корельовані збої (авторизація, перевищення лімітів запитів, проблеми з конекторами) стануть домінуючими, якщо не забезпечити стійкість спільних залежностей.

Надійність кожного кроку (p)	Надійність 10-крокового процесу (p^10)	Рівень відмов процесу	При 10 процесах на день	Що це означає на практиці
90.00%	34.87%	65.13%	~6.5 переривань/день	Територія прототипу. Більшість процесів перериваються
99.00%	90.44%	9.56%	~1 на 1.0 дня	Прийнятно для демо, але переривання все ще часті в реальному використанні.
99.90%	99.00%	1.00%	~1 на 10.0 днів	Все ще відчувається ненадійним, оскільки пропуски залишаються поширеними.
99.99%	99.90%	0.10%	~1 на 3.3 місяця	Ось тут починає відчуватися надійне програмне забезпечення корпоративного рівня.

Визначення надійності через вимірювані цілі (SLO)

«Набагато логічніше витратити трохи більше часу, щоб бути більш конкретним у своїх запитах». — Андрей Карпаті

Команди досягають вищих рівнів надійності, перетворюючи її на вимірювані цілі, а потім інвестуючи в механізми контролю, що зменшують варіативність. Почніть з невеликого набору показників (SLI), які описують як поведінку моделей, так і навколишньої системи:

Рівень завершення робочого процесу (успіх або явна ескалація).
Рівень успішності виклику інструментів у межах встановлених тайм-аутів, із суворою валідацією схеми на вході та виході.
Рівень виведення, що відповідає схемі, для кожної структурованої відповіді (JSON/аргументи).
Рівень відповідності політикам (PII, секрети та обмеження безпеки).
p95 наскрізної затримки та вартість на робочий процес.
Рівень резервного копіювання (безпечніша модель, кешовані дані або перегляд людиною).

Встановіть цільові показники SLO для кожного рівня робочого процесу (низький/середній/високий вплив) та керуйте бюджетом помилок, щоб експерименти залишалися контрольованими.

Дев’ять важелів для надійного збільшення “дев’яток”

1) Обмеження автономії за допомогою явного графа робочого процесу

Надійність зростає, коли система має визначені стани та детерміновану обробку для повторних спроб, тайм-аутів та завершальних результатів.

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

2) Забезпечення дотримання контрактів на кожному інтерфейсі

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

Використовуйте JSON Schema/protobuf для кожного структурованого виводу та валідуйте на стороні сервера перед виконанням будь-якого інструменту.
Використовуйте переліки (enums), канонічні ідентифікатори та нормалізуйте час (ISO-8601 + часовий пояс) та одиниці виміру (SI).

3) Багаторівнева валідація: синтаксис, семантика, бізнес-правила

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

Семантичні перевірки: цілісність посилань, числові межі, перевірка дозволів та детерміновані об’єднання за ID, коли це можливо.
Бізнес-правила: затвердження для операцій запису, обмеження щодо місця зберігання даних та обмеження для рівнів клієнтів.

4) Маршрутизація на основі ризику з використанням сигналів невизначеності

Дії з високим впливом потребують вищого рівня гарантій. Маршрутизація на основі ризику перетворює невизначеність на функцію продукту.

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

5) Інженерія викликів інструментів як розподілених систем

Конектори та залежності часто домінують у показниках відмов в агентних системах.

Застосовуйте тайм-аути для кожного інструменту, механізми відкату з джиттером, автоматичні вимикачі (circuit breakers) та обмеження одночасності.
Версіонуйте схеми інструментів та валідуйте їхні відповіді, щоб запобігти тихим збоям при зміні API.

6) Передбачувана та спостережувана система вилучення даних (retrieval)

Якість вилучення даних визначає, наскільки обґрунтованою буде ваша програма. Розглядайте її як версіонований продукт даних з метриками охоплення.

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

7) Створення конвеєра оцінки у промисловому середовищі

Додаткові “дев’ятки” надійності залежать від швидкого виявлення рідкісних збоїв та запобігання регресіям.

Підтримуйте набір “золотих” тестів, сформованих на основі реальних інцидентів у продакшені, та запускайте його при кожній зміні.
Запускайте тіньовий режим (shadow mode) та A/B-тестування з автоматичним відкатом при регресіях SLI.

8) Інвестиції в спостережуваність та операційне реагування

Коли збої стають рідкісними, швидкість діагностики та усунення стає обмежуючим фактором.

Генеруйте трасування/спани для кожного кроку, зберігайте приховані запити та вхід/вихід інструментів із суворими засобами контролю доступу, класифікуйте кожен збій згідно з таксономією.
Використовуйте посібники (runbooks) та перемикачі “безпечного режиму” (вимкнення ризикованих інструментів, перемикання моделей, вимога схвалення людиною) для швидкого пом’якшення наслідків.

9) Реалізація повзунка автономії з детермінованими резервними варіантами

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

За замовчуванням використовуйте операції лише для читання або зворотні дії, вимагайте явного підтвердження (або робочі процеси схвалення) для записів та незворотних операцій.
Створюйте детерміновані резервні варіанти: відповіді лише на основі вилучених даних, кешовані відповіді, обробники на основі правил або ескалація до перегляду людиною, коли впевненість низька.
Надайте безпечні режими для кожного клієнта: вимкніть ризиковані інструменти/конектори, примусово використовуйте потужнішу модель, знизьте температуру (temperature) та скоротіть тайм-аути під час інцидентів.
Розробляйте процеси відновлення передачі завдань: зберігайте стан, показуйте план/відмінності та дозволяйте рецензенту схвалити та продовжити з точного кроку за допомогою ідемпотентного ключа.

Ескіз реалізації: обгортка для обмеженого кроку

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

def run_step(name, attempt_fn, validate_fn, *, max_attempts=3, timeout_s=15):

# відстежуємо всі повторні спроби під одним спаном

span = start_span(name)

for attempt in range(1, max_attempts + 1):

try:

# обмежуємо затримку, щоб один крок не блокував робочий процес

with deadline(timeout_s):

out = attempt_fn()

# перевірка: схема + семантика + бізнес-інваріанти

validate_fn(out)

# шлях успіху

metric(“step_success”, name, attempt=attempt)

return out

except (TimeoutError, UpstreamError) as e:

# тимчасовий збій: повторна спроба з джиттером, щоб уникнути штормів повторних спроб

span.log({“attempt”: attempt, “err”: str(e)})

sleep(jittered_backoff(attempt))

except ValidationError as e:

# некоректний вивід: повторна спроба один раз у “безпечнішому” режимі (нижча температура / суворіший промпт)

span.log({“attempt”: attempt, “err”: str(e)})

out = attempt_fn(mode=”safer”)

# резервний варіант: зберігає систему в безпеці, коли повторні спроби вичерпані

metric(“step_fallback”, name)

return EscalateToHuman(reason=f”{name} failed”)

Чому підприємства наполягають на пізніх “дев’ятках”

Розриви в надійності призводять до бізнес-ризиків. Глобальне опитування McKinsey 2025 показує, що 51% організацій, які використовують ШІ, зазнали принаймні одного негативного наслідку, а майже третина повідомила про наслідки, пов’язані з неточністю ШІ. Ці результати стимулюють попит на кращі вимірювання, захисні механізми та операційні контролі.

Контрольний список для впровадження

Виберіть основний робочий процес, визначте його SLO для завершення та встановіть коди термінального статусу.
Додайте контракти та валідатори навколо кожного виводу моделі та вхід/вихід інструментів.
Розглядайте конектори та вилучення даних як першочергову задачу надійності (тайм-аути, автоматичні вимикачі, канарейки).
Маршрутизуйте дії з високим впливом через шляхи з вищим рівнем гарантій (верифікація або схвалення).
Перетворюйте кожен інцидент на тест на регресію у вашому “золотому” наборі.

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

Нікхіл Мунгел понад 15 років створює розподілені системи та команди ШІ в компаніях SaaS.

Прогноз ІТ-Блогу: Розвиток агентних систем перейде від демонстраційних можливостей до серйозних корпоративних застосувань завдяки впровадженню цих інженерних практик. З часом ми побачимо стандартизацію “шаблонів надійності” для складних ШІ-процесів, що прискорить впровадження та зменшить пов’язані ризики.

Інформація підготовлена на основі матеріалів: venturebeat.com