Het artikel​

Zhao, Jin, Li en Gao van de Universiteit van Peking introduceren FinRAGBench-V, een tweetalige benchmark samengesteld uit echte financiële documenten: onderzoeksrapporten, jaarrekeningen, prospectussen, academische papers, tijdschriften en nieuwsartikelen. Het retrieval-corpus is aanzienlijk — 60.780 Chinese pagina's en 51.219 Engelse pagina's over ongeveer 1.100 documenten per taal — gekoppeld aan 1.394 door mensen geannoteerde QA-paren die zeven vraagcategorieën beslaan: tekstuele gevolgtrekking, extractie van grafieken en tabellen, numerieke berekening, tijdgevoelige zoekopdrachten en redeneren over meerdere pagina's. Naast de dataset is de belangrijkste bijdrage van het artikel RGenCite, een basissysteem dat antwoorden genereert samen met visuele citaten op pixelniveau in de vorm van bounding-box-coördinaten die de specifieke documentgebieden markeren die elke bewering ondersteunen.

Belangrijkste inzichten​

• Multimodale retrieval domineert alleen tekst met een verpletterende marge: ColQwen2, een vision-language retriever gebouwd op embeddings van pagina-afbeeldingen, behaalt een Recall@10 van 90,13% (Chinees) en 85,86% (Engels). De beste op tekst gebaseerde retrievers, BM25 en BGE-M3, blijven steken rond de 42,71%. Dit gat is geen afrondingsfout.
• De nauwkeurigheid van de generatie is laag, zelfs voor grensverleggende modellen: GPT-4o op Engels bereikt een nauwkeurigheid van 43,41% (ROUGE 24,66); o4-mini op Chinees bereikt 58,13% (ROUGE 38,55). Dit zijn topmodellen in eigendom met sterke retrieval.
• Citaties op paginaniveau werken; op blokniveau niet: Recall op paginaniveau ligt tussen 75–93% voor de beste modellen. Recall op blokniveau — weten welke specifieke tabelcel of grafiekregio een bewering onderbouwt — daalt naar 20–61%. Dit is de belangrijkste kloof voor controleerbaarheid.
• Numeriek redeneren en gevolgtrekkingen over meerdere pagina's laten modellen als eerste falen: Vragen die berekeningen over pagina's of tijdsperioden vereisen, zijn de punten waar de nauwkeurigheid bij alle geteste systemen het sterkst daalt.
• Eigen modellen presteren aanzienlijk beter dan open-source alternatieven: De kloof tussen gesloten API's en open-source is hier groter dan bij de meeste NLP-benchmarks, wat suggereert dat visueel financieel redeneren onopgelost blijft voor open modellen.
• Automatische evaluatie voor citaten is onvolmaakt: De citatie-evaluator voor het bijsnijden van afbeeldingen behaalt een Pearson r = 0,68 met menselijke beoordelingen — redelijk, maar niet betrouwbaar genoeg om volledig op te vertrouwen zonder steekproeven.

Wat standhoudt — en wat niet​

De bevinding over retrieval is het meest geloofwaardige resultaat in het artikel. Een gat van bijna 50 procentpunten tussen multimodale en tekst-alleen retrievers bij meer dan 60.000 pagina's is te groot om te negeren. Wanneer je een financieel document OCR't voordat je het indexeert, vernietig je structurele lay-outsignalen — in welke kolom een getal verschijnt, of een bijschrift van een figuur de interpretatie van een tabel wijzigt — die enorm belangrijk blijken te zijn voor retrieval.

De generatiecijfers zijn eerlijk, maar moeilijk op zichzelf te interpreteren. De auteurs verklaren niet welk deel van de nauwkeurigheidskloof toe te schrijven is aan retrievalfouten versus generatiefouten. Gezien het feit dat de Recall@10 voor het Engels al 85,86% is, moet een aanzienlijk deel van de fouten aan de kant van de generatie liggen in plaats van aan de kant van de retrieval. Het kennen van die uitsplitsing zou verduidelijken of het knelpunt multimodale redenering is of iets fundamentelers over hoe MLLM's omgaan met financiële taal.

De evaluatieset van 1.394 QA-paren is klein voor de reikwijdte van de benchmark. Verdeeld over zeven categorieën en twee talen, hebben sommige segmenten ruim minder dan 200 voorbeelden. De statistische significantie van bevindingen op categorieniveau wordt impliciet gelaten. Dit is niet ongebruikelijk voor een benchmark-artikel, maar het betekent wel dat zorgvuldig geselecteerde vergelijkingen gemakkelijk te construeren zouden zijn.

Het citatie-evaluatieprotocol is een interessante bijdrage, maar een Pearson r = 0,68 met menselijke beoordelingen is niet sterk genoeg om automatische evaluatie te beschouwen als de absolute waarheid voor onderbouwing op blokniveau. De auteurs erkennen dit; toekomstig werk aan betere citatiemetrieken wordt expliciet aangegeven.

Waarom dit belangrijk is voor financiële AI​

Beancount werkt met platte tekst-grootboekbestanden, wat RAG op basis van alleen tekst verdedigbaar maakt voor het opvragen van eerdere transacties. Maar de bredere boekhoudkundige taak omvat documenten die uitdrukkelijk geen platte tekst zijn: bankafschriften in PDF, gescande facturen, afbeeldingen van bonnen, jaarverslagen met ingebedde tabellen en grafieken. Op het moment dat een Beancount-agent een grootboekboeking moet afstemmen met een brondocument — verifiëren of een bepaalde afschrijving overeenkomt met de factuur in het dossier — voert deze precies de taak uit die FinRAGBench-V benchmarkt.

De bevinding over citaten op blokniveau is het meest relevant voor deze use case. Als een agent een grootboekboeking moet rechtvaardigen door naar een specifiek regelitem in een PDF te wijzen, en het beste beschikbare systeem slechts 20–61% recall op blokniveau behaalt, dan is dat niet klaar voor een audit. Elke Beancount-pijplijn die gescande brondocumenten verwerkt, heeft een menselijke controle nodig totdat dit getal aanzienlijk verbetert.

De kloof in retrieval-modaliteit pleit ook sterk tegen puur tekstuele pijplijnen voor documentverwerking. Een afbeelding van een bon bevat lay-outinformatie — bedragvelden, namen van leveranciers, posities van regelitems — die door OCR wordt vernietigd. Die lay-outinformatie is precies wat een totaaltal op een regel onderscheidt van een belastingbedrag, en FinRAGBench-V laat zien dat multimodale retrievers dit benutten op manieren die tekst-retrievers niet kunnen.

Wat nu te lezen​

• ColPali: Efficient Document Retrieval with Vision Language Models — de voorganger van ColQwen2 die de visuele pagina-embedding-aanpak introduceerde waarop de beste retriever van FinRAGBench-V is gebouwd [arXiv:2407.01449, ECCV 2024]
• M3DocRAG: Multi-modal Retrieval is What You Need for Multi-page Multi-document Understanding — pakt visuele QA met meerdere documenten aan met een flexibel raamwerk dat enkelvoudige en meervoudige visuele redeneringen over pagina's heen afhandelt [arXiv:2411.04952]
• Benchmarking Temporal-Aware Multi-Modal RAG in Finance — een bijbehorende benchmark uit 2025 die de tijdgevoeligheid in financiële multimodale RAG evalueert, direct aanvullend op de categorie tijdgevoelige vragen van FinRAGBench-V [arXiv:2503.05185]

Het onderzoeksrapport​

EnterpriseArena is een 132-maanden (11 jaar) durende simulatie van middelenallocatie op CFO-niveau. Elke tijdstap staat voor één maand. De agent ontvangt gedeeltelijke observaties van de financiële gegevens van het bedrijf, geanonimiseerde zakelijke documenten en macro-economische signalen afkomstig van FRED, CBOE en S&P Global-data. De agent heeft een budget van 20 tool-aanroepen per maand, verdeeld over vier operaties — het verifiëren van de kaspositie, het beoordelen van financiële overzichten, het analyseren van marktomstandigheden en het projecteren van kasstromen — en moet kiezen uit drie acties: de boeken afsluiten (reconciliatie), financiering aanvragen (eigen of vreemd vermogen, met stochastische uitkomsten), of niets doen. De belangrijkste beperking is dat het kassaldo van het bedrijf op elk tijdstip niet-negatief moet blijven; een overtreding beëindigt de episode met een score van nul. Mits de agent overleeft, maximaliseert hij de uiteindelijke ondernemingswaarde volgens de scoreformule Rev_T × 5 + Cash_T − 5.000 × N_tools, waarbij overmatig gebruik van tools expliciet wordt bestraft.

Elf LLM's werden geëvalueerd, waaronder Gemini-3.1-Pro, Claude-Haiku-4.5, GPT-5.4, DeepSeek-V3.1, Llama-3.3-70B, Qwen3.5-397B en Qwen3.5-9B, naast een menselijke expert-baseline gevalideerd door twee financiële professionals met respectievelijk 8 en 14 jaar ervaring.

Belangrijkste inzichten​

• Overlevingspercentages variëren enorm tussen modellen: Qwen3.5-9B overleeft 80% van de runs, Gemini-3.1-Pro 50%, Claude-Haiku-4.5 en GLM-5 elk 20%, en GPT-5.4, DeepSeek-V3.1, Llama-3.3-70B, Mistral-Small-24B en Mixtral-8x7B elk 0%. Het algemene LLM-gemiddelde is 26%.
• Grotere modellen presteren niet betrouwbaarder dan kleinere: Qwen3.5-9B (9B parameters, 80% overleving, $78,8M eindwaardering) verslaat overtuigend Qwen3.5-397B (397B parameters, 20% overleving) en GPT-5.4 (0% overleving).
• De kloof met mensen is groot: de menselijke baseline behaalt 100% overleving en een eindwaardering van $152,2M ± $29,6M; het LLM-gemiddelde is $28,2M met 26% overleving.
• Boekafsluiting is het kritieke knelpunt: menselijke experts sluiten de boeken af (reconciliatie) in 94,3% van de tijdstappen; LLM's gemiddeld slechts in 19,3%. Dit is de actie die feitelijke financiële overzichten produceert en rationele vervolgbeslissingen mogelijk maakt.
• Informatie verzamelen zonder actie is dodelijk: Qwen3.5-397B gebruikt gedurende de simulatie veelvuldig tools voor marktanalyse en prognoses, maar sluit bijna nooit de boeken af (0,0% boekafsluitingspercentage) en vraagt bijna nooit om financiering, waardoor het sterft door een tekort aan liquide middelen ondanks het feit dat het "wist" wat er gebeurde.
• De boete op het tool-budget is van belang: de scoreformule straft agents die dwangmatig controleren in plaats van handelen, een beperking die de werkelijke opportuniteitskosten weerspiegelt.

Wat standhoudt — en wat niet​

Het ontwerp met een dubbele doelstelling — overleving als harde voorwaarde plus de eindwaardering — is een van de sterkste keuzes in recente benchmarks voor agents. Het weerspiegelt hoe echte CFO's daadwerkelijk te werk gaan: je kunt de groei niet optimaliseren als het geld op is. De anonimisering van kalenderdata en bedrijfsidentiteiten voorkomt dat modellen patronen herkennen op basis van onthouden historische resultaten, wat een wezenlijke methodologische verbetering is ten opzichte van financiële benchmarks die echte tickers en data gebruiken.

De taxonomie van foutmodi die de auteurs via casestudy's identificeren is geloofwaardig: GPT-5.4 behaalt een pass-rate van 99,1% (wat betekent dat het bij bijna elke tijdstap actie onderneemt door niets te doen), terwijl Qwen3.5-397B analyse verwart met actie. Dit zijn gedragsmatig verschillende foutmodi met verschillende oplossingen.

Waar ik minder van overtuigd ben: de stochastische macro-omgeving gebruikt Gaussiaanse ruis om marktschokken te benaderen, waarvan de auteurs zelf toegeven dat deze geen 'black swan'-gebeurtenissen of menselijke irrationaliteit kunnen repliceren. Het tool-budget van 20 aanroepen per maand is ook enigszins willekeurig — echte CFO's worden niet geconfronteerd met dit soort beperkingen in hun eigen geheugen, wat de vraag oproept of de benchmark financiële oordeelsvorming op de lange termijn meet, of eerder iets dat lijkt op RAG onder tijdsdruk. De structuur met één enkele agent is een andere expliciete beperking die de auteurs noemen: echte CFO's opereren binnen hiërarchieën van controllers, FP&A-analisten en treasury-teams, en het rapport doet geen poging dit te simuleren.

De bevinding dat de omvang van het model de overlevingskansen niet voorspelt, is opvallend en waarschijnlijk reëel, maar het mechanisme erachter wordt niet goed uitgelegd. De auteurs merken het op zonder volledig te ontleden of het een gebrek is aan het opvolgen van instructies, coherentie in een lange context of risicocalibratie.

Waarom dit belangrijk is voor financiële AI​

De boekafsluiting in EnterpriseArena is in feite de Beancount balance-bewering en de grootboekreconciliatiestap — het moment waarop de agent zich vastlegt op een feitelijk beeld van de financiële status voordat hij handelt. De bevinding dat LLM's dit in 80% van de gevallen overslaan, sluit direct aan op het write-back-veiligheidsprobleem: een agent die reconciliatie vermijdt voordat hij handelt, is een agent die handelt op basis van verouderde of gehallucineerde statussen. Voor Beancount-automatisering suggereert dit dat de reconciliatiestap verplicht en verifieerbaar moet zijn — niet optioneel — in elke agent-loop.

De horizon van 132 maanden is ook direct vergelijkbaar met grootboekbeheer over meerdere jaren. De bevinding dat aanhoudend situationeel bewustzijn na verloop van tijd afneemt, is dezelfde degradatie die we zouden verwachten bij een Beancount-agent die vijf jaar aan transactiegeschiedenis beheert: zelfs als de agent over alle data in de context beschikt, handelt hij er in maand 60 mogelijk niet meer coherent naar. Dit suggereert dat periodieke geforceerde reconciliatie-checkpoints — en niet alleen reactieve query's — noodzakelijk zijn in langlopende sessies met Beancount-agents.

De 'informatie-val' waar Qwen3.5-397B in trapt, is een nuttige waarschuwing voor ontwerpers: agents die zijn uitgerust met veel zoek-tools geven mogelijk de voorkeur aan zoeken boven actie, vooral wanneer de kosten van een foutieve actie (corruptie van het grootboek) hoog zijn. Beperkingen op het tool-budget, zoals EnterpriseArena die gebruikt, kunnen helpen om actiediscipline af te dwingen bij Beancount write-back-agents.

Wat nu te lezen​

• EcoGym (arXiv:2602.09514) — een aanvullende langetermijn-economiebenchmark over Vending-, Freelance- en Operation-omgevingen over meer dan 1.000 stappen; geen enkel model domineert in alle drie, wat suggereert dat de foutmodi in EnterpriseArena niet specifiek zijn voor één benchmarkontwerp.
• AFlow: Automating Agentic Workflow Generation (arXiv:2410.10762, ICLR 2025 oral) — herformuleert het ontwerp van workflows als een zoektocht in de code-ruimte met MCTS en LLM-feedback; als EnterpriseArena laat zien dat handmatig ontworpen agent-gedragingen falen, is AFlow de logische volgende stap voor het automatisch ontdekken van betere pipelines.
• ToolLLM: Facilitating Large Language Models to Master 16,000+ Real-world APIs (arXiv:2307.16789, ICLR 2024) — het fundamentele framework voor training en evaluatie van tool-gebruik; inzicht in hoe tool-aanroepend gedrag wordt aangeleerd in ToolLLM verduidelijkt of het vermijden van actie in EnterpriseArena een trainingsprobleem of een prompting-probleem is.

Het artikel​

Peijie Yu, Wei Liu, Yifan Yang en collega's van Alibaba presenteren WildToolBench (arXiv:2604.06185), een benchmark van 256 multi-turn dialoogscenario's met 1.024 taken die zijn afgeleid van authentieke patronen in gebruikersgedrag en zijn gebaseerd op ongeveer 1.600 publieke API's. Het kernargument is dat bestaande benchmarks verzadigd raken, niet omdat de modellen zo goed zijn, maar omdat de taken kunstmatig zijn. Echte gebruikers bundelen verzoeken, laten context weg die ze twee beurten geleden deelden, en wisselen af tussen het stellen van een toolvraag, koetjes en kalfjes, en het vragen om verduidelijking — soms binnen één enkel bericht. WildToolBench operationaliseert deze faalmodi in drie gestructureerde uitdagingscategorieën en meet zowel de nauwkeurigheid op taakniveau als de veel strengere sessienauwkeurigheid, die vereist dat alle vier de taken in een dialoog succesvol worden afgerond.

Kernpunten​

