ThinkingBox preveruje AI agentov podľa výsledku v databáze, nie podľa presvedčivej odpovede

Microsoft spolu s výskumnými partnermi sprístupnil benchmark ThinkingBox-Bench, ktorý mení spôsob hodnotenia AI agentov pracujúcich s podnikovými systémami. Namiesto otázky, či agent vytvoril presvedčivú odpoveď alebo technicky platné volanie nástroja, kontroluje, čo po jeho práci skutočne zostalo v databáze. Verejná súprava obsahuje 507 syntetických, stavových pracovných postupov z maloobchodu, cestovania, automobilového poistenia, neobankingu a podpory pre IT či ľudské zdroje. Každá úloha sa začína definovaným stavom, agent dostane prístup k nástrojom kompatibilným s MCP a výsledok posudzujú vykonateľné kontroly nad konečným stavom systému.

Správne volanie nástroja ešte nie je správny výsledok

Základná téza ThinkingBoxu je jednoduchá: trajektória agenta je iba tvrdenie, kým stav databázy predstavuje dôkaz. Agent môže vyhľadať objednávku, prečítať pravidlá, založiť servisný prípad a bez viditeľnej technickej chyby oznámiť používateľovi, že úlohu dokončil. Napriek tomu mohol nastaviť nesprávny stav prípadu, zmeniť iný záznam, vynechať povinnú operáciu alebo vytvoriť nežiaduci vedľajší účinok. Bežná kontrola textovej odpovede ani záznam úspešných volaní API takúto chybu nemusí odhaliť.

Benchmark preto nepredpisuje jedinú správnu postupnosť krokov. Každý pokus prebieha v izolovanej relácii s čerstvo inicializovaným stavom a rozhodujúci je požadovaný výsledok. Deterministické kontroly akceptujú rôzne platné trajektórie, pokiaľ vytvoria správne zmeny bez chýbajúcich alebo nadbytočných zásahov. Z 507 úloh sa 477 hodnotí iba podľa stavu a pri 30 sa navyše kontrolujú vlastnosti finálnej odpovede, napríklad povinné upozornenie používateľa. Zlaté odpovede, interné asercie a prihlasovacie údaje pritom zostávajú mimo dosahu testovaného modelu.

Výskumníci spúšťali každú úlohu dvadsaťkrát z rovnakého počiatočného stavu. Tým oddeľujú tri rozdielne otázky: ako často agent uspeje pri jednom pokuse, či dokáže úlohu vyriešiť aspoň raz a či ju zvládne vo všetkých zaznamenaných opakovaniach. Posledná metrika je pre produkciu najprísnejšia. Jednorazový úspech totiž nehovorí, či systém rovnakú refundáciu, rezerváciu alebo zmenu zákazníckeho záznamu vykoná správne aj zajtra a pri ďalších používateľoch.

Výsledky odhaľujú prudký prepad konzistentnosti

V zverejnenom porovnaní dosiahol najvyššie priemerné skóre jedného pokusu Claude Opus 5.5 s hodnotou 67,16 %. Nasledoval Claude Opus 5 so 66,50 % a GPT-5.4 so 65,36 %. Spomedzi modelov s otvorenými váhami bol najvyššie Kimi-K3 s 57,37 %. Výsledky nemožno bez ďalšieho preniesť na všetky agentické úlohy, ukazujú však, že ani popredné modely v kontrolovanom prostredí spoľahlivo nedokončili tretinu až takmer polovicu podnikových postupov.

Ešte výraznejší rozdiel vznikol pri opakovaní. Kimi-K3 vyriešil aspoň raz 476 z 507 úloh, no všetkých dvadsať pokusov zvládol iba pri 68 úlohách. Claude Opus 5 mal menšie pokrytie úloh vyriešených aspoň raz, ale konzistentne uspel pri 241 úlohách. Novší Claude Opus 5.5 zvýšil priemernú úspešnosť, no rovnakú hranicu dvadsiatich úspechov z dvadsiatich dosiahol tiež pri 241 úlohách. Vyššie jednorazové skóre teda automaticky neprinieslo viac pracovných postupov, na ktoré sa možno spoľahnúť pri každom opakovaní.

Autori analyzovali aj rozsiahlu spoločnú podmnožinu 121 680 platných behov dvanástich modelov. Vykonateľné kontroly odmietli 79 853 pokusov. Až 67,24 % týchto neúspešných behov sa pritom skončilo bez finálnej chyby nástroja, obsahovalo operáciu meniacu stav a navonok pôsobilo ako riadne dokončená práca. Medzi prekrývajúcimi sa zisteniami boli nesprávne hodnoty polí, nežiaduce dodatočné zmeny aj chýbajúce povinné účinky. To je dôležitý signál pre systémy, ktoré dnes považujú neprerušený beh alebo stav HTTP 200 za dôkaz úspechu.

