FinTrace: Evaluatie op trajectniveau van LLM tool-aanroepen voor financiële taken

FinTrace (arXiv:2604.10015) verschijnt een week na FinToolBench, waarover ik de vorige keer schreef, en de twee artikelen staan in directe verbinding met elkaar. Waar FinToolBench meet of een agent de juiste tools aanroept, stelt FinTrace de moeilijkere vraag: zelfs als een agent de juiste tools aanroept, redeneert hij dan ook echt over de resultaten? Dat onderscheid is de kern van het artikel en, naar mijn mening, de kern van het hele probleem rondom de Beancount write-back agent.

Het artikel

Cao et al. introduceren FinTrace, een benchmark van 800 door experts geannoteerde trajecten verdeeld over 34 real-world categorieën van financiële taken in de moeilijkheidsgraden makkelijk, gemiddeld en moeilijk. De auteurs bouwen hun evaluatie rond een rubriek van negen statistieken, georganiseerd langs vier assen: correctheid van acties (tool-aanroep F1, relevantie van de taak), executie-efficiëntie (stapefficiëntie, redundantiescore), proceskwaliteit (logische progressie, informatiebenutting, voortgangsscore) en outputkwaliteit (slagingspercentage van de taak, kwaliteit van het definitieve antwoord). Ze evalueren 13 LLM's en brengen ook FinTrace-Training uit, een dataset van 8.196 gecureerde voorkeurstrajecten voor fijnafstemming.

De centrale claim is dat frontier-modellen de tool-selectie onder de knie hebben, maar systematisch falen bij de moeilijkere stap: het gebruiken van wat de tools teruggeven. De benchmark onderzoekt dit met een 5-puntsschaal voor informatiebenutting, logische progressie en voortgangsscore, naast algoritmische statistieken voor tool-F1 en stapefficiëntie.

Belangrijkste ideeën

• Het best presterende model, Claude-Opus-4.6, behaalt een Tool-Calling F1 van 0,896 — een sterke selectie — maar scoort slechts 3,23/5 op Informatiebenutting, de zwakste van de vier outputgerichte statistieken.
• Het slagingspercentage (Task Pass Rate) van Claude-Opus-4.6 is 2,65/5, en de kwaliteit van het definitieve antwoord is 3,34/5; zelfs het topmodel produceert niet consequent correcte, volledige antwoorden.
• Qwen-3.5-9B vertoont een gedegenereerd patroon: bijna perfecte stapefficiëntie (1,000) en redundantie (1,000) omdat het nauwelijks tools aanroept, wat tot uiting komt in een Tool-Calling F1 van 0,109. Efficiënt maar nutteloos.
• Training op FinTrace-Training verbetert de statistieken van het tussenliggende proces (logische progressie stijgt van 2,29 naar 2,56 met DPO; voortgangsscore van 2,00 naar 2,30), maar de kwaliteit van het definitieve antwoord blijft steken — geen enkele variant overschrijdt significant het gemiddelde van 1,21 op de schaal van 1–5 voor kleine modellen.
• DPO presteert beter dan SFT bij het onderdrukken van catastrofale foutmodi: het aandeel logische progressiescores van 1 daalt van 11,9% (SFT) naar 9,5% (DPO).
• De universeel slechtste subcategorie over alle 13 modellen is Redeneren QA, waar Claude-Opus-4.6 slechts 0,62 in totaal behaalt — een hard plafond dat zelfs door de sterkste frontier-modellen wordt gedeeld.

Wat houdt stand — en wat niet

De kernbevinding — dat tool-selectie en tool-redenering van elkaar te scheiden zijn — is goed onderbouwd en de rubriek met vier assen is een waardevolle bijdrage. Eerdere benchmarks zoals FinToolBench stoppen bij executietraces; FinTrace voegt door LLM beoordeelde proceskwaliteitsstatistieken toe die blootleggen wat er tussendoor gebeurt. De inter-rater Cohen's κ van 0,89 op een validatie van 100 steekproeven is bemoedigend voor een benchmark die deels op LLM-beoordelaars is gebouwd.

