Превращение оценки баз данных в вознаграждения RL: пост-тренировка агентов с помощью ThinkingBox

Это продолжение нашего первого поста в блоге «Агент сказал, что закончил. База данных не согласилась». ThinkingBox-Training теперь доступен на GitHub.

Это продолжение нашего первого поста в блоге «Агент сказал, что закончил. База данных не согласилась». ThinkingBox-Training теперь доступен на .

Мы создали ThinkingBox для оценки работы агента путем сравнения конечного состояния базы данных с ожидаемым результатом. Затем мы использовали тот же тип исполняемого сигнала в качестве вознаграждения для задач обучения вне ThinkingBox-Bench. Для Qwen3.8-27B средний показатель успеха вырос с 51,70% до 60,78%, а количество задач, выполненных правильно во всех двадцати попытках, увеличилось с 38 до 107 после 50 шагов GRPO.

Рисунок 1. ThinkingBox превращает исполняемые проверки конечного состояния базы данных в вознаграждения для пост-тренировки агентов на задачах вне ThinkingBox-Bench.

Это совместный блог Microsoft и Hugging Face. Особая благодарность Мирко Миллетари и Сяну Цзяну из Microsoft, Серхио Паниего из Hugging Face и нашему бывшему стажеру Чжочуню Ли (Питтсбургский университет) за соавторство и рецензирование.

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

Каждая из 507 задач в ThinkingBox-Bench (наш эталонный набор данных) предоставляет агенту реальный бэкенд и набор инструментов, позволяет ему работать, а затем проверяет, что именно изменилось в базе данных. В первом посте мы поймали модель на том, что она закрыла тикет клиента как решенный, в то время как связанное с ним исключение перевозчика все еще оставалось открытым. Девять выглядящих компетентными вызовов инструментов, одна неверная строка в базе данных.

Затем мы заметили, что создали. Для большинства задач исполняемая проверка может возвращать 1 или 0 непосредственно из конечного состояния базы данных. Это не просто оценщик. Это может быть функция вознаграждения.

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

Сложность относительна по отношению к политике: задача сложна для текущей модели только до тех пор, пока эта модель ее не освоит.

Сложность относительна по отношению к политике: задача сложна для текущей модели только до тех пор, пока эта модель ее не освоит.

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

Что произошло после обучения

Мы использовали офлайн-сложность, относительную к политике, чтобы создать пул обучения, а затем дообучили Qwen3.8-27B с помощью GRPO в течение 50 шагов. Напомним, мы оцениваем каждую из 507 задач бенчмарка 20 раз. pass@1 измеряет средний успех по всем 10 140 попыткам. pass@20 измеряет долю задач, решенных хотя бы один раз. Observed 20/20 измеряет долю задач, которые проходят каждую записанную попытку.

Таблица 1. Результаты Qwen3.8-27B до и после 50 шагов GRPO на пуле обучения, выбранном офлайн.

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

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

Рисунок 2. Одна корпоративная задача по бронированию отеля, 20 попыток на модель. Базовая модель Qwen3.8-27B изменила бронирование без требуемого одобрения менеджера в 15 попытках. RL-дообученная модель сохранила состояние бронирования и оплаты во всех 20; все ожидаемые записи совпали в 19.

Содержание

• Что обнаружил бенчмарк за шестьдесят секунд
• Результаты: колонка надежности сдвинулась
• Где были получены приросты
• Чего стоит надежность
• Цикл обучения
• Офлайн-сложность, относительная к политике
• Что приносит вознаграждение
• Запуск стека обучения
• Что будет дальше

Спешите? Главный результат выше. Реализация находится в разделе «Запуск стека обучения».

Что обнаружил бенчмарк за шестьдесят секунд

ThinkingBox-Bench оценивает агентов по записям в базе данных, которые они оставляют после себя. Каждая из 507 задач запускает реальный бэкенд, предоставляет агенту набор инструментов MCP и симулированного пользователя LLM с приватным контекстом, а в конце выполняет исполняемые проверки конечного состояния базы данных. Проверки проводятся по записи в бэкенде, которая должна быть правильной, а не по конкретным вызовам инструментов. Это стимулирует модель находить, возможно, новые пути решения, а не «переоткрывать» решение, предложенное человеком, которое может быть субоптимальным, хотя и правильным.

В нашем первом посте мы прогнали восемнадцать моделей через этот бенчмарк по двадцать раз каждую и сообщили о разрыве, который скрывает общая точность. Kimi-K3 решила 93,89% задач хотя бы один раз, но выполнила только 68 из 507 задач (13,41%) во всех двадцати записанных попытках. Claude Opus 5 инвертировала это: более узкий охват, гораздо большая согласованность.

