Агент отлично справляется с задачей в тестовом прогоне, а на живой демонстрации вдруг сворачивает не туда и проваливается. На сцене это неловко. В продакшене — это уже вопрос надёжности: запрос, который однажды отработал идеально, при повторе может дать совсем другой результат. А если речь идёт о сверке финансовой транзакции или проверке договора на наличие обязательства, такая нестабильность превращается в стоп-фактор для всей системы.
Исследователи IBM Research — Evelyn Duesterwald, Lilian Ngweta, Vatche Isahagian, Jayaram Radhakrishnan, Vinod Muthusamy, Gaodan Fang, Ashwath Vaithinathan Aravindan, Punleuk Oum, G Thomas, Merve Unuvar, Ayhan Sebin и Michał Ulewicz — опубликовали работу, которая вскрывает неприятную правду: большинство бенчмарков прячут эту изменчивость за средним значением. Команда предложила не только способ измерить проблему, но и инструмент, который сокращает её почти вдвое.
Средняя точность как красивая ширма
Стандартная оценка агентов опирается на метрику Mean@k: запускаем бенчмарк k раз и усредняем долю успешных прохождений. Обычно k равно трём, иногда — единице. Именно это число красуется на каждом лидерборде, и именно его мы подразумеваем, когда говорим «агент точен на 77%».
Но Mean@k отвечает на вопрос «насколько агент хорош в среднем?». Он ничего не говорит о том, что волнует реального пользователя: сработает ли система снова, если задать ей тот же самый вопрос? Для этого нужна другая метрика — Pass^k, доля задач, которые агент решил успешно во всех k запусках подряд.
Важно не путать её с привычной Pass@k. Если Pass@k оптимистична — она проверяет, удался ли хотя бы один из k подходов (что логично, когда результат можно проверить и повторить), то Pass^k — её пессимистичное зеркало: успешными должны быть все попытки без исключения. Всегда выполняется соотношение Pass^k ≤ Mean@k ≤ Pass@k.
Насколько велика разница на практике? На бенчмарке AppWorld агент на архитектуре ReAct с моделью GPT-4.1 показал Mean@5 в 77,4% — действительно сильный результат. А вот Pass^5 оказался равен всего 53,0%. Иными словами, почти четверть задач агент решает то так, то эдак, при том что условия между запусками вообще не менялись. Разрыв в 24,4 процентного пункта авторы называют consistency gap — разрывом согласованности.
И это не проблема возможностей, которую лечат более крупной моделью. Согласованность — отдельная ось: агент может быть одновременно и способным, и непредсказуемым.
Почему агенты «переобуваются»: резкие и плоские решения
Каждый раз, когда языковая модель что-то решает — какой API вызвать, какой аргумент передать, повторять ли попытку, — это решение рождается из распределения вероятностей по следующим токенам. Ключевое значение имеет форма этого распределения.
- Резкое распределение. Почти вся масса сосредоточена на одном токене, конкуренты далеко позади. Один и тот же выбор воспроизводится запуск за запуском.
- Плоское распределение. Масса размазана между несколькими почти равными вариантами, и победитель определяется практически подбрасыванием монеты.
Именно поэтому проблема не исчезает при «правильных» настройках декодирования. Жадное декодирование и фиксированный seed управляют тем, как распределение превращается в токен, но ничего не говорят о самом распределении. На хостинговом эндпоинте вероятности слегка дрожат от запуска к запуску, так что один и тот же промпт к одной и той же модели при температуре ноль сегодня может разрешить почти-ничью в одну сторону, а завтра — в другую. В экспериментах IBM агент работал как раз при temperature 0.0, то есть вся наблюдаемая вариативность не имела отношения к обычной сэмплировке.
Добавьте сюда эффекты вроде неассоциативности вычислений с плавающей точкой на GPU и батчинга запросов: каждый шаг получает крошечный сдвиг, а траектория состоит из десятков шагов. Мизерная вероятность «перевернуться» на одном шаге накапливается в солидный шанс, что какой-то из прогонов пойдёт по другому пути. Отсюда и берётся разрыв в 24 пункта.
Диагностика: Consistency Analyzer
Задача превращается в поиск: какие именно шаги в конкретной траектории оказались «плоскими»? Для этого команда IBM построила Consistency Analyzer — диагностический инструмент, который переигрывает каждый шаг принятия решения из уже записанной траектории и измеряет, насколько реально варьируется вывод модели в этой точке.
Технически это выглядит так:
- Берётся одна записанная траектория — без эталонных ответов и без разметки.
- Каждый шаг решения переигрывается в контролируемом режиме: делается один дополнительный вызов модели, который запрашивает сразу k вариантов завершения (по умолчанию k=5).
- Контекст берётся уже записанный — никаких новых вызовов инструментов, никакого взаимодействия с окружением и никакого повторного сквозного прогона задачи.
- На выходе получается оценка согласованности для каждого шага, которая попадает в scorecard и указывает, какие именно решения рискуют «перевернуться» в следующий раз.
Диагностика полностью «чёрного ящика»: не нужны логиты, внутренности модели или дополнительная инструментация за пределами уже имеющейся траектории. Это делает инструмент пригодным для работы с реальным трафиком в продакшене, где переиграть задачу целиком зачастую невозможно даже один раз.
От диагноза к лечению: consistency guidelines
Второй этап — превращение диагноза в подсказки. Каждый «флажковый» шаг становится кандидатом в consistency guideline — новый тип правил в системе ALTK-Evolve, которая ранее уже умела автоматически дистиллировать опыт агента из прошлых траекторий и подмешивать его обратно во время вывода. Новые правила используют ту же инфраструктуру хранения и извлечения, но управляются принципиально иным сигналом: не ошибкой, а нестабильностью.
Вот реальный пример подсказок, сгенерированных GPT-4.1 по траектории задачи AppWorld «Сколько активностей в моём списке желаний согласно заметке в SimpleNote?»:
- При подсчёте чекбокс-маркеров в содержимом заметки используйте привязанное к строке регулярное выражение, а не простой подсчёт подстрок: заголовки заметок часто повторяют символ маркера в строке-легенде.
- Всегда проверяйте результаты поиска по заметкам — убедитесь, что совпадений несколько, и подтвердите нужную заметку, прежде чем продолжать.
Здесь нет узкой, специфичной для одной задачи информации. Ошибки в подсчёте строк и непроверенные результаты поиска — это точки принятия решений, которые всплывают с высокой неопределённостью во множестве задач AppWorld. В этом и смысл: анализатор нацелен на нестабильность, а не на провал, поэтому он ловит шаги, которые на этот раз агент случайно сделал правильно, но в следующий раз легко сделает неправильно.
Результаты: разрыв сокращён вдвое без потери точности
Оценка проводилась на наборе 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^k, торгуя Mean@k, просто перекладывает ненадёжность с места на место, а не решает проблему.
Подсказки обобщаются, а не латают одну траекторию
Если применить те же правила к другой, но родственной задаче внутри того же сценария 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, но не обязательно сократит разрыв.
- Диагностика не требует оценщика и живого переигрывания. Один дополнительный вызов LLM на шаг решения (с запросом k=5 завершений по умолчанию) — этого достаточно, без эталонных ответов и без повторного запуска задачи в окружении.
Попробовать инструменты можно уже сейчас: открытый репозиторий ALTK-Evolve включает Consistency Analyzer и генерацию consistency guidelines, использованные в экспериментах. Полная методология и оценки описаны в техническом отчёте на arXiv, а двухминутная демонстрация показывает, как пять параллельных прогонов агента сначала расходятся 3:2 из-за неуверенности в стратегии подсчёта, а после подстановки правил в контекст приходят к единому результату.
Вывод
История о том, как агент блистательно проходит задачу один раз и проваливает её при повторе, — не курьёз, а измеримая инженерная проблема. IBM Research показала, что разрыв между средней точностью и реальной воспроизводимостью достигает 24 процентных пунктов и что его можно диагностировать без эталонных ответов и живых переигровок, опираясь лишь на форму распределения вероятностей в точках принятия решений. Превращение диагноза в подсказки сокращает разрыв до 12 пунктов, не жертвуя средней точностью и работая даже на более слабых моделях. Для команд, строящих критичные для бизнеса агентные системы, вывод прост: недостаточно спрашивать, насколько агент хорош — нужно спрашивать, останется ли он таким же при следующем запуске.
