Un agent AI poate raporta succes, poate închide un tichet și poate suna convingător, iar în baza de date statusul rămâne greșit. ThinkingBox, benchmark lansat de Microsoft și Hugging Face, măsoară exact asta: starea finală și efectele secundare, nu textul generat. Concluzia: un singur succes nu înseamnă fiabilitate.

Cine a lansat ThinkingBox și ce măsoară de fapt

Microsoft și Hugging Face au publicat un benchmark comun numit ThinkingBox, disponibil prin Hugging Face, cu un sandbox de agenți și un set de evaluare pe 507 fluxuri de lucru de business cu stare persistentă. Fiecare task rulează de 20 de ori, de fiecare dată pornind de la un backend curat, iar evaluarea nu se uită la frumusețea răspunsului. Se uită la ce a rămas scris în baza de date după ce agentul termină.

Exemplul care dă tonul articolului lor: un client cu un aparat de bucătărie de 745 de dolari blocat în „excepție" la un centru de distribuție din Nashville, cu cincisprezece zile peste termenul estimat. Agentul face nouă apeluri de tool-uri, verifică comanda, tracking-ul, profilul clientului, caută politica de rambursare, confirmă că nu există tichet, deschide unul, documentează cronologia și închide tichetul ca rezolvat. Două lucruri sunt greșite: excepția de la curier rămâne deschisă, deci starea finală cerută era „on hold", nu „solved", iar clientul nu a primit un răspuns real la ce a întrebat. Un evaluator care se uită doar la apelurile de tool-uri ar vedea nouă apeluri corecte. Baza de date nu e de acord.

Sursa acestor date este articolul Microsoft și Hugging Face de pe blogul Hugging Face. Merită citit integral dacă lucrezi cu agenți care ating sisteme reale.

Distincția care contează: apel de tool versus rezultat

Diferența dintre „am apelat un tool" și „am produs rezultatul cerut" este miezul întregii discuții. Într-o analiză pe 121.680 de încercări valide, acoperind 12 modele, 79.853 de încercări au picat verificările executabile. Dintre ele, 67,24% s-au terminat curat, au invocat un tool care schimbă stare și nu au raportat nicio eroare finală. Cu alte cuvinte: două treimi din eșecuri arată ca succese dacă te uiți la log-uri superficiale.

Verificările pe starea finală au găsit valori greșite de câmp în 77,61% din cazuri, efecte secundare nedorite în 43,30% și efecte obligatorii lipsă în 25,36%. Procentele se suprapun, pentru că un singur traseu poate avea mai multe probleme simultan.

Traducerea în limbaj de operator: o traiectorie este o afirmație, starea bazei de date este proba. Dacă agentul tău scrie într-un CRM, într-un sistem de comenzi sau într-un sistem de tichete, singurul lucru care contează la final este ce valoare a rămas în câmp.

Un succes nu este fiabilitate: de ce 20 de repetări schimbă tot

Aici apare cea mai utilă parte a benchmark-ului pentru cineva care chiar vrea să implementeze. Fiecare task rulează de 20 de ori, din backend curat. Se raportează trei lucruri diferite: pass@1 (cât de des reușește în medie), pass@20 (dacă reușește măcar o dată în 20 de încercări) și „observed 20/20", adică numărul brut de task-uri care trec de toate cele 20 de ori.

Numărul care contează în producție este al treilea. Pass@1 este ce publică majoritatea clasamentelor, iar pe acea coloană lucrurile arată ca o ierarhie obișnuită de capabilitate. Dar când te uiți la cât din scorul de o singură încercare supraviețuiește după 20 de repetări, doar trei modele păstrează mare parte din el. Restul se prăbușesc.

Kimi-K3 este cel mai bun exemplu de capcană: are cea mai largă acoperire, rezolvă 476 din 507 task-uri măcar o dată, dar doar 68 de task-uri, adică 13,41%, trec de toate cele 20 de încercări. Claude Opus 5 face invers: rezolvă mai puține task-uri măcar o dată, dar termină 47,53% din benchmark corect la fiecare încercare.

Detaliul cel mai usturător pentru oricine crede că „modelul mai nou rezolvă": Claude Opus 5.5 are un scor mediu mai bun decât Claude Opus 5, 67,16% față de 66,50%, și rezolvă mai multe task-uri măcar o dată. Dar trece exact același număr de task-uri la toate cele 20 de încercări: 241. Jumătate de punct de acuratețe în titlu nu a cumpărat nicio fiabilitate suplimentară.

Ce costă consistența, nu doar capabilitatea

Benchmark-ul calculează și costul, iar aici apare o distincție pe care puține echipe o fac. Costul per succes (cost per successful task attempt) împarte costul unei singure runde de 507 încercări la numărul de reușite. Costul per task de încredere (cost per dependable task) împarte costul întregii campanii de 20 de runde la numărul de task-uri trecute 20 din 20.

Rezultatul: cel mai ieftin mod de a obține un răspuns corect nu este cel mai ieftin mod de a obține unul de încredere. GPT-5.6 Sol are cel mai mic cost per succes individual, dar costă mai mult per task de încredere decât GPT-5.4. Claude Opus 5.5 domină clar Claude Opus 5: același număr de task-uri dependabile (241), dar la 7,80 dolari față de 13,30 dolari per task de încredere.

