UC Berkeley и IBM: диагностика сбоев корпоративных агентов с IT-Bench и MAST

Сегодня разбираем материал huggingface.co о теме «IBM и UC Berkeley диагностируют причины сбоев корпоративных агентов с помощью IT-Bench и MAST». Материал полезен тем, кто хочет быстро понять суть темы и перевести идеи в прикладные действия.

Когда агентная система проваливает задачу, бенчмарк фиксирует факт провала — но не объясняет, что именно пошло не так. Мы столкнулись с этой проблемой вплотную, анализируя, как большие языковые модели ведут себя в реальной IT-автоматизации: разбирают инциденты, запрашивают логи и метрики, управляют Kubernetes в длинных инструментальных циклах. Чтобы вскрыть «чёрный ящик», мы применили таксономию сбоев мультиагентных систем (MAST) к ITBench — набору задач для SRE, безопасности и FinOps — и аннотировали 310 трассировок по трём моделям: Gemini-3-Flash, Kimi-K2 и GPT-OSS-120B

Ключевые выводы:

Модели, такие как Gemini-3-Flash, показывают сбои, сосредоточенные на изолированных проблемах, в частности, в верификации, с показателем 2,6 режима отказа на трассировку. В отличие от них, крупные открытые модели, такие как GPT-OSS-120B, подвержены каскадным сбоям, имея 5,3 режима отказа на трассировку. Даже небольшое расхождение на начальном этапе выполнения может отравить контекст, вызывая нарастающие галлюцинации

Основным предиктором сбоя в моделях становится FM-3.3 (некорректная верификация), что приводит к тому, что агенты зачастую «объявляют победу», не проверяя соответствие результатам

Kimi-K2 сталкивается с трудностями при определении момента завершения задач, что вызывает резкое увеличение случаев преждевременного завершения (+46%) и неосведомлённости о завершении (+43%). Эта модель может остановиться прямо перед решением задачи или застрять на длительный срок

Выводы из нашего анализа для разработчиков агентов:

Для передовых моделей, таких как Gemini, важно вынести верификацию наружу. Не позволяйте LLM самостоятельно оценивать свою работу; требуйте строгих инструментальных доказательств

Контроль завершения задач и циклов следует вынести за пределы модели, так как проблемы с завершением являются частыми причинами сбоев (FM-1.5). Необходимо добавлять явные условия остановки и детекторы циклов для периодических вызовов инструментов или реализовать конечные автоматы

При неоднозначных входных данных настаивайте на уточнении или переводите в режим только чтения. Сбои при уточнении (FM-2.2) часто становятся основной причиной отказов для небольших моделей. Неоднозначность должна быть оформлена как полноценная ветвь в графе вашего агента

Разрабатывая агентов для корпоративных IT-процессов, вам нужно больше, чем просто оценка: важно понять, что именно сломалось и какое вмешательство окажет наибольшее влияние

Проблема «чёрного ящика» в агентных бенчмарках

Бенчмарки, подобные ITBench, становятся стандартом для измерения производительности агентов в критически важных задачах IT-автоматизации. В ITBench агенты выступают в роли SRE-инженеров или аналитиков безопасности, отвечая за диагностику сбоев Kubernetes, устранение уязвимостей или управление облачными расходами в производственных условиях

Эти бенчмарки используют успешность как основную метрику для оценки агентов. Однако этого недостаточно для создания надёжных систем. Знание того, что агентская система достигает 14% успешности на ITBench, говорит о провале, но не уточняет его причину: было ли это потерей контекста, галлюцинацией команды или просто тем, что она не завершила работу

Без комплексного подхода к диагностике таких сбоев разработчики часто действуют наугад, прибегая к слепым исправлениям промптов, которые решают одну проблему, но создают другие

В качестве нового стандарта анализа режимов отказа сложных агентных систем мы разработали MAST. MAST даёт более глубокое понимание и открывает непрозрачную оценку этих бенчмарков. Разработанный на основе строгого анализа более 1 600 трассировок по семи различным фреймворкам, MAST предоставляет стандартизированную таксономию сбоев агентов

MAST преобразует неструктурированные журналы выполнения в структурированные «векторы сбоев» на основе 14 различных паттернов в трёх ключевых категориях:

FC1: Проблемы системного дизайна («Скелет»). Сбои здесь обусловлены архитектурой агента и определением его роли.

Примеры: FM-1.3 Повторение шагов (зацикливание), FM-1.4 Потеря истории разговора (утечки памяти), FM-1.5 Неосведомлённость о завершении (неспособность остановиться).

FC2: Межагентное рассогласование («Коммуникация»). Сбои, возникающие во время выполнения из-за того, как агенты взаимодействуют друг с другом или с окружением.

