Ho passato del tempo sulla linea text-to-SQL — BIRD, DIN-SQL, MAC-SQL — ma tutte condividono un presupposto che voglio mettere in discussione: che l'interfaccia giusta per la QA su tabelle sia generare SQL. TAPAS, pubblicato da Herzig et al. presso Google Research (ACL 2020), scommette sull'opposto. Non genera mai una query. Invece si limita a selezionare celle e opzionalmente applica un'aggregazione scalare, addestrato end-to-end solo a partire dalle denotazioni delle risposte.
L'articolo
TAPAS estende BERT per codificare tabelle aggiungendo sei nuove dimensioni di embedding in aggiunta ai classici ID di posizione e segmento. L'ID Colonna e l'ID Riga marcano dove ogni token si trova nella griglia della tabella. Un ID Rango codifica l'ordine numerico relativo all'interno di colonne ordinabili (rango 0 significa non confrontabile, rango i+1 per l'i-esimo valore più piccolo). Un indicatore di Risposta Precedente segnala le celle che sono state selezionate nel turno conversazionale precedente. Combinato con l'embedding binario di segmento che distingue i token della domanda dai token della tabella, questo dà a TAPAS la sua rappresentazione token a sette tipi.
Al momento dell'inferenza, il modello seleziona un insieme di celle applicando una soglia alle probabilità per cella, poi applica uno dei quattro operatori di aggregazione — NESSUNO, CONTA, SOMMA o MEDIA — per produrre la risposta finale. Non esiste SQL o forma logica intermedia. Il pre-addestramento esegue un obiettivo standard di modello linguistico mascherato su 6,2 milioni di coppie tabella-testo da Wikipedia in inglese.
Idee chiave
- Gli embedding di colonna/riga sono fondamentali. L'ablazione mostra che rimuoverli costa 19,4 punti di accuratezza su SQA, 10,6 su WikiSQL e 11,6 su WikiTQ — molto più di qualsiasi altro componente architetturale.
- Il pre-addestramento sulle tabelle è quasi altrettanto importante. Rimuoverlo fa scendere SQA di 12,5 punti e WikiTQ di 11,1 punti anche dopo il fine-tuning.
- Su SQA (QA conversazionale su tabelle), TAPAS aumenta l'accuratezza dal 55,1% al 67,2%, un balzo di 12 punti. L'embedding del token di Risposta Precedente è il meccanismo che fa funzionare il riporto conversazionale senza un tracker di stato separato.
- Su WikiSQL (tabella singola, per lo più ricerche e aggregazioni), TAPAS raggiunge l'83,6% — essenzialmente eguagliando l'83,9% del parser semantico SOTA, con zero generazione di SQL.
- L'apprendimento per trasferimento da WikiSQL a WikiTQ (ragionamento multi-passaggio, multi-colonna) produce il 48,7%, 4,2 punti sopra lo stato dell'arte all'epoca. Il trasferimento da SQA dà il 48,8%.
- La supervisione debole è l'affermazione chiave di accessibilità economica: il modello è addestrato su coppie (domanda, risposta), non triple (domanda, SQL, risposta), quindi puoi annotare grandi corpora senza competenze SQL.
Cosa regge — e cosa no
L'intuizione centrale — che molte domande di QA su tabelle possono essere risposte selezionando celle e applicando una di quattro operazioni scalari — è empiricamente solida per i benchmark testati. Ma l'onesta analisi degli errori dell'articolo su WikiTQ è rivelatrice: il 37% degli errori non è classificato dagli stessi autori, il 16% richiede manipolazioni di stringhe che il modello non può fare, e il 10% coinvolge ragionamenti temporali complessi. Ciò significa che il tetto di TAPAS non riguarda il fatto che gli operatori di aggregazione siano sbagliati; riguarda intere categorie di domande strutturalmente fuori portata.
Il vincolo dei 512 token è un muro duro. Le tabelle con più di circa 500 celle devono essere troncate, e il modello non ha alcun meccanismo per il ragionamento su più tabelle. Questo non è un problema di ottimizzazione — è architetturale. Il modello inoltre non può annidare aggregazioni: una domanda come "quanti conti hanno un saldo medio maggiore di zero?" richiede due passaggi (media all'interno di un predicato CONTA), che la testa a quattro operatori non può esprimere.
TAPEX (ICLR 2022) affronta direttamente il collo di bottiglia del pre-addestramento sostituendo il MLM su tabelle di Wikipedia con l'esecuzione sintetica di SQL su programmi auto-generati, spingendo WikiTQ al 57,5% (+4,8) e SQA al 74,5% (+3,5). Questo è un divario significativo. Ma TAPEX eredita gli stessi limiti architetturali sulla dimensione della tabella e la profondità compositiva.
La domanda irrisolta più profonda che nessuno dei due articoli affronta è se il paradigma di selezione delle celle sia una scelta migliore per la QA su tabelle nel mondo reale rispetto alla generazione di SQL su basi pratiche — non l'accuratezza del benchmark, ma la verificabilità e le garanzie di correttezza. Selezionare celle è opaco: ottieni una risposta ma nessun programma. La generazione di SQL è verbosa ma verificabile. Per l'uso in produzione, questo compromesso conta più di qualche punto di accuratezza.
Perché questo è importante per la finanza basata sull'AI
Un ledger Beancount è effettivamente una tabella piatta e strutturata: conti nelle righe, importi, date, valute e tag nelle colonne. Il paradigma diretto di selezione delle celle di TAPAS si mappa naturalmente sulle interrogazioni più comuni del ledger — "qual è il totale speso per la spesa a marzo?" — che sono esattamente aggregazioni SOMMA e CONTA su righe filtrate. L'embedding di Risposta Precedente è direttamente utile per sessioni conversazionali in cui un utente perfeziona una query ("e per l'anno scorso?").
Ma i ledger Beancount su larga scala infrangono i vincoli di TAPAS. Un ledger pluriennale con migliaia di transazioni supera il budget di 512 token di diversi ordini di grandezza. Le gerarchie di conti richiedono ragionamento su gruppi di righe. Query come "quali conti hanno un deflusso netto maggiore della loro media negli ultimi tre anni?" necessitano di aggregazioni annidate che la testa a quattro operatori non può esprimere. E, in modo critico: per la sicurezza del write-back, la selezione di celle non fornisce un programma verificabile da controllare prima di impegnare una modifica. SQL almeno fornisce un artefatto ispezionabile.
La mia conclusione provvisoria è che il paradigma di selezione delle celle è l'interfaccia giusta per un livello di interrogazione in linguaggio naturale in sola lettura su piccole istantanee di ledger — un mese di transazioni, la storia di un singolo conto. Per il ragionamento sull'intero ledger e qualsiasi cosa che coinvolga write-back, un approccio di sintesi di programma (sia in stile SQL che DSL Beancount) rimane più sicuro e più espressivo.
Cosa leggere dopo
- TAPEX: Table Pre-training via Learning a Neural SQL Executor (arXiv:2107.07653, ICLR 2022) — il successore diretto che sostituisce il MLM di Wikipedia con l'esecuzione sintetica di SQL; risponde direttamente se il pre-addestramento su programmi batte il pre-addestramento su testo per la QA su tabelle
- Binder: Binding Language Models in Symbolic Languages (arXiv:2210.02875) — usa GPT-3 per generare programmi in SQL o Python su tabelle e raggiunge SOTA su WikiTQ; l'approccio ibrido con cui i sostenitori della selezione di celle devono confrontarsi
- OmniTab: Natural and Artificially Structured Data for Table QA (arXiv:2207.02270) — combina corpora di tabelle naturali con dati SQL sintetici in una singola ricetta di pre-addestramento; testa se TAPAS e TAPEX sono complementari piuttosto che in competizione