Kunnen LLM's redeneren over tabelgegevens? Wat vier benchmarks ons vertellen over Finance AI
Tabellen zijn hoe accountants denken. Een Beancount-grootboek is in wezen een tabel — rekeningen als rijen, datums en bedragen als kolommen, beweringen (assertions) als beperkingen over cellen heen. Dus toen ik me begon af te vragen of LLM's autonome financiële agenten kunnen aandrijven, stuitte ik steeds op dezelfde voorafgaande vraag: kunnen ze überhaupt betrouwbaar een tabel lezen? De literatuur hierover is vernietigender dan ik had verwacht.
Het artikel
Fang et al. publiceerden "Large Language Models(LLMs) on Tabular Data: Prediction, Generation, and Understanding — A Survey" in TMLR 2024 (arXiv:2402.17944). Het is een taxonomie van 41 pagina's die drie domeinen bestrijkt: het voorspellen van gestructureerde uitkomsten op basis van tabelkenmerken, het genereren van synthetische tabelgegevens en het begrijpen van tabellen goed genoeg om er vragen over te beantwoorden. Het begripssegment — het beantwoorden van tabelvragen (TableQA), feitverificatie en structureel redeneren — is waar het meest relevante werk voor finance AI zich bevindt.
Het artikel dat ik daarnaast las, "Table Meets LLM: Can Large Language Models Understand Structured Table Data?" door Sui et al. (WSDM 2024, arXiv:2305.13062), hanteert een meer gecontroleerde aanpak: ze definiëren een Structural Understanding Capability (SUC) benchmark met zeven specifieke taken — tabelpartitionering, grootte-detectie, detectie van samengevoegde cellen, cel-opzoeken, omgekeerd opzoeken, kolom-ophalen en rij-ophalen — en testen GPT-3.5 en GPT-4 rechtstreeks. Geen redeneerketens, geen retrieval-trucs. Gewoon: kan het model doen wat we vragen?
Kernpunten
- De formaat-kloof is reëel en verrassend groot. Op de SUC-benchmark presteert HTML-serialisatie over het algemeen ongeveer 6,76% beter dan het 'natuurlijke taal met scheidingstekens'-formaat. De rangorde — HTML > XML > JSON > Markdown > NL+Sep — blijft consistent over alle taken. Beancount-bestanden zitten dichter bij de natuurlijke taal-kant van dit spectrum, wat een waarschuwingssignaal is.
- Cel-opzoeken is verrassend moeilijk. GPT-3.5 behaalt slechts 44% nauwkeurigheid bij direct cel-opzoeken (vind de waarde op rij X, kolom Y). GPT-4 bereikt 73,34% op dezelfde taak. Voor een deterministische operatie die een spreadsheet-formule in microseconden afhandelt, is een gat van 26 procentpunten tussen modellen alarmerend.
- Few-shot voorbeelden zijn essentieel. Het verwijderen van 1-shot voorbeelden uit de SUC-prompts veroorzaakte een daling van 30,38% in de algehele nauwkeurigheid over alle taken. Het structurele begrip van het model wordt zwaar ondersteund door demonstratie en is niet echt geïnternaliseerd.
- De kloof tussen mens en LLM op real-world tabel-QA is enorm. TableBench (arXiv:2408.09174, AAAI 2025) evalueert 886 vragen over feitenchecking, numeriek redeneren, gegevensanalyse en visualisatie. De menselijke nauwkeurigheid is 85,91%. GPT-4-Turbo scoort 40,38%, GPT-4o scoort 42,73%. De beste huidige modellen presteren op ongeveer de helft van het menselijke niveau op een benchmark die is ontworpen om real-world tabelcomplexiteit te weerspiegelen.
- De ineenstorting van complexiteit bij financiële spreadsheets is ernstig. FinSheet-Bench (arXiv:2603.07316) test LLM's op templates van private equity-fondsen met variërende structurele complexiteit. Eenvoudige zoekopdrachten behalen een nauwkeurigheid van 89,1%. Complexe aggregaties vallen terug naar 19,6%. Het grootste testbestand (152 bedrijven, 8 fondsen) levert een gemiddelde nauwkeurigheid van 48,6% op over alle modellen, tegenover 86,2% bij het eenvoudigste bestand.
- Lange tabellen breken modellen categorisch. Het TMLR-overzicht meldt dat boven de 1000 tokens de prestaties van GPT-3 degraderen tot bijna willekeurig. Zelfs modellen met een context-window van 200K hebben moeite met enorme datasets vanwege de kwadratische kosten van self-attention over lange sequenties.
Wat standhoudt — en wat niet
De benchmark van Sui et al. is zorgvuldig ontworpen en de cijfers zijn geloofwaardig. De bevinding dat HTML beter presteert dan markdown voor structurele taken is contra-intuïtief — markdown is compacter en LLM's zien er meer van tijdens de training — maar komt overeen met wat je zou verwachten: de expliciete tagging van HTML geeft het model meer ankers om door de structuur te navigeren zonder deze te hoeven afleiden.
Waar ik sceptisch over ben: de zelf-augmentatietechniek (een tweetraps-prompting waarbij de eerste prompt het model vraagt om kritieke waarden te identificeren alvorens te antwoorden) levert verbeteringen op van 0,84–5,68% op downstream-benchmarks zoals TabFact en ToTTo. Dit zijn echte cijfers uit echte experimenten, maar ze zijn marginaal. De techniek pakt het fundamentele probleem niet aan — het is een prompt-engineering-oplossing bovenop een werkelijk zwak structureel begrip.
Het TMLR-overzicht heeft het probleem van de reikwijdte dat alle surveys hebben: het bestrijkt alles van tabelvoorspelling (XGBoost-terrein) tot generatieve tabelsynthese en QA, wat de analyse verwatert. Het meest bruikbare gedeelte voor mijn doeleinden is het gestructureerde QA-traject, en zelfs daar catalogiseert het overzicht voornamelijk methoden in plaats van te synthetiseren welke daadwerkelijk betrouwbaar zijn.
De bevinding van FinSheet-Bench dat complexe aggregaties een score van 19,6% halen, is hier het meest finance-specifieke alarmsignaal. Portfolio-aggregatie, roll-ups op fondsniveau en vergelijkingen over meerdere perioden zijn precies de operaties die financiële rapportage niet-triviaal maken — en dat is precies waar LLM's door de mand vallen.
Waarom dit belangrijk is voor finance AI
Beancount-grootboeken zijn tabellen. Wanneer een autonome agent een grootboek leest om anomalieën te detecteren, rapporten te genereren of te beslissen over een terugschrijving (write-back), voert deze tabelredenering uit. Het bewijs suggereert dat huidige LLM's eenvoudige zoekopdrachten redelijk goed afhandelen (cel-ophalen op 73% voor GPT-4), maar instorten bij de operaties die er het meest toe doen: meerstaps aggregatie, grootte-inschatting voor grote grootboeken en redeneren over structurele variaties.
De bevinding over serialisatie heeft onmiddellijke praktische gevolgen. Als ik Beancount-bestanden naar een LLM stuur, beïnvloedt het formaat dat ik kies de nauwkeurigheid met enkele procentpunten, nog voordat ik een enkele regel agent-logica heb geschreven. De systeemeigen syntaxis van Beancount ligt dicht bij de "NL+Sep"-kant van de formaathiërarchie — leesbaar voor mensen, suboptimaal voor LLM's. Het converteren naar een meer gestructureerd tussenformaat (een JSON- of HTML-tabel van transacties) voordat het aan een model wordt gevoed, kan de kosten van voorverwerking waard zijn.
De ineenstorting van complexiteit op schaal is de meest ontnuchterende bevinding. Een echt Beancount-grootboek voor een klein bedrijf kan duizenden transacties, tientallen rekeningen en een geschiedenis van meerdere jaren bevatten. De resultaten van FinSheet-Bench suggereren dat zodra een tabel groeit tot een omvang die er echt toe doet, de nauwkeurigheid van LLM's degradeert naar een gebied dat niet veilig is voor autonome write-back.
Wat nu te lezen
- TableLLM (arXiv:2311.09206) — een fine-tuned model getraind op 169 Kaggle-tabellen (UniPredict); er wordt gemeld dat het GPT-4 zero-shot aanzienlijk overtreft bij tabelvoorspellingen, wat suggereert dat domeinspecifieke fine-tuning nog steeds de juiste aanpak is voor finance-specifieke tabeltaken.
- TAT-QA (arXiv:2105.07624) — een dataset specifiek voor discreet redeneren over hybride financiële documenten (tabellen + tekst, zoals kwartaalcijfers); het bijbehorende TAT-LLM-model is het meest directe precedent voor het toepassen van gespecialiseerde modellen op financieel tabelredeneren.
- ToRR: A Benchmark for Table Reasoning and Robustness (arXiv:2502.19412) — richt zich op adversariële verstoringen zoals het husselen van rijen en het herordenen van kolommen; als een Beancount-agent robuust is tegen herordening, is dat een signaal dat hij de structuur begrijpt in plaats van de positie.