И более крупная или лучшая модель не закрыла его. Claude Opus 5.5 набрала на 0,66 процентных пункта больше, чем Claude Opus 5 по pass@1, но прошла ровно такое же количество задач, 241, во всех двадцати попытках. Этот прирост в общей точности не дал никакой дополнительной надежности.

Если вы выбираете модель для работы, которая затрагивает производственные записи в базе данных, pass@1 не следует читать отдельно. Observed 20/20 показывает, какие задачи выполняются успешно при каждой попытке, что ближе к тому, чего требует надежность производства.

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

Результаты: колонка надежности сдвинулась

После обучения Qwen3.8-27B мы оценили выбранную контрольную точку после 50 шагов на бенчмарке из 507 задач, на котором она никогда не обучалась. Эти 507 задач представляют собой тестовый набор вне распределения: их домены, базы данных и большинство инструментов MCP не встречались во время RL-обучения.

Таблица 2. ThinkingBox-Bench pass@1 (%) по доменам для выбранных моделей из Таблицы 2 нашего первого блога и нашей дообученной модели для разных доменов и в целом. Числа Observed 20/20 приведены по всему бенчмарку из 507 задач. Каждая модель оценивается по всем 507 задачам в 20 повторных испытаниях. Жирным шрифтом отмечен лидер колонки; подчеркиванием отмечен занявший второе место.

Главный результат — строка observed-20/20 в Таблице 1. Модель 27B, которая изначально выполняла 38 (7,5%) задач ThinkingBox-Bench при каждой попытке, теперь выполняет 107 (21,1%) при каждой попытке, почти в три раза больше. Для сравнения, observed 20/20 для Kimi-K3 составляет 68, GPT-5.4 — 128, GPT-6 Astra — 231, а Claude Opus 5.5 лидирует с 241.

Средний успех и повторяемость дают разные порядки. В Таблице 2 мы замечаем, что GPT-5.6 Sol набрала немного больше по pass@1, чем RL-дообученная Qwen3.8-27B (61,91% против 60,78%), но прошла меньше задач во всех 20 записанных попытках: 82 против 107. Claude Sonnet 4.6 набрала меньше по pass@1, 59,19%, но проходила почти такое же количество задач каждый раз, 102. Ни одна метрика сама по себе не дает полной картины.

Наблюдаемая закономерность согласуется с «заострением» (sharpening): повторяемость успеха возросла, в то время как покрытие «хотя бы раз» немного снизилось. Это соответствует предыдущим работам. Одно из объяснений заключается в том, что распределение вероятностей сместилось в сторону траекторий, которые работают стабильно, в то время как некоторые маловероятные пути исчезли.

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

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

Где проявились улучшения

Рисунок 3. Базовые показатели по доменам, показатели RLFT и изменения в процентных пунктах. Зеленые ячейки показывают рост, красные — снижение; синяя заливка указывает на уровень показателя в рамках каждой метрики.

Показатели Pass@1 и наблюдаемый 20/20 выросли во всех пяти доменах. Результаты Pass@20 оказались неоднозначными: они выросли в сферах необанков и консалтинга, но снизились в ритейле, туризме и автостраховании. В автостраховании зафиксирована наибольшая потеря широты охвата (−7,0 пунктов), в то время как в ритейле — наибольший прирост наблюдаемого показателя 20/20 (+24,5 пункта).

Цена надежности

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

Стоимость одной надежной задачи = оценочная стоимость кампании 507 × 20 ÷ количество задач, решенных 20/20

Стоимость одной надежной задачи = оценочная стоимость кампании 507 × 20 ÷ количество задач, решенных 20/20

Применяя ту же математику затрат к измеренному потреблению токенов дообученным чекпоинтом:

Таблица 3. Оценочная стоимость оценки и надежность для базовой и дообученной с помощью RL модели Qwen3.8-27B. Стоимость одной успешной попытки рассчитывается путем деления общей оценочной стоимости кампании (507 x 20) на количество успешных попыток.

При стоимости $8,00 за надежную задачу дообученная модель приблизилась к GPT-5.4 ($6,80), GPT-6 Astra ($7,45) и Claude Opus 5.5 ($7,80) в сравнительном анализе.

Взгляд на одну попытку

Рисунок 4 сопоставляет стоимость одной успешной попытки с показателем pass@1.