Dat gezegd hebbende, beperken verschillende methodologische keuzes wat ik van de cijfers kan aannemen. De 34 taakcategorieën worden niet opgesomd in het hoofdartikel — ze zijn uitgesteld naar Appendix B — dus ik kan niet zeggen hoe representatief ze zijn voor de praktijk van de financiële wereld. De moeilijkheidsgraden zijn gedefinieerd door percentielrangen binnen de eigen query-pool van de benchmark, wat een circulaire meting is: 'moeilijk' betekent alleen ongebruikelijk ten opzichte van de andere 800 trajecten, niet moeilijk in absolute zin.

De analyse van de fijnafstemming is frustrerend. Het trainen van een 9B-model op FinTrace-Training verbetert de tussenliggende redenering, maar de kwaliteit van het definitieve antwoord blijft ondermaats. Het artikel wijt dit aan een "loskoppeling" tussen proces en output, maar legt niet uit waarom. De meest plausibele verklaring — dat een 9B-model de feitelijke kennis en rekenvaardigheid mist die nodig is voor financiële taken, ongeacht de kwaliteit van het traject — blijft onbesproken. Door DPO-resultaten alleen voor Qwen-3.5-9B te tonen, is het ook onmogelijk om te weten of grotere modellen er meer baat bij hebben.

Ik ben ook sceptisch over de algehele aggregatie van scores. Het combineren van algoritmische statistieken (F1 ∈ [0,1]) met door LLM beoordeelde scores op 1–5 Likert-schalen door te normaliseren naar [0,1] en te gemiddelden, gooit heel verschillende soorten fouten op één hoop. Een model dat de verkeerde tools aanroept, is op een andere manier defect dan een model dat de juiste tools aanroept en vervolgens de output negeert.

Waarom dit belangrijk is voor financiële AI

De kernbevinding is direct van toepassing op het Beancount write-back probleem. Een agent die betrouwbaar de juiste Beancount CLI-tools aanroept, maar vervolgens de output verkeerd interpreteert — bijvoorbeeld door een balansrespons te parsen en naar de verkeerde rekening te boeken — is slechter dan geen automatisering: het produceert overtuigend onjuiste journaalposten die er voor een vluchtige controleur correct uitzien.

De statistiek voor informatiebenutting is degene die ik het scherpst in de gaten zou houden voor elke Beancount-agent. Het feit dat het beste beschikbare model hierop 3,23/5 scoort in een gecontroleerde financiële benchmark, zou een dwingende beperking moeten zijn voor elke productie-inzet. Het pleit voor een verplichte menselijke beoordeling van elke write-back operatie, althans totdat we die score consistent boven de 4,0 zien komen.

FinTrace bevestigt ook wat ReDAct vorige week suggereerde: de juiste architectuur is geen end-to-end LLM-redenering, maar een pijplijn die verificatie externaliseert. Een agent die tools goed selecteert (Tool F1 ~0,9) en vervolgens de resultaten doorgeeft aan een aparte validatiestap voordat hij actie onderneemt, is beter verdedigbaar dan een agent die probeert te redeneren over onbewerkte tool-output in één enkele run.

Wat nu te lezen

• FinMCP-Bench (arXiv:2603.24943): het begeleidende artikel dat MCP gebruikt als standaard voor de tool-interface, de volgende op de leeslijst — direct vergelijkbaar met FinTrace maar gebouwd op een andere protocollaag.
• "Benchmarking LLM Tool-Use in the Wild" (arXiv:2604.06185): verscheen tegelijkertijd en evalueert tool-aanroepen buiten de financiële sector; zou kunnen verduidelijken of de kloof in informatiebenutting domeinspecifiek of algemeen is.
• "Data-Driven Function Calling Improvements in Large Language Model for Online Financial QA" (arXiv:2604.05387): richt zich op dezelfde foutmodi bij tool-aanroepen vanuit een trainingsdata-perspectief en zou kunnen verklaren wat de DPO van FinTrace-Training mist.