Примеры: FM-2.2 Неспособность запросить уточнение (предположение вместо вопроса), FM-2.3 Отклонение от задачи (уход в сторону).

FC3: Верификация задачи («Контроль качества»). Сбои в обеспечении качества результатов агентов.

Примеры: FM-3.1 Преждевременное завершение (слишком ранний отказ), FM-3.3 Некорректная верификация (галлюцинация успеха).

По этой теме полезно отдельно посмотреть Как я создал безопасные Firebase Cloud Functions с правами администратора и ограничением частоты запросов, чтобы расширить контекст и сравнить подходы.

Эксперимент: диагностика агентов ITBench

Мы проверяем идею использования MAST для того, чтобы сделать оценки агентов практически применимыми и получить представление о режимах отказа, применяя его к ITBench — популярному набору для оценки задач IT-автоматизации в области SRE, Security/Compliance и FinOps

Мы аннотировали 310 SRE-трассировок выполнения ITBench, созданных SRE-агентом на базе Codex в реалистичных средах. Эти трассировки фиксируют взаимодействия на естественном языке между агентами и их инструментами по трём моделям, представляющим различные уровни возможностей: Gemini-3-Flash, Kimi-K2 и GPT-OSS-120B. Это позволяет нам выйти за рамки простых метрик успешности и исследовать характерные сигнатуры сбоев, обусловливающие эти результаты. Для этого мы используем показатели полноты (recall), поскольку модели по своей конструкции выдают максимум 3–5 результатов, а SRE-специалисты предпочитают показатели полноты показателю F-1

Gemini-3-Flash: 100 трассировок (средняя полнота 75,5%)

Kimi-K2: 105 трассировок (средняя полнота 28,6%)

GPT-OSS-120B: 105 трассировок (средняя полнота 12,4%)

Ниже подробно изложены выводы этого диагностического анализа

Находка 1: более сильные модели демонстрируют изолированные сбои, открытые — каскадные

При изучении неудачных трасс в трёх моделях обнаруживается чёткая иерархия сложности. Она измеряется количеством различных режимов отказов, наблюдаемых в рамках одного неудачного запуска

Gemini-3-Flash: 2,6 режима отказов на неудачную трассу

Kimi-K2: 4,7 режима отказов на неудачную трассу

GPT-OSS-120B: 5,3 режима отказов на неудачную трассу

Это расхождение в плотности режимов отказов раскрывает фундаментальное различие в том, как эти системы выходят из строя. Gemini-3-Flash демонстрирует хирургический профиль отказов. Даже в неудачных запусках она сохраняет высокую внутреннюю согласованность и, как правило, терпит неудачу из-за единственного изолированного сбоя — например, некорректного шага верификации. Такие отказы точечны и значительно проще поддаются диагностике

На противоположном конце спектра GPT-OSS-120B страдает от каскадного коллапса. В этих трассах видно, что ошибки имеют тенденцию накапливаться со временем. Небольшое несоответствие в рассуждениях на раннем этапе процесса нередко приводит к отклонению от спецификации задачи, что, в свою очередь, вызывает полное дерейлирование агента. Kimi-K2 занимает промежуточное положение: отказы здесь более частые и сложные, чем у фронтирной модели, однако не достигают системной нестабильности, наблюдаемой у модели с открытыми весами 120B

Значимость этой находки состоит в том, что более высокий показатель успеха нередко сопровождается изолированными отказами. Системы, которые выходят из строя при меньшем числе одновременных проблем, значительно более предсказуемы и проще поддаются улучшению посредством целенаправленных инженерных вмешательств

Находка 2: «нефатальные» и «фатальные» отказы

Пожалуй, наиболее критическое понимание, которое даёт MAST, — это разграничение между отказами, которые система способна допустить, и теми, что являются фатальными для успеха последующей задачи. Сравнивая распределение режимов отказов в успешных трассах и в неудачных трассах, мы можем классифицировать их по трём категориям

«Нефатальные» (доброкачественные) дефекты

Во всех трёх моделях определённые режимы отказов встречаются часто даже в запусках, которые в итоге завершаются успешно. Как правило, это структурные трения, а не терминальные ошибки

FM-1.3 Повторение шагов: этот режим присутствует более чем в 90% успешных запусков Kimi-K2. В домене SRE итерация зачастую является необходимостью. Агент может запрашивать одну и ту же метрику несколько раз, чтобы проверить, стабилизируется ли сервис или вступило ли в силу исправление. Gemini-3-Flash фактически демонстрирует меньше повторений в своих неудачных трассах, что говорит о том, что иногда она терпит неудачу именно потому, что недостаточно итерирует