Рисунок 4. Золотая стрелка прослеживает путь от базовой позиции по стоимости Парето для Qwen3.8-27B до RLFT (ромб): pass@1 вырастает с 51,70% до 60,78%, в то время как оценочная стоимость одной успешной попытки падает с $0,177 до $0,139. Обведенные кружки обозначают границу стоимости Парето.

Это перемещает дообученный чекпоинт близко к GPT-5.6 Sol, хотя GPT-5.6 Sol остается дешевле и имеет немного более высокий показатель pass@1. Четыре модели, оцененные в нашей статье, выходят за пределы представленного диапазона.

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

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

Цикл обучения

Рисунок 5. Шесть этапов в контексте: задачи-кандидаты поступают на вход, первые три выполняются один раз в автономном режиме, последние три повторяются для каждой группы в процессе обучения. Обученный чекпоинт оценивается с помощью ThinkingBox-Bench.

Отбор выполняется один раз, в автономном режиме, относительно базовой модели политики, то есть в данном случае Qwen3.8 27B; затем обучение использует этот фиксированный, уже отобранный пул. Пунктирная янтарная стрелка на рисунке 5 отмечает путь, который мы не выбрали: повторное зондирование сложности во время процесса обучения.

Каждый прогон (rollout) — это полный эпизод, а не просто завершение текста. Он получает свежий бэкенд, изолированную сессию MCP и GPT-5 Chat в качестве симулируемого пользователя. Большинство наград поступает от детерминированных проверок конечного состояния; небольшая часть узких требований рубрикатора может вызывать настроенного судью (GPT-5 Chat).

Обучение и оценка должны интерпретировать вывод Qwen идентично. Это включает извлечение рассуждений, вызовы инструментов, типизацию аргументов, рендеринг и изолированное состояние задачи. В противном случае награда измеряет другого агента, а не того, который оценивается. Общий код интерпретации находится в trainer/core/tb_interpret.py.

Для эталонного прогона мы запустили полнопараметрическую RL-дообученную модель Qwen3.8-27B на 187 задачах, используя GRPO со средним значением токенов. Каждое обновление генерировало 18 групп по 8 прогонов, или 144 эпизода, на 24 H100. Обучение проходило синхронно с выгрузкой параметров и оптимизатора; AdamW использовал скорость обучения 1e-6 и нулевой распад веса. Мы проводили обучение в течение 50 шагов.

Группы с нулевой дисперсией заменялись DAPO-style во время обучения. Системные ошибки обрабатывались отдельно: тайм-аут бэкенда не является некорректным результатом работы агента, поэтому затронутые группы были перезаполнены, а не засчитаны как сбои.

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

Автономная сложность относительно политики

Прежде чем углубляться в выбор задач для обучения, сделаем оговорку:

Ни одна задача из ThinkingBox-Bench не была включена в пул обучения RL. Бенчмарк был зарезервирован для оценки.

Ни одна задача из ThinkingBox-Bench не была включена в пул обучения RL. Бенчмарк был зарезервирован для оценки.

ThinkingBox-Bench находится вне распределения относительно пула обучения RL: его домены, базы данных, политики и большинство инструментов не встречались во время обучения RL. Тем не менее, оба набора разделяют фреймворк ThinkingBox, механизмы симулируемого пользователя, исполняемую оценку конечного состояния, несколько общих инструментов и схожий стиль задач. Эти общие элементы ограничивают масштаб утверждения о переносе знаний.

Почему выбор имеет значение, сводится к одному арифметическому факту о 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], обеспечивает контраст, на котором может учиться GRPO. Это различие дорого обходится для агента с состоянием: каждый прогон требует выделения изолированного бэкенда, запуска реальной сессии инструментов и вызова отдельной модели для игры за пользователя.

Вопрос, который сформировал эту работу, был поэтому не только «какая модель или оптимизатор?». Он звучал так: какие задачи-кандидаты должны войти в фиксированный пул обучения?

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

Поэтому мы проводим зондирование. Каждая задача-кандидат многократно запускается против базовой модели политики. Правило на простом языке звучит так: задачи, которые модель всегда проваливает, вряд ли чему-то ее научат; задачи, которые она всегда проходит, уже изучены; задачи, которые она решает иногда, — это то, где результаты могут обеспечить контраст.

Оценка сложности по ограниченным пробам

Каждая задача-кандидат запускается n раз, давая k успехов. Мы моделируем ее латентную вероятность успеха с помощью апостериорной вероятности Джеффриса:

вероятность успеха | k успехов в n пробах ~ Beta(k + ½, n − k + ½)

