Le tabelle sono il modo di pensare dei commercialisti. Un registro Beancount è essenzialmente una tabella — i conti come righe, le date e gli importi come colonne, le asserzioni come vincoli tra le celle. Così, quando ho iniziato a chiedermi se gli LLM possano alimentare agenti finanziari autonomi, mi sono continuamente scontrato con la stessa domanda preliminare: possono almeno leggere in modo affidabile una tabella? La letteratura in merito è più impietosa di quanto mi aspettassi.
L'articolo
Fang et al. hanno pubblicato "Large Language Models(LLMs) on Tabular Data: Prediction, Generation, and Understanding — A Survey" in TMLR 2024 (arXiv:2402.17944). È una tassonomia di 41 pagine che copre tre domini: predizione di risultati strutturati da caratteristiche tabellari, generazione di dati tabellari sintetici e comprensione delle tabelle sufficiente a rispondere a domande su di esse. Il percorso della comprensione — risposta a domande su tabelle (TableQA), verifica dei fatti e ragionamento strutturale — è dove risiede il lavoro più rilevante per l'AI finanziaria.
L'articolo che ho letto insieme a questo, "Table Meets LLM: Can Large Language Models Understand Structured Table Data?" di Sui et al. (WSDM 2024, arXiv:2305.13062), adotta un approccio più controllato: definiscono un benchmark di Capacità di Comprensione Strutturale (SUC) con sette compiti ristretti — partizionamento della tabella, rilevamento della dimensione, rilevamento di celle unite, ricerca di cella, ricerca inversa, recupero di colonna e recupero di riga — e testano GPT-3.5 e GPT-4 direttamente. Nessuna catena di ragionamento, nessun trucco di recupero. Solo: il modello può fare ciò che chiediamo?
Idee chiave
- Il divario di formato è reale e sorprendentemente ampio. Sul benchmark SUC, la serializzazione HTML supera il formato in linguaggio naturale con separatori di circa il 6,76% complessivo. La classifica — HTML > XML > JSON > Markdown > NL+Sep — vale costantemente per tutti i compiti. I file Beancount sono più vicini all'estremità del linguaggio naturale di questo spettro, il che è un segnale d'allarme.
- La ricerca di cella è sorprendentemente difficile. GPT-3.5 raggiunge solo il 44% di accuratezza nella ricerca diretta di cella (trova il valore alla riga X, colonna Y). GPT-4 raggiunge il 73,34% sullo stesso compito. Per un'operazione deterministica che una formula di foglio di calcolo gestisce in microsecondi, un divario di 26 punti percentuali tra i modelli è allarmante.
- Gli esempi few-shot sono fondamentali. La rimozione di esempi 1-shot dai prompt SUC ha causato un calo complessivo dell'accuratezza del 30,38% in tutti i compiti. La comprensione strutturale del modello è fortemente impalcata dalla dimostrazione, non realmente interiorizzata.
- Il divario umano-LLM nel QA su tabelle reali è enorme. TableBench (arXiv:2408.09174, AAAI 2025) valuta 886 domande su verifica dei fatti, ragionamento numerico, analisi dei dati e visualizzazione. L'accuratezza umana è dell'85,91%. GPT-4-Turbo ottiene il 40,38%, GPT-4o il 42,73%. I migliori modelli attuali operano a circa la metà del livello umano su un benchmark progettato per riflettere la complessità delle tabelle reali.
- Il crollo di complessità nei fogli di calcolo finanziari è grave. FinSheet-Bench (arXiv:2603.07316) testa gli LLM su modelli di fondi di private equity con complessità strutturale variabile. Le ricerche semplici raggiungono l'89,1% di accuratezza. Le aggregazioni complesse scendono al 19,6%. Il file di test più grande (152 aziende, 8 fondi) produce un'accuratezza media del 48,6% su tutti i modelli, in calo rispetto all'86,2% sul file più semplice.
- Le tabelle lunghe rompono i modelli categoricamente. Il survey TMLR riporta che oltre i 1000 token, le prestazioni di GPT-3 degradano fino a quasi casuali. Anche i modelli con finestra di contesto di 200K faticano con dataset massicci a causa del costo quadratico dell'auto-attenzione su sequenze lunghe.
Cosa regge — e cosa no
Il benchmark di Sui et al. è progettato con cura e i numeri sono credibili. La scoperta che HTML superi il markdown per compiti strutturali è controintuitiva — il markdown è più compatto e gli LLM ne vedono di più nell'addestramento — ma si allinea con ciò che ci si aspetterrebbe: l'tagging esplicito di HTML fornisce al modello più ancoraggi per navigare la struttura senz doverla inferire.
Di ciò che sono scettico: la tecnica di auto-agenmento (prompt in due fasi dove il primo prompt chiede al modello di identifcare i valori critici prima di rispondere) produce miglioramenti dello 0,84–5,68% su benchmark a valle come TabFact e ToTTo. Questi sono numeri reali da esperimenti reali, ma sono marginali. La tecnica non affronta il problema fondamentale — è una toppa di prompt engineering su una comprensione strutturale genuinamente debole.
Il survey TMLR ha il problema di portata comune a tutti i survey: copre tutto, dalla predizione tabellare (paese di XGBoost) alla sintesi generativa di tabelle al QA, il che diluisce l'analisi. La sezione più attuabile per i miei scopi è il percorso del QA strutturato, e anche lì il survey cataloga principalmente metodi piuttosto che sintetizzare quali siano effettivamente affidabili.
La scoperta di FinSheet-Bench che le aggregazioni complesse ottengono il 19,6% è il campanello d'allarme più specifico per la finanza. L'aggregazione di portafoglio, i riepiloghi a livello di fondo e i confronti multi-periodo sono esattamente le operazioni che rendono il reporting finanziario non banale — e sono esattamente dove gli LLM crollano.
Perché questo è importante per l'AI finanziaria
I registri Beancount sono tabelle. Quando un agente autonomo legge un registro per rilevare anomalie, generare reporti o decidere su una scrittura di storno, sta eseguendo un ragionamento tabellare. Le prove suggeriscono che gli LLM attuali gestiscono ragionevolmente bene le ricerche semplici (recupero di cella al 73% per GPT-4) ma crollano sulle operazioni che contano di più: aggregazione a più fasi, stima della dimensione per registri grandi e ragionamento su variazioni strutturali.
La scoperta sulla serializzazione ha implicazioni pratiche immediate. Se sto inviando file Beancount a un LLM, il formato che scelgo influenza l'accuratezza di diversi punti percentuali prima ancora di scrivere una singola riga di logica dell'agente. La sintassi nativa di Beancount è vicina all'estremità "NL+Sep" della gerarchia di formato — leggibile per gli umani, subottimale per gli LLM. Convertire in un intermedio più strutturato (una tabella JSON o HTML di transazioni) prima di alimentare un modello potrebbe valere il costo di pre-elaborazione.
Il crollo di complessità su larga scala è la scoperta più sobria. Un vero registro Beancount per una piccola impresa potrebbe avere migliaia di transazioni, decine di conti e una storia pluriennale. I risultati di FinSheet-Bench suggeriscono che una volta che una tabella cresce fino a una dimensione in cui conta davvero, l'accuratezza dell'LLM degrada in un territorio che non è sicuro per la scrittura di storno autonoma.
Cosa leggere dopo
- TableLLM (arXiv:2311.09206) — modello fine-tunato addestrato su 169 tabelle Kaggle (UniPredict); riportato per superare sostanzialmente GPT-4 zero-shot nella predizione tabellare, il che suggerisce che il fine-tuning specifico per dominio è ancora l'approccio giusto per compiti tabellari specifici della finanza.
- TAT-QA (arXiv:2105.07624) — un dataset specificamente per il ragionamento discreto su documenti finanziari ibridi (tabelle + testo, come i reporti sugli utili); il modello TAT-LLM associato è il precedente più diretto per l'applicazione di modelli specializzati al ragionamento tabellare finanziario.
- ToRR: Un Benchmark per il Ragionamento e la Robustezza delle Tabelle (arXiv:2502.19412) — si concentra su perturbazioni avversarie come il mischiamento delle righe e il riordinamento delle colonne; se un agente Beancount è robusto al riordinamento, è un segnale che comprende la struttura piuttosto che la posizione.