PAL: Program-Aided Language Models voor betrouwbare financiële rekenkunde

Na enige tijd te hebben doorgebracht met de literatuur over tabellair redeneren, wilde ik de complementaire aanpak begrijpen: in plaats van LLM's in natuurlijke taal te laten redeneren over tabellen, wat gebeurt er als je ze code laat schrijven en de berekening volledig overdraagt? PAL (Gao et al., 2022, arXiv:2211.10435) is het canonieke antwoord, en het heeft duidelijke implicaties voor elk systeem dat betrouwbaar berekeningen moet uitvoeren over financiële gegevens.

Het paper

"PAL: Program-Aided Language Models" (Gao, Madaan, Zhou, Alon, Liu, Yang, Callan, Neubig; ICML 2023) vertrekt vanuit een eenvoudige observatie: LLM's ontleden problemen goed, maar voeren berekeningen slecht uit. Chain-of-thought prompting lost het eerste probleem op, maar laat het tweede ongemoeid. De voorgestelde oplossing is om te veranderen wat de LLM produceert als zijn "redeneerstappen" — in plaats van rekenkunde in natuurlijke taal, genereert het Python-code. Een Python-interpreter voert die code vervolgens uit en geeft het antwoord terug.

De splitsing tussen ontleding en uitvoering is helder: de LLM zorgt voor het begrijpen van het probleem en de programmastructuur; de interpreter zorgt voor alles wat numeriek is. Een vraag als "Olivia heeft $23, koopt vijf bagels voor $3 per stuk — hoeveel is er over?" wordt money_left = 23 - (5 * 3), en niet een reeks rekenstappen in proza die het model zou kunnen verpesten.

Belangrijkste ideeën

• Op GSM8K (wiskundevraagstukken voor de basisschool) behaalt PAL met Codex een nauwkeurigheid van 72,0% tegenover 65,6% voor chain-of-thought met hetzelfde Codex-model — een winst van +6,4 procentpunt — en 56,9% voor CoT met het veel grotere PaLM-540B-model. Een kleiner model wint door rekenkunde uit te besteden aan Python.
• Op GSM-hard, een versie van GSM8K waarbij getallen zijn vervangen door grotere waarden, behaalt PAL 61,2% tegenover 23,1% voor CoT — een absoluut gat van +38,1 procentpunt. Grote getallen maken rekenkunde op token-niveau onmogelijk; ze vormen geen probleem voor Python.
• Met meerderheidsstemming over 40 samples bereikt PAL 80,4% op GSM8K, waarmee het Minerva-540B (78,5%) nipt verslaat met een model dat ongeveer 1/10 van de grootte is.
• De winst vertaalt zich ook naar symbolisch redeneren. Op BIG-Bench Hard-taken zoals "Object Counting" scoort PAL 96,7% tegenover 73,0% voor CoT; op "Penguins in a Table" is dat 93,3% tegenover 79,2%.
• Een ablatie-onderzoek onthult waar het werk daadwerkelijk wordt gedaan: wanneer de LLM als zijn eigen interpreter optreedt (geen externe Python), stort de GSM8K-nauwkeurigheid in naar 23,2%. De interpreter is geen kleine verbetering — deze voert al het rekenwerk uit.
• Naamgeving van variabelen is belangrijk. Het vervangen van betekenisvolle variabelenamen door willekeurige tekens veroorzaakt aanzienlijke dalingen in nauwkeurigheid bij symbolische taken. Het model leest zijn eigen code.

Wat overeind blijft — en wat niet

De kernbewering is triviaal correct en de experimenten bevestigen dit overtuigend: Python is beter in rekenen dan een LLM, en GSM-hard maakt dit pijnlijk zichtbaar. De +38 procentpunt daar is geen toevalligheid in de benchmark — het weerspiegelt een categorische foutmodus van CoT bij schaling.

Wat ik minder overtuigend vind, is de presentatie als een algemene doorbraak in redeneren. PAL werkt op taken die toevallig deterministische, in Python uitdrukbare antwoorden hebben. Veel van wat belangrijk is bij financieel redeneren, laat zich niet op deze manier ontleden. Beslissen of een transactiepatroon "ongebruikelijk is voor deze rekening in Q4" of dat een overboeking een vlag voor handmatige controle verdient, is niet te reduceren tot een Python-expressie. PAL geeft je een betrouwbare rekenmachine; het geeft je geen oordeelsvermogen.