FM-1.1 Несоблюдение спецификации задачи: агенты нередко отклоняются от строгого форматирования инструментов или последовательных инструкций, однако всё равно умудряются определить правильную первопричину

Именно здесь MAST демонстрирует свою ценность. Он позволяет игнорировать доброкачественные отказы — например, повторения, которые часто возникают при устранении неполадок, — и сосредоточиться вместо этого на фатальных отказах, которые уничтожают запуск

«Фатальные» дефекты

Определённые паттерны поведения чётко разграничивают успех и неудачу. Когда эти режимы появляются, вероятность успешного исхода резко падает. Наиболее показательный пример — FM-3.3 (Некорректная верификация). Этот режим показывает увеличение на 52% в неудачных трассах Gemini-3-Flash по сравнению с успешными. Другие заметные режимы отказов — 1.5 (Незнание условий завершения) и 2.6 (Несоответствие рассуждения и действия)

Если они возникают, запуск, скорее всего, обречён; это направляет практиков к разработке надёжных стратегий управления контекстом для агентов в системе и множественных витков взаимодействий

Кейс: Gemini-3-Flash (решительная, но самонадеянная)

Gemini-3-Flash отличается высокой эффективностью, однако её основным узким местом является склонность предполагать успех без строгого доказательства. Сигнатура её отказов определяется массивной дельтой ошибок верификации. Она нередко определяет правильные сигналы, но завершает работу до их перекрёстной проверки с эталонными данными. Чтобы исправить это, разработчикам следует реализовать внешний шлюз верификации. Требуя доказательств на основе инструментов — например, снятого алерта или здорового порогового значения метрики — перед тем как позволить агенту завершить работу, можно нивелировать присущую этой модели самонадеянность

Исправление: для улучшения Gemini-3-Flash на ITBench инженерия промптов мало поможет. В частности, эксперименты, представленные в нашей статье для NeurIPS 2025, показывают, что при ручных вмешательствах — таких как инженерия промптов для устранения ошибок, связанных с памятью, — можно добиться лишь около 15,6% улучшения производительности. В то же время в предыдущем посте о MAST мы показали, что введение новых агентов — например, агента-суммаризатора, напоминающего другим агентам о происходящем и непрерывно дополняющего их состояние (исправление FM-1.4), или введение механизмов управления контекстом (например, более строгой конечной машины состояний для принудительного завершения в целях исправления FM-1.5) — позволяет добиться улучшения производительности до 53%, поскольку эти меры устраняют более фундаментальные проблемы системы

Кейс: Kimi-K2 (кризис завершения)

Хотя путаница с завершением (FM-3.1 и FM-1.5) является преобладающим режимом отказов для Kimi-K2, её неудачные траектории определяются повсеместным несоответствием действия и рассуждения (FM-2.6), которое присутствует в поразительных 92% её отказов

Разрыв исполнения: хотя части её внутренних рассуждений нередко точны, она страдает от 92-процентной распространённости отказов FM-2.6 (Несоответствие действия и рассуждения). Она часто определяет правильный следующий шаг, но затем выполняет избыточную или нерелевантную команду

Ловушка мета-цикла: примерно 25% неудачных трасс включают FM-2.3 (Дерейлирование задачи). Когда вызов инструмента возвращает незначительную ошибку, агент нередко бросает основной инцидент и входит в цикл отладки собственных скриптов расследования

Kimi-K2 — хороший пример модели с избыточным мышлением: её цепочки рассуждений зачастую слишком длинны, но она может давать сбои на этапе исполнения

Кейс: GPT-OSS-120B

GPT-OSS-120B демонстрирует наиболее нестабильную сигнатуру отказов в когорте. Эта модель показывает в среднем 5,3 различных режима отказов на неудачную трассу, что свидетельствует о фундаментальной неспособности поддерживать внутреннее состояние

Потеря истории разговора (FM-1.4): это уникальный фатальный дефект модели 120B. Она теряет историю разговора в 24% трасс, тогда как Gemini-3-Flash не демонстрировала потери памяти вообще, а Kimi-K2 — лишь в 7% случаев. По мере роста длины SRE-трасс GPT-OSS-120B фактически «забывает» алерты, которые изначально разбирала, что приводит к полному дерейлированию задачи

Разрыв рассуждений (FM-2.6): поразительные 94% трасс демонстрируют разрыв между рассуждением и действием. Она почти в 3 раза чаще, чем Gemini (31%), описывает правильный план, а затем выполняет совершенно не связанный или избыточный вызов инструмента

Как читать результаты: «фатальные» и «нефатальные» режимы отказов

Подводя итог, MAST позволяет разделить режимы отказов на два ведра

Восстанавливаемые / структурные (встречаются даже в успешных трассах)

