Как выявление ошибок ИИ-агентов делает их более надежными

Путешественник просит агента поддержки перенести бронирование отеля стоимостью 1450 долларов с люкса на номер делюкс. Согласно политике компании, для этого изменения сначала требуется одобрение менеджера. В 15 из 20 попыток модель с открытыми весами Qwen3.8-27B все равно внесла изменения. Она обновила номер, вернула деньги, отметила тикет поддержки как решенный и сообщила путешественнику, что все готово.

Хотя это может звучать как хорошее обслуживание клиентов, это является нарушением политики компании.

В нашей первой публикации сбой происходил в другую сторону. Агент сообщил путешественнику, что его запрос на тихий номер добавлен, в то время как поле специальных запросов в бронировании осталось пустым. Мы создали ThinkingBox, чтобы обнаруживать оба вида сбоев. Она запускает агента в изолированной среде с сохранением состояния, позволяет симулированному пользователю отвечать на его вопросы, а затем проверяет записи, оставленные агентом, вместо того чтобы просто доверять тому, что он сказал.

С тех пор мы расширили оценку до 18 моделей и опубликовали наш метод и результаты в paper. В этой статье рассматриваются три вывода, которые мы сделали:

• Средний успех и повторяемый успех ранжируют модели по-разному
• Самая дешевая успешная попытка не означает самую дешевую надежную задачу
• Та же проверка, которая оценивает агента, может быть использована для его обучения

После 50 шагов обучения с подкреплением на задачах за пределами бенчмарка та же модель 27B оставила это бронирование и его платежи нетронутыми во всех 20 попытках. В рамках бенчмарка из 507 задач количество задач, которые она успешно прошла во всех 20 попытках из 20, выросло с 38 до 107.

Большинство неуспешных запусков выглядели завершенными

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

В нашей статье сравнивается вердикт выполнения с тремя более слабыми сигналами на общем наборе задач по 12 моделям. Из 121 680 валидных попыток 79 853 не прошли проверку выполнения. В 67,24% этих сбоев агент все же завершал работу финальным ответом, сигнализирующим о завершении без задавания вопросов, вызывал по крайней мере один инструмент, изменяющий состояние, и не получал явной ошибки в своем финальном ответе инструмента.

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

Но записи говорили о другом. В 98,95% сбоев конечная база данных отличалась от ожидаемой. В 77,61% поле содержало неверное значение. В 43,30% агент внес изменения, о которых никто не просил, а в 25,36% необходимое изменение так и не произошло.

В статье также каждый неудачный запуск помечен одной доминирующей сигнатурой сбоя. В среднем по оцениваемым моделям 79,9% сбоев были связаны с использованием инструментов: агент сталкивался с ошибкой инструмента, невыполненным предварительным условием или пустым поиском и не восстанавливался, иногда продолжая работу так, будто действие было выполнено успешно. Эти метки описывают то, что показывает трассировка, а не доказанную первопричину. Но они указывают на исправления, не требующие новой модели: классифицируйте ошибки инструментов и системы, чтобы повторные попытки были направлены на восстанавливаемые, ограничивайте набор инструментов необходимым для рабочего процесса и требуйте одобрения человека для изменений, которые дорого отменить. Мы не измеряли, насколько помогает каждое из этих действий. Обучение, о котором пойдет речь в остальной части этой статьи, — это один из способов улучшить повторяемость, но не единственный.

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

Средний успех и повторяемый успех ранжируют модели по-разному

Запуск каждой задачи 20 раз дает три разных взгляда на одну и ту же модель:

• Pass@1: Доля всех 10 140 попыток (507 задач x 20), которые завершились успешно. Это эквивалентно среднему проценту успешных прохождений.
• Хотя бы один раз: Задачи, которые модель успешно прошла хотя бы в одной из своих k=20 попыток.
• Pass^20: Доля задач, которые модель успешно прошла во всех 20 зарегистрированных попытках. Таблицы также показывают соответствующее количество задач.

С момента нашей первой публикации мы расширили сравнение и обучили собственный чекпойнт, о котором рассказано далее в этой статье. В Таблице 1 обновлена таблица лидеров с выбранными моделями из этой оценки: pass@1 по доменам и в целом, а также pass^20 с количеством задач.

