Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Агента с инструментами научили одновременно улучшать задачи, решения и их проверку. Хотя препринт не прошёл рецензирование и все числа получили сами авторы, UnifiedPlayers обошёл сильнейший аналог как минимум на 3,5%. Для команд это аргумент не поручать самогенерацию данных одному исполнителю, а выделить отдельную обучаемую проверку.
Как три роли учатся на одном исполняемом результате
UnifiedPlayers разделяет обучение между планировщиком, исполнителем и оценщиком. Планировщик придумывает многошаговую задачу, исполнитель решает её с вызовами Python, а оценщик пишет программу, которая принимает или отклоняет всю траекторию: рассуждения, обращения к инструменту, полученные ответы и итог.
Обычная самопроверка часто опирается на согласие между несколькими ответами модели. Если большинство повторяет одну ошибку, система принимает её за правильный ответ и закрепляет при обучении. UnifiedPlayers вместо этого запускает проверяющий код в песочнице, поэтому одинаковые ответы сами по себе ещё не дают исполнителю высокую награду.
Один проверяющий код тоже может выродиться в правило, которое принимает или отклоняет всё подряд. Поэтому фиксированный механизм создаёт испорченные копии исходных траекторий, а песочница прогоняет программы оценщика как по оригиналам, так и по этим копиям. Получается матрица вердиктов, которая показывает, какие решения проходят проверку и различает ли оценщик исходную и намеренно повреждённую версии.
Каждая роль получает свою награду из этой матрицы. Планировщик поощряется за новые задачи около границы возможностей исполнителя, для которых удаётся написать различающую проверку. Исполнитель получает награду за прохождение проверяющих программ. Оценщик должен принимать исходные траектории, отклонять повреждённые и не копировать один шаблон кода.
Роли обучают по очереди через групповую относительную оптимизацию стратегии (GRPO): модель сравнивает несколько своих вариантов в одинаковом контексте и усиливает варианты с более высокой наградой. Пока обновляется одна роль, две другие остаются зафиксированными. После блока новый планировщик сразу готовит данные для исполнителя, а новый исполнитель — для оценщика, поэтому обратная связь обновляется внутри цикла.
Проверка стала различать ошибки, а не только согласие
Метод проверили на Qwen3-4B-Base и MiMo-7B-Base, охватив двенадцать наборов задач на математические и общие рассуждения. Во время обучения планировщик создавал математические задачи, исполнитель обращался только к Python, а главным соперником служил Agent0. Это проверка небольших базовых моделей в среде с кодом, а не произвольных агентов с браузером, корпоративными API или физическими действиями.
На математических задачах UnifiedPlayers превзошёл сильнейший предыдущий метод минимум на 3,5%, на общих рассуждениях — на 3,9%. Перенос на общие задачи примечателен тем, что обучающие задания относились к математике: улучшение не осталось внутри распределения, которое создавал планировщик.
Оценщик правильно различал исходные и повреждённые траектории в 84,2% случаев. Разброс награды между вариантами решения одного вопроса оказался в 2,03 раза выше, чем у самопроверки Agent0. Здесь больший разброс полезен: обучение получает менее одинаковый сигнал и может отличить удачную траекторию от слабой.
Механизм повреждения оказался не вспомогательной деталью. Без него средние результаты на математических и общих задачах снижались на 4,8 пункта. Значит, обучаемому оценщику недостаточно показывать только хорошие примеры: ему нужны целевые ошибки, на которых проверяющая программа учится проводить границу.
Меняет ли UnifiedPlayers планы агентных команд
Работа меняет план эксперимента, если команда собирается улучшать агента на созданных им самим траекториях. Связка «генератор задач плюс исполнитель» оставляет замкнутый контур: исполнитель формирует ответы и косвенно решает, какие из них считать правильными. UnifiedPlayers добавляет независимую роль, но связывает её с тем же наблюдаемым результатом — выполнением кода.
Практический прототип потребует не только дополнительной модели или адаптера. Нужны песочница, механизм правдоподобного повреждения траекторий и бюджет на многократный запуск проверок. Проверяющий код также придётся привязать к результатам конкретного процесса: состоянию базы, ответу API, расчёту или иному исходу, который можно проверить автоматически.
Свежая обратная связь важнее заранее накопленного набора вердиктов. Когда обновлённые роли сразу передавали результаты следующей роли, качество математики выросло ещё на 1,5 пункта, а общих рассуждений — на 1,7 пункта относительно режима с задержанной обратной связью при равных вычислениях. Поэтому три независимо обученных компонента не заменят общий цикл сбора доказательств.
Для продуктового агента вывод пока архитектурный, а не готовый рецепт обучения. Метод стоит проверять там, где ошибку можно воспроизвести и автоматически отличить от корректного исхода. Если результат оценивается только субъективным текстовым мнением, главное преимущество UnifiedPlayers — исполняемая проверка — исчезает.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
