PAL: Programm-gestützte Sprachmodelle für zuverlässige Finanzarithmetik

Nachdem ich mich mit der Literatur zum tabellarischen logischen Denken beschäftigt habe, wollte ich den komplementären Ansatz verstehen: Was passiert, wenn man LLMs nicht in natürlicher Sprache über Tabellen urteilen lässt, sondern sie Code schreiben lässt und die Berechnung vollständig auslagert? PAL (Gao et al., 2022, arXiv:2211.10435) ist die kanonische Antwort darauf und hat offensichtliche Auswirkungen auf jedes System, das Arithmetik über Finanzdaten zuverlässig durchführen muss.

Das Paper

"PAL: Program-Aided Language Models" (Gao, Madaan, Zhou, Alon, Liu, Yang, Callan, Neubig; ICML 2023) geht von einer einfachen Beobachtung aus: LLMs zerlegen Probleme gut, führen Arithmetik aber schlecht aus. Chain-of-Thought-Prompting löst das erste Problem, lässt das zweite aber unberührt. Die vorgeschlagene Lösung besteht darin, das zu ändern, was das LLM als seine "Denkschritte" produziert – anstelle von Arithmetik in natürlicher Sprache generiert es Python-Code. Ein Python-Interpreter führt diesen Code dann aus und liefert die Antwort zurück.

Die Aufteilung in Zerlegung und Ausführung ist sauber: Das LLM übernimmt das Problemverständnis und die Programmstruktur; der Interpreter kümmert sich um alles Numerische. Eine Frage wie "Olivia hat 23 $, kauft fünf Bagels zu je 3 $ – wie viel ist noch übrig?" wird zu money_left = 23 - (5 * 3), anstatt zu einer Abfolge von Prosa-Arithmetik, die das Modell verpatzen könnte.

Kernideen

• Bei GSM8K (Mathematik-Textaufgaben auf Grundschulniveau) erreicht PAL mit Codex eine Genauigkeit von 72,0 % gegenüber 65,6 % bei Chain-of-Thought mit demselben Codex-Modell – ein Gewinn von +6,4 Prozentpunkten – und 56,9 % bei CoT mit dem viel größeren PaLM-540B-Modell. Ein kleineres Modell gewinnt, indem es die Arithmetik an Python delegiert.
• Bei GSM-hard, einer Version von GSM8K, bei der Zahlen durch größere Werte ersetzt wurden, erreicht PAL 61,2 % gegenüber 23,1 % bei CoT – eine absolute Lücke von +38,1 Prozentpunkten. Große Zahlen bringen die Arithmetik auf Token-Ebene zu Fall; Python hingegen nicht.
• Mit Majority Voting über 40 Stichproben erreicht PAL 80,4 % bei GSM8K und übertrifft damit Minerva-540B (78,5 %) mit einem Modell, das etwa ein Zehntel so groß ist.
• Die Gewinne lassen sich auf symbolisches logisches Denken übertragen. Bei Aufgaben aus BIG-Bench Hard wie "Object Counting" erzielt PAL 96,7 % gegenüber 73,0 % bei CoT; bei "Penguins in a Table" 93,3 % gegenüber 79,2 %.
• Eine Ablationsstudie zeigt, wo die eigentliche Arbeit stattfindet: Wenn das LLM als sein eigener Interpreter fungiert (kein externes Python), bricht die GSM8K-Genauigkeit auf 23,2 % ein. Der Interpreter ist keine geringfügige Verbesserung – er erledigt die gesamte Arithmetik.
• Die Benennung von Variablen ist wichtig. Das Ersetzen aussagekräftiger Variablennamen durch Zufallszeichen führt bei symbolischen Aufgaben zu erheblichen Genauigkeitseinbußen. Das Modell liest seinen eigenen Code.

Was Bestand hat – und was nicht

Die Kernaussage ist trivial korrekt und die Experimente bestätigen dies überzeugend: Python ist in Arithmetik besser als ein LLM, und GSM-hard macht dies gnadenlos sichtbar. Die dortigen +38 Prozentpunkte sind keine Anomalie im Benchmark – sie spiegeln ein kategorisches Versagen von CoT bei Skalierung wider.

Was ich weniger überzeugend finde, ist die Einordnung als allgemeiner Durchbruch beim logischen Denken. PAL funktioniert bei Aufgaben, die zufällig deterministische, in Python ausdrückbare Antworten haben. Vieles von dem, was beim logischen Denken im Finanzbereich wichtig ist, lässt sich nicht so zerlegen. Die Entscheidung, ob ein Transaktionsmuster "ungewöhnlich für dieses Konto im 4. Quartal" ist oder ob eine Überweisung eine Kennzeichnung zur manuellen Überprüfung rechtfertigt, lässt sich nicht auf einen Python-Ausdruck reduzieren. PAL liefert eine zuverlässige Arithmetik-Engine; es liefert kein Urteilsvermögen.

