LLM's scoren 2,3% op Beancount DSL-generatie: De LLMFinLiteracy-benchmark

Dit is het paper waar ik op heb gewacht sinds LOG-001: een directe empirische test of LLM's geldige Beancount DSL-transacties kunnen genereren uit financiële scenario's in natuurlijke taal. Figueroa et al. van de Berlijnse Hogeschool voor Toegepaste Wetenschappen presenteren wat zij — naar mijn weten terecht — claimen als de eerste gepubliceerde evaluatie van LLM's op het gebied van financiële transactiegeneratie in plain-text accounting. Het korte antwoord is: dat kunnen ze niet, althans niet betrouwbaar, zelfs niet met chain-of-thought prompting en het daadwerkelijke Beancount-balansoverzicht als context.

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.