• Sessienauwkeurigheid zakt voor de meeste modellen naar enkele cijfers: Gemini-2.0-Flash-Thinking loopt voorop met 14,45% sessienauwkeurigheid, gevolgd door Claude-4-Sonnet met 12,50% en GPT-4o met 11,72%. Het voltooien van alle taken in een sessie van vier beurten is zo moeilijk dat zelfs een taaknauwkeurigheid van 60% resulteert in minder dan 15% sessienauwkeurigheid — een belasting door samengestelde waarschijnlijkheid op elke interactie.
• Compositionele orkestratie is het steilste struikelblok: Gemengde sequentieel-plus-parallelle tool-topologieën beperken de topmodellen tot 25% taaknauwkeurigheid, tegenover 54-62% voor puur parallelle of sequentiële ketens. Wanneer een taak een parallelle uitwaaiering vereist, gevolgd door een sequentiële samenvoeging, overstijgt het coördinatieprobleem wat elk huidig model betrouwbaar aankan.
• Verborgen intentie is een grotere kloof dan ooit tevoren is gemeten: WildToolBench zorgt ervoor dat 100% van de taken impliciete informatie of informatie uit eerdere beurten bevat; BFCL v3 haalt slechts 15,7%. Taken met afhankelijkheden over lange afstand — waarbij de ontbrekende informatie meer dan twee beurten terugligt — zijn het moeilijkste subtype, waarbij geen enkel model de 50% haalt, zelfs niet op taakniveau.
• Instructie-overgangen stapelen fouten op met een lineaire snelheid: Elke extra beleidswissel (tool-taak → chat → verduidelijking → tool-taak) verlaagt de nauwkeurigheid met ruwweg 5 tot 15 procentpunten. Bij drie overgangen verliezen de zwaarst getroffen modellen 30 punten. De auteurs noemen dit "self-conditioning": eerdere antwoorden beïnvloeden de interpretatie van de daaropvolgende instructies door het model op manieren die halverwege de sessie moeilijk te corrigeren zijn.
• Optimal Path Rate blijft onder de 43%: Zelfs wanneer modellen taken correct voltooien, verbruiken ze overtollige API-aanroepen. Claude-4-Sonnet behaalt de beste Optimal Path Rate met 42,74%, wat betekent dat de meerderheid van de correcte voltooiingen meer stappen vereist dan nodig — een directe kostenpost in latentie en tokens voor elk productiesysteem.
• Gespecialiseerde modellen voor toolgebruik presteren minder goed dan algemene 'frontier'-modellen: xLAM-2-70B en ToolACE2-8B laten beide foutpercentages voor verkeerde functienamen zien van meer dan 30%, slechter dan GPT-4o of Claude-4-Sonnet. Fine-tuning op nauwe corpora voor toolgebruik lijkt eerder broosheid dan robuustheid te creëren bij een verschuiving in distributie naar ongetemd gebruikersgedrag.

Wat standhoudt — en wat niet​

Het ontwerp van de benchmark is sterk op de punten die er het meest toe doen. Het onderscheid tussen taaknauwkeurigheid en sessienauwkeurigheid is exact juist: opstapelende faalmodi zijn wat echte implementaties de das omdoet, en het meeste eerdere werk rapporteert getallen op taakniveau die dit maskeren. De taxonomie van drie uitdagingen (compositionele orkestratie, verborgen intentie, instructie-overgangen) is goed onderbouwd en empirisch bewezen — de curves van prestatieverslechtering over de verschillende uitdagingstypen zijn reëel en opvallend.

Het zwakke punt is de schaal. 1.024 taken uit 256 scenario's is een geloofwaardig onderzoeksresultaat, maar mager voor een ranglijst die bedoeld is om 57 modellen in de loop van de tijd te volgen. De auteurs erkennen dit direct en maken melding van een geautomatiseerde schalingspipeline in toekomstig werk. Een ander punt is dat de bewering "gebaseerd op echte gebruikerslogs" veel gewicht moet dragen: de uiteindelijke taken zijn gedeeltelijk synthetisch, geconstrueerd door een multi-agent systeem op basis van bronpatronen en vervolgens geverifieerd door menselijke annotatoren. De claim is gefundeerd, maar de data is niet letterlijk "wild" — het is geïnspireerd op de praktijk. Dat is belangrijk voor hoe letterlijk je het plafond van 15% interpreteert; een deel van de kloof zou kunnen dichten als de generatiepipeline kunstmatige moeilijkheden introduceert die echte gebruikers in de praktijk niet vertonen.

Ik ben ook sceptisch over de analyse van instructie-overgangen als een architecturale claim. Het artikel schrijft dit toe aan een fundamentele beperking, maar de mismatch in trainingsdistributie tussen RLHF fine-tuning doelstellingen en multi-modale gebruikerssessies is de meer voor de hand liggende verklaring. Dat is oplosbaar, niet structureel.

Waarom dit belangrijk is voor financiële AI​

De drie faalmodi sluiten bijna perfect aan op hoe echte gebruikers communiceren met een Beancount write-back agent. Een gebruiker vraagt: "hoeveel heb ik vorige maand aan boodschappen uitgegeven, en voeg trouwens ook het bonnetje van de Whole Foods van vandaag toe" — dat is een compositionele taak gebundeld in één beurt. Ze vervolgen met: "maak er eigenlijk €47,23 van in plaats van €42, ik heb het opgezocht" — dat is een parametercorrectie die vereist dat de agent de sessiestatus bijhoudt. Vervolgens vragen ze: "is die categorie wel juist?" — dat is een verzoek om verduidelijking, en de agent moet de schrijfbewerking die hij net heeft voltooid niet opnieuw uitvoeren. Het plafond van 25% op gemengde sequentieel-plus-parallelle orkestratie en de daling van 30 punten door instructie-overgangen zijn precies de faalmodi die zich zouden manifesteren in een grootboek-agent die echte gebruikerssessies afhandelt.

De bevinding dat gespecialiseerde modellen voor toolgebruik minder goed presteren dan algemene frontier-modellen is bijzonder relevant. Als we zouden overwegen om een kleiner open model te finetunen op specifieke Beancount tool-calling voorbeelden — de voor de hand liggende zet om kosten te besparen — dan is WildToolBench een directe waarschuwing dat specialisatie ten koste kan gaan van de robuustheid tegenover de distributie van werkelijk gebruikersgedrag. De bevinding over de Optimal Path Rate is ook van belang: een agent die twee keer zoveel API-aanroepen gebruikt om een taak te voltooien is niet alleen inefficiënt; bij write-back operaties kunnen overbodige tussenliggende aanroepen het grootboek in een inconsistente tussentijdse staat achterlaten.

Wat nu te lezen​

• ToolLLM: Facilitating Large Language Models to Master 16000+ Real-world APIs (arXiv:2307.16789, ICLR 2024) — het fundamentele trainingsframework waar WildToolBench zich expliciet tegen afzet; het begrijpen van het synthetische evaluatie-ontwerp verduidelijkt wat live uitvoering precies toevoegt.
• τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains (arXiv:2406.12045) — het meest relevante eerdere werk over realistisch multi-turn toolgebruik; het vergelijken van τ-bench's retail- en luchtvaartdomeinen met de publieke API-dekking van WildToolBench laat zien hoezeer de uitdaging te generaliseren is.
• AFlow: Automating Agentic Workflow Generation (arXiv:2410.10762, ICLR 2025 oral) — als het probleem van instructie-overgangen kan worden opgelost door automatisch betere agent-workflows te ontdekken in plaats van trainingsdata op te schalen, dan is AFlow het meest geloofwaardige mechanisme om dit te doen.

Het artikel​

Geng, Cai, Wang, Koeppl, Nakov en Gurevych onderzoeken de opkomende literatuur over de betrouwbaarheidsschatting en kalibratie van LLM's voor taken variërend van meerkeuze-QA tot open-einde generatie en machinevertaling. Het kernprobleem: LLM's kunnen zowel uiterst nauwkeurig als volledig onbetrouwbaar zijn op manieren die van buitenaf moeilijk te onderscheiden zijn. Het overzicht organiseert de oplossingsruimte in twee hoofdtakken — white-box methoden die gebruikmaken van toegang tot interne modeltoestanden, en black-box methoden die het model als ondoorzichtig beschouwen — en maakt binnen elke tak verder onderscheid tussen het schatten van betrouwbaarheid en het achteraf kalibreren ervan.

Het artikel werd gepubliceerd op NAACL 2024 (pagina's 6577–6595), herzien in maart 2024 na een indiening in november 2023 door een team van de TU Darmstadt, MBZUAI en Mohamed bin Zayed University of AI.

Belangrijke ideeën​

• White-box betrouwbaarheid via logits: De eenvoudigste benadering maakt gebruik van waarschijnlijkheden op token-niveau of lengte-genormaliseerde log-likelihood als betrouwbaarheidssignaal. Deze methoden werken, maar kampen met een fundamentele ambiguïteit: een lage token-waarschijnlijkheid kan wijzen op een lage feitelijke betrouwbaarheid of simpelweg op een ongebruikelijke verwoording — het model kan onzeker zijn over de woordkeuze terwijl het zeker is over het onderliggende feit.

• Op consistentie gebaseerde black-box betrouwbaarheid (SelfCheckGPT): Manakul et al. (EMNLP 2023) samplen meerdere voltooiingen en scoren hun onderlinge consistentie met behulp van BERTScore, NLI of n-gram overlap. Geen logit-toegang nodig. Het belangrijkste inzicht: voor feiten die de LLM goed kent, convergeren herhaalde samples; voor gehallucineerde feiten lopen ze uiteen.

• Semantische entropie: Farquhar et al. (Nature, 2024) clusteren semantisch gelijkwaardige antwoorden alvorens de entropie te berekenen. Een LLM zou "Parijs" en "de Franse hoofdstad" anders kunnen verwoorden — ruwe token-entropie behandelt deze als afwijkend, semantische entropie niet. Dit is een kwalitatieve stap voorwaarts ten opzichte van consistentie op token-niveau die in het overzicht wordt gecontextualiseerd.

• Geverbaliseerde betrouwbaarheid is defect: Wanneer gevraagd wordt om een betrouwbaarheidspercentage te geven, vervallen modellen in overmoed. Empirisch werk (Groot et al., TrustNLP bij ACL 2024) toont aan dat GPT-3, GPT-3.5 en Vicuna allemaal een gemiddelde Expected Calibration Error (ECE) vertonen van meer dan 0,377 voor geverbaliseerde betrouwbaarheid, waarbij voorspellingen zich clusteren in het bereik van 90–100%, ongeacht de werkelijke nauwkeurigheid. Zelfs GPT-4 — het best gekalibreerde model dat is geëvalueerd — behaalt een AUROC van slechts ~62,7% bij het gebruik van geverbaliseerde betrouwbaarheid om correcte van onjuiste antwoorden te onderscheiden, nauwelijks boven kansniveau.

• Kalibratietechnieken variëren per taak: Voor classificatie pakken contextuele kalibratie (het aftrekken van class-prior bias geschat met een lege "[N/A]" prompt) en positie-debiasing (PriDE) bekende systematische vooroordelen aan. Voor generatie verfijnt Sequence Likelihood Calibration (SLiC) modellen op basis van gerangschikte voltooiingen. Temperature scaling — de eenvoudigste post-hoc oplossing — blijft concurrerend in veel omgevingen.

• Er bestaat geen uniforme benchmark: De meest vernietigende structurele observatie van het overzicht: er is geen enkele benchmark die betrouwbaarheidsschattingsmethoden over verschillende taken en domeinen heen beslaat. Dit maakt het bijna onmogelijk om methoden rigoureus te vergelijken. Het vakgebied vergelijkt appels met peren.

Wat houdt stand — en wat niet​

De taxonomie is solide. Het onderscheid tussen white-box en black-box is echt nuttig voor systeemontwerp, en de behandeling van op logits gebaseerde methoden is eerlijk over hun beperkingen — de auteurs merken direct op dat token-waarschijnlijkheid feitelijke betrouwbaarheid verwart met lexicale onzekerheid. Praktijkmensen onderschatten deze verwarring.

Waar het overzicht me frustreert: het is grotendeels beschrijvend. Er zijn bijna geen experimentele benchmarks die methoden rechtstreeks vergelijken, en de auteurs erkennen dit expliciet als een beperking. Ik blijf achter met een duidelijke kaart van de ontwerpruimte, maar zonder richtlijnen over welke methode te gebruiken voor een nieuwe taak.

De resultaten over geverbaliseerde betrouwbaarheid — GPT-4's AUROC van ~62,7% op zijn eigen uitgesproken betrouwbaarheid — zouden basiskennis moeten zijn voor iedereen die LLM's in productie neemt. Dat is het niet. Mensen sturen nog steeds prompts uit die vragen "op een schaal van 1–10, hoe zeker ben je?" en behandelen het antwoord als betekenisvol. Dat is het niet.

Het overzicht is ook summier over de RLHF-kalibratievraag: maakt post-training met menselijke feedback modellen beter of slechter gekalibreerd? Er is bewijs voor beide kanten, en het overzicht omzeilt dit grotendeels.

Waarom dit van belang is voor financiële AI​

ReDAct baseert zijn veiligheidsverhaal op een gekalibreerd onzekerheidssignaal van het goedkope model. Het overzicht maakt duidelijk hoe moeilijk dat eigenlijk is. Op logit gebaseerde signalen zijn beschikbaar in white-box omgevingen, maar verwarren lexicale en feitelijke onzekerheid. Op consistentie gebaseerde methoden werken in black-box scenario's, maar vereisen meerdere samples per beslissing — duur voor een high-throughput Beancount write-back-agent die een batch transactieboekingen verwerkt.

Het meest actiegerichte resultaat voor Bean Labs: semantische entropie clustert semantisch gelijkwaardige antwoorden voordat de consistentie wordt gescoord. Dit is precies wat van belang is voor grootboekmutaties, waarbij een model dezelfde debet/credit-relatie in meerdere syntactisch verschillende vormen kan uitdrukken. Een Beancount-agent zou semantische clustering moeten gebruiken over gesamplede voltooiingen van journaalposten — in plaats van ruwe variantie op token-niveau — om te detecteren wanneer het een rekeningnaam of bedrag hallucineert.

Het falen van de kalibratie bij geverbaliseerde betrouwbaarheid is een directe waarschuwing voor elke UI die "hoe betrouwbaar is de AI?" aan de gebruiker toont: vertrouw het getal dat het model produceert niet. Gebruik in plaats daarvan een externe kalibrator of een op consistentie gebaseerde methode, of toon het helemaal niet.

Wat nu te lezen​

• Farquhar et al., "Detecting hallucinations in large language models using semantic entropy," Nature, 2024 — de meest rigoureuze methode die uit dit overzichtskader voortkomt; de moeite waard om volledig te lezen in plaats van via de samenvatting in het overzicht.
• Manakul et al., "SelfCheckGPT: Zero-Resource Black-Box Hallucination Detection for Generative Large Language Models," EMNLP 2023 (arXiv:2303.08896) — de canonieke op consistentie gebaseerde methode; essentieel om te begrijpen voordat u enig black-box betrouwbaarheidssignaal inzet.
• Groot et al., "Overconfidence is Key: Verbalized Uncertainty Evaluation in Large Language and Vision-Language Models," TrustNLP bij ACL 2024 (arXiv:2405.02917) — de meest grondige empirische audit van hoe geverbaliseerde betrouwbaarheid faalt over verschillende modellen en taken heen.

Het onderzoeksartikel​

Saibo Geng, Hudson Cooper, Michał Moskal en collega's bij Microsoft Research introduceren JSONSchemaBench, een benchmark van 9.558 schema's afkomstig uit echte productiebronnen: GlaiveAI-functiesignaturen, GitHub-repositories gestratificeerd op complexiteit van triviaal tot ultra, Kubernetes API-configuraties, Snowplow event-analytics-schema's en de JSONSchemaStore-collectie. Ze evalueren zes beperkte decoderingsframeworks — Guidance, Outlines, Llamacpp, XGrammar, OpenAI Structured Outputs en Gemini — op drie assen: dekking (coverage, welk deel van de schema's het framework überhaupt aankan), efficiëntie (tokens-per-seconde overhead vergeleken met onbeperkte generatie) en kwaliteit (nauwkeurigheid van de daaropvolgende taak). Het evaluatierooster bevat ook de officiële JSON Schema Test Suite, die 45 functiecategorieën documenteert die elke conforme engine zou moeten ondersteunen.

De kernclaim is dat schemacomplexiteit de beslissende variabele is die capabele frameworks scheidt van kwetsbare, en dat geen enkel framework domineert op alle drie de assen.

Belangrijke inzichten​

• Dekking stort in onder schemacomplexiteit. Bij eenvoudige GlaiveAI-schema's scoren alle frameworks boven de 86%. Maar bij GitHub-Hard schema's — met nestingen op meerdere niveaus, recursieve definities en complexe patroonbeperkingen — daalt Guidance naar 41%, Llamacpp naar 39%, XGrammar naar 28% en Outlines naar een catastrofale 3%. OpenAI bereikt slechts 9% op GitHub-Hard, en Gemini produceert helemaal geen valide outputs bij schema's van gemiddelde complexiteit of hoger.
• Kubernetes legt een specifieke zwakte in XGrammar bloot. Ondanks de claims van XGrammar over snelheid, behaalt het slechts 7% dekking op Kubernetes-schema's. Dit komt waarschijnlijk doordat deze schema's afhankelijk zijn van contextafhankelijke patronen die de contextonafhankelijke precomputatie van XGrammar niet aankan. Dekking tegen een benchmark die Kubernetes-configs bevat, is niet optioneel voor productie-agents.
• Onder-beperking is gevaarlijker dan een compilatiefout. XGrammar vertoont 38 "under-constrained" fouten tegen de JSON Schema Test Suite — wat betekent dat het JSON genereert die het gedeclareerde schema schendt, terwijl het stilletjes succes rapporteert. Guidance heeft slechts 1 dergelijke fout. Voor een write-back agent wordt een compilatiefout opgemerkt tijdens de ontwerpfase; een onder-beperkte fout corrumpeert gegevens tijdens runtime zonder enig signaal.
• De "fast-forwarding" van Guidance levert een echte versnelling van 50% op. Wanneer er lange deterministische sequenties aanwezig zijn (bijv. veldnamen in een vaste objectstructuur), kan Guidance meerdere tokens per decoderingsstap vooruitspoelen. Op Llama-3.1-8B op een A100 draait Guidance op 6–9 ms per outputtoken, terwijl onbeperkte generatie op 15–16 ms draait. Outlines is met 30–46 ms langzamer dan onbeperkte generatie, grotendeels doordat de voorafgaande compilatie van de automaat 3–8 seconden per schema in beslag neemt.
• Beperkte decodering verbetert de nauwkeurigheid van redeneren enigszins. Op GSM8K (wiskunde) verhoogt Guidance de nauwkeurigheid van 80,1% (onbeperkt) naar 83,8%. Op Last Letter en Shuffle Objects liggen de winsten in de range van 1–3 punten. Dit spreekt de veelgehoorde vrees tegen dat het afdwingen van het JSON-formaat de kwaliteit van de antwoorden verslechtert — maar het effect is klein genoeg dat de keuze voor een formaat niet de drijfveer moet zijn voor frameworkselectie.
• Geen enkel framework dekt alle 45 JSON-schema functiecategorieën. Guidance dekt er 13, Llamacpp en XGrammar elk 1, en Outlines dekt er 0. De praktische implicatie is dat elk schema dat gebruikmaakt van if/then/else, unevaluatedProperties of recursieve $ref-definities onvoorspelbaar zal gedragen, afhankelijk van welke engine er onder de motorkap zit.

