Перетворення оцінювання баз даних на винагороди 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 графічних процесорів 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 і зафіксованого блокування пакетів:

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. Зберігайте облікові дані через ін’єкцію секретів під час виконання, а не у файлах, що фіксуються, чи історії оболонки.

Перш ніж виділяти навчальне завдання, скористайтеся командою пробного запуску з інструкції:

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

Вона має завершитися з нульовим кодом, не запускаючи Ray і не виділяючи графічні процесори. Перед запуском прочитайте виведену команду 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 графічні процесори, запустіть один раз із головного вузла:

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 · реліз v1.0
• Переглядач набору даних: microsoft/ThinkingBox-Bench
• Стаття: arXiv:2608.19741 або HF
• Навчання RL:

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