Kimi-K3 успешно прошла 476 из 507 задач хотя бы один раз, что больше, чем любая другая модель, показанная на Рисунке 2. Она прошла всего 68 задач во всех 20 попытках. Claude Opus 5 прошла меньше задач хотя бы один раз (401), но успешно прошла 241 задачу во всех 20 попытках. Одна модель находит больше решений. Другая повторяет свои решения более надежно. Другими словами, одна модель лучше исследует пространство поиска и ищет инновационные решения ценой большей вариативности, в то время как другая лучше использует известные стратегии решения.

Средняя точность тоже не закрывает этот вопрос. GPT-6 Astra набрала 58,31% по метрике pass@1, примерно на семь пунктов ниже, чем GPT-5.4 с 65,36%. Тем не менее, она успешно прошла 231 задачу во всех 20 попытках по сравнению со 128 у GPT-5.4. Мы также запустили Claude Opus 5.5, которая не фигурирует в статье, с тем же протоколом. Она набрала на 0,66 балла больше, чем Claude Opus 5 по метрике pass@1, и успешно прошла ровно такое же количество задач (241) во всех 20 попытках.

Какая колонка имеет значение, зависит от задачи. Если человек проверяет каждый результат, модели, которая в конечном итоге находит ответ, может быть достаточно. Если агент изменяет производственные записи без проверки, колонка pass^20 ближе к тому, что вам нужно. Это все еще наблюдение по 20 попыткам, а не гарантия для 21-й попытки, хотя увеличение числа попыток дает все более точную оценку.

Во сколько обходится надежная задача

В нашей первой публикации средний успех отделялся от повторяющегося успеха. Расширенная оценка добавляет сравнение затрат с использованием двух показателей:

• Стоимость одной успешной попытки: Оценочная стоимость всего запуска 507 x 20, разделенная на количество успешных попыток.
• Стоимость задачи со всеми 20 успешными попытками: Стоимость той же кампании, разделенная на количество задач, пройденных во всех 20 попытках.

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

Claude Opus 5.5 — это дополнительная оцениваемая модель, а не строка в Таблице 23 нашей статьи. Эти две колонки ранжируют модели по-разному. Среди 18 моделей из статьи GPT-5.6 Sol является самой дешевой в расчете на успешную попытку, но третьей — в расчете на задачу со всеми 20 успешными попытками. GPT-6 Astra стоит более чем в два раза дороже в расчете на успешную попытку, но при этом занимает второе место в расчете на задачу со всеми 20 успешными попытками, поскольку она чаще повторяет свои успехи.

Ни одна модель в Таблице 2 не является одновременно самой дешевой и самой точной, поэтому реальный вопрос заключается в том, какие модели вообще стоит рассматривать. Модель находится на границе Парето, если никакая другая модель не является одновременно более дешевой и по крайней мере столь же хорошей. На Рисунке 3 эта граница построена для стоимости одной успешной попытки: GPT-5.6 Sol, GPT-5.4 и Claude Opus 5.5. Каждая другая модель на графике превосходится по обеим осям одной из этих трех.

Граница зависит от того, что вы считаете хорошим качеством. Измерьте качество по задачам, пройденным во всех 20 попытках, оцените его в расчете на такую задачу, и граница изменится: GPT-5.6 Sol выбывает, а GPT-6 Astra присоединяется к GPT-5.4 и Claude Opus 5.5. Выбор в пользу повторяемости дает вам совсем другой короткий список, чем выбор в пользу среднего успеха.

Qwen3.8-27B отчетливее всего демонстрирует этот разрыв. Его успешные попытки обходятся недорого: по $0.177 каждая. Однако он успешно справился лишь с 38 задачами во всех 20 попытках, поэтому каждая надежно выполненная задача обошлась в $24.36.

Первая цена говорит о том, во сколько обходится попытка. Вторая показывает цену стабильности. Это породило новый вопрос для остальной части данной работы: можно ли снизить вторую цену за счет изменения самой модели, а не перехода на другую?

Превращение проверки в вознаграждение