Wat standhoudt — en wat niet​

De sterkste bijdrage van de benchmark is de bronvermelding van de schema's. Eerdere evaluaties gebruikten speelgoedschema's of collecties uit één bron. Het opnemen van Kubernetes-configs naast functiesignaturen biedt de juiste soort "adversarial diversity". De gelaagdheid in complexiteit (van triviaal tot ultra) geeft professionals bovendien een ijkpunt: als je schema's lijken op GlaiveAI-functieaanroepen, zijn zowel XGrammar als Guidance prima; als ze lijken op Kubernetes-manifesten, worden je opties snel beperkt.

De belangrijkste zwakte is de "single-sample greedy" evaluatie. Het meten van dekking met slechts één generatie per schema onderschat de werkelijke capaciteit — een framework kan 20% van de tijd falen, maar slagen bij een herpoging. Het artikel erkent dit, maar rapporteert geen "temperature-sampled pass@k" getallen, wat cruciaal zou zijn voor productiesystemen die herpogingen doen bij falen.

De vergelijking mengt ook onvergelijkbare modellen. Open-source frameworks (Guidance, Outlines, Llamacpp, XGrammar) zijn getest op Llama-3.2-1B, terwijl OpenAI en Gemini hun eigen, niet-openbare modellen draaien. De dekking van 9% van OpenAI op GitHub-Hard kan net zo goed de capaciteit van het model weerspiegelen als de architectuur van de beperkte decodering. Een eerlijke vergelijking zou gecontroleerde toegang tot het model vereisen — iets wat de auteurs uiteraard niet kunnen afdwingen bij propriëtaire aanbieders.

Waarom dit belangrijk is voor finance AI​

Elke Beancount write-back agent genereert gestructureerde output. Als de agent Beancount-instructies genereert als JSON voordat deze worden geconverteerd naar .beancount-syntaxis, of als hij tools aanroept via JSON-schema's, is de betrouwbaarheid van die JSON-generatie geen detail — het is de kern van de zaak. Het FinTrace-artikel liet zien dat geavanceerde modellen moeite hebben met redeneren over tool-outputs; JSONSchemaBench onthult een ander probleem: nog voordat er geredeneerd wordt, kan de formatteringslaag stilletjes niet-conforme output genereren.

Het Kubernetes-resultaat is bijzonder veelzeggend voor Beancount. Grootboekschema's zijn geen platte verzamelingen van sleutel-waardeparen. Account-hiërarchieën, transactie-metadata en tag-structuren creëren geneste recursieve patronen die vergelijkbaar zijn met Kubernetes API-objecten. Een framework dat 7% scoort op Kubernetes is niet klaar voor complexe grootboekschema's, ongeacht hoe laag de overhead per token is.

De "under-constrained" foutmodus is degene waar ik wakker van zou liggen. Een Beancount-agent die XGrammar gebruikt, zou een transactie kunnen genereren die de interne validatiecontrole van het framework passeert, maar het daadwerkelijke schema schendt — en de agent zou geen reden hebben om het opnieuw te proberen. Stille corruptie is erger dan een zichtbare fout.

Wat je hierna kunt lezen​

• XGrammar (arXiv:2411.15100, Dong et al.) — het technische artikel achter een van de snelste geteste frameworks, waarin de splitsing tussen contextonafhankelijke en contextafhankelijke tokens wordt uitgelegd en waarom Kubernetes-schema's dit onder druk zetten.
• Grammar-Aligned Decoding / ASAp (NeurIPS 2024) — toont aan dat token-maskering bij beperkte decodering de kansverdeling van het model kan vervormen en stelt een gecorrigeerd sampling-algoritme voor; de theoretische basis voor kwaliteitszorgen die de benchmark slechts indirect meet.
• XGrammar-2 (arXiv:2601.04426) — een vervolg dat XGrammar uitbreidt naar dynamische schema's in agent-omgevingen waar het schema zelf verandert tijdens een sessie met meerdere beurten, direct relevant voor Beancount-agents die hun outputformaat aanpassen op basis van welke accounttypen actief zijn.

Het artikel​

Jie Zhu, Yimin Tian en collega's van het Alibaba Cloud Qwen DianJin-team, YINGMI Wealth Management en Soochow University presenteren FinMCP-Bench, een evaluatiepakket met 613 samples dat 10 categorieën van financiële scenario's en 33 subscenario's beslaat. De tools zijn niet gesimuleerd — 65 echte MCP-conforme financiële tool-servers ondersteunen de benchmark, afgeleid van daadwerkelijke productielogs van de Qieman APP financiële assistent. De auteurs categoriseren samples in drie types: 145 single-tool, 249 multi-tool en 219 multi-turn. Ze testen zes modellen: de Qwen3-familie met 4B, 30B en 235B parameters (allemaal met uitgebreid redeneren), plus DeepSeek-R1, GPT-OSS-20B en Seed-OSS-36B. De belangrijkste evaluatiemetrieken zijn Tool Precision, Tool Recall, Tool F1 en een Exact Match Rate (EMR) die vereist dat elke tool-aanroep in een reeks exact correct is.

Kernideeën​

• MCP als evaluatie-substraat: het gebruik van echte MCP-serverdefinities in plaats van synthetische API-schema's overbrugt een grote kloof tussen benchmark-evaluatie en waar agenten daadwerkelijk mee te maken krijgen in geïmplementeerde financiële systemen.
• Driedeling in moeilijkheidsgraad: single-tool, multi-tool en multi-turn samples zijn niet alleen kwantitatieve verschillen — ze leggen kwalitatief verschillende foutmodi bloot.
• Multi-turn instorting: het beste model (Qwen3-235B) behaalt 60% EMR op single-tool, 10,62% EMR op multi-tool en 3,08% EMR op multi-turn. De daling van single naar multi-turn is 20×.
• Tool F1 is vergevingsgezinder: hetzelfde model scoort 66,85%, 69,42% en 41,56% TF1 over de drie instellingen — wat aantoont dat modellen vaak de juiste tools kiezen, maar fouten maken bij de volgorde, parameterinstelling of het bijhouden van het gesprek.
• Recall wint van precisie bij single-tool: modellen hebben de neiging om tools vaker aan te roepen dan nodig bij onzekerheid, in plaats van te weinig, wat de veiligere foutmodus is voor financiële taken, maar nog steeds verspilde API-aanroepen en ruis in het redeneerspoor betekent.
• Niet-monotone schaling: Qwen3-30B presteert niet consistent beter dan Qwen3-4B over alle subscenario's, wat de aanname doorbreekt dat groter altijd wint voor multi-staps toolgebruik.

Wat standhoudt — en wat niet​

Het gebruik van echte productielogs als bron voor single-tool voorbeelden is de sterkste methodologische keuze hier. Het verankert de benchmark in daadwerkelijk gebruikersgedrag in plaats van door onderzoekers bedachte scenario's, wat zeldzaam is in de literatuur over financiële AI. De multi-tool en multi-turn samples zijn synthetisch uitgebreid met behulp van afhankelijkheidsgrafieken en rollenspel-prompts, wat redelijk is gezien de kosten van labeling, maar het introduceert een risico: het syntheseproces heeft de neiging om schonere, meer voorspelbare queries te produceren dan echte gebruikers schrijven. De 3,08% EMR op multi-turn is alarmerend, maar moet voorzichtig worden geïnterpreteerd — EMR vereist dat de volledige reeks exact correct is, dus één verkeerde tussenliggende tool-aanroep laat de hele taak mislukken. Dat is een strikte en aantoonbaar onrealistische productiestandaard; metrieken voor gedeeltelijke score zoals TF1 vertellen een genuanceerder verhaal.

Wat het artikel niet behandelt: er is geen analyse of de prestatiekloof primair een probleem is van input-begrip (het model interpreteert verkeerd wat de gebruiker wil), een probleem met de output-formattering (juiste intentie maar verkeerd geformuleerde tool-aanroep), of een redeneerprobleem (verkeerde tussenconclusies). Zonder die uitsplitsing is het moeilijk te weten waar technische inspanningen moeten worden geïnvesteerd. Het artikel evalueert modellen ook in isolatie; er is geen test of het toevoegen van een verificatie- of reflectiestap het multi-turn beeld verandert.

De benchmark is ook sterk verbonden met de specifieke 65 tools van Qieman, wat de overdraagbaarheid van resultaten naar andere financiële platforms met andere tools beperkt.

Waarom dit belangrijk is voor financiële AI​

FinMCP-Bench is de meest relevante gepubliceerde evaluatie voor wat een Beancount write-back agent daadwerkelijk zou doen: een verzoek van een gebruiker ontvangen, identificeren welke tool (of keten van tools) van toepassing is, deze in volgorde aanroepen en vervolgstappen afhandelen. De multi-turn EMR van 3,08% is een harde realiteitscheck. Een Beancount-agent die een meerstaps grootboekcorrectie beheert — bijvoorbeeld het herclassificeren van een set transacties over accounts binnen een datumbereik, vervolgens afstemmen en daarna een rapport genereren — is precies het soort multi-turn, multi-tool taak waar huidige modellen bijna universeel op falen volgens de standaarden van exacte overeenkomst.

De MCP-benadering is direct relevant: de Python-API van Beancount, de beanquery-interface en de REST-laag van Fava zouden allemaal als MCP-servers kunnen worden ingekapseld. FinMCP-Bench vertelt ons dat het protocol niet de bottleneck is — het redeneren over reeksen van tool-aanroepen is dat wel.

De bevinding dat tool-recall hoger is dan precisie (modellen roepen te veel aan) is ook belangrijk voor de veiligheid van write-backs: een agent die de tool voor grootboekmutatie aanroept wanneer alleen een leesactie nodig was, zou het grootboek geruisloos kunnen corrumperen. Evaluatiemetrieken met een focus op precisie, en niet op recall, zouden het primaire veiligheidssignaal moeten zijn voor write-back agenten.

Wat nu te lezen​

• JSONSchemaBench (arXiv:2501.10868) — evalueert de betrouwbaarheid van gestructureerde output over 10.000 JSON-schema's; behandelt direct of de fouten in de formattering van tool-aanroepen in FinMCP-Bench een probleem zijn van beperkt decoderen.
• ToolLLM (arXiv:2307.16789, ICLR 2024) — het fundamentele trainingsframework voor toolgebruik waartegen FinMCP-Bench zich positioneert; het begrijpen van de diepte-eerst zoekboom-exploratie verduidelijkt wat de productielog-methodologie van FinMCP-Bench toevoegt.
• WildToolBench (arXiv:2604.06185) — evalueert toolgebruik op echte gebruikersvragen in de praktijk; de bevinding dat geen enkel model een nauwkeurigheid van 15% overschrijdt bij onvoorspelbaar gebruikersgedrag vormt een aanvulling op de productielog-benadering van FinMCP-Bench.

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.

Het artikel​

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.

Het artikel​

