Когда состояние базы важнее слов агента: как ThinkingBox превращает проверки в награды для RL

Microsoft и Hugging Face описывают подход, в котором результат работы агента оценивается по конечному состоянию базы данных, а тот же исполнимый сигнал используется для постобучения. На тестах ThinkingBox-Bench дообученная модель стала заметно стабильнее, хотя немного потеряла широту покрытия.

Отчёт агента — не доказательство результата

В агентных системах есть принципиальная разница между сообщением «задача выполнена» и фактическим изменением данных. Агент может корректно вызвать несколько инструментов, сформировать убедительное объяснение и всё же оставить в рабочей базе неверную запись. Именно эту проблему Microsoft и Hugging Face исследуют в ThinkingBox: агент получает доступ к реальному по структуре бэкенду и набору MCP-инструментов, а после завершения его работы проверяется не текстовый ответ, а итоговое состояние базы.

В описанном эксперименте тот же механизм проверки использовали уже не только как тест, но и как функцию вознаграждения для обучения с подкреплением. Если обязательные изменения присутствуют, а лишние или ошибочные побочные эффекты отсутствуют, эпизод получает награду 1. В противном случае награда равна 0.

Что изменилось после дообучения

Авторы дообучили Qwen3.8-27B с помощью GRPO в течение 50 шагов. В обучающий пул вошли 187 задач, отобранных отдельно от ThinkingBox-Bench. Сам бенчмарк из 507 задач оставили для последующей оценки.

На каждой задаче модель запускали 20 раз. Средняя доля успешных попыток, то есть pass@1, выросла с 51,70% до 60,78%. Ещё заметнее изменился показатель повторяемости: число задач, пройденных успешно во всех 20 запусках, увеличилось с 38 до 107. Это рост с 7,50% до 21,10%.

При этом pass@20 — доля задач, которые модель смогла решить хотя бы один раз, — немного снизился: с 453 до 446 задач, или с 89,35% до 87,97%. Иными словами, модель стала менее широкой, но более стабильной. Для прикладных сценариев, где ошибка в записи клиента или платеже неприемлема, такая разница между «иногда получается» и «получается снова и снова» особенно важна.

Почему средняя точность недостаточна

ThinkingBox предлагает смотреть на несколько метрик одновременно. Pass@1 показывает средний успех отдельных попыток, а pass@20 — способность найти решение хотя бы в одном из повторов. Показатель observed 20/20 отвечает на более строгий вопрос: какие задачи модель решает каждый раз в серии испытаний.

На одном из примеров агент должен был оформить понижение категории гостиничного номера, но политика требовала предварительного согласования менеджера. До обучения базовая модель в 15 из 20 попыток меняла бронирование и возвращала деньги без нужного разрешения. После RL-настройки она во всех 20 попытках сохраняла состояние бронирования и платежа; при этом все ожидаемые записи совпали в 19 запусках.

Авторы также приводят оценку вычислительных затрат. Для кампании из 507 задач и 20 повторов расчётная стоимость снизилась с 925,80 до 855,58 доллара, а стоимость одной успешной попытки — с 0,177 до 0,139 доллара. Эти суммы названы сравнительным индексом обслуживания, а не счётом за облачную инфраструктуру: в них не включены обучение и предварительный отбор данных.

Как выбирали задачи для обучения

Ключевая идея — не обучать модель на задачах, которые для неё уже слишком просты или пока практически недостижимы. Если все восемь траекторий в группе получают нулевую награду, GRPO не видит успешного поведения для сравнения. Если успешны все восемь, различий тоже нет. Полезна смешанная группа, где одни попытки проходят проверку, а другие — нет.

Поэтому каждую кандидатную задачу сначала запускали несколько раз на базовой политике. На основе числа успехов оценивали скрытую вероятность решения с помощью бета-распределения Джеффри. Затем задачи распределяли по пяти диапазонам. Почти всегда провальные и почти всегда успешные задачи отбрасывали, а промежуточные сохраняли для обучения. Такой отбор назван offline policy-relative difficulty: сложность определяется не абстрактно, а относительно текущей версии модели.

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

Что именно получает награду

Награждается не конкретный сценарий действий и не совпадение с заранее записанной последовательностью инструментов. Проверяется конечный результат: правильные записи, необходимые побочные эффекты и отсутствие лишних изменений. Благодаря этому агент может находить новый путь к тому же корректному состоянию, а не механически повторять демонстрацию.

Большинство проверок выполняются детерминированно. Для узких требований, которые нельзя надёжно вывести из состояния базы, используется отдельная бинарная проверка с настроенным LLM-судьёй. Авторы подчёркивают, что код интерпретации вывода модели в обучении и оценивании должен быть одинаковым: различия в извлечении рассуждений, вызовах инструментов или типах аргументов способны превратить награду в сигнал не для того поведения, которое затем измеряется.

Практический вывод

ThinkingBox показывает полезный шаблон для агентов, работающих с состоянием: сначала определить проверяемый конечный результат, затем превратить эту проверку в сигнал обучения. Но одного показателя pass@1 для оценки надёжности недостаточно. Перед внедрением стоит повторять задачи, измерять одновременно покрытие и стабильность, проверять паритет обучающего и оценочного конвейеров и заранее изучать распределение сложности.

Результаты не означают, что дообучение автоматически делает агента лучше во всех смыслах. В представленном эксперименте модель стала заметно более повторяемой, но немного потеряла способность хотя бы однажды решать широкий набор задач. Кроме того, тестовый набор был отделён от обучающего, однако оба использовали общую инфраструктуру ThinkingBox, похожий стиль задач и часть инструментов. Поэтому переносимость результата имеет ограниченные рамки и требует отдельной проверки.