τ-bench: Meranie spoľahlivosti AI agentov v reálnych doménach s použitím nástrojov

Po týždňoch sledovania línie uvažovania nad tabuľkami a text-to-SQL som chcel zmeniť perspektívu a položiť si inú otázku: ako dobre si súčasní agenti v skutočnosti počínajú, keď ich zapojíte do živého operačného cyklu so skutočným používateľom? τ-bench dáva tú najúprimnejšiu odpoveď, akú som kedy videl, a tie čísla sú znepokojujúce.

Dokument

Yao, Shinn, Razavi a Narasimhan – všetci z Princetonu a Sierra Research – vydali τ-bench (arXiv:2406.12045, jún 2024), aby vyplnili medzeru, ktorá je pri spätnom pohľade zrejmá: väčšina benchmarkov pre agentov predloží modelu úlohu a vyhodnotí jeho konečnú odpoveď izolovane. Reálne nasadenia takto nevyzerajú. Agent zákazníckeho servisu je prerušovaný, dostáva doplňujúce otázky, protichodné informácie a očakáva sa od neho, že bude počas otvorenej konverzácie dodržiavať firemné pravidlá ešte predtým, než vykoná akúkoľvek zmenu v databáze.

τ-bench zahŕňa dve reálne domény zákazníckeho servisu – maloobchod a leteckú spoločnosť – do simulačného prostredia, kde jeden jazykový model hrá používateľa a druhý agenta. Agent má prístup k API špecifickým pre danú doménu (zrušenie objednávky, zmena sedadla, uplatnenie kupónu) a k dokumentu s pravidlami, ktorý špecifikuje, ktoré akcie sú povolené a za akých podmienok. Hodnotenie neboduje medzikroky: porovnáva konečný stav databázy s anotovaným cieľovým stavom. Autori tiež zavádzajú pass^k, metriku spoľahlivosti, ktorá skúma, v akej časti pokusov agent uspeje konzistentne v k nezávislých pokusoch na tej istej úlohe.

Kľúčové myšlienky

• pass^k ako úprimná metrika: samotné skóre pass@1 je príliš zašumené. pass^k odhaľuje pravdepodobnosť, že agent uspeje v každom jednom z k opakovaní tej istej úlohy – čo je indikátor toho, či by ste mu dôverovali v produkcii.
• Prepad konzistencie: GPT-4o v maloobchode dosahuje 0,604 pri pass@1, ale pri pass@4 klesá na 0,383. To znamená, že približne v 60 % úloh zlyhá aspoň raz v štyroch pokusoch – čo rozhodne nie je agent bezpečný pre produkciu.
• Letecká doprava je náročnejšia ako maloobchod: pass@1 modelu GPT-4o klesá z 0,604 (maloobchod) na 0,420 (letecká doprava). Claude 3.5 Sonnet (verzia z októbra 2024) si vedie lepšie – 0,692 v maloobchode / 0,460 v leteckej doprave pri pass@1 – ale jeho pass@4 stále dosahuje len 0,462, resp. 0,225.
• Volanie funkcií poráža ReAct: variant GPT-4o s volaním funkcií (pass@1 = 0,420 v leteckej doprave) prekonáva Act (0,365) aj ReAct (0,325) na rovnakom jadre, čo naznačuje, že štruktúrované API nástrojov znižujú počet zlyhaní spôsobených formátom.
• Simulácia používateľa je premenná: autori používajú jazykový model na simuláciu používateľa, čo prináša vlastnú varianciu. Slabší simulátor používateľa môže znížiť alebo zvýšiť skóre agenta v závislosti od toho, ako verne reprezentuje nepriateľské správanie používateľa.
• Vyhodnotenie stavu databázy obchádza hry na čiastočný kredit: porovnávanie konečného stavu namiesto krokov dialógu znamená, že agent, ktorý vykoná správnu akciu a potom ju neúmyselne vráti späť, nezíska žiadny kredit – čo je správne rozhodnutie pre write-back systém.

Čo obstojí — a čo nie

Rámec pass^k je skutočne užitočný a očakávam, že pretrvá dlhšie než tento konkrétny benchmark. Rozhodnutie vyhodnocovať stav databázy namiesto podobnosti na úrovni tokenov je správne – priamo meria, či agent splnil úlohu, a nie či hovoril správne veci.