Približne štyri pätiny zlyhaní v diagnostickej analýze súviseli s používaním nástrojov. Agenti sa často dostali dostatočne ďaleko na to, aby sa pokúsili o zmenu, ale nezvládli chybu nástroja, nesplnenú podmienku alebo prázdny výsledok vyhľadávania. Autori preto upozorňujú, že časť problému nemusí vyriešiť iba výkonnejší základný model. Produkčný systém potrebuje rozlišovať obnoviteľné chyby, overovať predpoklady pred zápisom, kontrolovať výsledný stav a pri nezvratných operáciách vyžiadať ľudské schválenie.

Praktický dôsledok pre nasadzovanie agentov

Pre firmy z toho vyplýva potreba oddeliť schopnosť agenta od spoľahlivosti celého pracovného postupu. Demonštrácia, v ktorej agent raz správne spracuje faktúru alebo reklamáciu, potvrdzuje len to, že riešenie je možné. Pred produkčným nasadením treba rovnaký scenár opakovať, meniť okrajové podmienky a po každom behu kontrolovať autoritatívny systém záznamov. Pri databázových operáciách to znamená asercie nad konkrétnymi riadkami a poľami; pri externých účinkoch overenie odoslaných správ, vytvorených prípadov či uskutočnených transakcií.

Dôležitá je aj ekonomika. ThinkingBox rozlišuje cenu jedného úspešného pokusu od ceny spoľahlivo zvládnutej úlohy. Lacný model s prijateľným priemerom môže byť nákladný, ak vyžaduje časté opakovanie, kontrolu človekom alebo opravu chybných zápisov. Naopak drahší model nemusí byť automaticky výhodnejší, pokiaľ sa jeho vyššie jednorazové skóre nepremietne do konzistentnosti. Pri výbere modelu preto nestačí porovnať cenu tokenov; treba započítať aj validáciu stavu, kompenzačné operácie a riziko chýb v kritických procesoch.

Pre slovenské organizácie je tento prístup relevantný najmä pri agentoch napojených na účtovníctvo, elektronické obchody, zákaznícku podporu, poisťovníctvo alebo verejné služby. Menší jazykový trh navyše zvyšuje potrebu vlastných testov: anglický benchmark neoveruje kvalitu slovenského dialógu, lokálne právne pravidlá ani integrácie používané domácimi firmami. Rozumným pokračovaním by preto nebolo slepé prevzatie jeho rebríčka, ale vytvorenie izolovaných slovenských scenárov s rovnakým princípom hodnotenia konečného stavu.

Otvorený nástroj, ale nie definitívny verdikt

ThinkingBox je zverejnený ako otvorený framework pod licenciou MIT, benchmarkové dáta používajú licenciu CDLA-Permissive-2.0 a úlohy možno prezerať na Hugging Face. Framework dokáže spúšťať izolované MCP prostredia, simulovaného používateľa a hodnotenie výsledkov. Adaptér v OpenEnv poskytuje štandardizované rozhranie pre resetovanie úlohy, volanie nástrojov a odovzdanie odpovede. Samotný obraz OpenEnv však neobsahuje všetky závislosti; samostatne treba prevádzkovať proxy, MCP servery, Typesense a modelové koncové body.

Benchmark má aj limity. Všetky prípady sú syntetickými rekonštrukciami, nie záznamami skutočných zákazníkov. Pokrývajú päť domén a konkrétne navrhnuté rozhrania, takže poradie modelov sa môže zmeniť pri iných nástrojoch, promptoch alebo podnikových pravidlách. Zverejnené výsledky tiež samy osebe neukazujú, o koľko spoľahlivosť zvýši verifikácia pred potvrdením transakcie, menší počet nástrojov, cielenejšie opakovanie alebo ľudská kontrola. Autori tieto opatrenia opisujú ako testovateľné smery, nie ako už dokázané riešenia.

Najdôležitejším prínosom ThinkingBoxu preto nie je ďalšia tabuľka modelov, ale prísnejšie vymedzenie hotovej práce. Agent nemá dostať kredit za to, že správne opísal svoj zámer alebo odoslal syntakticky platný príkaz. Úloha je dokončená až vtedy, keď autoritatívny systém obsahuje požadovaný stav, chýbajú nežiaduce zásahy a výsledok sa dá opakovane reprodukovať. Pre agentov, ktorí majú prejsť z ukážok do reálnej prevádzky, je to podstatne vyššia, ale prakticky nevyhnutná latka.