вероятность успеха | k успехов в n пробах ~ Beta(k + ½, n − k + ½)

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

Мы разбиваем единичный интервал на пять корзин с границами 0.08, 0.40, 0.60 и 0.90, выбранными в качестве гиперпараметров для этих запусков. Каждая задача относится к той корзине, которая содержит наибольшую апостериорную массу:

• Редко решаемые [0, 0.08): исключить
• Сложные [0.08, 0.40): оставить
• Средней сложности [0.40, 0.60): оставить
• Часто решаемые [0.60, 0.90): оставить для полнопараметрического RLFT
• Почти всегда решаемые [0.90, 1]: исключить

Подробности приведены в Appendix C.4 of our ThinkingBox paper.

Одна задача: от начала до конца

Рисунок 7. Подробнее: одна задача на всех шести этапах: скрининг GPT-5.4, зондирование базовой модели (base-model probes), классификация сложности, группа роллаутов, оценка терминального состояния и обновление GRPO.

Рисунок 7 иллюстрирует путь одной задачи-кандидата, которая потенциально может попасть в обучающий пул. Для полнопараметрического пула Qwen3.8 27B модель GPT-5.4 сначала выступила в роли фильтра решаемости. Затем базовая политика успешно справилась лишь с несколькими пробами (например, 3 из 8), что дало апостериорное распределение Beta(3.5, 5.5). Его наибольшая масса (54,0%) пришлась на диапазон «Сложные» (Difficult).

При сэмплировании для обучения задача выдала смешанную группу наград [0, 0, 0, 0, 1, 1, 1, 1]. В результате успешные траектории получили преимущество (advantage) выше среднего по задаче, а неудачные — ниже среднего, обеспечив GRPO контраст, необходимый для обучения. Другая модель политики могла бы определить эту же задачу в иной диапазон сложности.

Итоговый отобранный обучающий пул для Qwen3.8-27B содержал 187 задач.

За что начисляется награда

Никаких наград за траекторию. Награда — это собственный исполняемый вердикт задачи.

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

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

Два пути начисления наград, один бинарный вердикт. Исполняемая проверка (подавляющее большинство случаев). Когда требуемый результат отражен в терминальном состоянии или побочных эффектах, детерминированный тест принимает или отклоняет его; вызов LLM-судьи не требуется. Проверка с участием судьи (меньшинство случаев). Если специфическое требование нельзя однозначно определить по состоянию базы данных, настроенный LLM-судья отвечает на бинарный вопрос из рубрики, который используется в исполняемом тесте.

Два пути начисления наград, один бинарный вердикт

• Исполняемая проверка (подавляющее большинство случаев). Когда требуемый результат отражен в терминальном состоянии или побочных эффектах, детерминированный тест принимает или отклоняет его; вызов LLM-судьи не требуется.
• Проверка с участием судьи (меньшинство случаев). Если специфическое требование нельзя однозначно определить по состоянию базы данных, настроенный LLM-судья отвечает на бинарный вопрос из рубрики, который используется в исполняемом тесте.

Запуск стека обучения

Мы публикуем пайплайн отбора данных, выполнения роллаутов, начисления наград и интеграцию с Verl, использованные для обучения Qwen3.8-27B, в . README репозитория служит отправной точкой. Подробные руководства:

• docs/data-preparation.md для гидратации задач, зондирования политики, исключения бенчмарка и разделения на обучающую/валидационную выборки;
• docs/reference-q38-run.md для валидированной конфигурации Qwen3.8 на 24x H100;
• docs/evaluation.md для слияния чекпоинта и запуска ThinkingBox-Bench 507 x 20.

Перед началом работы

Протестировано на Linux и WSL с Python 3.12 и uv. Вам потребуются графические процессоры NVIDIA с совместимым стеком CUDA/NCCL, локальный чекпоинт Qwen3.8-27B и OpenAI-совместимые эндпоинты для симулированного пользователя и судьи. Проверенная референсная конфигурация использует 3 ноды по 8 GPU H100; более компактные пользовательские конфигурации зависят от размера модели, длины контекста и параллелизма роллаутов.

Публичный пример списка задач предназначен для проверки интерфейса. Это не приватный обучающий пул из 187 задач, использованный в описываемом запуске. Предоставьте авторизованный источник обучающих данных, который не пересекается с публичным бенчмарком.

Установка

Разместите три репозитория рядом друг с другом:

Создание проверенного окружения

Опубликованный стек рассчитан на Linux, Python 3.12, Verl 0.9.0 и зафиксированный lock-файл пакетов:

