FinToolBench: Evaluácia LLM agentov pri používaní reálnych finančných nástrojov

Väčšina AI benchmarkov pre oblasť financií testuje, či model dokáže prečítať dokument. FinToolBench testuje, či model dokáže niečo urobiť — zavolať živé API, získať aktuálne trhové dáta a vrátiť správnu odpoveď. To je rozdiel, na ktorom záleží pri každom systéme snažiacom sa automatizovať reálnu finančnú prácu, a je to medzera, na ktorej dôsledné vyplnenie som čakal.

Odborná práca

Jiaxuan Lu a kolegovia predstavujú FinToolBench (arXiv:2603.08262, marec 2026) ako podľa ich tvrdenia prvý reálny, vykonateľný benchmark na evaluáciu finančných agentov učiacich sa používať nástroje. Rámcovanie je priame: existujúce finančné AI evaluácie sa zameriavajú na statické QA nad dokumentmi, zatiaľ čo všeobecné benchmarky na používanie nástrojov ako ToolLLM považujú financie len za ďalšiu kategóriu API bez doménovo špecifických obmedzení zhody (compliance). FinToolBench sa snaží vyplniť priestor medzi týmito dvoma režimami zlyhania.

Benchmark spája 760 vykonateľných finančných nástrojov — 261 živých endpointov z RapidAPI a 499 rozhraní z AkShare — s 295 prísne kurátorovanými evaluačnými dopytmi, rozdelenými na 166 prípadov s jedným nástrojom a 129 s viacerými nástrojmi. Nástroje pokrývajú oblasti akcií, dlhopisov, fondov, forexu, derivátov, makroekonómie a kryptomien. Zásadné je, že ide o reálne, volateľné API, nie o simulované makety (stubs). Autori tiež zavádzajú FATR (Finance-Aware Tool Routing), referenčného agenta využívajúceho vyhľadávanie BGE-M3 (top-20 kandidátov), karty nástrojov anotované finančnými atribútmi a plánovač ReAct s vedomím obmedzení, limitovaný na päť krokov.

Kľúčové myšlienky

• Vykonávanie nie je úzkym hrdlom — tým je uvažovanie nad výstupmi. GPT-4o má najvyššie podmienené soft skóre (CSS = 0,670), čo znamená, že poskytuje správne odpovede, keď úspešne zavolá nástroj, ale nástroje vyvoláva len v 22,7 % prípadov (TIR = 0,227). Qwen3-8B volá nástroje v 87,1 % prípadov, ale správnu odpoveď dosiahne len v 40,4 % prípadov, keď uspeje.
• Nesúlad zámeru (intent mismatch) je dominantným zlyhaním v oblasti zhody. IMR (Intent Mismatch Rate) presahuje 50 % u väčšiny modelov, čo znamená, že agenti bežne vykonávajú transakčné volania, keď dopyt vyžaduje len vyhľadanie informácií. To je v regulovanom finančnom kontexte vážny problém.
• Injekcia finančných atribútov pomáha zhode bez poškodenia schopností. Karty nástrojov referenčného FATR — anotovanie každého nástroja časovou citlivosťou, typom zámeru a regulačnou doménou — znižujú počet volaní zastaraných dát (TMR) a porušení domény (DMR) bez výrazného zhoršenia miery vyvolania.
• Dopyty s viacerými nástrojmi odhaľujú medzeru v spoľahlivosti. 129 dopytov vyžadujúcich viacero nástrojov potrebuje reťazenie volaní a odovzdávanie výstupov medzi krokmi; výkon podstatne klesá v porovnaní s prípadmi s jedným nástrojom, čo je v súlade so zisteniami z FinTrace a TheAgentCompany.
• Malé modely môžu v počte volaní prekonať tie veľké, ale nie v logickom uvažovaní. TIR 0,871 u Qwen3-8B oproti 0,227 u GPT-4o ukazuje, že menšie modely sú „agresívnejšie“, ale CER (podmienená miera vykonania, t. j. TESR/TIR) 0,339 pre Qwen3-8B oproti 0,618 pre GPT-4o odhaľuje, že GPT-4o je oveľa presnejší, keď sa už rozhodne nástroj zavolať.

Čo obstojí — a čo nie

