τ²-bench: Meranie nákladov na duálne riadenie v konverzačných AI agentoch

Počas posledných týždňov som prechádzal líniou τ-bench a τ²-bench (arXiv:2506.07982) je práca, na ktorú som čakal: konečne sa pýta, čo sa stane, keď používateľ nie je pasívnym dávkovačom informácií, ale aktívnym účastníkom s vlastnou sadou nástrojov. Pre každého, kto buduje konverzačného účtovného agenta, bola táto medzera vždy do očí bijúca.

Článok

Victor Barres, Honghua Dong, Soham Ray, Xujie Si a Karthik Narasimhan (Sierra AI a University of Toronto) predstavujú τ²-bench ako priame rozšírenie pôvodného τ-bench. Kľúčovým pozorovaním je, že predchádzajúce benchmarky pre konverzačných AI agentov sú s jedným riadením (single-control): iba agent môže vyvolávať nástroje; používateľ je obmedzený na správy v prirodzenom jazyku. Technická podpora v reálnom svete tento predpoklad porušuje. Keď vám agent zákazníckeho servisu povie, aby ste „vypli režim lietadlo“, vykonávate volanie nástroja na svojom vlastnom zariadení, nie len opisujete svoje preferencie.

Autori to modelujú ako decentralizovaný čiastočne pozorovateľný Markovov rozhodovací proces (Dec-POMDP), kde agent aj simulátor používateľa majú odlišné priestory akcií (volania funkcií a správy) nad zdieľaným dynamickým stavom sveta. Strana agenta vyzerá ako štandardné CRM: môže vyhľadávať záznamy o zákazníkoch, povoliť roaming alebo vymeniť SIM kartu. Strana používateľa je simulovaný telefón s nástrojmi na čítanie (get_status_bar, get_sim_status) a nástrojmi na zápis (toggle_airplane_mode, toggle_data, reseat_sim_card). Benchmark prichádza s novou telekomunikačnou doménou (114 úloh vybraných z 2 285 programovo vygenerovaných variantov) popri overených doménach maloobchodu (115 úloh) a leteckej dopravy (50 úloh) z pôvodného τ-bench.

Kľúčové myšlienky

• Formalizmus duálneho riadenia: Reprezentácia Dec-POMDP jasne oddeľuje to, čo každý hráč pozoruje a ktoré nástroje môže každý vyvolať. Je to prísnejšie ako ad-hoc prístup „používateľa s telefónom“, ktorý by ste mohli pripojiť k existujúcemu prostrediu pre jedného agenta.
• Kompozičný generátor úloh: Úlohy sú zostavené z 15 skupín atomických čiastkových úloh pokrývajúcich tri typy zámerov (service_issue, mobile_data_issue, mms_issue) s explicitným škálovaním náročnosti podľa počtu požadovaných krokov na vyriešenie.
• Výkon v telekomunikáciách (pass¹): GPT-4.1 dosahuje iba 34 %; o4-mini 42 %; Claude 3.7 Sonnet 49 %; GPT-4.1-mini okolo 50 %. Všetky modely tu dosahujú podstatne nižšie skóre ako v maloobchode alebo leteckej doprave.
• Penalizácia za duálne riadenie: Ablácia porovnáva predvolený režim (Default – používateľ má nástroje) s režimom bez používateľa (No-User – agent sám ovláda každý nástroj). GPT-4.1 klesá o 18 percentuálnych bodov; o4-mini klesá o 25 bodov. Tento rozdiel predstavuje náklady na koordináciu s aktívnym používateľom, oddelené od čistej náročnosti uvažovania.
• Rozdiel voči ideálnemu plánu (Oracle-plan gap): Aj keď agent dostane vopred kompletnú sekvenciu akcií, výkon nedosahuje 100 %, čo nám hovorí, že samotné vykonávanie a koordinácia s používateľom pridávajú chyby nad rámec plánovania.
• Štruktúrované nástroje používateľa dramaticky znižujú šum simulátora: Telekomunikačný simulátor používateľa produkuje iba 16 % chýb (6 % kritických) v porovnaní so 40 % chýb (12 % kritických) pri maloobchode v pôvodnom τ-bench. Zlepšenie pochádza z nahradenia voľných textových výziev pre používateľa prísne obmedzeným rozhraním nástrojov, ktoré sleduje stav zariadenia.

Čo obstojí — a čo nie