Последние две команды должны подтвердить проверенный пропатченный чекаут Verl и отсутствие нарушенных зависимостей. Не запускайте автоматическую синхронизацию пакетов после этого: она может заменить пропатченную установку из исходников на стандартный wheel-пакет Verl.

Подготовка данных для обучения

Начните с предоставленных публичных примеров или добавьте собственный авторизованный датасет в формате ThinkingBox. Затем запустите скрипт подготовки из репозитория:

Скрипт агрегирует результаты зондирования политики, применяет офлайн-фильтры сложности относительно политики и исключения бенчмарка, а затем записывает отобранные файлы train.yaml и test.yaml. В описаны входные поля, контракт загрузчика и полная команда.

Настройка и проверка запуска

Следуйте , чтобы запустить Typesense и MCP-серверы, настроить симулированного пользователя и судью, задать переменные модели, списка задач, чекпоинта и топологии, а также подготовить кластер Ray. Храните учетные данные во внедряемых во время выполнения секретах, а не в закоммиченных файлах или истории оболочки.

Перед выделением ресурсов под задачу обучения воспользуйтесь командой тестового запуска (dry-run) из руководства:

Она должна завершиться с кодом 0, не запуская Ray и не выделяя GPU. Внимательно изучите сформированную команду python -m verl.trainer.main_ppo и все определенные переопределения параметров перед реальным запуском.

Обучение

Лаунчер настраивает обучение; он не занимается провижинингом хостов. В референсной топологии из трех нод экспортируйте одинаковое окружение на каждой ноде, смонтируйте CHECKPOINT_DIR по одному и тому же абсолютному пути, затем запустите Ray:

После того как ray status покажет все 24 GPU, выполните запуск один раз с головной (head) ноды:

Оценка чекпоинта через OpenEnv

В первом посте о ThinkingBox рассматриваются настройка Typesense, MCP Session Proxy и OpenEnv. Объедините обученный чекпоинт, следуя , затем запустите его хостинг через vLLM.

Из корня репозитория OpenEnv укажите путь к директории объединенной модели в MERGED_MODEL, а в THINKINGBOX_DATA — к зафиксированному чекауту бенчмарка. Для исторической оценки чекпоинта использовалась следующая конфигурация хостинга на восьми A100:

В отдельном терминале запустите прокси совместимости OpenEnv для шаблона чата Qwen из чекаута ThinkingBox Training. Он прослушивает порт 8014 и перенаправляет запросы на vLLM на порту 8001:

Оставьте его запущенным на время оценки. В другом терминале проверьте готовность:

Обновите запись агента в существующем thinkingbox.yaml; сохраните его конфигурацию MCP, симулированного пользователя и судьи:

Запустите OpenEnv, как описано в первом посте, указав OPENENV_TB_CONFIG на этот thinkingbox.yaml, а OPENENV_TB_DATASET — на $THINKINGBOX_DATA. Как только эндпоинт /ready вернет успешный ответ, запустите полный протокол: 507 задач × 20 попыток:

Полный профиль валидирует все 10 140 ожидаемых ключей «задача/повторение» перед агрегацией.

Дальнейшие шаги

Ценность этой работы заключается не в единичном чекпоинте Qwen3.8-27B. Главное — это цикл обучения и отбор обучающих данных, преобразующий исполняемые результаты в награды.

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

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

Более подробную информацию можно найти по следующим ссылкам:

• Среда: envs/thinkingbox_env
• OpenEnv: Документация среды ThinkingBox
• Фреймворк: microsoft/thinkingbox · tutorial
• Бенчмарк: microsoft/thinkingbox-data · v1.0 release
• Просмотр набора данных: microsoft/ThinkingBox-Bench
• Статья: или HF
• Обучение RL:
• Блог: Агент сказал, что все готово. База данных не согласилась.

Цитирование статьи

Код ThinkingBox распространяется по лицензии MIT; данные бенчмарка — CDLA-Permissive-2.0.

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

ThinkingBox, ThinkingBox-Bench и ThinkingBox-Training созданы командой Microsoft Copilot Studio в партнерстве с Toloka при участии сотрудников из Питтсбургского университета, Северо-Западного университета, Колумбийского университета и Калифорнийского университета в Ирвайне, которые проходили стажировку в Microsoft. Вопросы приветствуются в разделе комментариев ниже, на github или по электронной почте firstnamelastname@microsoft.com.

Небольшая часть задач также включает узкие бинарные требования к результатам, которые база данных не может четко зафиксировать; для таких проверок можно вызвать настроенного LLM-судью.

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