«Точность скрывает проблему надёжности»: IBM измерила, как часто агент проваливает ту же самую задачу

Средняя точность против надёжности на повторе

Пост вышел 15 сентября 2026 года в блоге Hugging Face, под ним подписаны двенадцать авторов из IBM Research, включая Эвелин Дуэстервальд (Evelyn Duesterwald), Лилиан Нгвету (Lilian Ngweta) и Мерве Унувар (Merve Unuvar). Это продолжение более ранней публикации, в которой авторы представили ALTK-Evolve — систему, превращающую прошлые траектории агента в переиспользуемые правила и подставляющую их обратно во время инференса. Новый текст вводит отдельный тип правил, «правила согласованности», и инструмент диагностики под названием Consistency Analyzer.

Отправная точка — разница между двумя метриками. Обычная оценка агентов считает Mean@k: задачу запускают k раз и усредняют долю успехов, часто при k=3, а иногда и при k=1; именно это число стоит в таблицах лидербордов и означает «77% точности» на практике. Второе число — Pass^k: доля задач, в которых агент справился во всех k запусках. Отдельно авторы напоминают про Pass@k, где достаточно успеха хотя бы в одной из k попыток: это оптимистичная метрика, она отвечает на другой вопрос. Соотношение между ними авторы записывают как Pass^k ≤ Mean@k ≤ Pass@k, а разницу Mean@k минус Pass^k называют разрывом согласованности.

Цифры для примера: ReAct-агент на GPT-4.1 на наборе AppWorld test_normal показывает Mean@5 77,4% и Pass^5 всего 53,0%. Иначе говоря, почти четверть бенчмарка — это задачи, которые агент решает через раз, хотя сама задача между запусками не меняется. На сложных задачах разрыв доходит до 30 пунктов. Авторы подчёркивают, что это не проблема возможностей: агент может быть способным и одновременно нестабильным, и увеличивать модель — не то же самое, что повышать согласованность.

Почему агент «переламывается»

Причина, по мнению авторов, в форме распределения вероятностей на каждом решении. Любой выбор агента — какой API вызвать, какой аргумент передать, повторять ли попытку — выходит из распределения по следующим токенам. Острое распределение ставит почти всю массу на один токен: следующие варианты далеко позади, и один и тот же выбор повторяется из запуска в запуск. Плоское распределение размазывает сопоставимую массу по нескольким почти равным токенам, и победитель определяется почти как подбрасывание монеты.

Дальше вступают эффекты платформы. Острые распределения устойчивы: неассоциативность вычислений с плавающей точкой на GPU, батчирование запросов и прочие побочные эффекты сдвигают числа незначительно, чтобы переставить явного лидера. Плоские распределения к такому сдвигу чувствительны, потому что почти равные варианты могут поменяться местами. А поскольку траектория связывает десятки решений, небольшая вероятность «перелома» на каждом шаге накапливается в большую вероятность того, что какой-то запуск пойдёт иначе, — отсюда и 24 пункта разрыва.

Отдельно авторы объясняют, почему настройки декодирования эту проблему не снимают: жадное декодирование и фиксированный seed определяют, как распределение превращается в токен, но ничего не говорят о самом распределении. На хостируемом эндпоинте вероятности немного меняются от запуска к запуску, поэтому один и тот же промпт к одной и той же модели при нулевой температуре может разрешить почти равный выбор сегодня одним способом, а завтра другим. В их собственной установке агент работает при temperature 0.0, то есть наблюдаемая вариативность — не обычная случайная выборка.

Как устроена диагностика

Consistency Analyzer получает одну записанную траекторию и воспроизводит каждый шаг решения через контролируемый ресемплинг, измеряя, насколько вывод модели варьируется именно в этой точке. Технически это один дополнительный вызов модели на шаг решения, выполненный один раз офлайн: при выборке запрашивается k вариантов завершения сразу (по умолчанию k=5) и они проигрываются против уже записанного контекста — без новых вызовов инструментов, без новых взаимодействий со средой и без второго сквозного прогона задачи. Результат — оценка согласованности по каждому шагу, собранная в отчёт-«scorecard», который показывает, какие решения рискуют перевернуться на следующем запуске.

Авторы подчёркивают, что метод полностью «чёрноящичный»: без логитов, без внутренностей модели и без какой-либо инструментовки сверх уже имеющейся траектории. Для диагностики нужны одна трасса и отсутствие эталонных ответов — именно поэтому, по их словам, подход применим к рабочему трафику, где задачу часто нельзя прогнать сквозь среду даже один раз.

Правила вместо разовой заплатки

