Un agent care spune că a terminat nu înseamnă un agent care a terminat. Diferența dintre „am executat" și „starea bazei de date e cea corectă" este exact ce au construit Microsoft și Hugging Face în ThinkingBox, iar noul pas publicat pe 22 octombrie 2026 duce lucrurile dintr-o zonă de evaluare într-una de antrenare. Pe scurt: aceleași verificări executabile ale stării finale a bazei de date au fost folosite ca recompensă pentru post-training, iar rezultatul măsurat pe Qwen3.8-27B este o creștere a succesului repetabil, nu doar a mediei de reușite izolate.

Materialul sursă este blogul Hugging Face semnat împreună cu Microsoft (ThinkingBox-Training), continuarea unui prim articol care arăta cât de mult ascunde acuratețea de headline. Aici nu discutăm despre o lansare de produs comercial, ci despre un stack de antrenare publicat pe GitHub, cu rezultate pe un benchmark intern. E o distincție importantă pentru oricine vrea să o transforme în promisiuni de marketing.

Ce s-a schimbat concret față de primul articol

Primul articol ThinkingBox arăta o problemă pe care o vedem constant în discuțiile despre agenți: un model poate închide un tichet ca rezolvat în nouă apeluri de unelte care arată competente, iar în baza de date rămâne un rând greșit. Benchmark-ul are 507 sarcini, fiecare cu un backend real, un set de unelte MCP și un utilizator LLM simulat cu context privat. La final se rulează verificări executabile pe starea terminală a bazei de date, nu pe succesiunea de apeluri. Asta încurajează modelul să găsească soluții proprii, nu să reproducă traseul uman.

Constatarea care a declanșat noul articol este simplă: pentru majoritatea sarcinilor, o verificare executabilă returnează direct 1 sau 0 din starea finală a bazei de date. Adică nu e doar un grader, e o funcție de recompensă gata de folosit. Echipa a construit un bazin de antrenare din sarcini în format ThinkingBox, în afara benchmark-ului, și a folosit rezultatele executabile ca recompense.

Rezultatul principal, măsurat pe Qwen3.8-27B: succesul mediu (pass@1) a urcat de la 51,70% la 60,78%, iar sarcinile rezolvate corect în toate cele 20 de încercări au crescut de la 38 la 107, după 50 de pași de GRPO. Aproape triplu la capitolul „încredere", cu un minus mic la acoperire: pass@20 a scăzut de la 453 la 446 de sarcini.

De ce metrica „20 din 20" contează mai mult decât pass@1

Aici e miezul analizei, și e locul unde majoritatea discuțiilor despre agenți ratează esențialul. În primul articol, Kimi-K3 rezolva 93,89% din sarcini cel puțin o dată, dar doar 13,41% din sarcini în toate cele 20 de încercări. Claude Opus 5.5 avea acoperire mai mică, dar consistență mult mai mare. Iar Claude Opus 5.5 față de Claude Opus 5 a câștigat 0,66 puncte procentuale la pass@1 fără să câștige absolut nicio sarcină în plus la 20/20.

Tradus pentru cine lucrează cu sisteme care ating date de producție: pass@1 e metrica de demo, observed 20/20 e metrica de operare. Un agent care reușește 9 din 10 ori pare bun până când acea a zecea încercare e cea care scrie în baza de date a clientului. Consecvența nu e un detaliu de raportare, e diferența dintre un sistem pe care îl lași nesupravegheat și unul pe care îl verifici manual la fiecare rulare.

Merită subliniat și ce spune echipa despre mecanism: pattern-ul e consistent cu o „ascuțire" a distribuției. Probabilitatea s-a mutat spre traiectorii care funcționează repetat, iar unele căi cu probabilitate mică au dispărut. Modelul nu a devenit mai larg, a devenit mai repetabil. Nu e un detaliu neutru: înseamnă că antrenarea pe recompense executabile te poate face mai puțin creativ pe margini, în timp ce te face mai de încredere pe traseul principal.

Cum se selectează sarcinile de antrenare și de ce e cea mai grea parte

Detaliul tehnic care mi se pare cel mai subestimat în tot articolul: problema nu a fost „ce model sau ce optimizer", ci „ce sarcini intră în bazinul fix de antrenare". Motivul e o aritmetică simplă a GRPO. Dacă toate cele opt rollout-uri eșuează, vectorul de recompensă e zero și nu există avantaj de învățat. Dacă toate reușesc, e unu și la fel nu înveți nimic. Doar un grup mixt, cu reușite și eșecuri, oferă contrastul din care GRPO extrage semnal.

Iar fiecare rollout e scump: backend izolat, sesiune reală de unelte, un model separat care joacă rolul utilizatorului. De aici ideea de dificultate relativă la politică, offline. Echipa a estimat o singură dată probabilitatea de succes a fiecărei sarcini cu modelul de bază, înainte de antrenare, și a ținut bazinul fix pe toată durata rulării. Nu au re-probat dificultatea în timpul antrenării, deși figura din articol marchează explicit calea neexplorată.

Două precauții pe care le-au declarat deschis și pe care orice cititor onest ar trebui să le rețină: nicio sarcină din ThinkingBox-Bench nu a intrat în bazinul de antrenare, iar benchmark-ul rămâne out-of-distribution. Totuși, cele două seturi împărtășesc framework-ul, mașinăria de utilizator simulat, grading-ul executabil și câteva unelte comune. Asta limitează cât de departe poți întinde concluzia de transfer. E o onestitate metodologică rară și exact genul de detaliu care lipsește din anunțurile de tip „modelul nostru e mai bun".

