Doorgaan naar hoofdinhoud

FinToolBench: Evaluatie van LLM-agents bij het gebruik van financiële tools in de praktijk

· 6 min leestijd
Mike Thrift
Mike Thrift
Marketing Manager

De meeste AI-benchmarks voor de financiële sector testen of een model een document kan lezen. FinToolBench test of een model iets kan doen — een live API aanroepen, actuele marktgegevens ophalen en een correct antwoord geven. Dat is de kloof die telt voor elk systeem dat echt financieel werk probeert te automatiseren, en het is de kloof waarop ik heb gewacht tot iemand deze rigoureus zou dichten.

Het artikel

2026-07-05-fintoolbench-evaluating-llm-agents-real-world-financial-tool-use

Jiaxuan Lu en collega's introduceren FinToolBench (arXiv:2603.08262, maart 2026) als, naar eigen zeggen, de eerste praktijkgerichte, uitvoerbare benchmark voor het evalueren van agents die financiële tools leren gebruiken. De formulering is direct: bestaande AI-evaluaties voor de financiële sector richten zich op statische vraag-antwoordsessies over documenten, terwijl algemene benchmarks voor toolgebruik, zoals ToolLLM, financiën behandelen als slechts een andere API-categorie zonder domeinspecifieke compliance-beperkingen. FinToolBench probeert de ruimte tussen deze twee tekortkomingen te vullen.

De benchmark koppelt 760 uitvoerbare financiële tools — 261 live endpoints van RapidAPI en 499 interfaces van AkShare — aan 295 rigoureus geselecteerde evaluatievragen, verdeeld over 166 scenario's met één tool en 129 scenario's met meerdere tools. De tools bestrijken domeinen zoals aandelen, obligaties, fondsen, forex, derivaten, macro-economie en crypto. Cruciaal is dat dit echte, aanroepbare API's zijn, geen gesimuleerde stubs. De auteurs introduceren ook FATR (Finance-Aware Tool Routing), een baseline-agent die gebruikmaakt van BGE-M3 retrieval (top-20 kandidaten), toolcards voorzien van financiële attributen, en een ReAct-planner die rekening houdt met beperkingen en beperkt is tot vijf stappen.

Kernpunten

  • Uitvoering is niet het knelpunt — het redeneren over de outputs wel. GPT-4o heeft de hoogste Conditional Soft Score (CSS = 0,670), wat betekent dat het correcte antwoorden geeft wanneer het succesvol een tool aanroept, maar het roept tools slechts in 22,7% van de gevallen aan (TIR = 0,227). Qwen3-8B roept tools in 87,1% van de gevallen aan, maar geeft slechts in 40,4% van de gevallen het juiste antwoord wanneer het slaagt.
  • Intentie-mismatch is de dominante compliance-fout. De IMR (Intent Mismatch Rate) overstijgt de 50% bij de meeste modellen, wat betekent dat agents routinematig aanroepen met een transactionele intentie doen terwijl de query slechts om een informatieve zoekopdracht vraagt. Dat is een ernstig probleem in gereguleerde financiële contexten.
  • Injectie van financiële attributen helpt bij compliance zonder de capaciteiten te schaden. De toolcards van de FATR-baseline — waarbij elke tool wordt geannoteerd met tijdigheid, intentietype en regelgevingsdomein — verminderen het aantal aanroepen van verouderde gegevens (TMR) en domeinschendingen (DMR) zonder de aanroepfrequentie significant te verslechteren.
  • Queries met meerdere tools leggen de betrouwbaarheidskloof bloot. De 129 queries met meerdere tools vereisen het koppelen van aanroepen en het doorgeven van outputs tussen stappen; de prestaties dalen aanzienlijk vergeleken met scenario's met één tool, wat overeenkomt met bevindingen van FinTrace en TheAgentCompany.
  • Kleine modellen kunnen vaker aanroepen, maar redeneren minder goed dan grote modellen. De TIR van 0,871 voor Qwen3-8B tegenover 0,227 voor GPT-4o laat zien dat kleinere modellen "schietgraag" zijn, maar de CER (Conditional Execution Rate, d.w.z. TESR/TIR) van 0,339 voor Qwen3-8B tegenover 0,618 voor GPT-4o onthult dat GPT-4o veel nauwkeuriger is wanneer het besluit een tool aan te roepen.

Wat standhoudt — en wat niet