Каждый помеченный шаг становится кандидатом в «правила согласованности» в стандартном формате ALTK-Evolve, поэтому он попадает в уже существующий конвейер хранения и извлечения. В посте приведён реальный пример — две инструкции, которые GPT-4.1 сгенерировал по траектории задачи AppWorld «How many activities are done in my bucket list as per my SimpleNote note?»: при подсчёте чекбоксных маркеров в тексте заметки использовать регулярное выражение с привязкой к строке, а не простой подсчёт подстроки, потому что заголовки заметок часто повторяют символ-маркер в строке-легенде; и всегда проверять результаты поиска по заметкам, убеждаясь, что совпадений несколько, прежде чем продолжать.

Ценность здесь не в конкретике одной задачи. Ошибки подсчёта строк и непроверенные результаты поиска — это шаги, которые с высокой неопределённостью всплывают во множестве задач AppWorld, и анализатор нацелен именно на нестабильность, а не на провал: он ловит шаги, которые агент на этот раз угадал, но легко мог бы пройти иначе. Для наглядности авторы приложили двухминутное демо: пять параллельных запусков агента на этой задаче разделились 3 к 2 из-за неуверенности в стратегии подсчёта, а после добавления правил в контекст все пять запусков дали одинаковый результат.

Результаты: разрыв вдвое, точность не страдает

Оценка шла на AppWorld test_normal (168 задач) с ReAct-агентом на GPT-4.1: правила строились по одной базовой траектории на задачу и проверялись на пяти новых запусках. В сумме Pass^5 вырос с 53,0% до 69,0%, а Mean@5 — с 77,4% до 81,0%, то есть разрыв между «выглядит способным» и «на него можно положиться» сократился с 24,4 до 12,0 пункта. Почти треть ранее нестабильных задач стала задачами, которые агент проходит в каждом запуске.

По уровням сложности выигрыш распределён так: средний уровень +22,9 пункта (+44% относительно), сложный +14,3 пункта (+45%), лёгкий +12,2 пункта — там просто было меньше места для роста. Важная оговорка авторов: Mean@5 не падает нигде. Сохранение средней точности было жёстким требованием, а не приятным бонусом: система, которая поднимает Pass^5 за счёт Mean@5, просто перекладывала бы ненадёжность с места на место.

Правила переносятся и на другие задачи: на другом варианте того же сценария AppWorld они всё ещё поднимают Pass^5 на 13,0 пункта — всего на 3 пункта ниже результата для той же задачи. Более резкий аргумент даёт слабая модель gpt-oss-120b: Pass^5 для той же задачи вырос на 6,0 пункта с куда более низкой базы (10,1% → 16,1%), а обобщение на похожую задачу дало +8,7 пункта — больше, чем прирост на исходной задаче. По мнению авторов, это признак того, что правила фиксируют действительно переиспользуемые шаблоны ошибок, а не запоминают особенности одной траектории.

Что авторы советуют тем, кто выпускает агентов

Список рекомендаций в посте короткий. Первое: публиковать Pass^k рядом с Mean@k, потому что среднее не отличает надёжного агента от удачливого, и даже k=3 покажет разрыв, о котором вы не знали. Второе: ожидать, что разрыв растёт со сложностью, — на самом сложном уровне одно усреднённое число обманывает сильнее всего. Третье: не хвататься сразу за более крупную модель, поскольку согласованность ортогональна возможностям, и сильная модель поднимает Mean@k, но не обязательно сокращает разрыв. Четвёртое: для диагностики не нужны ни оценщик, ни живой прогон — достаточно одного дополнительного вызова модели на шаг решения с выборкой из пяти завершений.

Что открыто и где детали

Инструментарий лежит в открытом репозитории AgentToolkit/altk-evolve под лицензией Apache-2.0; в нём описаны установка, MCP-сервер, веб-интерфейс и ускоренный режим запуска, а описание проекта умещается в одну строку — «Self improving agents through iterations». На момент проверки у репозитория 108 звёзд, 14 форков, 60 открытых issues и 8 pull requests, а сам код — на Python 3. В репозиторий, по словам авторов, теперь входят и Consistency Analyzer, и генерация правил согласованности, использованные в экспериментах.

Полная методология — в техническом отчёте «Closing the Consistency Gap: Self-Evolving Agents That Learn to Stay on Course», который вышел на arXiv 8 сентября 2026 года под номером arXiv:2609.08832. Там та же логика описана как самопорождающаяся система: она находит нестабильные шаги с низкой согласованностью и превращает их в эпизодическую память, на которую агент опирается в следующих запусках, а ядром служат Consistency Analyzer и генератор правил. В отчёте для AppWorld с ReAct и GPT-4.1 указан прирост доли задач, решаемых во всех пяти запусках: +16 пунктов на той же задаче и +13 пунктов при обобщении на похожие. Любопытная деталь: блог подписан двенадцатью авторами из IBM Research, а у отчёта на arXiv в списке авторов пятеро — Дуэстервальд, Бенджамин Элдер, Нгвета, Шашанка Убару и Малгожата Зимон.