Selecția e un filtru, nu o predicție

Un detaliu operațional care mi se pare important: echipa tratează erorile de sistem separat. Un timeout de backend nu e un rezultat incorect al agentului, așa că grupurile afectate au fost reumplute, nu punctate ca eșecuri. Pare minor, dar e diferența dintre un semnal de antrenare curat și unul care învață modelul să evite infrastructura lentă în loc să rezolve sarcina.

Costul apare și el în calcul. Campania completă de 507 sarcini ori 20 de rulări a scăzut de la 925,80 dolari la 855,58 dolari. Costul pe încercare reușită a scăzut de la 0,177 la 0,139 dolari, iar costul pe sarcină de încredere, adică pe sarcină trecută în toate cele 20 de încercări, a scăzut de la 24,36 la 8,00 dolari. Echipa precizează clar că sunt indici comparativi de serving, nu facturi, că includ doar inferența și exclud costul rulării de antrenare și al sondajului de politică. Nu transform asta în „ieftin" sau „scump": sunt cifre relative, valabile în setup-ul lor.

Ce înseamnă pentru tine, ca antreprenor sau marketer în România

Dacă ai un magazin online sau un business de servicii și te uiți la agenți AI care ar trebui să execute operațiuni, lecția nu e „cumpără Qwen3.8-27B". Lecția e despre ce măsori înainte să lași un agent să atingă ceva real. Întrebarea corectă nu e „cât de des reușește", ci „câte operațiuni reușește de fiecare dată, în condiții identice". Pentru un flux care modifică stocuri, comenzi sau date de client, a doua cifră e cea care contează.

Aplicat concret, înainte de a automatiza ceva, merită să stabilești starea finală corectă a datelor, nu doar pașii pe care îi vrei. Dacă un agent trebuie să proceseze o retur, ce trebuie să arate comanda la final? Ce rânduri trebuie să existe, ce câmpuri trebuie să rămână neschimbate? Dacă poți scrie acea verificare ca un test binar, ai și baza pentru un sistem de încredere, și un mod de a alege între doi agenți care par egali la demo.

Pe partea de conținut și date, logica se leagă de ce se întâmplă cu infrastructura care devine citabilă de agenți, subiect pe care l-am analizat în Shopify UCP location search. Cu cât mai mulți agenți citesc și scriu date, cu atât contează ca starea finală să fie corectă, nu doar ca acțiunea să pară reușită. La fel, când construiești workflow-uri AI în producție, principiul din hallucination detection e același: nu te baza pe ce spune modelul că a făcut, verifică rezultatul.

Limite, incertitudini și ce ar merita testat

Câteva lucruri pe care articolul nu le spune și pe care nu le inventez. Nu știm cum se transferă rezultatul pe alte modele sau pe domenii din afara celor cinci din benchmark. Nu știm cum arată performanța pe sarcini care nu pot fi reduse la o verificare binară a stării finale, iar echipa recunoaște că o minoritate de cerințe de rubrică apelează la un judge. Nu știm ce se întâmplă după 50 de pași, dacă există un platou sau o continuare a câștigului.

Ce ar merita verificat, ca ipoteză de lucru, nu ca fapt: dacă înlocuirea grupurilor cu varianță zero, în stil DAPO, plus un bazin reîmprospătat periodic, ar recupera din pierderea de acoperire. Dacă observația de „ascuțire" se menține pe rulări mai lungi. Și dacă un sistem cu verificări executabile proprii, adaptat pe domeniul tău, produce aceeași creștere de consistență. Sunt întrebări deschise, nu concluzii.

FAQ

ThinkingBox e un produs comercial? Nu. ThinkingBox-Training e disponibil pe GitHub, ca stack de antrenare, iar benchmark-ul are 507 sarcini. Articolul descrie rezultate de cercetare măsurate pe Qwen3.8-27B, nu o ofertă de piață cu preț și disponibilitate comercială.

De ce scade pass@20 când crește observed 20/20? Pentru că antrenarea mută probabilitatea spre traiectorii care funcționează repetat, iar unele căi cu probabilitate mică dispar. Modelul devine mai repetabil pe traseul principal, nu mai larg. E un compromis declarat, nu un efect ascuns.

Pot folosi asta pentru agenți care scriu în baza mea de date? Poți folosi principiul: definește starea finală corectă și verifică executabil rezultatul, nu doar apelurile. Stack-ul concret cere resurse și competențe de ML, deci pentru majoritatea echipelor de marketing rămâne o direcție de evaluare, nu o instalare de weekend.

Arc: AI ajută, omul decide, ALLSoft execută

Un model poate analiza, planifica și propune, iar ThinkingBox arată exact cât de valoros e să ai un semnal executabil în spate. Dar decizia despre ce înseamnă „corect" pentru businessul tău, ce date pot fi atinse de un agent și unde pui verificarea umană rămâne la media buyer și la operatorul senior. AI-ul nu îți spune dacă un retur procesat corect e și unul profitabil pentru tine.

Pasul concret îl face ALLSoft Agency: pornim de la ce măsori azi, separăm constatările măsurate de ipoteze și construim verificările înainte de a lăsa un sistem să atingă date reale. Fără promisiuni de cifre pe care nu le-am văzut în contul tău.