De keuze van de benchmark om echt live, uitvoerbare API's te gebruiken is de belangrijkste bijdrage, en het is een waardevolle. Gesimuleerde API's zijn het publieke geheim van benchmarks voor toolgebruik: de 16.000 API's van ToolLLM klinken indrukwekkend totdat je beseft dat de evaluatie een LLM gebruikt als rechter om te bepalen of een aanroep "zou hebben" gewerkt. FinToolBench vermijdt dat.

De compliance-metrieken (TMR, IMR, DMR) zijn conceptueel juist — financiële agents moeten het verschil weten tussen het ophalen van de slotkoers van gisteren en het initiëren van een transactie — maar de beschrijving in het artikel over hoe deze classificaties worden afgedwongen is mager. Het is niet duidelijk of de ground-truth labels voor het intentietype (informatief versus transactioneel) zijn geverifieerd door juridische of compliance-experts, of simpelweg zijn toegewezen door de auteurs van de dataset. Dat is in de praktijk van groot belang.

De lijst met geteste modellen is ook opvallend smal: Doubao-Seed-1.6, Qwen3-8B, GLM-4.7-Flash en GPT-4o. Geen Claude Sonnet of Gemini 2.5, wat logische vergelijkingen zouden zijn geweest. De resultatentabel laat zien dat GPT-4o een uitbijter is met hoge precisie maar lage dekking; ik zou willen weten of het toolgebruik van Claude dichter bij het conservatieve patroon van GPT-4o ligt of bij het agressieve patroon van Qwen3-8B.

De evaluatieset van 295 queries is klein naar moderne benchmark-standaarden. Met 760 tools betekent een dekkingsgraad van 295 queries dat de meeste tools nooit worden getest. Het artikel rapporteert geen dekkingsstatistieken per domein, wat betekent dat de hoofdcijfers gedreven kunnen worden door een subset van goed gedekte domeinen zoals aandelen en macro-economie.

Waarom dit belangrijk is voor AI in de financiële sector

Beancount write-back agents — elke agent die bean-add aanroept, een ledger-bestand aanpast of beanquery bevraagt — worden geconfronteerd met precies de foutmodi die FinToolBench blootlegt. Het probleem van intentie-mismatch vertaalt zich direct: een Beancount-agent die een schrijfaanroep doet terwijl de gebruiker een leesvraag stelde, heeft hetzelfde foutsymptoom als een IMR-schending. De dimensie van tijdigheid komt overeen met het probleem van het aanroepen van verouderde, gecachte ledger-statussen wanneer de gebruiker het huidige saldo verwacht.

De spanning tussen precisie en dekking (GPT-4o versus Qwen3-8B) is ook direct relevant. Voor Beancount write-back acties geef ik de voorkeur aan het conservatieve aanroepgedrag van GPT-4o — lage TIR maar hoge CER en CSS — boven een model met een hoge aanroepfrequentie dat regelmatig de verkeerde tool uitvoert. Foutieve schrijfacties zijn veel kostbaarder dan het niet uitvoeren van een actie (no-ops).

De FATR-aanpak om tools te annoteren met compliance-attributen in plaats van te vertrouwen op het model om deze af te leiden, is een ontwerppatroon dat de moeite waard is om over te nemen. Het voorzien van Beancount CLI-tools van expliciete metadata over de vraag of een aanroep alleen-lezen is of muterend, en of deze betrekking heeft op de huidige versus gearchiveerde ledger-status, is hetzelfde idee toegepast op een kleinere schaal.

Verder lezen

  • FinTrace (arXiv:2604.10015) — evaluatie op trajectniveau over 34 financiële taakcategorieën met 9 metrieken; breidt de enkelvoudige aanroep-evaluatie van FinToolBench direct uit naar reeksen van meerdere stappen, en finetunet Qwen-3.5-9B met DPO om het tussentijdse redeneren te verbeteren.
  • FinMCP-Bench (arXiv:2603.24943) — 613 samples over 65 op MCP gebaseerde financiële tools die enkelvoudige, meervoudige en multi-turn aanroepen testen; de MCP-benadering is direct relevant voor Beancount tool-interfaces.
  • ToolLLM (arXiv:2307.16789, ICLR 2024) — het ToolBench-artikel waar FinToolBench zich expliciet tegen afzet; begrijpen wat de baseline met gesimuleerde API's wel en niet kan meten, verduidelijkt hoeveel de uitvoerbaarheid van FinToolBench daadwerkelijk toevoegt.