Dopo aver dedicato tempo alla letteratura sul ragionamento tabellare, volevo comprendere l'approccio complementare: piuttosto che far ragionare gli LLM sulle tabelle in linguaggio naturale, cosa succede quando si permette loro di scrivere codice e delegare completamente il calcolo? PAL (Gao et al., 2022, arXiv:2211.10435) è la risposta canonica, e ha implicazioni ovvie per qualsiasi sistema che debba eseguire operazioni aritmetiche su dati finanziari in modo affidabile.
L'articolo
"PAL: Modelli Linguistici Assistiti da Programmi" (Gao, Madaan, Zhou, Alon, Liu, Yang, Callan, Neubig; ICML 2023) parte da un'osservazione semplice: gli LLM scompongono bene i problemi ma eseguono male l'aritmetica. L'uso del prompting a catena di pensiero risolve il primo problema, ma lascia intatto il secondo. La soluzione proposta è cambiare ciò che l'LLM produce come suoi "passaggi di ragionamento" — invece di un'aritmetica in linguaggio naturale, genera codice Python. Un interprete Python esegue poi quel codice e restituisce la risposta.
La separazione tra scomposizione ed esecuzione è netta: l'LLM gestisce la comprensione del problema e la struttura del programma; l'interprete gestisce tutto ciò che è numerico. Una domanda come "Olivia ha 23 ciascuno — quanto le rimane?" diventa soldi_rimanenti = 23 - (5 * 3), non una sequenza di operazioni aritmetiche in prosa che il modello potrebbe sbagliare.
Idee chiave
- Su GSM8K (problemi di matematica scolastica), PAL con Codex raggiunge il 72,0% di accuratezza contro il 65,6% della catena di pensiero con lo stesso modello Codex — un guadagno di +6,4pp — e il 56,9% per CoT con il modello molto più grande PaLM-540B. Un modello più piccolo vince delegando l'aritmetica a Python.
- Su GSM-hard, una versione di GSM8K in cui i numeri sono sostituiti con valori più grandi, PAL raggiunge il 61,2% contro il 23,1% di CoT — un divario assoluto di +38,1pp. I numeri grandi rompono l'aritmetica a livello di token; non rompono Python.
- Con il voto di maggioranza su 40 campioni, PAL raggiunge l'80,4% su GSM8K, superando Minerva-540B (78,5%) con un modello circa 1/10 delle dimensioni.
- I guadagni si generalizzano al ragionamento simbolico. Su compiti BIG-Bench Hard come il Conteggio di Oggetti, PAL ottiene il 96,7% contro il 73,0% di CoT; su Pinguini in una Tabella, il 93,3% contro il 79,2%.
- Un'analisi di ablazione rivela dove avviene effettivamente il lavoro: quando l'LLM agisce come proprio interprete (nessun Python esterno), l'accuratezza su GSM8K crolla al 23,2%. L'interprete non è un miglioramento minore — sta eseguendo tutta l'aritmetica.
- La denominazione delle variabili è importante. Sostituire nomi di variabili significativi con caratteri casuali causa significativi cali di accuratezza sui compiti simbolici. Il modello legge il proprio codice.
Cosa regge — e cosa no
L'affermazione centrale è banalmente corretta e gli esperimenti la confermano in modo convincente: Python è migliore di un LLM nell'aritmetica, e GSM-hard lo rende brutalmente visibile. Il +38pp non è una stranezza del benchmark — riflette una modalità di fallimento categorica di CoT sotto scala.
Quello che trovo meno convincente è l'inquadramento come una svolta generale nel ragionamento. PAL funziona su compiti che, per caso, hanno risposte deterministiche ed esprimibili in Python. Gran parte di ciò che conta nel ragionamento finanziario non si scompone in questo modo. Decidere se un pattern di transazioni è "insolito per questo conto nel Q4" o se un trasferimento merita un flag di revisione manuale non è riducibile a un'espressione Python. PAL ti fornisce un motore aritmetico affidabile; non ti fornisce giudizio.
La dimensione della sicurezza non riceve alcuna attenzione nell'articolo. I benchmark vengono eseguiti in un ambiente controllato, ma qualsiasi implementazione che genera ed esegue Python arbitrario in risposta a input forniti dall'utente è una superficie d'attacco significativa. Fughe dal kernel da interpreti in sandbox, accesso al filesystem o ai segreti, input creati in modo avversario che generano codice malevolo — nulla di tutto ciò viene affrontato. Per le applicazioni finanziarie, questa non è una nota a piè di pagina.
L'articolo inoltre non analizza in profondità le modalità di fallimento quando la generazione del codice va storta. Se PAL emette Python sintatticamente non valido, ricade nel nulla. Gli autori riportano i tassi di successo dell'esecuzione ma non caratterizzano cosa causa i fallimenti di generazione o se sono casuali o sistematici. Dato che l'interprete sta facendo tutta l'aritmetica, la qualità del codice è l'intero collo di bottiglia dell'affidabilità — ed è sotto-analizzata.
Perché questo è importante per l'IA finanziaria
Questo è uno degli articoli più direttamente applicabili a Beancount che abbia mai letto. Le operazioni contabili sono quasi perfettamente allineate con ciò che PAL fa bene: sommare transazioni per categoria, applicare tassi di cambio, calcolare la base imponibile su più lotti, riconciliare i totali degli estratti conto bancari con i saldi contabili. Queste sono operazioni deterministiche, a forte componente aritmetica ed esprimibili in Python. Gli agenti basati su CoT allucineranno numeri qui; PAL non lo farà, purché la struttura del programma sia corretta.
Program of Thoughts (arXiv:2211.12588), un articolo concorrente che ha sviluppato indipendentemente la stessa idea, ha valutato su tre dataset di QA finanziario — FinQA, ConvFinQA e TATQA — e ha riportato un guadagno medio del ~12% rispetto alla catena di pensiero. Questa è la prova più diretta che l'approccio di generazione di programmi aiuta nel ragionamento nel dominio finanziario, non solo nella matematica scolastica.
La questione della sicurezza del write-back, comunque, è più acuta in un contesto contabile che sui benchmark. Un agente che genera Python per leggere dati Beancount è a basso rischio. Uno che genera Python per scrivere voci contabili necessita di un ambiente di esecuzione strettamente limitato — uno che possa toccare solo gli oggetti contabili e nient'altro, che fallisca in modo chiuso su qualsiasi eccezione, e che richieda al codice generato di superare una whitelist prima dell'esecuzione. PAL tratta l'interprete come un motore di calcolo neutro. Un agente finanziario di produzione non può farlo.
Cosa leggere dopo
- Program of Thoughts Prompting (Chen et al., arXiv:2211.12588) — lavoro concorrente che valuta su FinQA, ConvFinQA e TATQA e riporta un guadagno medio del ~12% rispetto a CoT; la valutazione specifica per la finanza che PAL rimanda.
- FinQA: Un Dataset di Ragionamento Numerico su Report Finanziari (Chen et al., EMNLP 2021) — il benchmark alla base delle valutazioni finanziarie di PoT; capire cosa viene effettivamente testato calibra quanto fidarsi del trasferimento ai casi d'uso reali di Beancount.
- Self-Refine: Perfezionamento Iterativo con Auto-Feedback (Madaan et al., arXiv:2303.17651) — stesso primo autore di PAL, estende l'intuizione della generazione di codice a cicli di autocorrezione iterativi; rilevante per capire se gli agenti in stile PAL possano riprendersi dai propri fallimenti di generazione del codice.