Новый тест IBM и Artificial Analysis показал пределы AI-агентов в SRE

Artificial Analysis и IBM Research запустили ITBench-AA — новый бенчмарк для проверки AI-агентов на корпоративных IT-задачах. Первый набор посвящён SRE: модели расследуют Kubernetes-инциденты по офлайн-снимкам с логами, метриками, трассами, событиями и топологией приложения, а затем должны назвать минимальный набор независимых Kubernetes-сущностей, которые вызвали сбой.

Результат неприятно трезвый для рынка агентных систем: лучший показатель на момент запуска — 46,7% у Claude Opus 4.7 в режиме Adaptive Reasoning Max Effort. GPT-5.5 xhigh идёт почти рядом с 45,8%, Qwen3.7 Max набирает 42,5%. Все передовые модели в этом тесте остались ниже 50%.

Как устроен тест

ITBench-AA основан на IBM ITBench — открытом фреймворке для IT-автоматизации. Artificial Analysis взяла SRE-часть и сделала собственную независимую реализацию: 59 задач реагирования на Kubernetes-инциденты, из них 40 из публичного релиза IBM и 19 закрытых задач, которыми поделилась команда ITBench. Каждая задача прогоняется по три раза.

Агент работает не в виде чат-бота с готовой подсказкой, а через открытый испытательный контур Stirrup: получает изолированную командную оболочку, видит смонтированный снимок инцидента и сам решает, какие команды запускать. В конце он записывает диагноз в JSON. В X-треде Artificial Analysis отдельно подчёркивается этот формат: в публичной SRE-задаче агент видит пользовательские сбои во frontend path и расследует их через shell, а не выбирает ответ из списка.

Метрика тоже жёсткая. Главный показатель — average precision at full recall. Если агент пропустил хотя бы одну настоящую причину, повтор получает 0. Если все причины найдены, считается точность: true positives / (true positives + false positives). Поэтому лишние догадки прямо наказываются.

Почему “почти нашёл” здесь недостаточно

Для обычного бенчмарка 46% можно было бы трактовать как половину пути. Для SRE это другой разговор. В реальном инциденте пропущенная причина означает, что система может упасть снова, а лишняя причина уводит команду в неправильный ремонт. ITBench-AA специально требует минимальный набор независимых Kubernetes-сущностей: deployments, pods, namespaces, network policies и другие объекты должны быть названы не россыпью подозрений, а как точный диагноз.

Это хорошо показывает слабое место нынешних агентов. Они уже умеют читать много разнородных сигналов, запускать команды и строить гипотезы. Но когда нужно остановиться, отфильтровать шум и не добавить лишнее, качество резко проседает. Artificial Analysis указывает и на операционную цену такого поведения: GPT-5.5 xhigh набирает 45,8% в среднем за 30,9 шага, а Gemini 3.1 Pro Preview тратит 82,9 шага и получает 30,3%. Больше расследования не равно лучше диагноз: лишние contributing entities сверх true root cause прямо уменьшают итоговый балл.

Открытые модели ближе, чем кажется

Отдельно интересен результат моделей с открытыми весами. GLM-5.1 Reasoning набирает 40,3%, DeepSeek V4 Pro Reasoning Max Effort — 38,3%, Gemma 4 31B Reasoning — 37,3%. Они не догоняют верхнюю тройку, но разрыв уже не выглядит пропастью, особенно с учётом прикладного характера задачи.

Стоимость усиливает этот вывод. По данным треда, Gemma 4 31B Reasoning даёт 37% примерно за $0,14 на задачу, GLM-5.1 Reasoning — 40% за $1,23, а Gemini 3.1 Pro Preview — 30% за $2,23. Gemini 3.5 Flash high стоит около $1,70 на задачу и примерно совпадает с ним по качеству. Для продакшен-SRE это важнее красивой позиции в таблице: цена долгого агентного копания быстро становится отдельным инженерным ограничением.

Для компаний это полезнее очередного абстрактного рейтинга рассуждений. ITBench-AA проверяет не “знает ли модель Kubernetes”, а может ли агент работать как младший SRE в ограниченной, но реалистичной среде: читать артефакты, выбирать команды, собирать причинную цепочку и не фантазировать сверх данных.

Вывод пока простой: AI-агенты уже подходят для помощи в сортировке инцидентов, первичном разборе и обучающих сценариях, но выпускать их в полностью автономное реагирование рано. Новый бенчмарк важен именно потому, что переводит разговор из демо в проверяемую инженерную плоскость: не “модель рассуждает”, а “модель нашла все причины и не придумала лишних”.