Исполняемая проверка возвращает 1 или 0 на основе финальных записей. Это в точности соответствует форме вознаграждения в обучении с подкреплением. Для большинства задач вердикт полностью формируется за счет детерминированных проверок финального состояния; в меньшинстве случаев также используется узкий вопрос «да-нет» для модели-судьи для проверки требований, которые не могут быть зафиксированы в поле базы данных, например, уведомление клиента о том, что его предпочтение не гарантировано. В любом случае вознаграждение представляет собой один бинарный вердикт на попытку. Мы обучили Qwen3.8-27B в той же среде, которая использовалась для его оценки: с тем же изолированным бэкендом, интерфейсом инструментов MCP, циклом симуляции пользователя и оценкой терминального состояния. Для обучения мы использовали GPT-5 Chat в качестве симулируемого пользователя и судьи; для оценки по бенчмарку в этих ролях применялась GPT-5.4-mini. При обучении использовались задачи в формате ThinkingBox, не пересекающиеся с 507 задачами из бенчмарка: другие серверы MCP, структуры данных, бизнес-домены и политики. Хотя — в силу схожести общей настройки песочницы, настройки серверов MCP и инструментов — некоторое пересечение все же возможно, бенчмарк из 507 задач по-прежнему можно считать находящимся вне распределения (out-of-distribution).

Мы использовали GRPO, который производит выборку группы попыток для одной и той же задачи и вознаграждает каждую попытку относительно среднего значения по группе. При восьми попытках и бинарном вознаграждении математика оказывается беспощадна. Если все восемь попыток терпят неудачу, вознаграждения равны [0, 0, 0, 0, 0, 0, 0, 0]. Если проходят все восемь, они равны [1, 1, 1, 1, 1, 1, 1, 1]. В обоих случаях задача не дает сигнала вознаграждения. Смешанная группа, такая как [0, 0, 0, 1, 1, 1, 1, 1], дает его: успешные попытки получают положительное подкрепление, а неудачные — отрицательное.

Каждая попытка в группе представляет собой полноценный эпизод со своим собственным бэкендом, сеансом работы с инструментами и симулируемым пользователем. Группа, которая ничему не учит, все равно стоит восьми эпизодов. Поэтому практический инженерный вопрос заключался в том, какие именно задачи должны попадать в обучающую выборку.

Мы ответили на него один раз перед началом обучения на базовой модели:

• Отбор. GPT-5.4 выполнила каждую задачу-кандидат для проверки разрешимости.
• Зондирование. Базовая модель Qwen3.8-27B запускала каждую задачу-кандидат несколько раз.
• Классификация. Мы оценили вероятность успеха каждой задачи с помощью апостериорного распределения Джеффриса, Beta(k + 1/2, n - k + 1/2) для k успехов в n зондированиях, и отнесли задачу к одному из пяти диапазонов сложности.

Мы оставили задачи, чья наибольшая апостериорная масса приходилась на три средних диапазона (от 0.08 до 0.90), и отбросили задачи из крайних диапазонов. Например, задача-кандидат, которую базовая модель способна решить в трех зондированиях из восьми, получает апостериорное распределение Beta(3.5, 5.5); 54.0% этого распределения приходится на диапазон «Сложные» (от 0.08 до 0.40), что больше, чем в любом другом диапазоне, поэтому задача сохраняется. В результате получился фиксированный набор из 187 тренировочных задач.

Имея фиксированный набор для обучения, мы заменяли группы с нулевой дисперсией во время батчинга, следуя подходу DAPO, и заполняли группы, потерянные из-за системных сбоев, вместо того чтобы засчитывать таймаут бэкенда как неверный ответ.

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

Для обучающего прогона мы использовали обучение по всем параметрам (full-parameter training) с GRPO на уровне средних значений токенов на 24 графических процессорах H100. На каждом шаге планировалось 18 групп по восемь попыток. Мы использовали скорость обучения (learning rate) 1e-6, отсутствие штрафа KL, нулевой коэффициент затухания весов (weight decay), а в качестве симулируемого пользователя и судьи — GPT-5 Chat. Мы приводим результаты для 50-й контрольной точки (checkpoint 50).

Что изменилось

Мы оценили 50-ю контрольную точку на всех 507 задачах бенчмарка по 20 попыток на каждую в рамках того же протокола, что и для всех остальных моделей.

Модель стала более стабильной, а не универсальной. Она успешно справилась с 69 дополнительными задачами во всех 20 попытках и потеряла по крайней мере один успешный результат в семи задачах.

Средняя точность также выросла. С показателем 60.78% обученная модель опережает GPT-6 Astra и Kimi-K3 по метрике pass@1 (Таблица 1), и в статье она заявлена как лучшая среди всех оценивавшихся моделей с количеством параметров менее 100 млрд.