OmniEval construeert een tweedimensionaal evaluatierooster: vijf taakklassen (extractieve QA, multi-hop redeneren, contrast-QA, long-form QA en conversationele QA) gekruist met 16 financiële onderwerpen (aandelenmarkten, investment banking, fondsen, schadeverzekeringen en andere). Het resultaat is een gestructureerde benchmark met 11,4k automatisch gegenereerde testvoorbeelden, 1,7k door mensen geannoteerde voorbeelden en een corpus voor het ophalen van 362k documenten, samengesteld uit zes Chinese financiële gegevensbronnen (BSCF-DB met 193k documenten, FinGLM met 55k, BAAI-Fin met 48k, officiële web-crawls, PDF's en financiële inhoud van Wikipedia). De benchmark bevat ook een fijnmazige LLM-evaluator — Qwen2.5-7B-Instruct getraind op 910 door mensen gelabelde instanties — die de kwaliteit van de generatie scoort op nauwkeurigheid, hallucinatie, volledigheid, benutting en numerieke nauwkeurigheid. Het artikel werd gepubliceerd tijdens EMNLP 2025.

Belangrijke ideeën​

• De automatisch gegenereerde testcases slaagden voor een menselijke acceptatiecontrole met 87,47%, wat betekent dat ongeveer 1 op de 8 gegenereerde instanties werd weggegooid — geen verwaarloosbaar foutenpercentage voor een benchmark.
• De beste retriever (GTE-Qwen2-1.5B) behaalde een MAP van 0,4370 en een MRR van 0,4491 op de automatisch gegenereerde set, wat betekent dat het hoogst gerangschikte tekstfragment minder dan de helft van de tijd correct is, zelfs met de sterkste geteste retriever.
• De nauwkeurigheid van de generatie (ACC) over alle retriever-LLM-combinaties varieerde van 0,3238 tot 0,4476 — de beste configuratie beantwoordt minder dan de helft van de vragen correct.
• Numerieke nauwkeurigheid (NAC) is de scherpste bevinding: 0,0659 tot 0,3595. Het beste systeem heeft financiële getallen in ongeveer 36% van de gevallen goed; het slechtste zit bijna op nul.
• De fijnmazige evaluator bereikte een overeenstemming van 74,4% met menselijke annotatie (κ = 0,6486), wat aanzienlijk beter is dan baselines die alleen met prompting werken (55–71%) — maar nog steeds één op de vier evaluaties niet in overeenstemming laat met het menselijk oordeel.
• Multi-hop redeneren en conversationele QA waren consequent de moeilijkste taakklassen.

Wat houdt stand — en wat niet​

Het ontwerp van de matrix-evaluatie is oprecht nuttig. Vorige financiële benchmarks (FinanceBench, FinQA, DocFinQA) behandelen evaluatie als één enkele as — meestal de nauwkeurigheid van het antwoord — en missen de structurele variatie in hoe RAG faalt. Weten dat een systeem goed scoort op extractieve QA maar slecht op multi-hop redeneren is actiegericht; weten dat het een bepaald algemeen gemiddelde scoort is dat niet. Het OmniEval-rooster maakt die variatie zichtbaar, en de bevinding dat prestaties inconsistent zijn over verschillende onderwerpen is precies het soort resultaat dat beoefenaars moeten zien voordat ze systemen implementeren.

Dat gezegd hebbende, zijn er echte beperkingen waar ik direct over wil zijn. Het corpus is overwegend Chinees: vijf van de zes gegevensbronnen zijn Chinese financiële gegevens (BSCF, FinGLM, BAAI-Fin), en de zesde is de Chinese Wikipedia. Het artikel rapporteert geen resultaten uitgesplitst naar taal — het rapporteert alleen geaggregeerde getallen. Dit maakt elke score in het artikel verdacht als claim over financiële RAG in het algemeen, in tegenstelling tot financiële RAG over Chinese tekst met op Chinees gespecialiseerde retrievers en LLM's (GTE-Qwen2-1.5B, Qwen2.5-72B, Yi15-34B). Engelstalige financiële gebruikers kunnen deze cijfers niet direct gebruiken.

De LLM-evaluator is getraind op 910 gelabelde instanties. Dat is mager. De menselijke overeenstemming van 74,4% bij κ = 0,6486 is verdedigbaar als startpunt, maar betekent dat het evaluatiekader zelf aanzienlijke ruis introduceert. Als de benchmark wordt gebruikt om systemen te vergelijken die slechts enkele procentpunten verschillen, zal de variantie van de evaluator het signaal overstemmen.

De automatische generatiepijplijn — GPT-4 produceert testvragen, mensen filteren bij 87,47% acceptatie — roept ook een vraag op over contaminatie die het artikel niet behandelt: door GPT-4 gegenereerde vragen kunnen de sterke punten van modellen uit de GPT-4-klasse bevoordelen op een manier die oudere of kleinere modellen systematisch benadeelt.

Waarom dit belangrijk is voor financiële AI​

De scores voor numerieke nauwkeurigheid zijn de getallen waar ik steeds naar terugkeer: 0,0659–0,3595. Als het best geteste RAG-systeem financiële getallen slechts 36% van de tijd goed krijgt in een gebenchmarkte evaluatie, dan zal elke Beancount-write-back-agent die bovenop een naïeve RAG-pijplijn is gebouwd, de grootboekgegevens corrumperen. Het formaat van Beancount is onvergeeflijk — een onjuist bedrag, datum of accountnaam produceert ofwel een parse-fout of een stille boekhoudfout die zich over boekjaren kan voortplanten. Deze benchmark geeft ons concreet bewijs dat RAG-retrieval en LLM-generatie nog niet betrouwbaar genoeg zijn voor directe schrijfacties naar het grootboek zonder een validatielaag.

De taakklasse-structuur sluit ook nauw aan op Beancount-use-cases. Extractieve QA komt overeen met eenvoudige balanscontroles. Multi-hop redeneren komt overeen met vragen als "wat is mijn netto-inkomen na belasting over Q1–Q3?". Conversationele QA komt overeen met een gebruiker die iteratief een reconciliatieverzoek verfijnt gedurende een sessie. De bevinding van OmniEval dat multi-hop- en conversationele taken het moeilijkst zijn, is precies het slechte nieuws voor het ontwerp van de Beancount-agent: de eenvoudige gevallen zijn bijna in orde; de realistische gevallen zijn waar het systeem uit elkaar valt.

Wat nu te lezen​

• ARES: An Automated Evaluation Framework for Retrieval-Augmented Generation (arXiv:2311.09476, NAACL 2025) — de dichtstbijzijnde analoog in het algemene domein voor de fijnafstemmingsmethode van de OmniEval-evaluator; het vergelijken van de ARES-methodologie met die van OmniEval zou verduidelijken of de ontwerpkeuzes van de LLM-evaluator principieel of ad-hoc zijn.
• RAGEval: Scenario-Specific RAG Evaluation Dataset Generation Framework (ACL 2025, aclanthology.org/2025.acl-long.418) — geautomatiseerde scenariogeneratie voor RAG-evaluatie; breidt de methode voor automatische generatie uit die OmniEval gebruikt en kan de bezorgdheid over contaminatie aanpakken.
• FinRAGBench-V: A Benchmark for Multimodal RAG with Visual Citation in the Financial Domain (arXiv:2505.17471) — breidt RAG-evaluatie uit naar multimodale financiële documenten (tabellen, grafieken); relevant omdat Beancount-gebruikers steeds vaker afbeeldingen van bonnen en PDF-afschriften hebben naast hun grootboeken in platte tekst.

Het artikel​

Het overzicht van Xu en Ding (arXiv:2409.01980) stelt voor om LLM-gebaseerde anomalie- en out-of-distribution (OOD) detectie te organiseren in twee hoofdklassen: LLM's voor Detectie, waarbij het model direct anomalieën identificeert, en LLM's voor Generatie, waarbij het model trainingsgegevens aanvult of verklaringen in natuurlijke taal produceert die een stroomafwaartse detector voeden. Elke klasse wordt verder onderverdeeld. Detectie splitst zich in op prompting gebaseerde methoden (bevroren of getunede LLM's die worden bevraagd met prompts in natuurlijke taal) en op contrast gebaseerde methoden (modellen uit de CLIP-familie die abnormaliteit scoren door beeldfragmenten te vergelijken met tekstbeschrijvingen). Generatie splitst zich in op augmentatie gerichte methoden (het genereren van pseudo-OOD-labels of synthetische minderheidssteekproeven) en op verklaring gerichte methoden (het produceren van rationele onderbouwingen in natuurlijke taal voor gemarkeerde gebeurtenissen).

De bijbehorende GitHub-leeslijst bevat ongeveer 39 artikelen: 24 over detectie, 10 over augmentatie en 5 over verklaring.

Belangrijkste ideeën​

• Op contrast gebaseerde methoden domineren beeldanomaliedetectie. WinCLIP behaalt 91,8% en 85,1% AUROC op zero-shot anomalieclassificatie en segmentatie op MVTec-AD zonder enige datasetspecifieke afstemming, wat concurrerend is met gesuperviseerde methoden die op die dataset zijn getraind.
• Bevroren LLM's stuiten op een modaliteitskloof bij niet-tekstuele gegevens. Het overzicht merkt expliciet op dat "het direct prompten van bevroren LLM's voor anomalie- of OOD-detectieresultaten over verschillende gegevenstypen vaak suboptimale prestaties oplevert vanwege de inherente modaliteitskloof tussen tekst en andere gegevensmodaliteiten."
• LoRA en adapter-tuning herstellen een groot deel van die kloof. Methoden zoals AnomalyGPT en AnomalyCLIP finetunen met parameterefficiënte technieken en presteren aanzienlijk beter dan hun bevroren tegenhangers.
• Generatie als augmentatie wordt onderbenut. Door BLIP-2 gegenereerde pseudo-OOD-labels op bijschriftniveau presteren beter dan alternatieven op woordniveau en beschrijvingsniveau bij OOD-detectie, wat suggereert dat rijkere tekstsupervisie belangrijk is, zelfs voor visuele taken.
• Verklaringsgerichte generatie is de nieuwste subcategorie. Systemen zoals Holmes-VAD en VAD-LLaMA gaan verder dan binaire vlaggen om onderbouwingen in natuurlijke taal te genereren voor afwijkende gebeurtenissen, voornamelijk in bewakingsvideo's.
• Tabelvormige gegevens zijn bijna afwezig. Het overzicht citeert één methode — "Tabular" door Li et al. (2024) — die tabelrijen omzet in tekstprompts en finetunet met LoRA, maar biedt geen vergelijkende cijfers.

Wat standhoudt — en wat niet​

De tweeklasse-taxonomie is oprecht helder en ik zal deze waarschijnlijk gebruiken om mijn eigen denken te structureren. Het onderscheid tussen detectie en generatie legt een reële architecturale splitsing vast: ofwel vraag je de LLM om direct te classificeren, ofwel gebruik je het om een beter trainingssignaal op te bouwen voor een traditionele detector.

Wat ik niet kan accepteren is de presentatie van het artikel als een breed overzicht van anomaliedetectie. De dekking is overweldigend geconcentreerd op industriële defectbeelden (MVTec-AD, VisA) en bewakingsvideo's (UCF-Crime, XD-Violence). Van de ongeveer 39 gecatalogiseerde artikelen behandelen bijna geen enkele tabelvormige of financiële gegevens. Tijdreeksen krijgen een paar citaten. Tabelvormige gegevens krijgen één zin. Dit is geen landschapskaart voor Bean Labs — het is een landschapskaart voor computer vision-onderzoekers die CLIP willen gebruiken voor defectdetectie.

De auteurs erkennen dat "ruimtegebrek gedetailleerde metrische samenvattingen verhindert", wat een beleefde manier is om te zeggen dat er geen vergelijkingstabellen zijn. Voor een overzichtsartikel is de afwezigheid van kwantitatieve synthese een aanzienlijk gemis. Lezers kunnen dit artikel niet gebruiken om te beslissen welk paradigma beter is voor hun use case zonder elk geciteerd artikel afzonderlijk op te zoeken.

De hallucinatie-uitdaging wordt vermeld als een open probleem, maar de behandeling is oppervlakkig — het benoemt het risico zonder te analyseren welke detectieparadigma's meer of minder vatbaar zijn, of hoe verklaringsgerichte generatie hallucinaties detecteerbaarder zou kunnen maken door menselijke beoordeling.

Waarom dit belangrijk is voor financiële AI​

Twee subcategorieën zijn relevant ondanks de focus op beelden. Ten eerste is de subcategorie verklaringsgerichte generatie precies wat Beancount-audit-agents nodig hebben: niet alleen een melding dat een journaalpost afwijkend is, maar een zin in natuurlijke taal die uitlegt waarom. Financiële auditors kunnen niet handelen op basis van een binaire output. Ten tweede is de bijna volledige stilte van het overzicht over tabelvormige anomaliedetectie op zichzelf informatief — het bevestigt dat de AnoLLM, CausalTAD en AD-LLM-lijn die ik heb gevolgd een grensgebied is in plaats van een platgetreden pad, en dat het ontwerpen van LLM-gebaseerde audit-tools voor Beancount-grootboeken het synthetiseren van inzichten uit visie-anomaliedetectie vereist die nog niet zijn overgebracht naar tabelvormige omgevingen.

De afweging tussen prompting en tuning is de meest actiegerichte bevinding: zero-shot prompting werkt als eerste benadering, maar lijdt onder de modaliteitskloof; op LoRA gebaseerde finetuning op representatieve gelabelde voorbeelden dicht de kloof. Voor een Beancount-implementatie met gelabelde anomalievoorbeelden uit historische grootboeken lijkt het pad van finetuning betrouwbaarder dan pure prompting.

Wat nu te lezen​

• "Advancing Anomaly Detection: Non-Semantic Financial Data Encoding with LLMs" (arXiv:2406.03614) — gebruikt LLM sentence-transformer embeddings op echte journaalposten in het grootboek; een directe brug van het raamwerk van dit overzicht naar de Beancount-tabelvormige use case.
• "Enhancing Anomaly Detection in Financial Markets with an LLM-based Multi-Agent Framework" (arXiv:2403.19735) — multi-agent pijplijn voor anomaliedetectie in marktgegevens; het multi-agent coördinatiepatroon kan worden overgedragen naar grootboekaudits.
• AnomalyGPT (arXiv:2308.15366) — gefinetuned LVLM voor industriële anomaliedetectie met lokalisatie op pixelniveau; het lezen hiervan verduidelijkt wat "LLM tuning voor detectie" architecturaal werkelijk betekent, wat het overzicht wel beschrijft maar niet uitlegt.

De paper​

Hsieh et al. beginnen bij een diagnostische observatie: LLM's — zelfs die getraind zijn op lange contexten — vertonen een hardnekkig U-vormig aandachtspatroon. Tokens aan het begin en aan het einde van de invoer krijgen onevenredig veel aandacht, ongeacht of ze relevant zijn, terwijl tokens in het midden systematisch ondergewaardeerd worden. De auteurs koppelen dit empirisch aan de verloren-in-het-midden-nauwkeurigheidsdip, in plaats van het als een afzonderlijk fenomeen te behandelen.

Hun oplossing is elegant in concept. Ze ontleden aandacht in twee additieve componenten: relevantie (wat we willen) en positionele bias (wat we niet willen). Om de bias-term te isoleren, sturen ze een "dummy"-document — niet-informatieve vulmateriaal — door dezelfde context op elke positie en registreren ze de resulterende aandachtsverdeling. Die aandacht voor het dummy-document benadert de pure positionele prior. Door deze af te trekken van de werkelijke aandachtsscores, blijft er een residu over dat de ware relevantie beter weerspiegelt:

Gekalibreerde aandacht = Attn(document, k) − Attn(dummy, k)

De herschaalde scores worden vervolgens gebruikt om opgehaalde documenten te herordenen of te herwegen vóór de uiteindelijke stap van antwoordgeneratie. Cruciaal is dat er geen training vereist is. De kalibratie wordt tijdens de inferentie toegepast op de laatste 16 decoderlagen en alle aandachtskoppen. De kosten zijn O(K) extra forward-passes, waarbij K het aantal opgehaalde documenten is — niet onbeduidend, maar wel voorspelbaar.

Kernideeën​

• De U-vormige aandachts-bias is intrinsiek aan de modelarchitectuur en blijft bestaan, zelfs in modellen die expliciet zijn getraind met doelstellingen voor lange context.
• Het doorgeven van een dummy (leeg/ruis) document door dezelfde ophaalcontext isoleert de positionele prior; het aftrekken ervan verwijdert bias zonder enige finetuning.
• Recall@3 op NaturalQuestion (K=20, referentiedocument in het midden geplaatst) springt van 20,52% naar 68,32% met kalibratie; bij K=10, van 36,38% naar 74,27%.
• De end-to-end QA-nauwkeurigheid verbetert met 6–15 procentpunten wanneer het referentiedocument zich midden in de context bevindt; verbeteringen houden stand in 22 van de 24 experimentele configuraties.
• De methode presteert beter dan zes vergelijkingsbasislijnen: standaard aandacht, query-generatie ranking, relevantie-generatie prompting, attention sorting (Peysakhovich & Lerer 2023), prompt herordening en LongLLMLingua-rk.
• De methode werd geëvalueerd op NaturalQuestion (2.655 echte zoekopdrachten over Wikipedia) and SynthWiki (990 synthetische, door GPT-4 gegenereerde items).

Wat standhoudt — en wat niet​

Het kernresultaat is opvallend en ik geloof het. Een Recall@3-gat van 20,52%→68,32% voor referentiedocumenten in het midden van de context is niet het soort getal dat bij nader inzien verdampt — het meet iets werkelijks over hoe aandacht wordt verdeeld. Het trainingsvrije ontwerp is een echt praktisch voordeel: je kunt dit bovenop elke bestaande RAG-pipeline plaatsen zonder de modelgewichten aan te raken.

Dat gezegd hebbende, heb ik enkele bedenkingen. Ten eerste gaat de "dummy-document" benadering ervan uit dat positionele bias ruwweg positie-scheidbaar en additief is — een lineaire decompositie waarvan de auteurs zelf aangeven dat deze potentieel te simplistisch is. Echte aandachts-bias kan op niet-lineaire manieren interageren met de inhoud. Ten tweede worden de O(K) extra forward-passes geprijsd als "acceptabel", maar ze worden nooit gebenchmarkt voor latentie of kosten. In een productiesysteem met K=20 resultaten draai je 21 forward-passes in plaats van 1 per zoekopdracht. Voor een Beancount-agent die honderden transacties sorteert, doet deze vermenigvuldiger ertoe.

Ten derde — en dit is de meest interessante beperking — merken de auteurs op dat positionele bias nuttig kan zijn voor bepaalde taken. Recency-bias (bias naar recentheid) zou er bijvoorbeeld voor kunnen zorgen dat een model recente grootboekmutaties correct zwaarder weegt dan oudere. Het lukraak verwijderen van bias zou taken kunnen schaden waarbij positie een geldig signaal is. Dit wordt erkend maar niet bestudeerd.

Ten slotte gebruiken de experimenten NaturalQuestion en een synthetische dataset. Financieel-specifieke documenten — dichte tabellen, meerjarige deponeringen, grootboekmutaties met een repetitieve structuur — verschillen sterk van open-domein Wikipedia-passages. De kalibratie zou op die distributies gevalideerd moeten worden voordat men kan claimen dat het zal werken voor financiële RAG.

Waarom dit belangrijk is voor financiële AI​

De directe verbinding is duidelijk: elke log sinds DocFinQA draait om hetzelfde probleem. Wanneer een Beancount-agent 20 relevante grootboekmutaties ophaalt om een vraag te beantwoorden als "reconcilieer maart tegen het bankafschrift", zullen mutaties uit het midden van het opgehaalde venster systematisch minder aandacht krijgen dan mutaties bovenaan en onderaan de context. Dat is geen fout bij het ophalen — het is een fout aan de kant van de generatie die met geen enkele verbetering in retrieval-ranking op te lossen is.

De gevonden-in-het-midden-kalibratie is een aannemelijke verzachting die geen hertraining van het onderliggende model vereist en rechtstreeks kan worden toegepast binnen de generatiestap van elke grootboek-QA-pipeline. De bezorgdheid over de O(K)-kosten is reëel maar beheersbaar — een venster van 20 documenten met een model van gemiddelde grootte valt nog steeds binnen praktische grenzen. Wat ik zou willen zien voordat ik het implementeer, is een validatie specifiek op Beancount-gestructureerde gegevens: helpt de positionele correctie uniform, of onderdrukt het onbedoeld het recentheidssignaal dat recente transacties betrouwbaarder maakt dan oude?

Het bredere principe — dat aandachtsmechanismen positionele priors coderen onafhankelijk van de relevantie van de inhoud, en dat die priors kunnen worden weggekalibreerd zonder hertraining — is er een om te onthouden. Het opent de deur naar vergelijkbare kalibraties voor andere biases: tokenfrequentie-bias, normalisatie van invoerlengte, en verbositeits-bias in generatie.

Wat nu te lezen​

• "Mitigate Position Bias in LLMs via Scaling a Single Hidden States Channel" (arXiv:2406.02536, ACL Findings 2025) — stelt voor om een enkele dimensie van de verborgen toestand te schalen in plaats van aandachtsscores af te trekken; de moeite waard om direct te vergelijken met de gevonden-in-het-midden benadering.
• "Large Language Models for Anomaly and Out-of-Distribution Detection: A Survey" (arXiv:2409.01980, NAACL 2025) — de volgende op de leeslijst; verbindt de AnoLLM-, CausalTAD- en AD-LLM-threads in een verenigde taxonomie.
• Liu et al., "Lost in the Middle: How Language Models Use Long Contexts" (arXiv:2307.03172, TACL 2023) — de oorspronkelijke diagnose waarop gevonden-in-het-midden reageert; essentiële achtergrondinformatie.

Het paper​

ReDAct (Reason-Defer-Act) bouwt voort op het ReAct-promptingparadigma en introduceert een agent-architectuur met twee modellen. Een klein, goedkoop model — Qwen3-80B, Llama3.3-70B, of Llama4-Maverick — handelt standaard elke stap af. Bij elke stap genereert het een redeneerspoor (reasoning trace) en vervolgens een actie. Het systeem meet de onzekerheid op tokenniveau over alleen de actie-generatiestap en vergelijkt deze met een gekalibreerde drempelwaarde. Als de onzekerheid die drempel overschrijdt, wordt de stap opnieuw uitgevoerd door een groot, duur model (GPT-5.2, Qwen3-235B, of Qwen3-480B); anders wordt de actie van het kleine model uitgevoerd.

De onzekerheidsmaten zijn informatietheoretisch en vereisen alleen log-kansen (log-probabilities) op tokenniveau: Sequence Probability (som van negatieve log-kansen), Perplexity (lengte-genormaliseerd) en Mean Token Entropy (gemiddelde entropie over tokenposities). De drempelwaarde wordt gekalibreerd op basis van een held-out set van rollouts van het kleine model, door de waarde te kiezen die een doelgericht aantal aanroepen naar het grote model per episode K produceert.

Belangrijke ideeën​

• Meet onzekerheid bij de actiestap, niet bij de redeneerstap. Een aanvullend experiment op 2.411 ALFWorld-stappen wees uit dat onzekerheid op redeneerniveau een zwak onderscheidend vermogen heeft tussen correcte en incorrecte stappen; perplexiteit op actieniveau heeft een meetbaar hogere ROC-AUC en PRR als voorspeller van correctheid.
• PPL-deferral met Qwen3-80B + GPT-5.2 behaalt 80,8% ± 1,1% op ALFWorld, wat hoger is dan GPT-5.2 alleen (78,3% ± 1,9%), terwijl het $16,25 kost tegenover $45,21 — ongeveer 64% goedkoper.
• ~15% van de stappen wordt gedelegeerd in de praktijk om een kalibratiedoel van ongeveer 10% te halen; het verschil ontstaat doordat mislukte (kortere) trajecten onevenredig veel bijdragen aan het budget voor deferral.
• Willekeurige deferral bij hetzelfde percentage scoort 77,0% — nog steeds beter dan alleen het kleine model (68,3%), maar slechter dan door UQ (uncertainty quantification) gestuurde deferral. Het onzekerheidssignaal doet er echt toe, niet alleen het feit dat het grote model vaker wordt aangeroepen.
• MiniGrid toont minder ruimte voor verbetering. Qwen3-80B + GPT-5.2 met PPL-deferral bereikt 95,0% tegenover 99,0% voor GPT-5.2 alleen. De kleinere taak-vocabulaire zorgt voor een harder plafond voor de deferral-aanpak wanneer het kleine model structureel ontoereikend is.
• Verdeling van deferral is taakafhankelijk. ALFWorld delegeert meer in latere stappen (langere promptgeschiedenis), terwijl MiniGrid een bimodaal patroon vertoont dat gekoppeld is aan de initiële positie van de agent. Dit betekent dat kalibratie met een vaste drempelwaarde beter generaliseert binnen een taakfamilie dan tussen verschillende taakfamilies.

Wat overeind blijft — en wat niet​

De kernbevinding op empirisch gebied is geloofwaardig: perplexiteit over de actiestring is een redelijke proxy voor de vraag of een bepaalde stap fout dreigt te gaan. De redeneer/actie-decompositie in ReAct biedt op natuurlijke wijze een helder punt om een onzekerheidssignaal aan te koppelen, en het aanvullende experiment voor correctheidsvoorspelling geeft een oprechte mechanistische rechtvaardiging voor de ontwerpkeuze.

Waar ik minder van overtuigd ben: het resultaat dat het grote model wordt overtroffen op ALFWorld. 80,8% ± 1,1% versus 78,3% ± 1,9% overlappen bij één standaarddeviatie. De auteurs schrijven dit toe aan complementaire krachten — het kleine model handelt routine-stappen af zonder de incidentele risico's die het grote model neemt — maar er is geen ablatie per stap om dit verhaal te verifiëren. Het zou evengoed ruis kunnen zijn.

De keuze van benchmarks is ook beperkt. ALFWorld en MiniGrid zijn op tekst gebaseerde huishoudsimulaties en grid-world navigatie — nauwe omgevingen waarin tool-calling, code-executie of het ophalen van meerdere documenten niet worden getest. Of onzekerheids-gekalibreerde deferral standhoudt in die rijkere contexten (de contexten die relevant zijn voor Beancount) blijft onbeantwoord. En de keuze voor GPT-5.2 als groot model maakt de kostencijfers moeilijk te reproduceren.

De kalibratieprocedure bevat een niet-geadresseerde circulariteit: de drempelwaarde wordt geselecteerd op dezelfde distributie als waarop deze is gekalibreerd, zonder validatie op een apart gehouden set. De auteurs erkennen de verschuiving in distributie tussen kalibratie (rollouts van het kleine model) en evaluatie (hybride rollouts), maar laten de robuustheid van de drempelwaarde over aan toekomstig werk.

Waarom dit belangrijk is voor finance AI​

Beancount write-back agenten staan voor precies dezelfde deferral-vraag bij elke transactie. Een routinematige boodschappenaankoop heeft categorisering nodig; een ongebruikelijke multi-leg valutaswap met een gedeeltelijk gematchte omschrijving heeft een mens nodig. De huidige praktijk is ofwel volledige automatisering (risicovol) of volledige menselijke beoordeling (duur). Het ReDAct-framework suggereert een werkbare middenweg: draai het goedkope model en escaleer wanneer de perplexiteit over de kandidaat-boeking een gekalibreerde drempelwaarde overschrijdt.

De financiële context voegt twee overwegingen toe die het paper niet behandelt. Ten eerste zou deferral hier vaak moeten betekenen: pauzeren en de gebruiker om hulp vragen, in plaats van een groter LLM aanroepen — de standaard voor correctheid van het grootboek is de intentie van de gebruiker, niet een benchmarkscore. Ten tweede is de onomkeerbaarheid van een definitieve Beancount-boeking groter dan een verkeerd geplaatst object in ALFWorld. Het kalibratiedoel K zou waarschijnlijk conservatief moeten worden afgestemd op een lagere precisie van het kleine model alvorens te delegeren, en niet andersom.

Het signaal van 64% kostenbesparing is de moeite waard om serieus te nemen, zelfs met deze kanttekeningen. Als een Beancount-agent een maand aan transacties verwerkt en slechts 15% van de categoriseringsbeslissingen het dure model nodig heeft, ziet de economie van het draaien van een capabele write-back agent er veel gunstiger uit.

Wat nu te lezen​

• KnowNo (Ren et al., 2023, CoRL): "Robots that ask for help: uncertainty alignment for large language model planners" — gebruikt conformale voorspelling (conformal prediction) om een dekking-garantie te kalibreren voor wanneer hulp moet worden gevraagd. ReDAct vergelijkt hier niet mee; het begrijpen van de afweging tussen conformale garanties en drempelkalibratie is essentieel alvorens een productiebenadering te kiezen. [arXiv:2307.01928]
• A Survey of Confidence Estimation and Calibration in Large Language Models (Guo et al. geüpdatet, NAACL 2024) — een systematische taxonomie van geverbaliseerd vertrouwen, op sampling gebaseerde methoden en post-hoc kalibratiemethoden; de theoretische achtergrond om te bepalen of perplexiteit de juiste onzekerheidsproxy is of dat gekalibreerde logit-schaling beter zou presteren. [arXiv:2311.08298]
• UALA: Uncertainty-Aware Language Agent (Han, Buntine, Shareghi) — past een structureel vergelijkbare onzekerheidsdrempel toe op de beslissing voor tool-aanroepen (een tool gebruiken vs. vertrouwen op modelkennis), waardoor het aantal tool-aanroepen met meer dan 50% wordt verminderd; de directe aanvulling op ReDAct voor de tool-gebruik-as van agent-onzekerheid. [https://uala-agent.github.io/]

Het artikel​

OpenHands (Wang et al., 2024; ICLR 2025) is een open-source platform voor het bouwen en evalueren van LLM-agents die fungeren als generalistische softwareontwikkelaars. Onder leiding van Xingyao Wang en Graham Neubig, met een team van 24 auteurs, stelt het artikel dat de meeste bestaande agent-frameworks ofwel te onderzoeksgericht zijn (hardgecodeerde taaklussen) of te productiegericht (closed-source of voor één enkel doel) om te dienen als gedeelde basis voor de onderzoeksgemeenschap. OpenHands probeert dit op te lossen door een gestandaardiseerde runtime, een zuivere agent-abstractie en 15 geïntegreerde evaluatie-benchmarks aan te bieden in één onder MIT gelicentieerde repo.

De runtime is een in Docker gesandboxte omgeving met een bash-shell, een Jupyter IPython-server en een door Playwright aangestuurde Chromium-browser. Agents communiceren via drie primaire actietypes: IPythonRunCellAction voor Python, CmdRunAction voor shell-commando's en BrowserInteractiveAction voor webnavigatie. Een primitief voor coördinatie tussen meerdere agents, AgentDelegateAction, stelt een hoofdagent in staat om gespecialiseerde sub-agents aan te sturen. De standaard backbone is CodeAct — oorspronkelijk gepubliceerd als een op zichzelf staand artikel dat betoogt dat code de ideale universele actieruimte is voor LLM-agents — en het platform wordt geleverd met verschillende agent-implementaties, waaronder een algemene CodeActAgent en een gespecialiseerde BrowsingAgent.

Belangrijke ideeën​

• Code als universele actieruimte: CodeAct consolideert alle agent-acties (bestandsbewerkingen, API-aanroepen, datatransformaties) in Python of bash, waardoor de LLM kan redeneren in hetzelfde medium waarin het het meest intensief is getraind. Dit omzeilt de kwetsbaarheid van JSON-schema's die vaak een probleem vormen bij agents die functies aanroepen.
• Gesandboxte Docker-runtime: elke agent draait in een geïsoleerde container, zodat agents vrijuit willekeurige code kunnen uitvoeren zonder de hostmachine in gevaar te brengen — een vereiste voor elke financiële productie-agent die echte inloggegevens toevertrouwd krijgt.
• 15 benchmarks in één omgeving: SWE-Bench Lite (codeherstel), HumanEvalFix (bugfixing), WebArena (webnavigatie), GPQA (redeneren op academisch niveau), GAIA (algemene probleemoplossing) en nog tien andere. Het samenbrengen van deze benchmarks voorkomt selectieve evaluatie (cherry-picking).
• CodeActAgent + claude-3.5-sonnet behaalt 26% op SWE-Bench Lite en 79,3% op HumanEvalFix; BrowsingAgent bereikt 15,5% op WebArena — competitieve zero-shot resultaten zonder enige taakspecifieke training.
• GAIA-prestaties: 32,1% met GPTSwarm, ver onder de menselijke baseline van 92% — consistent met elke andere benchmark voor algemene agents die een kloof van 60–70 punten laat zien tussen mens en agent.
• Schaal van de gemeenschap: 71,4K GitHub-sterren en meer dan 188 bijdragers op het moment van de ICLR-indiening; TheAgentCompany heeft OpenHands geadopteerd als evaluatieomgeving, wat het de de facto status van benchmark-infrastructuur geeft.

Wat standhoudt — en wat niet​

Het ontwerp van de gesandboxte runtime is degelijk technisch werk. Het isoleren van de uitvoering van de agent in Docker is de juiste standaardkeuze voor elk systeem dat later schrijftoegang kan krijgen tot echte financiële grootboeken, en het is oprecht nuttig dat de benchmarks op één plek staan in plaats van verspreid over incompatibele repo's.

De benchmark-dekking is echter meer ambitieus dan systematisch. De 15 benchmarks omvatten zeer uiteenlopende taaktypen en moeilijkheidsgraden zonder een duidelijk raamwerk voor hoe resultaten moeten worden geaggregeerd of vergeleken. Het rapporteren van 26% op SWE-Bench Lite naast 79,3% op HumanEvalFix in hetzelfde artikel riskeert de indruk te wekken dat dezelfde agent tegelijkertijd matig en uitstekend is — de taken zijn simpelweg niet vergelijkbaar. De auteurs bieden geen principiële methodologie voor aggregatie over meerdere benchmarks.

De CodeAct-aanname — dat code het juiste universele actieformaat is — wordt betwist. Het werkt goed voor ontwikkelingstaken, maar legt een Python/bash-tussenlaag op aan elke actie, wat latentie toevoegt en faalt wanneer de actiesemantiek niet duidelijk naar code vertaalt (ambigue instructies van de gebruiker, API's die alleen natuurlijke taal gebruiken). Het artikel voert geen benchmark uit tegen niet-code actieruimtes om aan te tonen dat het voordeel reëel is en niet wordt beïnvloed door de onderliggende LLM.

Misschien wel de belangrijkste kloof is de splitsing tussen evaluatie en implementatie. Het percentage van 26% op SWE-Bench komt voort uit een relatief schone, goed gespecificeerde benchmark. Verslagen uit de gemeenschap en discussies over GitHub-issues beschrijven consequent een veel lagere betrouwbaarheid bij ambigue of langdurige real-world taken — dezelfde foutmodus die TheAgentCompany documenteerde. Het artikel gaat niet in op hoe robuustheid gemeten of verbeterd kan worden bij realistische ruis in taakspecificaties.

Waarom dit belangrijk is voor financiële AI​

OpenHands is hetgeen dat het dichtst in de buurt komt van een gedeelde basis voor agents voor de gemeenschap. Als Bean Labs evaluatie-infrastructuur bouwt voor Beancount-agents, is de runtime-architectuur hier — Docker-sandbox, Python/bash-acties, inplugbare LLM-backends — de moeite waard om over te nemen in plaats van opnieuw op te bouwen. Het AgentDelegateAction-primitief vertaalt zich op natuurlijke wijze naar een pijplijn voor financiële agents waarbij een orkestrator op het hoogste niveau delegeert aan gespecialiseerde sub-agents: één voor het lezen van het grootboek, één voor het signaleren van anomalieën, één voor voorgestelde correcties die door een mens worden beoordeeld.

De cijfers van SWE-Bench en TheAgentCompany vormen samen een ontnuchterend uitgangspunt: zelfs de best beschikbare agents voltooien ongeveer 26–30% van de realistische, eenduidige softwaretaken. Automatisering van financiële grootboeken is moeilijker — transacties zijn vaak ambigu, de impact van fouten is groot en de intentie van de gebruiker is vaak onvolledig gespecificeerd. De juiste conclusie is niet dat agents er niet klaar voor zijn, maar dat de eerste productieve implementaties nauw gedefinieerde "write-once" workflows zullen zijn (categorisatievoorstellen, signalering van afstemmingen) in plaats van autonome grootboekbewerkingen in meerdere stappen.

Wat je nu kunt lezen​

• ReDAct: Uncertainty-Aware Deferral for LLM Agents (arXiv:2604.07036) — koppelt een goedkoop model aan een duur model en delegeert alleen naar het dure model wanneer de onzekerheid hoog is; adresseert direct hoe een agent in OpenHands-stijl moet beslissen wanneer een Beancount-correctie moet worden geëscaleerd naar menselijke beoordeling.
• FinTrace: Holistic Trajectory-Level Evaluation of LLM Tool Calling for Long-Horizon Financial Tasks (arXiv:2604.10015) — 800 door experts geannoteerde taakreeksen over 34 financiële scenario's; de evaluatiemethodologie die OpenHands mist voor financieel-specifiek gebruik van tools op de lange termijn.
• FinMCP-Bench: Benchmarking LLM Agents for Real-World Financial Tool Use under the Model Context Protocol (arXiv:2603.24943) — 613 voorbeelden over 65 echte MCP-financiële tools, direct relevant voor hoe een Beancount-agent gebouwd op de runtime van OpenHands geëvalueerd zou worden in een echte MCP-implementatie.

De paper​

Fin-RATE, gepubliceerd in februari 2026 door Yidong Jiang, Junrong Chen en collega's van Yale en samenwerkende instellingen, introduceert een benchmark die is opgebouwd uit 2.472 SEC-indieningen van 43 bedrijven in 36 sectoren over de periode 2020–2025. De benchmark organiseert 7.500 door experts gecureerde QA-paren in drie soorten taken die de workflows van professionele analisten weerspiegelen: DR-QA (detail en redenering binnen een enkele indiening), EC-QA (vergelijking tussen entiteiten van twee bedrijven onder een gedeeld onderwerp) en LT-QA (longitudinale tracking van hetzelfde bedrijf over verschillende rapportageperioden). Elk taaktype bevat 2.500 vragen. De evaluatie omvat 17 LLM's — closed-source modellen inclusief GPT-4.1 en GPT-5, open-source algemene modellen zoals DeepSeek-V3 en Llama-3.3-70B, en financieel gespecialiseerde modellen zoals Fin-R1, Fino1-14B, FinanceConnect-13B en TouchstoneGPT-7B. De scorebepaling maakt gebruik van een uniform LLM-as-Judge-framework met drie onafhankelijke rechters (GPT-5, DeepSeek-V3.2, Qwen3-235B) die elk antwoord beoordelen op correctheid en vijf analytische dimensies.

Kernideeën​

• Prestaties storten in naarmate de complexiteit van de taak toeneemt: de nauwkeurigheid daalt met 18,60% van DR-QA (één document) naar longitudinale LT-QA en met 14,35% van DR-QA naar EC-QA (meerdere entiteiten), gemiddeld over alle 17 modellen.
• GPT-5 met zoeken op het web presteert het best, maar de pieknauwkeurigheid ligt op slechts 43–44% voor alle drie de taaktypes — teleurstellend voor een benchmark die bedoeld is om de workflows van echte analisten te weerspiegelen.
• Fin-R1, het financieel gespecialiseerde redeneermodel, behaalt 57,48% op DR-QA, maar zakt weg naar 3,32% op EC-QA — een daling van 54 punten die de achteruitgang van elk algemeen model ver overstijgt.
• In RAG-omgevingen dalen de prestaties van alle modellen tot ver onder de 27%, vergeleken met prestaties op basis van 'gold-context' tot 57,48%; de retrieval-pijplijn, niet de LLM, is de beperkende factor.
• Het rapport introduceert een taxonomie van 13 fouttypen in vier categorieën: hallucinatie en tegenstrijdigheden, financieel-specifieke numerieke en semantische fouten, fouten in het begrijpen van de zoekopdracht/context en fouten op retrieval-niveau. Ontbrekend bewijs (Missing Evidence) is verantwoordelijk voor 75,44% van de fouten bij de EC-QA-taak onder RAG.
• Financieel gespecialiseerde modellen vertonen systematisch hogere hallucinatiepercentages dan algemene modellen bij complexe taken, ondanks een betere beheersing van financiële terminologie.

Wat overeind blijft — en wat niet​

De structuur met drie paden is werkelijk goed ontworpen. De meeste financiële benchmarks (FinQA, TAT-QA, FinanceBench) behandelen QA als een taak voor een enkel document. Fin-RATE is een van de eerste die expliciet de vergelijking tussen entiteiten en longitudinale tracking als hoofdtaken modelleert, en de resultaten leggen een fundamentele kloof bloot: huidige LLM's gaan redelijk om met QA over geïsoleerde publicaties, maar vallen uiteen zodra ze informatie over documenten, entiteiten of tijdsperioden heen moeten synthetiseren.

De instorting van Fin-R1 is de meest opvallende bevinding van het rapport en ik denk dat deze wordt ondergewaardeerd. Een op financiën afgestemd model dat uitblinkt in extractie uit één document, heeft zichzelf blijkbaar in een hoek getraind: het leerde sjablonen voor het beantwoorden binnen één document, niet redeneerstrategieën voor het relateren van entiteiten en tijdsperioden. Dit is een concrete waarschuwing tegen 'narrow domain' fine-tuning zonder expliciet toezicht op redeneren over meerdere documenten. Het model is waarschijnlijk overfit op het oppervlakkige patroon van "zoek het getal in de indiening" en heeft geen generalisatiepad naar "vergelijk dit getal met het equivalente getal in een andere indiening van een ander bedrijf."

Dat gezegd hebbende, zijn er methodologische zorgen die genoemd moeten worden. GPT-5 is tegelijkertijd een van de geëvalueerde modellen en een van de drie rechters die de antwoorden beoordelen. De auteurs gebruiken drie rechters om individuele bias te verminderen, wat helpt, maar de overlap tussen rechter en model bij het sterkste geëvalueerde model is ongemakkelijk. Het rapport meldt een hoge mate van overeenstemming tussen de rechters, maar kwantificeert niet apart welk deel van de GPT-5-antwoorden door GPT-5 zelf werd beoordeeld, noch of de door GPT-5 zelf beoordeelde scores systematisch verschillen van die van de andere twee rechters. Elke zelfevaluatie-bias zou het resultaat van het best presterende model in de studie opblazen.

De steekproef van 43 bedrijven is ook mager. De dekking van de soorten indieningen is prijzenswaardig breed (10-K, 10-Q, 8-K, 6-K, DEF 14A, en diverse S- en SC-series), maar dezelfde 43 bedrijven komen in alle taken voor. Modellen die de publicaties van deze bedrijven in de pre-training hebben gezien, hebben een niet-gekwantificeerd voordeel, en het rapport bevat geen contaminatie-analyse.

De bevinding over retrieval is belangrijk maar onvolledig. Het rapport stelt vast dat RAG-prestaties met ongeveer 30 punten dalen ten opzichte van de gold-context omdat de retrieval faalt. Maar het benchmarkt slechts één enkele retrieval-setup — het behandelt falende retrieval als een diagnose in plaats van als iets om systematisch te variëren. Een vervolgrapport dat verschillende retrieval-architecturen op Fin-RATE test, zou veel bruikbaarder zijn.

Waarom dit belangrijk is voor financiële AI​

Beancount-grootboekaudits vereisen precies de twee vaardigheden waarvan Fin-RATE onthult dat ze niet goed werken: longitudinale tracking (hoe heeft deze rekening zich over de boekjaren ontwikkeld?) en vergelijking tussen entiteiten (sluit de balans van deze dochteronderneming aan bij de geconsolideerde jaarrekening?). De daling van 18,60% in nauwkeurigheid bij temporele tracking is een concreet cijfer dat de verwachtingen moet bijstellen voor elke Beancount-agent die over meerdere rapportageperioden redeneert. Als grensverleggende modellen falen op 43% bij longitudinale SEC QA met gold-context, moet een Beancount-agent die door meerjarige grootboekgeschiedenissen navigeert, worden ontworpen met expliciete retrieval, temporele onderbouwing en menselijke escalatie — niet met end-to-end LLM-inferentie.

De bevinding over de dominantie van retrieval is vooral van belang voor de prioriteitsstelling bij systeemontwerp. Als de prestaties met gold-context bijna het dubbele zijn van de RAG-prestaties, ligt de juiste investering in betere chunking, selectie van fragmenten en retrieval — niet in een capabeler basis-LLM. Dit weerspiegelt wat DocFinQA vond voor SEC-indieningen met een lange context: de pijplijn rondom het model is de bottleneck.

De waarschuwing over Fin-R1 is ook direct van toepassing op de Beancount-use case. Fine-tuning op Beancount DSL-syntaxis en transactiepatronen kan een model opleveren dat het genereren van eenvoudige boekingen goed afhandelt, maar faalt bij de reconciliatie over meerdere rekeningen en perioden die een audit nuttig maakt. Specialisatie zonder training in redeneren over meerdere documenten is kwetsbaar op precies de manieren die Fin-RATE meet.

Wat je nu kunt lezen​

• Fin-R1 (arXiv:2503.16252) — om te begrijpen welke trainingsopzet leidde tot zulke broze prestaties over meerdere documenten, en of redeneren over meerdere documenten überhaupt de bedoeling was.
• FinTrace (arXiv:2604.10015) — evaluatie op trajectniveau van LLM-tool-aanroepen over 34 financiële taakcategorieën; vult de statische QA-weergave van Fin-RATE aan met een diagnose op procesniveau over waar modellen de juiste tools aanroepen maar niet over de resultaten kunnen redeneren.
• OpenHands (arXiv:2407.16741) — het open agent-platform dat ten grondslag ligt aan de TheAgentCompany-evaluaties; het begrijpen van de architectuur verduidelijkt welke baseline-agentcapaciteiten beschikbaar waren en welke tekortkomingen te wijten zijn aan de moeilijkheidsgraad van de taak in plaats van aan platformbeperkingen.

Het paper​

Chanyeol Choi, Jihoon Kwon en collega's bij een financieel AI-bedrijf presenteren een dataset van 5.703 door experts geannoteerde query–bewijs–antwoord-tripletten, afkomstig van een echte Q&A-dienst voor hedgefondsanalisten. De documenten zijn Form 10-K-deponeringen van 490 S&P 500-bedrijven, verzameld via SEC EDGAR. Wat FinDER onderscheidt van eerdere benchmarks is de query-kant: 89,86% van de queries bevat drie of meer domeinspecifieke afkortingen of acroniemen. In plaats van "Wat is de totale omzet van bedrijf X voor het boekjaar 2023?", zou een echte analist kunnen typen: "GOOGL 10-K FY23 revs breakdown by segment." De dataset werd gepubliceerd op de ICLR 2025 Workshop on Advances in Financial AI en verscheen later op ICAIF 2025.

Belangrijkste ideeën​

• Retrieval-recall is over de hele linie schokkend laag: E5-Mistral (de beste dense retriever) behaalt in totaal slechts 25,95% context recall; BM25 haalt 11,68%. De categorie "Financials" — de categorie die het meest relevant is voor boekhouding — is het moeilijkst: respectievelijk 15,84% en 6,42%.
• Alleen query-ambiguïteit kost al 8,2 precisiepunten: Bij het testen van E5-Mistral op 500 queries vergeleken de auteurs goedgevormde parafrases (33,9 precisie) met de echte afgekoorte queries (25,7 precisie). Het verschil is volledig toe te schrijven aan de verwerking van afkortingen/acroniemen, niet aan de complexiteit van de documenten.
• Retrieval-kwaliteit is de dominante bottleneck voor generatie: LLM's zonder context scoren bijna nul (9–10% correct); met de top-10 opgehaalde passages bereiken ze 29–34%; met perfecte "oracle"-context springen ze naar 60–68%. Dat gat van 35 punten tussen realistische en oracle-omstandigheden is groter dan het gat tussen open-source en frontier-modellen.
• Compositionele rekenkunde hapert zelfs met goede retrieval: Taken met berekeningen in meerdere stappen (compositionele queries) bereiken slechts ~20% correctheid over alle vier de modellen — Claude-3.7-Sonnet, GPT-o1, DeepSeek-R1-Distill en Qwen-QWQ — zelfs met de top-10 opgehaalde passages. GPT-o1 loopt voorop bij vermenigvuldigingstaken met 42,90%, maar zakt naar 27,78% bij delingen.
• LLM-reranking voegt een bescheiden maar consistente verbetering toe: Door modellen de top-10 E5-Mistral resultaten te laten herordenen (rerank) voordat ze antwoorden, behaalt Claude-3.7-Sonnet een F1 van 63,05 en GPT-o1 62,90. Deepseek-R1-Distill blijft achter op 60,01, ondanks sterke prestaties op het gebied van gestructureerd redeneren elders.
• Moeilijkheidsgraad per categorie is ongelijk: Risico-queries zijn het makkelijkst op te halen (E5-Mistral: 33,07 recall); Financials blijven het lastigst (15,84). Dit correleert met de query-structuur — risicotoelichtingen gebruiken natuurlijke taal, financiële tabellen gebruiken compacte numerieke notatie.

Wat overeind blijft — en wat niet​

De kernbijdrage is solide: dit is een echte query-distributie van werkende analisten, en het probleem met afkortingen is reëel. Elke benchmark die is opgebouwd uit Wikipedia of crowdsourcing in de stijl van FinQA mist dit. De evaluatiestructuur met drie niveaus — geen context, realistische retrieval, oracle-context — is het juiste ontwerp; het scheidt de retrieval-kwaliteit duidelijk van de redeneerkwaliteit en toont het resterende generatie-gat aan (nog steeds ~32–34% falen, zelfs met perfecte context bij kwalitatieve vragen).

Waar het paper het zwakst is, is de reproduceerbaarheid. Op het moment van publicatie was de dataset niet publiekelijk beschikbaar — de auteurs verklaarden dat ze "van plan zijn deze later publiekelijk vrij te geven." Dit is een aanzienlijk probleem voor een workshop-paper dat zichzelf presenteert als een evaluatiestandaard. Benchmarks die niet worden vrijgegeven, zijn geen benchmarks; het zijn casestudy's. Sindsdien is het verschenen op ICAIF 2025, dus een release kan zijn gevolgd, maar de arXiv-versie bevestigt dit niet.

De retrieval-evaluatie gebruikt ook slechts vier enkelstapsmodellen (BM25, GTE, mE5, E5-Mistral). Er is geen hybride retrieval, geen query-expansie, geen HyDE, geen herschrijfstap die specifiek gericht is op het afkortingsprobleem. Gezien het feit dat de auteurs het afkortingsgat nauwkeurig hebben gekarakteriseerd, is het verrassend dat ze de voor de hand liggende oplossing niet testen: de query uitbreiden ("GOOGL" → "Alphabet Inc.") vóór de retrieval. Dat experiment ontbreekt.

De resultaten van de generatie verdienen een nadere blik. De ~9–10% prestatie zonder context is geen nuttige ondergrens — het is in feite nul — maar het oracle-plafond van 60–68% is informatiever dan het lijkt. Zelfs met de juiste passage in de hand falen de beste modellen op ongeveer een derde van de kwalitatieve vragen en vier vijfde van de compositionele rekenkunde. Dat plafond is belangrijk: het betekent dat retrieval alleen het probleem niet kan oplossen.

Waarom dit belangrijk is voor financiële AI​

De query-distributie in FinDER komt goed overeen met hoe Beancount-gebruikers daadwerkelijk interageren met een grootboek-agent. Een gebruiker die zijn rekeningen al jaren bijhoudt, zal afgekoorte, contextuele queries typen — "AMZN kaart Q3 reimb?" in plaats van "Wat zijn de Amazon creditcard-terugbetalingen in Q3?". Standaard embedding-modellen zullen er niet in slagen de juiste boekingen op te halen omdat ze zijn getraind op schone natuurlijke taal. De daling van 8,2 punten in precisie van schone naar echte queries is waarschijnlijk conservatief voor een persoonlijk grootboekdomein, waar eigenzinnige afkortingen ("vve bijdr" voor "bijdrage vereniging van eigenaren") nog verder afliggen van trainingsdata dan de standaard SEC-afkortingen.

Het 25,95% context recall-plafond op E5-Mistral is een dwingende factor: elke Beancount RAG-pijplijn moet rekening houden met een grote fractie gemist bewijs. Eén implicatie is dat re-retrieval met een hoge recall (meerdere stappen, diverse query-formuleringen) belangrijker is dan het verhogen van de F1 in een enkele stap. Een andere is dat query-normalisatie — het koppelen van gebruikersafkortingen aan canonieke accountnamen vóór de retrieval — een expliciete voorverwerkingsstap moet zijn en niet aan het embedding-model moet worden overgelaten.

De 20% nauwkeurigheid van compositionele rekenkunde, zelfs met oracle-context, is een apart signaal: voor Beancount-rekentaken is de bottleneck de redenering, niet de retrieval. PAL-stijl offloading (het genereren van Python-rekenwerk in plaats van berekeningen in vrije tekst) blijft het juiste antwoord voor numerieke taken, ongeacht hoe goed de retrieval wordt.

Wat nu te lezen​

• Fin-RATE (arXiv:2602.07294) — de bijbehorende benchmark voor tracking over meerdere perioden op SEC-deponeringen; de nauwkeurigheid daalt met 18,60% bij temporele taken, wat direct aansluit op het Beancount-probleem van meerjarige grootboeken.
• IRCoT (arXiv:2212.10509, ACL 2023) — het verweven van retrieval met chain-of-thought redeneren; de meerstaps retrieval-structuur pakt direct de lage enkelstaps recall aan die FinDER blootlegt.
• Query-expansie met LLM's voor domeinspecifieke retrieval — er is nog geen enkel benchmark-paper dat dit goed dekt, maar het FinDER-afkortingsgat maakt dit tot een onderzoeksprioriteit van de eerste orde; zoeken naar "HyDE financial domain" en "query expansion SEC filings 2025" is het juiste startpunt.

Het artikel​

"Lost in the Middle: How Language Models Use Long Contexts" door Nelson F. Liu, Kevin Lin, John Hewitt, Ashwin Paranjape, Michele Bevilacqua, Fabio Petroni en Percy Liang voert twee gerichte experimenten uit: vraagbeantwoording over meerdere documenten via NaturalQuestions-Open (met 10, 20 en 30 opgehaalde documenten) en synthetische sleutel-waarde-retrieval (met 75, 140 en 300 paren). In elk experiment variëren ze systematisch waar het relevante document of sleutel-waarde-paar zich binnen de invoercontext bevindt — begin, midden of eind — terwijl de rest gelijk blijft. De bevinding is helder: de prestaties volgen een U-vormige curve met het dieptepunt in het midden van de context, en deze curve verschijnt bij elk getest model.

Kernideeën​

• De U-vorm is reëel en consistent. In de QA-setting met 20 documenten waren de prestaties op de eerste positie ongeveer 75%, degradeerden naar ongeveer 55% op positie 10, om vervolgens weer te herstellen naar ongeveer 72% op positie 20 — een gat van ~20 punten tussen de randen en het midden.
• Alle modellen volgen hetzelfde patroon. De geteste modellen variëren van gesloten naar open, van klein naar groot: GPT-3.5-Turbo (4K en 16K), GPT-4, Claude-1.3 (8K and 100K), MPT-30B-Instruct en LongChat-13B. De U-curve dook in elk model op, inclusief modellen die expliciet in de markt werden gezet vanwege hun uitgebreide contextvensters.
• Zelfs Claude-1.3-100K is niet immuun. De variant met een context van 100K gedroeg zich net als de andere. Een groot contextvenster betekent niet dat het model er daadwerkelijk gelijkmatige aandacht aan besteedt.
• De closed-book baseline vormt een ontnuchterende ondergrens. GPT-3.5-Turbo zonder enige documenten beantwoordde 56,1% van de NaturalQuestions correct; met 'oracle'-toegang tot enkel het relevante document steeg dit naar 88,3%. Maar op de slechtste middenposities in de setting met 20 documenten zakten de prestaties onder de closed-book baseline — wat betekent dat het toevoegen van meer context actief schadelijk was.
• Encoder-decoder modellen (Flan-T5-XXL, Flan-UL2) zijn robuuster binnen hun trainingslengte, maar vallen terug wanneer contexten deze overschrijden. Het architecturale verschil is van belang, maar beide degraderen nog steeds op schaal.
• De hoofdoorzaak is causale attention-masking. Elk token kan alleen aandacht besteden aan voorgaande tokens, waardoor posities aan het prille begin meer totale aandachtsgewicht over het model verzamelen dan posities in het midden. Recency-effecten trekken het einde van de context ook weer omhoog.

Wat blijft overeind — en wat niet​

Het experimentele ontwerp is hier bewonderenswaardig zuiver: positie is de enige variabele die wordt gemanipuleerd, de taken zijn standaard benchmarks en de bevinding wordt gerepliceerd over een breed scala aan modelfamilies. Ik heb geen enkel bezwaar tegen het kernresultaat.

Wat ik minder overtuigend vind, is de formulering van de sleutel-waarde-retrievaltaak als een zinvolle proxy voor de realiteit. UUID-naar-UUID-lookups testen of een model een onthouden string kan nazeggen, niet of het iets kan doen dat redeneren vereist. De U-curve verschijnt daar ook, wat de claim over positiebias versterkt, maar het betekent ook dat het artikel twee verschillende fenomenen op één hoop gooit: retrieval-nauwkeurigheid bij exact-match-taken en de kwaliteit van redeneren over relevante fragmenten. Ik zou willen weten of de U-vorm erger of beter wordt wanneer het relevante document meerstaps-inferentie vereist vóór het uiteindelijke antwoord, in plaats van alleen letterlijke reproductie.

Er is ook een hiaat dat de auteurs grotendeels erkennen maar niet dichten: ze testen nooit of instructie-fine-tuning of RLHF de positiegevoeligheid verandert, alleen of een groter contextvenster dat doet. Gezien het feit dat de hoofdoorzaak architecturaal is (causale masking), vermoed ik dat instructie-tuning het niet zal oplossen, maar het artikel bevestigt dit niet.

Waarom dit ertoe doet voor finance AI​

Dit artikel biedt de mechanistische verklaring voor een empirisch patroon dat ik voortdurend tegenkom. DocFinQA faalde bij lange SEC-deponeringen. IRCoT en FLARE halen beide meerdere fragmenten op en voegen deze samen voordat ze gaan redeneren. Elke RAG-pipeline die ik in een financiële context heb gezien, dumpt opgehaalde fragmenten sequentieel in de prompt en hoopt dat het model de juiste zal opmerken.

De implicatie voor Beancount-agents is concreet. Als een agent tien grootboekregels ophaalt als context, lopen de regels op posities 3–7 het hoogste risico om te worden genegeerd of omgeven door hallucinaties. Dit is geen retrieval-probleem — het is een presentatieprobleem. Er volgen twee reacties uit dit artikel: plaats de meest diagnostisch relevante regels ofwel vooraan (en achteraan), of voeg ze helemaal niet samen en redeneer over fragmenten één voor één.

De bevinding compliceert ook het narratief rondom long-context LLM's. Elk kwartaal kondigt een nieuw model een groter contextvenster aan. Dit artikel stelt dat een lang venster niet betekent wat u denkt dat het betekent als u de bewijslast er gelijkmatig over verdeelt. Een model met een context van 128K dat de relevante transactie begraaft op positie 60K, is slechter dan een model met een context van 4K dat precies het juiste fragment ophaalt.

Voor de terugschrijfveiligheid zijn de implicaties ongemakkelijk: als het model wordt gevraagd een grootboeksessie samen te vatten en de relevante beleidsregel "boek deze transactie niet" verschijnt in het midden van een lange systeemprompt, kan het model handelen alsof het die regel nooit heeft gelezen.

Wat nu te lezen​

• "Found in the Middle: How Language Models Use Long Contexts Better via Plug-and-Play Positional Encoding" (Zhang et al., arXiv:2403.04797) — stelt Multi-scale Positional Encoding (Ms-PoE) voor als een trainingsvrije oplossing via RoPE-schaling; claimt tot 3,8 punten verbetering op Zero-SCROLLS, wat de U-curve direct aanpakt.
• "Never Lost in the Middle: Mastering Long-Context Question Answering with Position-Agnostic Decompositional Training" (arXiv:2311.09198) — kiest de tegenovergestelde aanpak en traint het model om expliciet positie-agnostisch te zijn; de vergelijking met Ms-PoE verduidelijkt of fine-tuning of trucs tijdens de inferentie de betere hefboom zijn.
• "Mitigate Position Bias in Large Language Models via Scaling a Single Dimension" (arXiv:2406.02536) — identificeert de specifieke dimension van positionele verborgen toestanden die verantwoordelijk is voor de bias en schaalt deze zonder hertraining; de meest chirurgische oplossing die tot nu toe is voorgesteld, relevant voor het inzetten van bestaande modellen zonder hertraining.

Het artikel​

Tiankai Yang, Yi Nian en collega's van USC en Texas A&M introduceren AD-LLM (arXiv:2412.11142, ACL Findings 2025), de eerste benchmark die LLM's systematisch evalueert over drie paradigma's voor anomaliedetectie op NLP-datasets. De setting is 'one-class classification': trainingsdata bevat alleen normale voorbeelden, en het model moet anomalieën signaleren tijdens de testfase. De vijf datasets — AG News, BBC News, IMDB Reviews, N24 News en SMS Spam — zijn allemaal afgeleid van tekstclassificatietaken waarbij één categorie als afwijkend is aangemerkt. Het artikel zet twee LLM's, GPT-4o en Llama 3.1 8B Instruct, af tegen 18 traditionele unsupervised baselines die uiteenlopen van end-to-end methoden (CVDD, DATE) tot combinaties van embeddings en detectors in twee stappen (OpenAI-embeddings + LUNAR, LOF, Isolation Forest, etc.).

Belangrijkste inzichten​

• Zero-shot detectie werkt goed voor tekst. GPT-4o scoort een AUROC van 0,9293–0,9919 op de vijf datasets in de 'Normal+Anomaly' setting; Llama 3.1 bereikt 0,8612–0,9487. De beste traditionele baseline, OpenAI + LUNAR, scoort rond de 0,92 op AG News — GPT-4o evenaart of verslaat dit zonder enige training.
• Synthetische augmentatie helpt consistent, maar bescheiden. Door LLM's gegenereerde synthetische voorbeelden verbeteren de OpenAI + LUNAR-pipeline op alle vijf de datasets. Augmentatie van categoriebeschrijvingen verbetert ook de meeste baselines, hoewel de winst ongelijk verdeeld is — Llama 3.1 verbetert de AUROC met +0,07 op IMDB Reviews, maar elders zijn de resultaten kleiner.
• Modelselectie is de zwakke schakel. GPT-o1-preview adviseert modellen die op de meeste datasets beter presteren dan de gemiddelde baseline-prestaties, en benadert af en toe de beste methode (bijv. op IMDB Reviews en SMS Spam). Het identificeert echter nooit betrouwbaar de best presterende methode, en de auteurs erkennen dat de aanbevelingen gebaseerd zijn op simplistische inputs die datasetspecifieke statistieken missen.
• De kloof tussen open-source en propriëtair is reëel. Het AUROC-voordeel van GPT-4o ten opzichte van Llama 3.1 8B is 4 tot 13 punten, afhankelijk van de dataset. Dit gat is consistent met het patroon dat wordt gezien in publicaties over zero-shot tabulaire anomaliedetectie.
• NLP-anomaliedetectie mist nog steeds een definitieve benchmark. Vijf datasets, allemaal afgeleid van classificatie-corpora, is mager. Het bijbehorende NLP-ADBench-artikel (EMNLP Findings 2025) breidt dit uit naar acht datasets en 19 algoritmen, maar gebruikt nog steeds dezelfde constructie van 'semantische-categorie-als-anomalie', wat deze taken enigszins kunstmatig maakt.

Wat houdt stand — en wat niet​

De zero-shot bevindingen zijn geloofwaardig. Het gebruik van LLM's als scorers zonder finetuning op gelabelde anomaliedata is echt nuttig wanneer de anomalieklasse semantisch coherent is — een spambericht verschilt van een legitiem SMS-bericht op manieren die een goed getraind taalmodel begrijpt. De AUROC-cijfers zijn hoog en de vergelijking met sterke baselines op basis van OpenAI-embeddings is eerlijk.

De reikwijdte is echter beperkt op een manier die in het artikel wordt onderbelicht. In alle vijf de datasets zijn anomalieën gecodeerd als een andere onderwerpcategorie — spam versus legitieme SMS, nieuws van een uitgesloten uitgever versus in-distributie bronnen. Dit betekent dat de LLM in feite onderwerpclassificatie uitvoert, een taak waarvoor het expliciet is voorgetraind. De benchmark bevat geen semantische anomalieën binnen een enkele categorie (bijv. ongebruikelijke transacties binnen hetzelfde rekeningtype), wat precies het soort anomalie is dat van belang is voor financiële auditing.

De taken voor data-augmentatie en modelselectie worden geëvalueerd op dezelfde vijf datasets, waardoor het artikel uiteindelijk benchmarkt of LLM's iets andere varianten van hetzelfde beperkte probleem marginaal beter kunnen maken. De auteurs noemen eerlijk zes beperkingen — waaronder het feit dat ze slechts een subset van LLM's testen, few-shot en finetuning-regimes uitsluiten, en vertrouwen op simplistische inputs voor modelselectie — wat intellectueel integer is, maar ook aangeeft hoe voorlopig deze benchmark nog is.

Een resultaat dat de moeite waard is voor sceptici: de AUPRC-scores zijn aanzienlijk lager dan de AUROC voor beide modellen. Llama 3.1 op BBC News bereikt een AUROC van 0,8612 maar slechts een AUPRC van 0,3960, wat de onbalans tussen klassen in de one-class setup weerspiegelt. In auditcontexten waar hoge precisie vereist is, is AUPRC de betekenisvollere metriek, en hier is het beeld minder rooskleurig.

Waarom dit belangrijk is voor Finance AI​

De agenda van Bean Labs omvat twee use-cases voor anomaliedetectie: het in realtime onderscheppen van ongebruikelijke grootboekregels (tabulair, gestructureerd) en het signaleren van verdachte verhalende tekst in facturen, memo's of supporttickets (ongestructureerde NLP). AD-LLM is direct relevant voor de tweede casus en geeft ons een realistisch plafond: GPT-4o kan zero-shot anomalieën op onderwerpsniveau in tekst detecteren met een AUROC boven de 0,93 op schone, gebalanceerde datasets. Dat is een nuttige 'prior', maar anomalieën in grootboekomschrijvingen zijn subtieler — een factuurmemo die een routinedienst beschrijft maar toebehoort aan een leverancier die is gemarkeerd voor verdachte patronen, is geen probleem van onderwerpclassificatie. De benchmark biedt een startpunt, geen definitief antwoord.

De bevinding over modelselectie is apart interessant voor systeemontwerp. De droom om een LLM te vragen "welke anomaliedetector moet ik gebruiken voor deze dataset?" en een betrouwbaar antwoord te krijgen, komt nog niet uit. Dat betekent dat de keuze tussen finetuning in AnoLLM-stijl, causale prompting in CausalTAD-stijl of een klassieke embedding-methode nog steeds menselijk oordeel of systematische empirische evaluatie vereist — het kan niet worden gedelegeerd aan een LLM-adviseur.

Wat nu te lezen​

• NLP-ADBench (arXiv:2412.04784, EMNLP Findings 2025) — de begeleidende benchmark van dezelfde groep, die acht datasets en 19 algoritmen beslaat; biedt de bredere context van klassieke baselines die de op vijf datasets beperkte AD-LLM niet kan bieden.
• Large Language Models for Anomaly and Out-of-Distribution Detection: A Survey (arXiv:2409.01980, NAACL Findings 2025) — geeft een overzicht van het volledige landschap van op LLM gebaseerde AD-benaderingen voor tekst, afbeeldingen en tabulaire modaliteiten; vult de context in waarin AD-LLM zich bevindt ten opzichte van eerder werk.
• AnoLLM: Large Language Models for Tabular Anomaly Detection (OpenReview:7VkHffT5X2, ICLR 2025) — de tabulaire tegenhanger; het vergelijken van de op waarschijnlijkheid gebaseerde benadering met de op prompts gebaseerde zero-shot strategie van AD-LLM verduidelijkt welk paradigma geschikter is voor Beancount-grootboekmutaties.

Het paper​

Wang et al. stellen CausalTAD voor, een methode die bovenop LLM-anomaliedetectoren in AnoLLM-stijl werkt en één gerichte wijziging aanbrengt: in plaats van tabulaire rijen te serialiseren in een willekeurige of willekeurige kolomvolgorde, ontdekt het causale afhankelijkheden tussen kolommen en herordent het deze om die afhankelijkheden te respecteren voordat het LLM de rij leest.

Het paper heeft twee bewegende delen. Ten eerste een causaal-gestuurde kolomordening-module. De auteurs passen het COAT factor-extractie-framework aan: een LLM leest kolom-metadata en samples om semantische factoren op hoog niveau te extraheren (voor creditcardtransacties zou een factor zoals "Compensatie" de kolommen voor bedrag en verkoper kunnen omvatten). Uit deze factoren bouwen drie causale ontdekkingsalgoritmen — PC, LiNGAM en FCI — elk een gericht causaal diagram over de factoren. Het probleem van kolomherordening wordt dan een Lineair Ordeningsprobleem: vind de permutatie π die de som van de gewichten van de gerichte randen maximaliseert, zodat oorzaakkolommen vóór gevolgkolommen verschijnen in de geserialiseerde tekst. Omdat de LP veel bijna-optimale oplossingen heeft, samplen ze K ≈ 10 ordeningen binnen 90% van het optimum en middelen ze daarover.

Ten tweede een causaal-bewuste herwegingsmodule. Niet alle kolommen zijn even relevant. Een kolom die veel factoren beïnvloedt, krijgt een hoger gewicht αj = |M⁻¹(cj)|, het aantal factoren waaraan deze bijdraagt. De uiteindelijke anomaliescore is het gewogen gemiddelde van de negative log-likelihoods per kolom over de K ordeningen heen.

Belangrijkste ideeën​

• Kolomvolgorde is een niet-triviale inductieve bias voor autoregressieve LLM's: door een oorzaakkolom vóór de gevolgkolom te plaatsen, kan het model conditioneren op de juiste context bij het toekennen van waarschijnlijkheid aan het gevolg.
• Causale ontdekking op factorniveau (in plaats van op het niveau van de ruwe kolommen) stelt de methode in staat om tabellen met gemengde typen te verwerken, waar directe causale ontdekking tussen heterogene kolommen ruisgevoelig is.
• Op 6 benchmark-datasets met gemengde typen bereikt CausalTAD met SmolLM-135M een gemiddelde AUC-ROC van 0,834 tegenover 0,803 voor AnoLLM — een absolute verbetering van 3,1 punten met hetzelfde backbone-model.
• Specifiek op de Fake Job Posts-dataset scoort CausalTAD 0,873 tegenover 0,800 voor AnoLLM — een relatieve winst van 9,1%, wat groot genoeg is om van belang te zijn in een echt triagesysteem.
• Over 30 numerieke ODDS-benchmark-datasets behaalt CausalTAD de beste gemiddelde AUC-ROC, waarbij het consequent beter presteert dan klassieke baselines (Isolation Forest, ECOD, KNN) en deep learning-methoden (DeepSVDD, SLAD).
• Alle drie de causale ontdekkingsalgoritmen verslaan willekeurige ordening in de ablatie; LiNGAM presteert iets beter dan PC en FCI op de gemengde datasets.

Wat standhoudt — en wat niet​

De kernbewering — dat causale kolomvolgorde helpt — wordt goed onderbouwd. De ablatie is helder: het vervangen van willekeurige ordening door een van de drie causale ontdekkingsmethoden verbetert de resultaten op de Fake Job Posts-benchmark (van 0,832 naar 0,870–0,873), en de herweging op basis van het aantal factoren helpt verder in elke configuratie. Dat is een geloofwaardig verhaal.

Wat ik minder overtuigend vind, is de bootstrapping-aanname. Het causale diagram wordt geconstrueerd door een LLM te gebruiken om semantische factoren te extraheren uit precies die gegevens die het systeem moet analyseren. Als het LLM het domein verkeerd begrijpt — bijvoorbeeld bij een op maat gemaakt boekhoudsysteem met niet-standaard kolomnamen — zal de factorextractie onjuist zijn, en een slecht causaal diagram is aantoonbaar slechter dan een willekeurige volgorde omdat het een systematische bias introduceert. De auteurs erkennen dit risico ("leunt op de capaciteit van LLM's voor factorextractie"), maar toetsen de nauwkeurigheid van de factorextractie niet onafhankelijk.

Er is ook een probleem met rekenkundige overhead dat serieuzer is dan het paper suggereert. Het uitvoeren van drie causale ontdekkingsalgoritmen, het oplossen van een LP, het samplen van K ordeningen en vervolgens het uitvoeren van inferentie op K geserialiseerde versies van elk testpunt vermenigvuldigt de inferentiekosten met K. Voor een grootboek met miljoenen boekingen is dit van belang. Het paper merkt op dat "toekomstig werk zich kan richten op het verbeteren van de efficiëntie", maar biedt geen concrete profilering.

Tot slot zijn de 30 numerieke ODDS-datasets uitgebreid bestudeerd en aantoonbaar verzadigd voor dit soort methoden. Het betekenisvollere signaal zit in de 6 datasets met gemengde typen — die realistisch zijn voor de financiële sector — en de verbeteringen daar zijn, hoewel reëel, enigszins bescheiden in absolute termen.

Waarom dit belangrijk is voor finance AI​

Beancount-transacties hebben een oprechte causale structuur: het boekingsbedrag stuurt causaal de rekeningselectie aan, de rekening stuurt de tegenpartijverwachting aan, en de memo-tekst is causaal stroomafwaarts van alle drie. Willekeurige kolomserialisatie negeert dit, wat betekent dat een model in AnoLLM-stijl "memo: boodschappen | rekening: Kosten:Voeding | bedrag: $4200" net zo makkelijk ziet als de correct geordende versie.

CausalTAD biedt een principiële manier om "bedrag en rekening komen eerst" te coderen zonder dit als een regel hard te coderen. Voor de audit-agents van Bean Labs suggereert dit een praktische architecturale keuze: voordat je een batch transacties scoort op anomalieën, voer je één pass uit om het causale diagram over het kolomschema van het grootboek te ontdekken, en gebruik je die vaste volgorde voor alle daaropvolgende inferentie. De overhead wordt eenmalig op schema-niveau betaald, niet per transactie.

Het voorbeeld van creditcardfraudedetectie in het paper heeft in wezen dezelfde taakstructuur als anomaliedetectie in een grootboek: heterogene kenmerken, zeldzame labels en een causale volgorde die domeinexperts intuïtief kennen, maar die LLM's anders zouden negeren.

Wat nu te lezen​

• AD-LLM: Benchmarking Large Language Models for Anomaly Detection (arXiv:2412.11142, ACL Findings 2025) — de systematische benchmark over drie LLM-anomaliedetectie-paradigma's waar CausalTAD in past; het lezen hiervan geeft het volledige landschap in plaats van de enkele vergelijking tussen AnoLLM en CausalTAD.
• COAT: Boosting Large Language Model-Based In-Context Learning for Tabular Data (Liu et al., 2024) — het factor-extractie-framework dat CausalTAD aanpast; begrijpen hoe dit werkt verduidelijkt waar de kwaliteit van het causale diagram kan falen.
• Causal discovery in heterogeneous data: a survey — om de relatieve voordelen van PC vs LiNGAM vs FCI op tabulaire data met gemengde typen te begrijpen, aangezien het paper alle drie als uitwisselbaar behandelt, terwijl ze verschillende onafhankelijkheidsaannames doen.

Het artikel​

AnoLLM herformuleert tabelgebaseerde anomaliedetectie als een dichtheidsschatting van het taalmodel in plaats van een classificatie via prompts. In plaats van het LLM te vragen welke rijen er verdacht uitzien, finetunen de auteurs een vooraf getraind taalmodel op geserialiseerde "in-distribution" (normale) trainingsrijen, en scoren vervolgens elke testrij op basis van de negatieve log-likelihood (NLL) onder die geleerde verdeling. Een rij die totaal niet lijkt op de trainingsverdeling krijgt een hoge NLL — dat is de anomaliescore. Geen indexformaat, geen parsering van de output, geen fragiele extractie met regex.

De serialisatie zet elke tabelrij om naar een string in natuurlijke taal met kolomnamen en waarden. Voor kolommen met tekstwaarden wordt de NLL per kolom genormaliseerd om lengte-bias te voorkomen, waarbij langere beschrijvingen anders mechanisch hogere waarschijnlijkheidskosten zouden accumuleren. Voor numerieke en categorische kolommen wordt de ruwe NLL op token-niveau over het veld opgeteld. Het model wordt gefinetuned in een semi-gesuperviseerde setting — alleen als normaal gelabelde rijen worden gebruikt voor de training — gedurende maximaal 2.000 stappen met behulp van gedistribueerde GPU-training.

Kernideeën​

• Het probleem met het uitvoerformaat: eerdere benaderingen van indexvoorspelling vereisen dat LLM's op betrouwbare wijze indexen van afwijkende rijen uit een batch uitvoeren. Modellen uit de Llama-familie koppelen vaak verkeerde indexen aan waarden, genereren indexen buiten de batchgrootte of geven simpelweg alles aan als afwijkend. NLL omzeilt dit volledig.
• AnoLLM behaalt de beste prestaties op zes benchmark-datasets met gemengde kenmerktypen, waaronder fraudedetectie bij voertuigverzekeringen en e-commerce fraudedatasets van Kaggle.
• Op de 30 overwegend numerieke ODDS-benchmarkdatasets presteert AnoLLM op gelijke voet met de beste klassieke baselines — niet duidelijk beter, maar concurrerend.
• De NLL-per-kolom normalisatie voor tekstkenmerken is een kleine maar essentiële technische beslissing: zonder dit zou een transactiebeschrijving met dertig tokens de score domineren boven een bedrag van twee cijfers, wat de verkeerde inductieve bias is.
• De context van de trainingsbaseline: de zero-shot GPT-4 benadering (arXiv:2406.16308) behaalt een gemiddelde AUROC van 74,1 op ODDS, vergelijkbaar met ECOD (75,5) en KNN (70,7). Het voordeel van AnoLLM komt specifiek naar voren bij datasets waar tekstuele en categorische kenmerken een betekenisvol anomaliesignaal bevatten.

Wat standhoudt — en wat niet​

Het kernidee van NLL is solide. Het gebruik van een gefinetuned taalmodel als dichtheidsschatter over geserialiseerde rijen is principieel en het verwerkt op natuurlijke wijze de gezamenlijke verdeling van alle kolommen tegelijk — iets wat klassieke niet-gesuperviseerde detectoren die kolom voor kolom worden toegepast, niet zuiver kunnen doen. De oplossing voor indexvoorspelling is echt nuttig en de vergelijking met de zero-shot baseline is eerlijk.

Wat mij stoort, is de kloof tussen kosten en baten waarover het artikel te weinig rapporteert. AnoLLM vereist het finetunen en hosten van een LLM voor inferentie — een aanzienlijke investering in infrastructuur vergeleken met het fitten van ECOD of IsolationForest op een CPU in enkele seconden. Op de ODDS-benchmark (puur numeriek) is AnoLLM slechts "op gelijke voet", niet beter. De argumentatie voor AnoLLM ligt dus volledig in het regime van gemengde types, waarbij de zes geëvalueerde datasets afkomstig zijn van fraudedetectie op Kaggle. Zes datasets is een magere empirische basis voor een sterke aanbeveling, vooral omdat benchmark-datasets van Kaggle vaak schone schema's, vaste kolomsemantiek en bekende grondwaarheid hebben — zaken die bij productie-grootboekgegevens vaak ontbreken.

Het probleem met de kolomvolgorde blijft ook open. CausalTAD (arXiv:2602.07798) identificeerde dit gat onmiddellijk: AnoLLM serialiseert kolommen in een willekeurige volgorde en negeert de causale relaties tussen velden. Voor gestructureerde gegevens met bekende causale ketens — het type account beïnvloedt geldige transactiebereiken, die weer de verwachte tegenpartij beïnvloeden — is dit een reële beperking. CausalTAD frameert de herordening als een lineair ordeningsprobleem en rapporteert een consistente verbetering ten opzichte van AnoLLM over meer dan 30 datasets. Dat dit gat bestond en zo snel gevonden kon worden, suggereert dat het serialisatie-ontwerp van AnoLLM niet volledig doordacht was.

Er is ook een schaalvraag die het artikel niet beantwoordt: bij welk volume aan normale trainingsvoorbeelden wordt het finetunen van een LLM de moeite waard ten opzichte van bijvoorbeeld een tabelgebaseerd deep learning-model dat rechtstreeks op de numerieke kenmerken is getraind? Voor persoonlijke Beancount-grootboeken met een paar duizend regels kunnen de rekenkosten gemakkelijk opwegen tegen eventuele winst in nauwkeurigheid.

Waarom dit belangrijk is voor finance AI​

Beancount-grootboekvermeldingen zijn precies het soort gegevens van gemengde types waar AnoLLM zich op richt: bedragen (numeriek), accountnamen (gestructureerde tekst), begunstigde/omschrijving (vrije tekst), tags (categorisch), data (gestructureerd). Een enkele rij zoals 2024-03-15 * "AWS" "Cloudfactuur" Assets:Checking -2.400,00 EUR codeert tegelijkertijd informatie over al deze types. Klassieke anomaliedetectoren hebben het hier moeilijk omdat ze voor elk kolomtype een aparte behandeling nodig hebben en de correlaties tussen beide verliezen — het gezamenlijke patroon dat "AWS"-facturen in een bepaald bereik moeten liggen en op een specifiek account moeten vallen.

De NLL-benadering van AnoLLM zou in principe deze gezamenlijke patronen leren van normale historische vermeldingen en afwijkingen over elke kolomcombinatie signaleren. Dat is potentieel nuttiger dan op regels gebaseerde JET's of statistische tests op één kolom.

Dat gezegd hebbende, de beperking van dubbel boekhouden is structurele kennis die AnoLLM niet kan leren van geserialiseerde rijen alleen — debet moet gelijk zijn aan credit, account-hiërarchieën moeten worden gerespecteerd. Deze domeininvarianten zijn harde beperkingen, geen statistische regelmatigheden, en geen enkele hoeveelheid LLM-finetuning op historische rijen zal deze betrouwbaar afdwingen als de trainingsdata uitzonderingen of afrondingsfouten bevat. De juiste architectuur combineert waarschijnlijk de NLL-score van AnoLLM voor semantische anomalieën met expliciete regelcontroles voor structurele anomalieën.

Wat nu te lezen​

• CausalTAD (arXiv:2602.07798) — verbetert AnoLLM direct door causale kolomvolgorde toe te voegen; het meest directe vervolg om te evalueren.
• AD-LLM: Benchmarking Large Language Models for Anomaly Detection (arXiv:2412.11142, ACL Findings 2025) — biedt de systematische evaluatie over meerdere paradigma's die ontbreekt in artikelen over individuele methoden.
• "Language Models are Realistic Tabular Data Generators" (Borisov et al., arXiv:2210.06280, ICLR 2023) — het BE-GREAT model dat AnoLLM als baseline gebruikt; het begrijpen hiervan verduidelijkt wat AnoLLM daadwerkelijk verbetert buiten de indexvoorspelling.

Het paper​

Figueroa, Grundmann, Freidank, Löser en Nejdl evalueren vijf open-weight ~7B-modellen op een benchmark van twee taken die zij LLMFinLiteracy noemen. Taak 1 vraagt modellen om tekstuele scenario's te genereren die van invloed zouden zijn op een gegeven liquiditeitsratio (current, quick of cash ratio), uitgaande van een reëel kwartaalbalansoverzicht van een van de vijf DAX-genoteerde bedrijven (Airbus, Bayer, Deutsche Telekom, Mercedes-Benz, SAP). Taak 2 vraagt modellen om die scenario's te vertalen naar compileerbare Beancount-transacties. De Beancount-compiler dient als de grondwaarheid voor de syntaxiscontrole; menselijke domeinexperts evalueren de semantische correctheid. Het paper introduceert een foutentaxonomie van 12 klassen over de twee taken en maakt gebruik van een 9-staps chain-of-thought prompt die regels voor dubbel boekhouden, een input/output-voorbeeld en het echte bedrijfsbalansoverzicht in Beancount-formaat bevat. De geëvalueerde modellen — Llama-3-8B, Qwen-2-7B, Mistral-7B, CodeLlama-7B en CodeQwen-1.5-7B — werden allemaal lokaal gedraaid vanwege de gevoeligheid van financiële gegevens. Het corpus bevat in totaal 1.500 gegenereerde samples, waarvan 300 gestratificeerde items door menselijke experts zijn geëvalueerd.

Kernideeën​

• Slechts 7 van de 300 geëvalueerde scenario-transactieparen (2,3%) waren van begin tot eind volledig correct; zelfs wanneer alleen naar de drie modellen voor algemeen gebruik wordt gekeken, stijgt het percentage slechts naar 3,8%.
• De twee beste modellen, Qwen-2-7B en Mistral-7B, produceren slechts in 21,67% en 20,00% van de gevallen correcte scenario's, en in slechts 16,67% en 10,00% van de gevallen correct compileerbare transacties.
• Modellen gespecialiseerd in code (CodeLlama, CodeQwen) scoren 0% op beide taken; zij reageerden op het prompt-sjabloon met de letterlijke tekst "Processed — Waiting for next input", waarbij ze de taak volledig negeerden.
• Syntaxis is niet de bottleneck: geen enkel model produceerde een enkele syntaxis-fout. De tekortkomingen liggen volledig in het boekhoudkundig redeneren — balansfouten domineren bij Qwen-2 (61,67%) and Llama-3 (38,33%), terwijl Mistral meestal verwijst naar rekeningen die niet voorkomen in het verstrekte balansoverzicht (45% fouten door onbekende rekeningen).
• Een aanzienlijk deel van de transacties die succesvol compileren, is semantisch onjuist — de favoriete truc van het model is om het verminderen van een schuld "het verkopen van je schuld" te noemen, wat wel de cash verhoogt, maar om de verkeerde reden.
• GPT-4o, ingezet als geautomatiseerde beoordelaar, slaagde er niet in inconsistenties te signaleren in alle 10 onzinnige scenario's die het kreeg voorgelegd. Dit bevestigt dat LLM-zelfevaluatie geen betrouwbare kwaliteitscontrole is voor boekhoudkundige output.
• Modellen kopiëren grotendeels het input/output-voorbeeld in de prompt in plaats van te generaliseren: de 7 correcte paren lijken sterk op de structuur van de verstrekte voorbeeldtransactie.

Wat standhoudt — en wat niet​

De kern van de empirische bijdrage van dit paper is solide. De Beancount-compiler is een objectief, reproduceerbaar criterium voor correctheid, en het gebruik van echte bedrijfsbalansen in plaats van testdata verhoogt de ecologische validiteit. De hiërarchische foutentaxonomie is zorgvuldig ontworpen — door de evaluatie bij de eerste fout te stoppen, wordt voorkomen dat er "gedeeltelijke punten" worden gegeven voor waardeloze output.

Dat gezegd hebbende, zijn er duidelijke beperkingen die de auteurs grotendeels erkennen. Vijf ~7B open-weight modellen uit 2023–2024 vormen een smal segment van het landschap van mogelijkheden; GPT-4o en Claude werden uitgesloten om privacyredenen, wat begrijpelijk is, maar betekent dat het hoofdcijfer (2,3% correct) de huidige stand van de techniek onderschat. De formules voor financiële ratio's werden bewust uit de prompts weggelaten om inherente domeinkennis te testen — een methodologisch interessante keuze, maar een die de resultaten onvergelijkbaar maakt met elk systeem dat redelijkerwijs formulestructuur zou bevatten. En 300 door mensen geëvalueerde samples over vijf modellen, drie ratio's en vijf bedrijven is bescheiden; de cellen per model per ratio zijn te klein (12 samples) om sterke conclusies te trekken over de variantie.

Het meest interessante methodologische hiaat is de afwezigheid van enig iteratief of op feedback gebaseerd protocol. Geen tool-calling, geen zelfcorrectie, geen feedbackloop met de compiler — alleen een eenmalige generatie. Gezien het feit dat CRITIC (LOG-012) en gerelateerd werk laten zien dat interactieve verfijning met tools de nauwkeurigheid aanzienlijk verbetert bij taken met verifieerbare output, zou een experiment met een Beancount-compiler-in-the-loop veel informatiever zijn geweest over de inzetbaarheid.

Waarom dit belangrijk is voor financiële AI​

Elke ontwerpbeslissing voor de Bean Labs write-back agent rust op aannames over wat LLM's kunnen doen met Beancount DSL. Dit paper is het eerste empirische ankerpunt. De belangrijkste bevindingen zijn ontnuchterend, maar ook op een nuttige manier te interpreteren.

Ten eerste zijn de foutvormen specifiek, niet willekeurig. Balansfouten en onbekende rekeningen zijn de twee dominante problemen, en beide zijn aan te pakken met een compiler-in-the-loop feedbackloop: de Beancount-compiler vertelt je precies welke rekening onbekend is en of de transactie in balans is. Een agent-architectuur die itereert op compiler-output — in plaats van eenmalig te genereren en te stoppen — zou de one-shot resultaten hier aanzienlijk moeten overtreffen. Ten tweede is de syntaxis geen probleem. Modellen hebben de oppervlaktegrammatica van Beancount duidelijk geleerd; ze kunnen alleen de financiële intentie niet betrouwbaar vertalen naar correcte rekeningmutaties. Dat onderscheid is belangrijk voor de vraag waar te investeren in prompting en fine-tuning. Ten derde verhoogt de bevinding dat GPT-4o de boekhoudkundige kwaliteit niet automatisch kan evalueren de lat voor elk geautomatiseerd verificatiesysteem: je hebt de compiler nodig, plus steekproeven door domeinexperts, niet een LLM-criticus.

Het paper bevestigt ook iets wat ik al vermoedde op basis van het werk aan anomaliedetectie (LOG-049): LLM's die financiële transacties verwerken, zijn te snel geneigd om te compileren en in te dienen. De categorie "Incorrect | Compiles" — transacties die de syntaxiscontrole passeren maar semantisch fout zijn — is precies de foutvorm die een veiligheidswaarborg voor write-back moet opvangen. Een transactie kan perfect in balans zijn en toch omzet boeken als een vermindering van passiva, wat door een puur syntactische controle niet zou worden opgemerkt.

Wat nu te lezen​

• AnoLLM: Large Language Models for Tabular Anomaly Detection (OpenReview:7VkHffT5X2, ICLR 2025) — anomaliescores op basis van waarschijnlijkheid als alternatief voor de batch-detectiebenadering; combineert natuurlijk met een Beancount-compilersignaal om structureel geldige maar statistisch afwijkende invoer te markeren.
• ReDAct: Uncertainty-Aware Deferral for LLM Agents (arXiv:2604.07036) — stuurt beslissingen met een laag vertrouwen door naar een groter model of een mens; behandelt direct de vraag wanneer een Beancount write-back agent de beslissing moet overlaten aan een menselijke controle in plaats van verder te gaan na een compiler-feedbackloop.
• CRITIC: Large Language Models Can Self-Correct with Tool-Interactive Critiquing (arXiv:2305.11738, ICLR 2024) — het meest relevante bestaande werk voor het bouwen van een compiler-in-the-loop correctie-agent bovenop de architectuur die dit paper evalueert.