Questo è l'articolo che aspettavo da LOG-001: un test empirico diretto su se gli LLM possano generare transazioni valide in DSL Beancount da scenari finanziari in linguaggio naturale. Figueroa et al. dell'Università di Scienze Applicate di Berlino presentano quella che affermano—correttamente, per quanto posso giudicare—essere la prima valutazione pubblicata degli LLM sulla generazione di transazioni finanziarie nella contabilità in testo semplice. La risposta breve è: non possono, almeno non in modo affidabile, anche con prompting a catena di pensiero e il bilancio reale di Beancount fornito come contesto.
L'articolo
Figueroa, Grundmann, Freidank, Löser e Nejdl valutano cinque modelli open-weight da circa 7B su un benchmark a due compiti chiamato LLMFinLiteracy. Il compito 1 chiede ai modelli di generare scenari testuali che influenzerebbero un dato rapporto di liquidità (corrente, acido, o di cassa) dato un bilancio trimestrale reale di una delle cinque aziende quotate DAX (Airbus, Bayer, Deutsche Telekom, Mercedes-Benz, SAP). Il compito 2 chiede ai modelli di tradurre quegli scenari in transazioni Beancount compilabili. Il compilatore Beancount funge da verificatore di sintassi ground-truth; esperti umani del dominio valutano la correttezza semantica. L'articolo introduce una tassonomia degli errori in 12 classi tra i due compiti e utilizza un prompt a catena di pensiero in 9 passaggi che include regole contabili a partita doppia, un esempio input/output, e il bilancio reale dell'azienda in formato Beancount. I modelli valutati—Llama-3-8B, Qwen-2-7B, Mistral-7B, CodeLlama-7B e CodeQwen-1.5-7B—sono stati tutti eseguiti on-premise a causa della sensibilità dei dati finanziari. Il corpus totale è di 1.500 campioni generati, con 300 voci stratificate valutate da esperti umani.
Idee chiave
- Solo 7 delle 300 coppie scenario-transazione valutate (2,3%) erano completamente corrette end-to-end; anche limitandosi ai tre modelli generalisti si sale solo al 3,8%.
- I due modelli migliori, Qwen-2-7B e Mistral-7B, producono scenari corretti solo il 21,67% e il 20,00% delle volte, e transazioni compilate corrette solo il 16,67% e il 10,00% delle volte.
- I modelli specializzati sul codice (CodeLlama, CodeQwen) ottengono lo 0% in entrambi i compiti; hanno risposto al modello di prompt con una stringa letterale "Processed — Waiting for next input", ignorando completamente il compito.
- La sintassi non è il collo di bottiglia: nessun modello ha prodotto un singolo errore di sintassi. Gli errori sono interamente nel ragionamento contabile—gli errori di bilancio dominano per Qwen-2 (61,67%) e Llama-3 (38,33%), mentre Mistral fa principalmente riferimento a conti che non esistono nel bilancio fornito (45% di errori di conto sconosciuto).
- Una frazione significativa delle transazioni che compilano con successo è semanticamente sbagliata—il trucco preferito dei modelli è definire la riduzione di una passività come "vendita del tuo debito," che aumenta la cassa ma per la ragione sbagliata.
- GPT-4o usato come giudice automatico non è riuscito a segnalare incongruenze in tutti i 10 scenari insensati mostrati, confermando che l'autovalutazione degli LLM non è un portale di qualità affidabile per output contabili.
- I modelli copiano in gran parte l'esempio input/output nel prompt piuttosto che generalizzare: le 7 coppie corrette assomigliano strettamente alla struttura della transazione di esempio fornita.
Cosa regge—e cosa no
Il contributo empirico centrale dell'articolo è solido. Il compilatore Beancount è un criterio di correttezza oggettivo e riproducibile, e l'uso di bilanci aziendali reali anziché dati giocattolo aggiunge validità ecologica. La tassonomia gerarchica degli errori è progettata con cura—fermare la valutazione al primo errore evita di gonfiare il "credito parziale" per output spazzatura.
Detto questo, ci sono limitazioni ovvie che gli autori in gran parte riconoscono. Cinque modelli open-weight da ~7B del 2023–2024 sono una fetta limitata del panorama delle capacità; GPT-4o e Claude sono stati esclusi per motivi di privacy, il che è comprensibile, ma significa che il numero headline (2,3% di correttezza) sottostima la frontiera. Le formule dei rapporti finanziari sono state deliberatamente omesse dai prompt per testare la conoscenza intrinseca del dominio—una scelta metodologicamente interessante, ma che rende i risultati incomparabili a qualsiasi sistema che includerebbe ragionevolmente la documentazione delle formule. E 300 campioni valutati da umani su cinque modelli, tre rapporti e cinque aziende è modesto; le celle per modello per rapporto sono troppo piccole (12 campioni) per trarre conclusioni forti sulla varianza.
La lacuna metodologica più interessante è l'assenza di qualsiasi protocollo iterativo o basato su feedback. Nessun tool-calling, nessuna autocorrezione, nessun ciclo di feedback del compilatore—solo generazione one-shot. Dato che CRITIC (LOG-012) e lavori correlati mostrano che il raffinamento interattivo con strumenti migliora sostanzialmente l'accuratezza su compiti con output verificabili, un esperimento con compilatore Beancount-in-the-loop sarebbe stato molto più informativo sulla distribuibilità.
Perché questo è importante per l'AI finanziaria
Ogni decisione di design per l'agente di write-back di Bean Labs si basa su assunzioni su ciò che gli LLM possono fare con DSL Beancount. Questo articolo è il primo ancoraggio empirico. I risultati principali sono sobri ma anche interpretabili in modo utile.
Primo, i modi di fallimento sono specifici, non casuali. Gli errori di bilancio e i conti sconosciuti sono i due problemi dominanti, ed entrambi sono affrontabili con un ciclo di feedback compiler-in-the-loop: il compilatore Beancount ti dice esattamente quale conto è sconosciuto e se la transazione è in equilibrio. Un'architettura di agente che itera sull'output del compilatore—piuttosto che generare una volta e fermarsi—dovrebbe superare sostanzialmente i risultati one-shot qui. Secondo, la sintassi è gratuita. I modelli hanno chiaramente imparato la grammatica superficiale di Beancount; semplicemente non riescono a tradurre in modo affidabile l'intento finanziario in movimenti di conti corretti. Questa distinzione conta per dove investire in prompting e fine-tuning. Terzo, il risultato che GPT-4o non può valutare automaticamente la qualità contabile alza l'asticella per qualsiasi sistema di verifica automatizzata: serve il compilatore, più controlli a campione da esperti del dominio, non un critico LLM.
L'articolo conferma anche qualcosa che sospettavo dal lavoro sul rilevamento di anomalie (LOG-049): gli LLM che operano su transazioni finanziarie compilano-e-inviano troppo prontamente. La categoria "Incorrect | Compiles"—transazioni che superano il controllo di sintassi ma sono semanticamente sbagliate—è esattamente il modo di fallimento che un guardrail di sicurezza per il write-back deve intercettare. Una transazione può bilanciare perfettamente e comunque registrare ricavi come riduzione di una passività, il che passerebbe inosservato con qualsiasi controllo puramente sintattico.
Cosa leggere dopo
- AnoLLM: Large Language Models for Tabular Anomaly Detection (OpenReview:7VkHffT5X2, ICLR 2025)—scoring di anomalie basato su verosimiglianza come alternativa all'approccio di rilevamento a batch; si combina naturalmente con un segnale del compilatore Beancount per segnalare voci strutturalmente valide ma statisticamente anomale.
- ReDAct: Uncertainty-Aware Deferral for LLM Agents (arXiv:2604.07036)—instrada decisioni a bassa confidenza verso un modello più grande o un umano; affronta direttamente la questione di quando un agente di write-back Beancount dovrebbe rimandare alla revisione umana piuttosto che procedere dopo un ciclo di feedback del compilatore.
- CRITIC: Large Language Models Can Self-Correct with Tool-Interactive Critiquing (arXiv:2305.11738, ICLR 2024)—il lavoro esistente più rilevante per costruire un agente di correzione compiler-in-the-loop sopra l'architettura valutata in questo articolo.