Преобразование оценки баз данных в награды RL: постобучение агентов с ThinkingBox

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

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

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

Это совместная публикация Microsoft и Hugging Face. Особая благодарность Mirco Milletari и Xiang Jiang из Microsoft, Sergio Paniego из Hugging Face, а также нашему бывшему стажёру Zhuochun Li (Университет Питтсбурга) за участие в написании и проверке материала.

Мы создали 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 из них.

Содержание

1. Что показал тест за шестьдесят секунд
2. Результаты: показатель надёжности вырос
3. Где проявился прирост
4. Какова цена надёжности
5. Цикл обучения
6. Сложность, относительная к политике, в офлайн-режиме
7. За что начисляется награда
8. Запуск стека обучения
9. Что дальше

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

Что показал тест за шестьдесят секунд

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. pass@1 (%) ThinkingBox-Bench по предметным областям для выбранных моделей из таблицы 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. Ни одна метрика по отдельности не даёт полной картины.

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

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

Где проявился прирост

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

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

Какова цена надёжности

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

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

Применим ту же формулу стоимости к измеренному использованию токенов дообученной контрольной точкой:

Таблица 3. Оценочная стоимость оценки и надёжность базовой и дообученной с RL Qwen3.8-27B. Стоимость успешной попытки равна общей оценочной стоимости кампании (507 × 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 задачах с использованием token-mean GRPO. На каждом обновлении генерировались 18 групп по 8 rollout, то есть 144 эпизода, на 24 H100. Обучение выполнялось синхронно с выгрузкой параметров и оптимизатора; AdamW использовал скорость обучения 1e-6 и нулевое затухание весов. Обучение продолжалось 50 шагов.

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

Так обучались отобранные задачи. Остаётся вопрос: какие задачи вошли в обучающую выборку?

Сложность, относительная к политике, в офлайн-режиме

Прежде чем подробно рассмотреть отбор обучающих задач, сделаем оговорку:

Ни одна задача ThinkingBox-Bench не включалась в обучающую выборку для RL. Тестовый набор был зарезервирован для оценки.

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

Важность отбора сводится к одному арифметическому факту о GRPO. Если все восемь rollout завершаются неудачей, вектор наград имеет вид [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 может обучаться. Для агента с состоянием это различие обходится дорого: каждый rollout создаёт изолированный бэкенд, запускает настоящий сеанс инструментов и вызывает отдельную модель, играющую роль пользователя.

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

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

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

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

Каждая задача-кандидат запускается 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]: исключить

Дополнительные сведения приведены в приложении C.4 к нашей статье о ThinkingBox.

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

Рисунок 7. Одна задача через все шесть этапов: проверка решаемости с помощью GPT-5.4, проверки базовой модели, классификация сложности, группа rollout, оценка конечного состояния и обновление GRPO.

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

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

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

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

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

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

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

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

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

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

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

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

Перед началом

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

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

Установка

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

mkdir -p ~/thinkingbox-workspace
cd ~/thinkingbox-workspace

git clone https://github.com/microsoft/thinkingbox.git
git clone https://github.com/microsoft/thinkingbox-data.git
git clone --branch main https://github.com/microsoft/thinkingbox-training

git -C thinkingbox checkout 892964e7226044e5463ad188da119df838f4bec1
git -C thinkingbox-data checkout thinkingbox-bench-v1.0

Создание проверенной среды

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

cd ~/thinkingbox-workspace/thinkingbox-training

uv venv --python 3.12
source .venv/bin/activate

uv sync --frozen --extra fast --extra tracking --extra eval-proxy
uv pip install -e ../thinkingbox
uv pip install --config-settings editable-mode=compat \
  -e ../thinkingbox-data/servers/thinkingbox_tools
uv pip install --config-settings editable-mode=compat \
  -e ../thinkingbox-data/servers/tb_business_ops_servers_202606

python scripts/prepare_verl.py --dest .deps/verl --install
python scripts/verify_verl_install.py
uv pip check

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

Подготовка обучающих данных

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

cd ~/thinkingbox-workspace/thinkingbox-training
source .venv/bin/activate
python data/prepare_data.py --help

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

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

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

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

DRY_RUN=true ./scripts/run_train.sh \
  trainer.total_training_steps=50 \
  trainer.save_freq=5

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

Обучение

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

ROLE=head NODE_IP="$HEAD_IP" GPUS_PER_NODE=8 \
  ./scripts/start_ray.sh


ROLE=worker NODE_IP="$WORKER_IP" \
  HEAD_ADDRESS="$HEAD_IP:6379" GPUS_PER_NODE=8 \
  ./scripts/start_ray.sh

После того как ray status сообщит обо всех 24 GPU, один раз запустите процесс с головного узла:

export RAY_ADDRESS=auto
export GPUS=0,1,2,3,4,5,6,7

./scripts/run_train.sh \
  trainer.project_name=thinkingbox-training \
  trainer.experiment_name=q38-full-rlft \
  trainer.total_training_steps=50 \
  trainer.save_freq=5

Оценка контрольной точки через OpenEnv

В первой публикации ThinkingBox описаны Typesense, прокси сессий MCP и настройка OpenEnv. Объедините обученную контрольную точку согласно docs/evaluation.md, а затем обслуживайте её с помощью vLLM.

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

vllm serve "$MERGED_MODEL" \
  --served-model-name q38-rlft \
  --host 127.0.0.1 \
  --port 8001 \
  --tensor-parallel-size 8 \
  --dtype bfloat16 \
  --max-model-len 262144 \
  --gpu-memory-utilization 0.85 \
  --max-num-seqs 16 \
  --max-num-batched-tokens 8192 \
  --language-model-only \
  --enable-chunked-prefill \
  --enable-prefix-caching \
  --reasoning-parser qwen3 \
  --enable-auto-tool-choice \
  --tool-call-parser qwen3_xml

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

cd ~/thinkingbox-workspace/thinkingbox-training
source .venv/bin/activate
bash scripts/launch_sysmerge.sh

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

curl --fail http://127.0.0.1:8014/readyz

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

orchestrator:
  agent_model:
    type: aoai
    endpoint_url: http://127.0.0.1:8014/v1/chat/completions
    deployment: q38-rlft
    credential:
      type: api-key
      api_key: <your_api_key>
    is_reasoning: true
    temperature: 1.0
    top_k: 20
    top_p: 0.95
    max_completion_tokens: 8192
    timeout: 1800

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

uv run --project envs/thinkingbox_env --frozen \
  thinkingbox-eval \
  --config "$PWD/thinkingbox.yaml" \
  --base-url http://127.0.0.1:8000 \
  --dataset "$THINKINGBOX_DATA" \
  --output q38-rlft-full.jsonl \
  --errors-output q38-rlft-full-errors.jsonl \
  --repeat 20 \
  --coverage-profile full \
  --aggregate-output q38-rlft-full-aggregate.json \
  --message-timeout 1800

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

Что дальше

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

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

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

Дополнительные сведения доступны по следующим ссылкам:

• Окружение: envs/thinkingbox_env
• OpenEnv: документация окружения ThinkingBox
• Фреймворк: microsoft/thinkingbox · руководство
• Тестовый набор: microsoft/thinkingbox-data ·

  Переведено автоматически с английского. Оригинал статьи — по ссылке ниже.