Microsoft и Hugging Face представиха на 22 октомври ThinkingBox-Training: използване на проверимото крайно състояние на база данни като reward за обучение на агенти. За Qwen3.8-27B авторите отчитат след 50 GRPO стъпки ръст на средния успех от 51,70% на 60,78%. Задачите, успешни във всичките 20 опита, се увеличават от 38 на 107, но делът с поне един успех спада от 89,35% на 87,97%.

Това е полезен компромис за разглеждане, а не еднопосочно подобрение по всички показатели. Резултатите са на екипа и не са повторени от SIExpo. Новината е за training интеграцията и анализа от 22 октомври; основният benchmark и научната публикация са по-стари.

Крайният запис има собствена тежест

Научната работа описва sandbox с изолирани MCP сесии, следи на изпълнението и оценка на крайното backend състояние. Важната идея е да се приемат различни валидни пътища до резултата, но да се отхвърлят липсващи, неправилни или допълнителни ефекти. Това не свежда добрата работа до един убедителен отговор в чата.

Публичният ThinkingBox-Bench dataset има 507 задачи, английски език и лиценз CDLA-Permissive-2.0. Авторите уточняват, че задачите са синтетични реконструкции на бизнес процеси, а не записи на реални клиенти. Затова benchmark успехът не бива да се представя като доказано изпълнение в банка, магазин или хотел на истински потребител.

Нашият извод е, че крайният отговор и крайното състояние трябва да се оценяват отделно. Например в собствена тестова система може да има коректно написано обяснение, но да е пропуснато нужно действие. Възможна е и обратната ситуация: състоянието е променено, но потребителят не получава необходимото обяснение. Това са различни критерии за приемане, които трябва да са зададени предварително.

Какво е публикувано за обучение

Training хранилището описва двоична оценка от изолирани задачи. Повечето проверки са детерминистични; малка част използват тесен въпрос към LLM judge. Симулираният потребител не оценява агента. Референтната конфигурация е с три възела по осем H100, Linux и Python 3.12. Публичните примери проверяват интеграцията, но не са частният training pool за отчетения резултат. Следователно наличният код не означава незабавна пълна репликация на експеримента.

Това ограничение е съществено за планиране на ресурс. Малък пример, който се зарежда успешно, не показва нито цена на обучение, нито постигнато качество. Бихме разделили първата техническа проверка от инвестиционното решение за голям run. Наличието на скрипт за стартиране не е само по себе си аргумент да се резервира GPU клъстер.

Как да се използва идеята в собствен пилот

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

След това бихме повторили всяка задача и бихме пазили резултатите по опит. Един общ процент скрива разликата между задача, която винаги се изпълнява, и такава, която успява случайно. Бихме разгледали и отказите: правилното запазване на състоянието при липса на разрешение може да е очакваният резултат, а не провал на агента.

Важно е примерите за обучение и окончателната оценка да останат отделни. Нашият пилот би имал предварително фиксиран тестов набор и преглед на проверяващите условия. Ако самата проверка е непълна, агентът може да оптимизира грешната цел. ThinkingBox-Training дава конкретен начин този въпрос да бъде изследван; не премахва нуждата бизнес правилата да бъдат описани точно.

Корица: концептуална AI илюстрация на проверка на крайно състояние; не съдържа реални клиентски данни.

Проверено по посочените източници: 2026-10-23T06:29:40.415508+00:00.