Rámec Dec-POMDP je jednou z najstarostlivejších formulácií problému, aké som v benchmarkovaní agentov videl. Programový generátor úloh je skutočne užitočný: poskytuje preukázateľne správne úlohy a explicitne kontrolovateľnú zložitosť, na rozdiel od ručne vytvorených zbierok úloh, ktoré trápia väčšinu benchmarkov. Čísla spoľahlivosti simulátora používateľa sú presvedčivé – zníženie kritických chýb z 12 % na 6 % veľa znamená, keď sa snažíte dôverovať svojmu evaluačnému signálu.

Napriek tomu je telekomunikačná doména úzka. Štyria zákazníci, deväť liniek, päť paušálov: toto je kontrolované laboratórium, nie podnikový systém. Čísla pass¹ pre gpt-4.1-mini a Claude 3.7 Sonnet (~50 %) vyzerajú prekvapivo vysoko vzhľadom na to, ako náročnú doménu autori opisujú, čo ma núti premýšľať, či 114 úloh stačí na to, aby sa zabránilo nafúknutiu skóre šťastnými pokusmi. Autori uznávajú, že ich súbor úloh je len vzorkou. Analýzu „persony“ používateľa tiež považujem za slabú: článok ukazuje, že persona „Hard“ (64-ročný dôchodca s nízkou technickou sebadôverou) je náročnejšia ako persona „Easy“, čo nie je prekvapujúce. Čo by som chcel vidieť, je, či sa líši typ zlyhania koordinácie – spôsobuje náročnejšia persona viac chýb v uvažovaní alebo viac komunikačných chýb?

Článok tiež neskúma, čo sa stane, keď je dokument s pravidlami (policy document) agenta nesprávny alebo neúplný, čo je realistický scenár pre produkčné nasadenie. Každý výsledok predpokladá, že agent dostane presné pravidlá.

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

Predpoklad jedného riadenia zakotvený v τ-bench, WorkArena a väčšine benchmarkov orientovaných na dialóg sa zle prenáša na skutočný scenár podpory Beancount. Používateľ, ktorý žiada agenta Beancount o opravu svojej hlavnej knihy (ledger), nielen opisuje problém – môže súčasne upravovať súbor vo svojom textovom editore, spúšťať bean-check alebo nahrávať nový export CSV zo svojej banky. To je prostredie s duálnym riadením presne v zmysle τ²-bench.

Pokles o 18 – 25 percentuálnych bodov pri prechode z režimu No-User do Default je číslo, ku ktorému sa budem neustále vracať. Naznačuje to, že aj keby sme postavili agenta Beancount, ktorý by bol takmer dokonalý v autonómnej manipulácii s účtovnou knihou, zavedenie aktívneho používateľa, ktorý zdieľa prístup na zápis, by znížilo mieru úspešnosti zhruba o štvrtinu. Návrhy pre bezpečný spätný zápis, o ktorých sme uvažovali (GuardAgent, ShieldAgent, overiteľné MCP), boli navrhnuté pre nastavenia s jedným riadením; vyžadujú prehodnotenie, ak je používateľ tiež agentom vyvolávajúcim nástroje nad rovnakým prostredím.

Zlepšenie spoľahlivosti simulátora používateľa je tiež priamo využiteľné v praxi. Ak chcem spúšťať offline evaluácie agenta Beancount bez náboru ľudských účtovníkov, správnym inžinierskym rozhodnutím je pevné prepojenie simulovaného používateľa s deterministickým prostredím účtovnej knihy – namiesto spoliehania sa na voľné hranie rolí pomocou LLM.

Čo si prečítať ďalej

• τ-bench (Yao et al., arXiv:2406.12045): Základ, ktorý tento článok rozširuje – pred interpretáciou výsledkov τ²-bench stojí za to prečítať si o pôvodnej konštrukcii úloh a návrhu metriky pass^k.
• ToolSandbox (Lu et al., arXiv:2408.04682): Zavádza stavové nástroje pre jemnozrnné hodnotenie agentov; najrelevantnejšia architektúra pre návrh testovacieho prostredia s duálnym riadením pre Beancount.
• TheAgentCompany (Xu et al., arXiv:2412.14161): 175 úloh vo vnútri simulovanej softvérovej spoločnosti s reálnymi internými nástrojmi; momentálne najrealistickejší benchmark podnikovej automatizácie a ďalší článok na mojom zozname čítania.