Semnătura dominantă a eșecurilor este și ea practică: aproximativ patru din cinci eșecuri sunt de manipulare a tool-urilor, nu de raționament. Adică agenții ajung destul de departe să înceapă fluxul, apoi nu se recuperează după erori de tool, precondiții eșuate sau căutări care întorc gol. Este o problemă de retry și de recuperare din eroare înainte de a fi o problemă de model. Dificultatea variază și pe domenii: retail mediu 59,52% pass@1, asigurări auto 33,83%.

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

Dacă vinzi online în România și te uiți la automatizări AI pentru suport clienți, procesare de comenzi sau retururi, lecția nu este „AI-ul e slab". Lecția este că indicatorul pe care îl urmărești de obicei este greșit.

Primul lucru de schimbat: nu accepta rezumatul agentului ca dovadă. Verifică starea terminală înainte de a confirma o acțiune, nu textul pe care agentul îl scrie despre ea. Dacă un agent închide un tichet, citește statusul din sistemul de tichete, nu mesajul de confirmare.

Al doilea: clasifică erorile de tool și de sistem, astfel încât retry-urile să lovească doar cele recuperabile. Un lookup care întoarce gol nu este același lucru cu o eroare de autentificare, iar un retry orb pe ambele consumă bani și uneori creează efecte secundare.

Al treilea: redu suprafața de tool-uri la ce are nevoie fluxul. Fiecare tool în plus este o cale în plus pe care agentul poate lua o decizie greșită, iar benchmark-ul arată clar că eșecurile vin predominant din manipularea tool-urilor.

Al patrulea: cere aprobare umană pentru schimbările pe care nu le poți anula ieftin. Rambursări, anulări de comenzi, modificări de preț, ștergeri de cont. Astea nu se automatizează complet doar pentru că demo-ul arată bine.

Un ultim detaliu de onestitate: autorii spun explicit că nu au măsurat câștigul acestor practici pe acest benchmark. Sunt recomandări rezonabile, nu rezultate dovedite. Tratează-le ca ipoteze de testat în fluxurile tale, nu ca garanții. Dacă vrei să vezi cum arată presiunea de consistență pe alte straturi de infrastructură, un exemplu util este analiza despre cât durează crawl, indexare și recuperare după update, unde „a funcționat o dată" nu spune nimic despre comportamentul repetat.

Cum verifici singur, fără să te bazezi pe promisiuni

Benchmark-ul este deschis prin OpenEnv, iar exemplul din articol este adaptat dintr-un task executabil, cu verificarea care pică redusă la un singur câmp: statusul tichetului este „solved" acolo unde starea finală cerută este „hold". Asta înseamnă că poți reproduce logica pe fluxurile tale.

Pași propuși, ca recomandare a noastră, nu ca rezultat măsurat: definește starea de start și starea finală cerută pentru fiecare flux; scrie verificări executabile care citesc valoarea reală din backend, nu mesajul agentului; rulează fiecare scenariu de mai multe ori, de preferat 20, din stări curate; numără câte scenarii trec de toate repetările, nu media; și separă erorile de tool de erorile de raționament înainte de a schimba modelul.

O precizare de metodă, ca să nu sari la concluzii: o verificare incompletă nu dovedește absența unei funcții sau a unui efect. Dacă testul tău nu acoperă un anumit efect secundar, nu poți afirma că agentul nu îl produce. Și nu traduce un audit automat în pierderi de bani, efecte pe CPA sau pe vânzări, ori încălcări legale. Pentru asta ai nevoie de probe directe, nu de o presupunere derivată dintr-un scor.

Dacă lucrezi cu agenți care ating date reale, consistența este un criteriu de arhitectură, nu un detaliu de model. Iar dacă vrei să vezi cum se leagă subiectul de partea de conținut și vizibilitate, profilurile sociale în Search Console arată aceeași logică: ce contează este ce ajunge efectiv în sistem, nu ce crezi că ai trimis.

FAQ

Ce este ThinkingBox, pe scurt? Un benchmark lansat de Microsoft și Hugging Face care evaluează agenți AI pe starea finală a backend-ului și pe efectele secundare lăsate, nu pe textul generat. Fiecare task rulează de 20 de ori din stări curate, pe 507 fluxuri de business.

De ce pass@1 nu este suficient pentru decizii de producție? Pentru că măsoară cât de des reușește un agent în medie, nu dacă reușește de fiecare dată. Modele cu acoperire largă pot trece rar de toate cele 20 de încercări, iar diferența dintre „poate o dată" și „face mereu" este exact ce contează când un flux atinge înregistrări reale.

Unde eșuează de obicei agenții? Aproximativ patru din cinci eșecuri sunt legate de manipularea tool-urilor, nu de raționament: recuperare după erori de tool, precondiții eșuate sau căutări care întorc gol. Este o problemă de retry și de design al fluxului înainte de a fi o problemă de alegere a modelului.

Concluzia ALLSoft Agency

AI-ul ajută real la analiză și planning: poți mappa fluxuri, poți genera scenarii de test, poți structura verificări pe starea finală și poți prioritiza unde consistența contează mai mult. Dar decizia și execuția rămân umane. Media buyer-ul și operatorul decid ce se automatizează, ce rămâne cu aprobare umană și ce criteriu de fiabilitate se acceptă înainte de a atinge date reale.

Pasul concret îl face ALLSoft Agency: trecem de la discuția despre capabilități la verificarea efectelor, pe fluxurile care contează pentru businessul tău. Fără hype, fără cifre inventate, doar ce se poate proba în sistem.