Журнал · Rit.work

Починить инцидент мало: агенту ещё нужно вовремя остановиться

Incident-Arena проверяет ремонт работающих систем под нагрузкой: лучшая конфигурация прошла 64,3% задач, а часть агентов испортила уже найденное решение.

Rit.work
Студия разработки
2 октября 2026 г.2 мин чтения

Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.

Правильного исправления недостаточно, чтобы ИИ-агент успешно устранил сбой в работающей системе. Хотя работа не рецензирована и числа получили сами авторы, в Incident-Arena лучшая конфигурация прошла с первой попытки 64,3% задач. Для внедрения таких агентов одной сильной модели мало: нужны проверка восстановления под нагрузкой и механизм, который не даст продолжить изменения после ремонта.

Incident-Arena состоит из 20 вручную подготовленных инцидентов в Kubernetes. В систему внедряют ошибку на уровне конфигурации, состояния во время работы или образа приложения, а агент получает ограниченный доступ к журналам, метрикам и средствам ремонта. Вместо проверки патча бенчмарк подаёт новый трафик, следит за задержкой и ошибками, перезапускает затронутый сервис и проверяет сохранность данных. Ремонт засчитывают, только если сервис восстановился и агент не вышел за разрешённые границы.

Главная проблема оказалась не только в поиске причины. В 55% запусков агенты выполняли все действия из эталонного ремонта, но лишь 59% таких запусков проходили итоговую проверку. Агенты объявляли успех до стабилизации показателей, не устраняли последствия сбоя или продолжали менять систему и отменяли собственное исправление. Увеличение объёма рассуждений подняло результат лишь на 4,6 процентного пункта в пределах погрешности, зато средняя стоимость запуска выросла в 2,3 раза.

Проверка охватила 3 000 запусков на трёх системах: Saleor, FrappeERP и созданном авторами аналоге Slack. Большинство задач пришлось на последний, а тип ошибки, приложение и момент появления сбоя в наборе связаны между собой. Поэтому результат описывает именно эти среды и способы доступа, но показывает полезный принцип оценки: агент должен не назвать причину и не предложить патч, а безопасно вернуть сервис в рабочее состояние и вовремя остановиться.

Источники

Иллюстрация: рисунок из статьи «Incident-Arena: Getting agents to the last nine of reliability», Andre Fu, Malik Drabla, Leon Liu и др., CC BY 4.0

Пауза в чтении

Похоже на вашу задачу?

Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.

Rit.work

Студия разработки

Собираем мобильные приложения и помогаем командам получать от AI реальную пользу. Основатель и команда, работаем удалённо — с клиентами в России и за рубежом.

← Ко всем материалам
Понравилось? Обсудим вашу задачу