Domény sú však zámerne úzke. Maloobchod a letecká doprava sú procedurálne čisté: dokumenty s pravidlami sú konečné a napísané pre benchmark, API sú malé a dobre špecifikované a simulátor používateľa je v predvolenom nastavení spolupracujúci. Reálne dokumenty s pravidlami sú nejednoznačné; skutoční používatelia klamú, zle si pamätajú a odporujú pri odmietnutí. Autori benchmarku to uznávajú – samotná existencia τ²-bench (arXiv:2506.07982) ako pokračovania, ktoré sa rozširuje na model Dec-POMDP s dvojitým riadením, kde aj používateľ manipuluje so stavom prostredia, je priznaním, že vyhodnotenie s jedným riadením podhodnocuje náročnosť.

Existuje tiež otázka, čo pass^k v skutočnosti meria. Ak je samotná simulácia používateľa stochastická, variancia v k pokusoch zmiešava nekonzistentnosť agenta s nekonzistentnosťou simulátora. Dokument to uvádza, ale úplne neoddeľuje tieto dva zdroje variancie. Pri aplikáciách kritických z hľadiska bezpečnosti by ste chceli identifikovať príčiny zlyhaní – ignoruje agent pravidlá, zle číta úmysel používateľa alebo len vyberá nesprávny formát volania nástroja?

Rebríček na llm-stats.com teraz ukazuje modely ako Step-3.5-Flash s hodnotou 0,882, čo by vyzeralo ako dramatický pokrok, keby ste si nevšimli, že nastavenie vyhodnocovania sa pravdepodobne posunulo: novšie príspevky sa zdajú byť skórované pod inými verziami simulátora používateľa a možno aj s iným rozdelením úloh. Porovnávanie rôznych záznamov v vyvíjajúcich sa benchmarkoch je vždy podozrivé.

Prečo je to dôležité pre finančnú AI

Write-back agent pre Beancount, ktorého mám na mysli, je štrukturálne identický s agentmi, ktorých vyhodnocuje τ-bench: má nástroje špecifické pre doménu (pridanie transakcie, oprava zostatku, rekategorizácia položky), obmedzenia pravidiel (neupravovať uzavreté obdobia, nevytvárať záporné zostatky, dodržiavať účtovú osnovu) a používateľa, ktorý dáva pokyny v prirodzenom jazyku v rámci konverzácie, ktorá môže trvať mnoho krokov.

Zistenie o pass^k je pre nás najpraktickejším výsledkom. Ak špičkový model ako Claude 3.5 Sonnet dosahuje pass@4 len 0,462 v maloobchode – v relatívne zhovievavej doméne – mali by sme očakávať podobnú alebo horšiu konzistenciu pri zápise do účtovnej knihy, kde sa chyby v transakciách sčítajú a porušenia pravidiel nemusia byť okamžite viditeľné. Navrhovanie systému s ohľadom na konzistenciu v k pokusoch od začiatku – nielen optimalizácia pass@1 – mení architektúru: hovorí to v prospech konzervatívneho používania nástrojov (pýtať sa pred zápisom, nie po ňom), explicitných krokov kontroly pravidiel pred akýmkoľvek volaním API a samostatného overovacieho agenta, ktorý audituje navrhované zmeny v databáze predtým, ako sú potvrdené.

Metodika vyhodnocovania stavu databázy je tiež priamo prenosná. Štruktúrovaný formát súborov Beancount umožňuje jednoducho porovnať očakávaný stav účtovnej knihy so skutočným stavom po write-back relácii, čo nám dáva rovnaký druh objektívneho signálu na vyhodnotenie, aký používa τ-bench.

Čo si prečítať ďalej

• τ²-bench (arXiv:2506.07982): pokračovanie, ktoré sa rozširuje na prostredia s dvojitým riadením, kde nástroje vyvolávajú aj používatelia; priamo relevantné, ak modelujeme používateľa ako aktívneho účastníka opráv účtovnej knihy, a nie ako pasívneho žiadateľa.
• AgentEval / GAIA (arXiv:2311.12983): benchmark GAIA vyhodnocuje všeobecných AI asistentov v úlohách z reálneho sveta vyžadujúcich prehliadanie webu a používanie nástrojov; užitočný doplnok k doménovo špecifickému zameraniu τ-bench.
• WorkArena (arXiv:2403.07718): vyhodnocuje agentov v úlohách reálneho podnikového softvéru v ServiceNow; doména má bližšie k účtovným workflow než maloobchod alebo letecká doprava a stojí za prečítanie kvôli lekciám o návrhu úloh.