Die Sicherheitsdimension findet im Paper keine Beachtung. Die Benchmarks laufen in einer kontrollierten Umgebung, aber jeder Einsatz, der beliebiges Python als Reaktion auf Benutzereingaben generiert und ausführt, stellt eine erhebliche Angriffsfläche dar. Kernel-Escapes aus Sandbox-Interpretern, Zugriff auf das Dateisystem oder Geheimnisse, adversarial gestaltete Eingaben, die bösartigen Code generieren – nichts davon wird thematisiert. Für Finanzanwendungen ist dies keine Randnotiz.

Das Paper analysiert auch die Fehlermodi bei fehlerhafter Codegenerierung nicht tiefgehend. Wenn PAL syntaktisch ungültiges Python ausgibt, gibt es keine Rückfalloption. Die Autoren berichten über Erfolgsquoten bei der Ausführung, charakterisieren jedoch nicht, was Generierungsfehler verursacht oder ob diese zufällig oder systematisch sind. Da der Interpreter die gesamte Arithmetik übernimmt, ist die Codequalität der einzige Engpass für die Zuverlässigkeit – und dieser wird zu wenig analysiert.

Warum dies für Finanz-KI wichtig ist

Dies ist eines der am direktsten auf Beancount anwendbaren Paper, die ich gelesen habe. Ledger-Operationen sind fast perfekt auf das abgestimmt, was PAL gut kann: Transaktionen nach Kategorien summieren, Wechselkurse anwenden, die Steuerbasis über mehrere Lots hinweg berechnen, Kontoauszugssummen mit Ledger-Salden abgleichen. Diese Aufgaben sind deterministisch, arithmetiklastig und in Python ausdrückbar. CoT-basierte Agenten werden hier Zahlen halluzinieren; PAL wird das nicht tun, solange die Programmstruktur stimmt.

"Program of Thoughts" (arXiv:2211.12588), ein zeitgleich erschienenes Paper, das unabhängig dieselbe Idee entwickelte, wurde an drei Datensätzen für Finanz-QA evaluiert – FinQA, ConvFinQA und TATQA – und berichtete über einen durchschnittlichen Gewinn von ca. 12 % gegenüber Chain-of-Thought. Das ist der direkteste Beweis dafür, dass der Ansatz der Programmgenerierung beim logischen Denken im Finanzbereich hilft, nicht nur bei Grundschulmathematik.

Die Frage der Rückschreibesicherheit ist jedoch im Kontext eines Ledgers schärfer als bei Benchmarks. Ein Agent, der Python generiert, um Beancount-Daten zu lesen, ist risikoarm. Ein Agent, der Python generiert, um Ledger-Einträge zu schreiben, benötigt eine streng begrenzte Ausführungsumgebung – eine, die nur Ledger-Objekte und nichts anderes berühren kann, die bei jeder Ausnahme sicher sperrt (fail-closed) und die erfordert, dass der generierte Code vor der Ausführung eine Whitelist passiert. PAL betrachtet den Interpreter als neutrale Rechen-Engine. Ein produktiver Finanz-Agent kann das nicht tun.

Was man als Nächstes lesen sollte

• Program of Thoughts Prompting (Chen et al., arXiv:2211.12588) – zeitgleiche Arbeit, die auf FinQA, ConvFinQA und TATQA evaluiert und einen durchschnittlichen Gewinn von ~12 % gegenüber CoT berichtet; die finanzspezifische Evaluation, die PAL aufschiebt.
• FinQA: A Dataset of Numerical Reasoning over Financial Reports (Chen et al., EMNLP 2021) – der Benchmark, der den PoT-Finanzbewertungen zugrunde liegt; zu verstehen, was tatsächlich getestet wird, hilft dabei einzuschätzen, wie sehr man der Übertragbarkeit auf echte Beancount-Anwendungsfälle trauen kann.
• Self-Refine: Iterative Refinement with Self-Feedback (Madaan et al., arXiv:2303.17651) – derselbe Erstautor wie PAL, erweitert die Erkenntnis der Codegenerierung um iterative Selbstkorrekturschleifen; relevant für die Frage, ob PAL-ähnliche Agenten sich von ihren eigenen Fehlern bei der Codegenerierung erholen können.