Het beveiligingsaspect krijgt geen aandacht in het paper. De benchmarks draaien in een gecontroleerde omgeving, maar elke implementatie die willekeurige Python genereert en uitvoert in reactie op door gebruikers geleverde invoer, vormt een aanzienlijk aanvalsoppervlak. Kernel-escapes uit gesandboxte interpreters, toegang tot het bestandssysteem of geheimen, kwaadaardig geformuleerde invoer die schadelijke code genereert — niets hiervan wordt behandeld. Voor financiële toepassingen is dit geen voetnoot.

Het paper analyseert ook niet diepgaand de foutmodi wanneer de codegeneratie misgaat. Als PAL syntactisch ongeldige Python uitspuugt, valt het terug op niets. De auteurs rapporteren slagingspercentages voor uitvoering, maar karakteriseren niet wat generatiefouten veroorzaakt of dat deze willekeurig of systematisch zijn. Gezien het feit dat de interpreter al het rekenwerk doet, is de codekwaliteit de enige bottleneck voor betrouwbaarheid — en dat is ondergeanalyseerd.

Waarom dit belangrijk is voor financiële AI

Dit is een van de meest direct toepasbare papers voor Beancount die ik heb gelezen. Grootboekbewerkingen sluiten bijna perfect aan bij waar PAL goed in is: transacties optellen per categorie, wisselkoersen toepassen, de fiscale basis berekenen over meerdere lots, en saldi op bankafschriften afstemmen met grootboeksaldi. Deze zijn deterministisch, rekenintensief en in Python uitdrukbaar. Op CoT gebaseerde agents zullen hier getallen hallucineren; PAL zal dat niet doen, zolang de programmastructuur correct is.

"Program of Thoughts" (arXiv:2211.12588), een gelijktijdig verschenen paper dat onafhankelijk hetzelfde idee ontwikkelde, evalueerde op drie financiële QA-datasets — FinQA, ConvFinQA en TATQA — en rapporteerde een gemiddelde winst van ~12% ten opzichte van chain-of-thought. Dat is het meest directe bewijs dat de aanpak van programmastructuur-generatie helpt bij redeneren in het financiële domein, en niet alleen bij basisschool-wiskunde.

De vraag over de veiligheid bij terugschrijven (write-back safety) is echter urgenter in een grootboekcontext dan in benchmarks. Een agent die Python genereert om Beancount-gegevens te lezen, is een laag risico. Een agent die Python genereert om grootboekmutaties te schrijven, heeft een strikt beperkte uitvoeringsomgeving nodig — een omgeving die alleen grootboekobjecten kan aanraken en niets anders, die "fails closed" bij elke uitzondering, en waarbij de gegenereerde code een whitelist moet passeren vóór uitvoering. PAL beschouwt de interpreter als een neutrale rekenmachine. Een professionele financiële agent kan dat niet doen.

Wat nu te lezen

• Program of Thoughts Prompting (Chen et al., arXiv:2211.12588) — gelijktijdig werk dat evalueert op FinQA, ConvFinQA en TATQA en een gemiddelde winst van ~12% rapporteert ten opzichte van CoT; de financieel-specifieke evaluatie die PAL achterwege laat.
• FinQA: A Dataset of Numerical Reasoning over Financial Reports (Chen et al., EMNLP 2021) — de benchmark die ten grondslag ligt aan de PoT financiële evaluaties; het begrijpen van wat er feitelijk wordt getest helpt om in te schatten hoeveel vertrouwen men kan hebben in de overdracht naar echte Beancount-toepassingen.
• Self-Refine: Iterative Refinement with Self-Feedback (Madaan et al., arXiv:2303.17651) — van dezelfde eerste auteur als PAL, breidt het inzicht in codegeneratie uit naar iteratieve zelfcorrectie-loops; relevant voor de vraag of PAL-achtige agents kunnen herstellen van hun eigen fouten in codegeneratie.