Continuo a tornare sulla stessa osservazione scomoda riguardo al ragionamento tabellare: quando i LLM spiegano il loro lavoro sulle tabelle usando catene di pensiero testuali, stanno narrando una rappresentazione mentre ragionano su un'altra. Chain-of-Table, un articolo di Google Research pubblicato a ICLR 2024, prende sul serio questa tensione e propone una soluzione semplice — lasciare che sia la tabella stessa a trasportare lo stato di ragionamento intermedio, non il testo.
L'articolo
Wang et al. presentano Chain-of-Table: Evoluzione delle Tabelle nella Catena di Ragionamento per la Comprensione delle Tabelle (arXiv:2401.04398, ICLR 2024). L'articolo affronta una lacuna lasciata dal prompting standard a catena di pensiero quando applicato a dati tabellari: il CoT ragiona in linguaggio naturale, ma le tabelle sono artefatti strutturati, e la narrazione linguistica delle trasformazioni tabellari è sia verbosa che dispersiva. L'idea centrale è lasciare che il LLM pianifichi una sequenza di operazioni tabellari programmatiche — filtro, raggruppamento, ordinamento, selezione colonna, aggiunta colonna — eseguendo ciascuna per produrre uno stato tabellare intermedio, e restituire quella tabella evoluta al LLM come input per il passo successivo. La risposta finale viene generata dallo stato tabellare terminale piuttosto che da una lunga catena testuale. Gli autori tracciano un'analogia esplicita con lo sviluppo SQL: un analista esperto scrive passaggi intermedi CREATE TABLE ... AS SELECT, non un'unica query monolitica. Chain-of-Table formalizza quella pratica per gli agenti LLM.
La valutazione copre tre benchmark: WikiTableQuestions (WikiTQ), TabFact e FeTaQA. Il modello primario è PaLM 2, con validazione incrociata su GPT-3.5 e LLaMA 2 70B.
Idee chiave
- Chain-of-Table raggiunge il 67,31% di accuratezza di denotazione su WikiTQ rispetto al 61,48% di Dater, il baseline precedente più forte — un miglioramento di +5,83 punti percentuali.
- Su tabelle superiori a 4.000 token, il vantaggio cresce a +10,25 punti (44,87% contro 34,62%), che è dove il metodo conta di più nella pratica.
- L'accuratezza su TabFact raggiunge l'86,61% contro l'84,63% di Dater; il BLEU su FeTaQA migliora da 29,47 a 32,61.
- Le cinque operazioni atomiche —
f_select_row,f_select_column,f_group_by,f_sort_by,f_add_column— coprono la stragrande maggioranza dei modelli di ragionamento osservati in questi benchmark;f_group_byfa la maggior parte del lavoro su WikiTQ, dove il conteggio è la modalità di errore dominante. - Chain-of-Table richiede al massimo 25 generazioni campione per domanda, contro 50 per Binder e 100 per Dater — un guadagno di efficienza del 50–75% insieme a una migliore accuratezza, cosa davvero insolita nella ricerca sui LLM dove il compromesso va quasi sempre nella direzione opposta.
- L'approccio è agnostico rispetto al modello: supera costantemente i baselines testuali CoT su PaLM 2, GPT-3.5 e LLaMA 2.
Cosa regge — e cosa no
Il contributo empirico centrale dell'articolo è solido. I benchmark sono standard, i baselines sono equi e la storia sull'efficienza è convincente. Rendere la tabella stessa una rappresentazione intermedia esplicita piuttosto che narrarla in prosa è un'idea pulita con una motivazione intuitiva, e i risultati su tabelle grandi sono le prove più convincenti: quando la tabella entra a malapena nel contesto, avere operazioni che la riducono progressivamente a ciò che conta è chiaramente meglio che produrre ancora più testo.
Detto questo, ci sono lacune reali. L'analisi della propagazione degli errori è superficiale. Se il LLM genera un argomento f_select_row errato al secondo passo di una catena di cinque passi, ogni operazione successiva opera su una tabella intermedia corrotta, e la risposta finale è spazzatura. L'articolo riporta l'accuratezza aggregata ma non analizza la frequenza con cui il ragionamento fallisce a causa di errori nei passi iniziali rispetto a quelli finali, né se l'approccio sia robusto a operazioni parzialmente errate. Per un metodo che dipende da una sequenza di chiamate corrette, questa è un'omissione significativa.
Anche il vocabolario delle operazioni è una scommessa. Cinque operazioni coprono la maggior parte dei modelli in WikiTQ e TabFact perché quei benchmark sono stati progettati attorno a compiti tabellari relazionali. Le tabelle finanziarie del mondo reale — bilanci, saldi di prova del ledger, dichiarazioni fiscali — richiedono di routine join tra tabelle correlate, aggregati calcolati con condizioni (SOMMA dei dare DOVE conto INIZIA CON '6') e trasformazioni pivot. Nessuna di queste è nel set di operazioni. Gli autori lo riconoscono implicitamente ma non lo testano.
Infine, non c'è una spiegazione teorica del perché gli stati tabellari intermedi dovrebbero essere migliori del testo intermedio. L'intuizione è accattivante, ma l'articolo è puramente empirico. Il lavoro successivo (TableMaster, arXiv:2501.19378; H-STAR, NAACL 2025) si è rapidamente spostato verso approcci ibridi adattivi che mescolano SQL e ragionamento testuale, il che suggerisce che la comunità abbia letto la stessa lacuna che ho visto io: le operazioni tabellari pure non sono universalmente migliori, solo migliori sui benchmark testati.
Perché questo conta per l'AI finanziaria
Per gli agenti ledger Beancount, l'architettura di Chain-of-Table si mappa quasi perfettamente su ciò che voglio in una pipeline di scrittura. Una query Beancount come "quali sono le mie spese nette per categoria nel Q1, escluse le transazioni taggate :ignore?" richiede esattamente il tipo di trasformazioni tabellari sequenziali proposte dall'articolo: filtrare le righe per data, filtrare per tag, raggruppare per categoria di conto, sommare gli importi. Se l'agente può pianificarlo come una catena di operazioni intermedie esplicite piuttosto che generare un'unica query o ragionarci in prosa, la traccia di audit è leggibile e ogni passo è verificabile in modo indipendente.
Anche il miglioramento di efficienza sulle tabelle grandi è direttamente rilevante. Un ledger Beancount multi-anno con decine di migliaia di transazioni supera facilmente i 4.000 token quando viene materializzato. Il miglioramento di 10 punti in quel regime non è un artefatto del benchmark; riflette ciò che accade realmente quando la tabella deve essere progressivamente ristretta prima che il ragionamento possa essere preciso.
Il pezzo mancante per Beancount è l'operazione di join. La contabilità a partita doppia collega le transazioni tra i conti, e qualsiasi compito di riconciliazione richiede ragionamento su almeno due linee temporali di conti. Chain-of-Table come pubblicato non può esprimere questo. Estendere il vocabolario delle operazioni per includere join tra conti è il passo ingegneristico successivo ovvio per un agente di ragionamento Beancount in produzione.
Cosa leggere dopo
- Chain-of-Query: Scatenare il Potere dei LLM nella Comprensione delle Tabelle Assistita da SQL tramite Collaborazione Multi-Agente (2025, arXiv:2508.15809) — estende il concetto di operazione verso la generazione SQL multi-agente, che affronta la lacuna dei join
- TableMaster: Una Ricetta per Avanzare nella Comprensione delle Tabelle con Modelli Linguistici (arXiv:2501.19378) — introduce il ragionamento adattivo che alterna tra operazioni tabellari e CoT testuale; il seguito più diretto di Chain-of-Table
- DATER: Text-to-SQL basato su Decomposizione per LLM su Contesti Lunghi (arXiv:2308.01463) — approccio complementare di decomposizione per SQL complesso su schemi di grandi dimensioni, rilevante per il design dell'interfaccia naturale di beanquery