Voľba benchmarku používať skutočne živé, vykonateľné API je jeho primárnym prínosom, a to veľmi podstatným. Simulované API boli špinavým tajomstvom benchmarkov na používanie nástrojov: 16 000 API v ToolLLM znie pôsobivo, až kým si neuvedomíte, že evaluácia používa LLM ako sudcu toho, či by volanie „bolo“ fungovalo. FinToolBench sa tomu vyhýba.

Metriky zhody (TMR, IMR, DMR) sú konceptuálne správne — finanční agenti potrebujú poznať rozdiel medzi získaním včerajšej uzatváracej ceny a iniciovaním obchodu — ale popis v práci o tom, ako sa tieto klasifikácie vynucujú, je strohý. Nie je jasné, či označenia pre typ zámeru (informačný vs. transakčný) overovali experti na právo alebo compliance, alebo ich jednoducho priradili autori datasetu. V praxi na tom veľmi záleží.

Zoznam modelov je tiež nezvyčajne úzky: Doubao-Seed-1.6, Qwen3-8B, GLM-4.7-Flash a GPT-4o. Chýba Claude Sonnet alebo Gemini 2.5, ktoré by boli prirodzeným porovnaním. Tabuľka výsledkov ukazuje, že GPT-4o je odľahlou hodnotou s vysokou presnosťou, ale nízkym pokrytím; chcel by som vedieť, či sa správanie Clauda pri používaní nástrojov blíži skôr ku konzervatívnemu vzorcu GPT-4o alebo agresívnemu Qwen3-8B.

Evaluačná sada s 295 dopytmi je na pomery moderných benchmarkov malá. Pri 760 nástrojoch znamená miera pokrytia 295 dopytmi, že väčšina nástrojov sa nikdy netestuje. Práca neuvádza štatistiky pokrytia podľa domén, čo znamená, že hlavné čísla môžu byť ovplyvnené podmnožinou dobre pokrytých domén, ako sú akcie a makroekonómia.

Prečo na tom záleží pre finančnú AI

Agenti so spätným zápisom do Beancount — akýkoľvek agent, ktorý volá bean-add, opravuje súbor hlavnej knihy alebo dopytuje beanquery — čelia presne tým režimom zlyhania, ktoré FinToolBench odhaľuje. Problém nesúladu zámeru sa prekladá priamo: agent pre Beancount, ktorý vykoná príkaz na zápis, keď sa používateľ pýtal na čítanie, má rovnaký charakter zlyhania ako porušenie IMR. Dimenzia aktuálnosti (timeliness) mapuje problém volania zastaraného nacacheovaného stavu hlavnej knihy, keď používateľ očakáva aktuálny zostatok.

Napätie medzi presnosťou a pokrytím (GPT-4o vs. Qwen3-8B) je tiež priamo relevantné. Pre spätný zápis do Beancount by som oveľa radšej prijal konzervatívne správanie GPT-4o — nízke TIR, ale vysoké CER a CSS — než model s vysokou mierou vyvolania, ktorý často spustí nesprávny nástroj. Chybné zápisy sú oveľa nákladnejšie ako nevykonanie žiadnej operácie.

Prístup FATR spojený s anotovaním nástrojov atribútmi zhody namiesto spoliehania sa na to, že ich model odvodí, je dizajnový vzor, ktorý stojí za prijatie. Obalenie nástrojov CLI Beancount explicitnými metadátami o tom, či je volanie len na čítanie alebo meniace stav, a či sa dotýka aktuálneho alebo archivovaného stavu knihy, je rovnaká myšlienka aplikovaná na menší rozsah.

Čo si prečítať ďalej

• FinTrace (arXiv:2604.10015) — evaluácia na úrovni trajektórií v 34 finančných kategóriách úloh s 9 metrikami; priamo rozširuje evaluáciu FinToolBench z jedného volania na viacstupňové sekvencie a dolaďuje Qwen-3.5-9B pomocou DPO na zlepšenie priebežného uvažovania.
• FinMCP-Bench (arXiv:2603.24943) — 613 vzoriek nad 65 finančnými nástrojmi založenými na MCP, testujúcich vyvolanie jedného nástroja, viacerých nástrojov a viacúrovňovú konverzáciu; rámcovanie MCP je priamo relevantné pre rozhrania nástrojov Beancount.
• ToolLLM (arXiv:2307.16789, ICLR 2024) — práca ToolBench, voči ktorej sa FinToolBench explicitne vymedzuje; pochopenie toho, čo benchmark so simulovanými API dokáže a nedokáže merať, objasňuje, koľko v skutočnosti prináša vykonateľnosť vo FinToolBench.