ThinkingBox учит агентов по состоянию базы, а не по убедительности ответа
Microsoft и Hugging Face использовали исполняемые проверки как награду. Повторяемость улучшилась, но охват задач изменился неоднозначно.
Проверка того, что осталось после работы
ThinkingBox возник как тест для агентов, выполняющих деловые операции через инструменты. В каждом задании важно итоговое состояние записей: статус обращения, бронирование, платёж или побочное изменение. Правильно оформленный вызов инструмента ещё не означает, что достигнут нужный результат. В первом октябрьском материале Microsoft и Hugging Face показали случай, когда агент выполнил несколько внешне разумных шагов и закрыл обращение, хотя проблема доставки оставалась открытой. Набор ThinkingBox-Bench содержит 507 сценариев; каждый запускается многократно из одинакового исходного состояния. Это позволяет отделить единичный удачный проход от повторяемого поведения, а изменение базы — от красивого завершающего сообщения.
Из оценщика сделали сигнал обучения
22 октября авторы описали продолжение: исполняемую проверку конечного состояния использовали как награду для обучения с подкреплением. Тренировочные задания построены в том же формате, но находятся вне проверочного набора. Для отбора оценивали вероятность успеха исходной модели: слишком простые сценарии почти не давали нового сигнала, слишком трудные также оказывались мало полезны. Выбранный пул зафиксировали до обучения. В эксперименте с Qwen3.8-27B после 50 шагов GRPO доля успешных попыток выросла с 51,70 до 60,78 процента. Число заданий, выполненных без ошибки во всех двадцати попытках, поднялось с 38 до 107. Это измерение устойчивости внутри опубликованного эксперимента, а не гарантия поведения в произвольном сервисе.
Три показателя отвечают на разные вопросы
Одновременно доля задач, решённых хотя бы однажды за двадцать попыток, немного снизилась: с 453 до 446 задач. Такой результат не противоречит росту среднего успеха. Модель может чаще правильно проходить знакомые типы сценариев и при этом перестать изредка находить решение некоторых других. Именно поэтому авторы отдельно показывают среднюю удачу, охват хотя бы одним успехом и наблюдаемое прохождение 20 из 20. Последняя метрика тоже не означает доказанную стопроцентную надёжность: это результат конечного числа испытаний. Иллюстрация с изменением гостиничного бронирования показывает ещё одну грань — иногда правильное действие состоит в сохранении записей до получения необходимого согласования, а не в максимально быстром выполнении запроса.
Как устроено воспроизведение
Вместе с текстом доступны инструкции по объединению обученных контрольных точек и оценке через vLLM и OpenEnv. Руководство фиксирует ожидаемый объём: 507 заданий по двадцать повторов, то есть 10 140 уникальных результатов. Проверяются пропуски, повторы и системные ошибки; итоговый показатель не предлагается считать по неполному прогону. Обучение и обслуживание требуют собственной инфраструктуры, а пример команды не создаёт вычислительные узлы автоматически. Здесь существенны версии данных, шаблоны инструментов и начальное состояние серверов. Иначе изменение результата можно ошибочно приписать модели, хотя причина находится в окружении. Публикация даёт исследуемый способ получения награды и воспроизводимый контур испытаний, а не готовую замену прикладным правилам доступа и согласования операций.
