Превръщане на оценяването на бази данни в 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 (University of Pittsburgh) за съавторството и прегледа.

Създадохме ThinkingBox, за да откриваме агенти, които казват, че са приключили, когато това не е така.

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

След това осъзнахме какво сме създали. При повечето задачи изпълнима проверка може да върне директно 1 или 0 от крайното състояние на базата данни. Това не е просто оценяващ механизъм. Това може да бъде функция за награда.⁺

Затова създадохме обучителен пул от задачи във формат ThinkingBox извън бенчмарка и използвахме изпълнимите им резултати като награди. Предизвикателството беше да изберем кои задачи са подходящи за обучение на агента: повечето задачи вече са решени или са безнадеждни за конкретния модел, а и в двата случая не го учат на нищо.

Трудността зависи от политиката: дадена задача е трудна за текущия модел само докато моделът не я научи.

Наричаме това офлайн трудност, относителна към политиката. Оценихме вероятността за успех на всяка задача веднъж, използвайки базовата политика преди обучението, и поддържахме избрания обучителен пул фиксиран през цялото изпълнение.

Какво се случи след обучението

Използвахме офлайн трудност, относителна към политиката, за да създадем обучителния пул, след което дообучихме Qwen3.8-27B с GRPO за 50 стъпки. За припомняне, оценяваме всяка от 507-те задачи в бенчмарка 20 пъти. pass@1 измерва средния успех при всичките 10 140 опита. pass@20 измерва дела на задачите, решени поне веднъж. Наблюдаваното 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 не трябва да се разглежда самостоятелно. Наблюдаваното 20/20 показва кои задачи се изпълняват успешно при всеки опит — показател, който е по-близък до изискванията за производствена надеждност.

Изпълнимата присъда въз основа на крайното състояние на терминала беше и наградата при обучението. Преди да разгледаме подробно цикъла на обучение, ето какво се промени при бенчмарка, използван само за оценка.

Резултати: колоната за надеждност се промени

След обучението на Qwen3.8-27B оценихме избраната контролна точка от стъпка 50 върху бенчмарка от 507 задачи, върху който моделът не беше обучаван. 507-те задачи представляват тестов набор извън разпределението: техните области, бази данни и повечето MCP инструменти не са били срещани по време на RL обучението.

Таблица 2. pass@1 (%) в ThinkingBox-Bench по области за избрани модели от Таблица 2 от първата ни публикация и за нашия дообучен модел по отделни области и общо. Стойностите за наблюдаваното 20/20 са за целия бенчмарк от 507 задачи. Всеки модел е оценен върху всичките 507 задачи при 20 повторени изпитвания. Получерният шрифт обозначава лидера в колоната; подчертаването обозначава втория резултат.

Основният резултат е редът за наблюдаваното 20/20 в Таблица 1. Модел 27B, който първоначално изпълняваше 38 (7.5%) от задачите в ThinkingBox-Bench при всеки опит, сега изпълнява 107 (21.1%) при всеки опит — почти три пъти повече. За сравнение, наблюдаваното 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 и наблюдаваното 20/20 се увеличиха и в петте области. Pass@20 беше смесен: увеличи се при необанките и консултантските услуги, но спадна при търговията на дребно, пътуванията и автомобилното застраховане. Автомобилното застраховане имаше най-голямата загуба на широчина (−7.0 пункта), докато търговията на дребно имаше най-голямото увеличение на наблюдаваното 20/20 (+24.5 пункта).

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

Първата публикация изчисляваше цената на последователността с проста математика: разделяше изчислената цена на цялата кампания от 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 обозначава пътя, който не избрахме: повторно изследване на трудността по време на обучителното изпълнение.

Всяко разгръщане е пълен епизод, а не текстово допълване. То получава свеж бекенд, изолирана 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. Системните грешки се обработваха отделно: изтичането на времето на бекенда не е неправилен резултат на агента, затова засегнатите групи се попълваха отново, вместо да се оценяват като неуспешни.

Това обяснява как са били обучавани запазените задачи. Остава въпросът кои задачи са попаднали в обучителния пул.

Офлайн трудност, относителна към политиката

Преди да разгледаме задълбочено избора на обучителни задачи, едно уточнение:

Нито една задача от 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 + ½)

Фигура 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, изследвания с базовия модел, класификация на трудността, група от разгръщания, оценяване на крайното състояние и обновяване на 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 оценяващ модел отговаря на двоичен въпрос от рубриката, използван от изпълнимия тест.

Стартирайте обучителния стек

Публикуваме избора на данни, разгръщането, наградата и интеграцията с 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 x 20.

Преди да започнете

Тествано е на Linux и WSL с Python 3.12 и uv. Необходими са ви NVIDIA GPU с поддържан CUDA/NCCL стек, локална контролна точка Qwen3.8-27B и OpenAI-съвместими крайни точки за симулирания потребител и оценяващия модел. Валидираната референтна конфигурация използва 3 възела × 8 H100 GPU; по-малките персонализирани конфигурации зависят от размера на модела, дължината на контекста и паралелността на разгръщанията.

Публичният списък с примерни задачи упражнява интерфейса. Това не е частният обучителен пул от 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 и липса на повредени зависимости. Не изпълнявайте друго автоматично синхронизиране на пакети след това: то може да замени пачнатата изходна инсталация с оригиналното колело на 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

Тя трябва да приключи с код нула, без да стартира 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 Session Proxy и настройката на 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
• Рамка:

  Преведено автоматично от английски. Оригиналната статия е на връзката по-долу.