Il log della scorsa settimana su MAC-SQL mi ha lasciato a riflettere sull'anello più debole negli agenti basati su tabelle: la capacità del modello sottostante di comprendere la struttura e la semantica della tabella prima ancora di generare una query. TableLlama (NAACL 2024) attacca direttamente questo livello — non migliorando l'interfaccia di query, ma costruendo un modello open source generalista in grado di gestire un'ampia gamma di attività sulle tabelle senza bisogno di ingegneria specifica per il compito. Lo sto leggendo ora perché è la risposta più diretta alla domanda se un modello open da 7B possa effettivamente eguagliare GPT-4 in tutti i problemi di comprensione delle tabelle che un agente Beancount dovrebbe affrontare.
L'articolo
TableLlama, di Tianshu Zhang, Xiang Yue, Yifei Li e Huan Sun della Ohio State University, ottimizza Llama 2 (7B) su un nuovo dataset di istruzioni di fine-tuning chiamato TableInstruct — 2,6 milioni di esempi che coprono 11 attività relative a tabelle. Per gestire il contesto lungo imposto dalle tabelle, adottano LongLoRA, un approccio di estensione parametricamente efficiente che allunga la finestra di contesto a 8K token senza un riaddestramento completo. La valutazione copre otto attività in-domain (annotazione del tipo di colonna, estrazione di relazioni, entity linking, augmentazione dello schema, popolamento di righe, QA gerarchica su tabelle, QA su celle evidenziate e verifica di fatti) più sei dataset out-of-domain su cui il modello non è mai stato addestrato.
L'affermazione principale: un singolo modello open ottimizzato può eguagliare o superare lo SOTA specifico per attività nella maggior parte dei benchmark in-domain e superare il modello base Llama 2 di 5–44 punti assoluti out-of-domain — incluso il restringimento del divario con GPT-4 in diverse attività.
Idee chiave
- Nei compiti in-domain, TableLlama supera decisamente GPT-4 nei compiti di riconoscimento strutturale: Annotazione del Tipo di Colonna (F1 94,39 vs 31,75), Estrazione di Relazioni (F1 91,95 vs 52,95), BLEU di FeTaQA (39,05 vs 21,70) e accuratezza di esecuzione di HiTab (64,71 vs 48,40).
- Sui dataset out-of-domain, il quadro si capovolge. GPT-4 è in testa nell'accuratezza di WikiTQ (68,40 vs 35,01) e HybridQA (58,60 vs 39,38) — entrambi compiti che richiedono un ragionamento compositivo multi-hop sulle tabelle piuttosto che un semplice pattern matching strutturale.
- WikiSQL mette in luce il divario nella generazione di query in modo netto: TableLlama ottiene il 50,48% rispetto a uno SOTA del 92,70%. Questo divario di 42 punti è il numero più rilevante dal punto di vista pratico per chi costruisce interfacce NL-to-query.
- LongLoRA è fondamentale qui. Le tabelle finanziarie sono lunghe. Senza la finestra di contesto estesa, un modello da 7B non potrebbe gestire questa intera classe di compiti.
- Gli autori riconoscono che i vincoli di calcolo li hanno limitati alla dimensione 7B, lasciando le varianti 13B e 70B non valutate.
Cosa regge — e cosa no
La configurazione del benchmark mescola mele con arance in un modo che merita attenzione. Il confronto in-domain oppone un TableLlama ottimizzato a un GPT-4 zero-shot. Su compiti basati su TURL come l'Annotazione del Tipo di Colonna, il punteggio F1 di 31,75 di GPT-4 non significa che GPT-4 sia fondamentalmente incapace di comprendere i tipi di colonna — significa che un prompt zero-shot senza una formattazione specifica per il compito fallisce su un dataset che si aspetta un formato di output molto particolare. Il confronto onesto è sui compiti out-of-domain, dove entrambi i modelli non hanno visto dati di addestramento, e lì il divario è umiliante: accuratezza WikiTQ 35,01 vs 68,40.
WikiTQ è il test di stress giusto perché richiede domande del tipo "Quale paese ha vinto più medaglie negli eventi in cui il record precedente è stato stabilito prima del 1990?" — un genuino ragionamento compositivo attraverso le celle della tabella. Il deficit di 33 punti di TableLlama su WikiTQ rispetto a GPT-4 è il segnale più chiaro che l'istruzione tuning su compiti strutturali non si trasferisce automaticamente al ragionamento relazionale.
I successi nell'augmentazione dello schema e nell'entity linking sono reali e significativi — quei compiti richiedono genuinamente la comprensione della struttura della tabella in modi con cui un prompt zero-shot di GPT-4 fatica. Ma sono anche più vicini al recupero di informazioni che al ragionamento, il che limita quanto questi risultati possano generalizzarsi.
Una preoccupazione separata: il dataset TableInstruct da 2,6 milioni di esempi è uno sforzo ingegneristico significativo, ma collassa tipi di compiti molto diversi in un unico formato di istruzione. Non c'è un'ablazione che mostri quali tipi di compiti interferiscono tra loro o quali sono fondamentali per i guadagni out-of-domain. Il successivo benchmark di follow-up del gruppo OSU (TableBench, AAAI 2025) ha scoperto che i modelli ottimizzati su TableInstruct raggiungono prestazioni paragonabili a GPT-3.5 ma sono ancora inferiori a GPT-4 — il che attenua considerevolmente l'ottimismo dell'articolo originale.
Perché questo è importante per l'AI finanziaria
I libri mastri di Beancount sono tabelle strutturate: ogni voce ha una data, un conto, un importo e metadati opzionali. I compiti sulle tabelle di questo articolo corrispondono direttamente alle operazioni che un agente Beancount deve eseguire. L'annotazione del tipo di colonna corrisponde alla comprensione di quali conti appartengono a quale tipo di conto (Attività, Passività, Spese). L'entity linking corrisponde alla risoluzione dei nomi dei beneficiari in descrizioni di transazioni inconsistenti. E il divario di WikiSQL corrisponde precisamente al problema dell'interfaccia NL di beanquery.
I risultati qui mi danno una visione calibrata: un modello ottimizzato da 7B può gestire il riconoscimento della struttura del libro mastro in modo sufficientemente affidabile per essere utile, ma non ci si può ancora fidare di tradurre domande in linguaggio libero in espressioni beanquery corrette senza l'intervento di un modello di capacità superiore. L'accuratezza del 50% su WikiSQL (contro il 93% dello SOTA) significa che un'interfaccia beanquery basata solo su modelli open genererebbe query errate circa la metà delle volte su formulazioni di domande non familiari. Per un agente di scrittura, questo tasso di fallimento è troppo alto. Per un'interfaccia di query in sola lettura con revisione umana, potrebbe essere accettabile come prima bozza.
Il contributo di LongLoRA è direttamente applicabile: i libri mastri di Beancount pluriennali possono facilmente superare gli 8K token, e l'approccio qui mostra come ottimizzare per tabelle lunghe senza un costo computazionale proibitivo.
Cosa leggere dopo
- TableBench: A Comprehensive and Complex Benchmark for Table Question Answering (arXiv:2408.09174, AAAI 2025) — il follow-up dello stesso gruppo OSU che valuta oltre 30 LLM su QA di tabelle più complesse e scopre che il divario open-vs-GPT-4 persiste anche dopo il fine-tuning con TableInstruct
- TAPEX: Table Pre-training via Learning a Neural SQL Executor (arXiv:2107.07653, ICLR 2022) — pre-addestramento sull'esecuzione sintetica di SQL come contrappunto all'istruzione tuning; baseline importante per il dibattito pre-addestramento vs fine-tuning nella comprensione delle tabelle
- Rethinking Table Instruction Tuning (arXiv:2501.14693) — lavoro recente che mette in discussione se la ricetta standard di TableInstruct generalizzi effettivamente, e quali scelte di composizione dei dati siano più importanti