Это отказы, которые не являются фатальными и от которых система может восстановиться, чтобы успешно завершить задачу

FM-1.3 Повторение шагов

FM-3.3 Некорректная верификация (важный нюанс: система всё же верифицирует; она просто делает это плохо)

FM-2.6 Несоответствие рассуждения и действия (часто присутствует, но не всегда является решающим)

Фатальные / решающие (тесно связаны с неудачными трассами)

Это отказы, от которых система, как правило, не может восстановиться

FM-1.5 Незнание условий завершения

FM-3.1 Преждевременное завершение

FM-1.4 Потеря истории разговора

FM-2.3 Дерейлирование задачи (редкое, но крайне диагностически значимое при появлении)

FM-2.2 Неспособность запросить уточнение (особенно для режимов Granite/Llama)

Это и есть «более глубокое понимание»: две модели могут иметь одинаковый показатель успеха на небольшой выборке, однако терпеть неудачу по совершенно разным причинам — и требовать разных исправлений

MAST — это инструмент, который анализирует трассировки агентных систем для выявления детализированных типов сбоев, поддерживающих разработку и отладку систем. Применяя MAST к ITBench, мы переходим от общих наблюдений («Открытые модели испытывают трудности») к конкретной инженерной дорожной карте, которая помогает улучшить производительность агентных систем, опирающихся на эти модели

Для Gemini-3-Flash: сбой верификации (FM-3.3) является наиболее распространённым фатальным сбоем для хирургических моделей. Никогда не позволяйте агенту самостоятельно завершать работу; требуйте жёстких, опосредованных инструментами доказательств — например, подтверждения от AlertManager или изменений состояния K8s — прежде чем считать выполнение задачи успешным

Для Kimi-K2: используйте детерминированный конечный автомат, чтобы устранить частые трудности модели с распознаванием завершения задачи. Цепочки рассуждений этой модели могут быть слишком длинными и с трудом завершаться, поэтому она может значительно выиграть от более жёсткого контроля над моментом окончания работы

Для GPT-OSS-120B: системный коллапс происходит, когда незначительные несоответствия в рассуждениях (FM-2.6) отравляют историю задачи. Внедрите агрессивную гигиену контекста и раннее обнаружение ошибок, чтобы небольшие расхождения не накапливались и не приводили к полному срыву выполнения

Ресурсы по теме:

IT-Bench Paper: https://arxiv.org/pdf/2502.05352

IT-Bench Code: https://github.com/itbench-hub/ITBench

MAST Paper: https://arxiv.org/abs/2503.13657

MAST Code: https://github.com/multi-agent-systems-failure-taxonomy/MAST

Ответы на эти вопросы могут быть для вас полезными

Что такое MAST и чем он отличается от обычного бенчмарка?

MAST — это таксономия сбоев мультиагентных систем, которая преобразует сырые трассировки выполнения в структурированные векторы сбоев по 14 паттернам. В отличие от бенчмарка, который фиксирует только факт провала, MAST объясняет конкретную причину и категорию сбоя, что позволяет выбрать точное инженерное исправление.

Почему Gemini-3-Flash показывает лучшие результаты, но всё равно даёт сбои?

Gemini-3-Flash достигает средней полноты 75,5%, однако её главная уязвимость — FM-3.3 (Некорректная верификация): модель «объявляет победу», не сверяясь с реальным состоянием системы. Исправление — внешний шлюз верификации с обязательными инструментальными доказательствами перед завершением задачи.

Почему инженерия промптов не решает проблемы агентов на ITBench?

Эксперименты показывают, что ручные правки промптов дают не более 15,6% прироста производительности. Фундаментальные проблемы — потеря контекста (FM-1.4) и неспособность остановиться (FM-1.5) — требуют архитектурных решений: агентов-суммаризаторов и конечных автоматов состояний, которые обеспечивают прирост до 53%.

Чем опасна модель GPT-OSS-120B в длинных SRE-трассах?

GPT-OSS-120B теряет историю разговора в 24% трасс и демонстрирует разрыв между рассуждением и действием в 94% случаев. По мере роста длины трассы модель буквально «забывает» исходные алерты, что приводит к полному дерейлированию задачи. Решение — агрессивная гигиена контекста и раннее обнаружение ошибок.

Какие режимы отказов встречаются даже в успешных запусках и не требуют немедленного исправления?

FM-1.3 (Повторение шагов) присутствует в более чем 90% успешных запусков Kimi-K2 — в SRE-домене итерация при диагностике инцидентов нормальна. FM-1.1 (Несоблюдение спецификации задачи) также нередко встречается в успешных трассах. MAST позволяет отделить эти доброкачественные паттерны от фатальных и не тратить ресурсы на их устранение в первую очередь.