Стоимость изменилась вслед за стабильностью. Стоимость каждой надежно выполненной задачи снизилась с $24.36 до $8.00, что находится в том же диапазоне, что и у GPT-5.4 ($6.80), GPT-6 Astra ($7.45) и Claude Opus 5.5 ($7.80). Цена отдельного успешного выполнения изменилась в меньшей степени. На рис. 5 обученная модель нанесена на тот же график, что и на рис. 3: она сместилась с $0.177 до $0.139 за успешное выполнение и с 51.70% до 60.78% по pass@1 — близко к границе эффективности, но все еще позади GPT-5.6 Sol по обеим осям. Более существенное изменение наблюдается в расчете на надежно выполненную задачу, поскольку обучение почти втрое увеличило количество задач, успешно решаемых при каждой попытке. Эти сравнения учитывают только затраты на инференс. Они ничего не говорят о том, во сколько обошелся сам процесс обучения.

Задача с отелем на рис. 1 показывает, как именно изменения выглядят на примере одной конкретной задачи. После обучения модель не внесла изменений в бронирование и платежи ни в одной из 20 попыток. Все ожидаемые записи совпали в 19 случаях из 20; в одной попытке отсутствовал ожидаемый тег. Отказ от изменения бронирования необходиров для выполнения этой задачи, однако это не то же самое, что ее успешное прохождение.

Меньшие прогоны LoRA с темным же вознаграждением также показали улучшение: показатель pass@1 для Qwen3.6-27B вырос с 32.94% до 53.17%, а для Qwen3.5-9B — с 5.65% до 13.33% (подробнее см. в нашей статье).

Достижение стабильных результатов при некотором сужении общего охвата согласуется с концепцией заострения (sharpening): вероятность смещается в сторону подходов, которые работают стабильно, а некоторые редко используемые пути исчезают. В предыдущих работах отмечались схожие закономерности.

Что следует иметь в виду

• Синтетические задачи. Задачи из бенчмарка и обучающего набора являются синтетическими реконструкциями корпоративных рабочих процессов с симулированными пользователями. Это не производственный трафик.
• Отложенные, но связанные задачи. Ни одна задача из бенчмарка не использовалась при обучении. Тем не менее, задачи обучения и бенчмарка используют общий фреймворк ThinkingBox, дизайн симулируемого пользователя, подход к оценке и стиль задач. Мы не измеряли перенос навыков на несвязанные сценарии работы агентов.
• Проверки настолько полны, насколько полны их спецификации. Вознаграждение, построенное на основе исполняемых проверок, вознаграждает ровно то, что требуют эти проверки, — и ничего из того, что они упускают из виду.
• Затраты являются приблизительными. Они рассчитаны на основе прейскурантных цен на определенную дату и не включают расходы на обучение, симулятор, судью, инфраструктуру и косвенные издержки от сбоев.

Основные выводы

Если вы создаете агентов, которые вносят изменения в реальные записи, следует напрямую руководствоваться четырьмя правилами:

• Проверяйте состояние, а не стенограммы. Пишите утверждения (assertions) для проверки записей, которые оставляете после себя ваш агент, как мы подробно описывали в нашем первом посте.
• Сообщайте о повторяющихся успехах. Запускайте каждую задачу более одного раза и публикуйте показатель pass@1 вместе с количеством задач, успешно решенных при каждой попытке. Указывайте, какой оценщик вы используете.
• Проверяйте, прежде чем обучать. Запустите вашу базовую модель несколько раз на ваших кандидатных задачах и посмотрите на распределение. Задачи, в которых она всегда терпит неудачу или всегда справляется, требуют полного выполнения и вряд ли чему-то ее научат.
• Держите обучение и оценку синхронизированными. Прогоняйте один и тот же записанный вывод модели через парсеры обучения и оценки и проверяйте, что оба извлекают идентичные имена инструментов и аргументы. В противном случае обучение может поощрять поведение, которое оценка интерпретирует иначе.

Ссылки

• Фреймворк: , с интерфейсом командной строки tb, циклом симулируемого пользователя, прокси-сервером сеансов MCP и тестовым окружением
• Обучение: microsoft/thinkingbox-training, с выбором данных, прогонами, наградами и проверенной эталонной конфигурацией
• Документ:

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