La scorsa settimana ho trattato BIRD, il benchmark che ha rivelato quanto gli LLM inciampano quando il text-to-SQL passa da database giocattolo curati a schemi del mondo reale con denominazioni disordinate, conoscenza di dominio e vincoli di efficienza. DIN-SQL è l'articolo che avrei dovuto leggere prima: ha definito ciò che una pipeline di prompting LLM accuratamente decomposta può effettivamente raggiungere su Spider e BIRD, ed è arrivato a NeurIPS 2023 da Mohammadreza Pourreza e Davood Rafiei proprio mentre GPT-4 diventava ampiamente disponibile. Leggerlo ora — dopo che BIRD ha esposto il limite — rende molto più facili da vedere chiaramente i punti di forza e i limiti.
L'articolo
DIN-SQL (arXiv:2304.115) affronta un netto divario di prestazioni. All'inizio del 2023, i migliori modelli ottimizzati — RESDSQL-3B+NatSQL — raggiungevano il 79,9% di accuratezza di esecuzione sul set di test di Spider, mentre GPT-4 con prompting naive few-shot riusciva solo al 67,4% sul set di sviluppo. L'ipotesi di Pourreza e Rafiei è che questo divario sia principalmente un problema di interfaccia: gli LLM sono abbastanza capaci, ma generare SQL in un unico passaggio chiede loro di risolvere il collegamento dello schema, la classificazione della complessità e la sintesi della query tutto in una volta. Decomponi questi in sotto-attività sequenziali e alimenta ogni soluzione in avanti come contesto, e la storia cambia.
La loro pipeline ha quattro fasi: (1) un modulo di collegamento dello schema che usa il prompting chain-of-thought per mappare la domanda in linguaggio naturale a colonne e valori specifici nello schema; (2) un modulo di classificazione e decomposizione che classifica la query in facile (tabella singola, nessun join), complessa non annidata (join ma nessuna sottoquery), o complessa annidata (join, sottoquery, operazioni di insieme) e, per query annidate, scompone il problema in sottoquery; (3) un modulo di generazione SQL che abbina la strategia di prompting alla classe di complessità — few-shot semplice per facile, rappresentazione intermedia NatSQL per complesso non annidato, chain-of-thought multi-step per complesso annidato; e (4) un modulo di autocorrezione che chiede al modello di rivedere il proprio output per errori minori come DISTINCT mancante o DESC fuori posto.
Idee chiave
- GPT-4 + DIN-SQL raggiunge l'85,3% di accuratezza di esecuzione sul set di test holdout di Spider, un salto di +5,4 punti rispetto al precedente SOTA ottimizzato RESDSQL-3B+NatSQL (79,9%), senza dati di addestramento specifici per l'attività.
- Sul dev di Spider, la pipeline di decomposizione porta GPT-4 dal 67,4% (baseline few-shot) al 74,2% — un guadagno netto di +6,8 punti. CodeX Davinci passa dal 61,5% al 69,9%.
- L'ablazione conferma che ogni fase contribuisce: rimuovere il solo collegamento dello schema fa scendere CodeX dal 69,9% al 65,9%; rimuovere la classificazione lo porta ulteriormente al 63,1%.
- I guadagni sono concentrati nelle query facili e medie. Sulle query "extra hard", anche la pipeline completa DIN-SQL + GPT-4 raggiunge solo il 43,4% sul dev di Spider — la decomposizione non risolve la complessità, riduce solo gli errori evitabili su query trattabili.
- L'autocorrezione è sensibile al modello: GPT-4 risponde a prompt "gentili" che chiedono potenziali miglioramenti; CodeX risponde meglio a prompt "generici" che assumono che l'SQL sia sbagliato. Ciò suggerisce che il modulo sta facendo una pulizia stilistica, non una verifica semantica reale.
- Sul dev di BIRD, DIN-SQL + GPT-4 ottiene un punteggio del 50,72% rispetto a una baseline GPT-4 semplice del 46,35% — un miglioramento di +4,4 punti, sostanzialmente inferiore ai guadagni di Spider, su cui tornerò.
Cosa regge — e cosa no
Il risultato centrale è reale. Decomporre text-to-SQL in sotto-attività esplicite migliora le prestazioni, e gli studi di ablazione sono sufficientemente puliti per credere ai contributi dei singoli moduli. Il collegamento dello schema è la cosa più importante per le query difficili, il che ha senso: il modello non può generare JOIN corretti se prima non ha identificato correttamente a quali tabelle e colonne si riferisce la domanda.
Ma diverse cose mi danno da pensare. La discrepanza tra il 74,2% sul dev e l'85,3% sul test è sospetta. I set di sviluppo sono solitamente più difficili o almeno altrettanto difficili dei set di test perché i modelli sono implicitamente ottimizzati su di essi; un salto di +11 punti dal dev al test è insolito. Gli autori non spiegano questo, e mi fa chiedere se il set di test abbia una distribuzione diversa di difficoltà delle query, o se ci sia qualcosa nel modo in cui viene valutato il test holdout (tramite il server ufficiale della classifica di Spider) che differisce dalla loro valutazione sul dev. Non citerei l'85,3% senza questa precisazione.
Il divario su BIRD (50,72% sul dev) è notevolmente inferiore ai guadagni di Spider. I database BIRD hanno schemi del mondo reale disordinati con nomi di colonna abbreviati, terminologia specifica del dominio e valori ambigui. Il modulo di collegamento dello schema di DIN-SQL è stato progettato pensando agli schemi relativamente puliti di Spider; quando gli schemi diventano più sporchi, l'accuratezza del collegamento diminuisce e il resto della pipeline si degrada con essa. Questo è esattamente ciò che l'articolo di BIRD ha misurato, e DIN-SQL non lo risolve.
I numeri di costo e latenza sono un problema per qualsiasi sistema di produzione: circa $0,50 e 60 secondi per domanda con GPT-4. Va bene per un analista di dati che esegue dieci query al giorno, ma è completamente inutilizzabile per un uso interattivo. L'articolo presenta questo come una limitazione nota, ma non propone un percorso per ridurla. DAIL-SQL (arXiv:2308.15363), apparso pochi mesi dopo, avrebbe mostrato che una migliore selezione degli esempi anziché una decomposizione esplicita potrebbe raggiungere l'86,6% su Spider — superando DIN-SQL a un costo significativamente inferiore.
Il modulo di autocorrezione è la parte più debole. Gli autori riconoscono che coglie errori "minori". Quello che non può fare è rilevare errori semantici — casi in cui l'SQL generato è sintatticamente valido e viene persino eseguito, ma risponde alla domanda sbagliata. Questa è la modalità di errore più difficile per gli utenti reali.
Perché questo è importante per la finanza AI
Beanquery (BQL) è un linguaggio di query simile a SQL per i dati contabili di Beancount. Ha la propria struttura di tabelle — transactions, postings, balance, prices — con gerarchie di conti, tag e campi di metadati che non assomigliano affatto agli schemi di database generici. Un'interfaccia in linguaggio naturale per BQL è una cosa reale e utile (esiste già un server beanquery-mcp sperimentale che implementa esattamente questo tramite MCP), e la strategia di decomposizione di DIN-SQL è il punto di partenza giusto.
Il collegamento dello schema su BQL è il problema analogo al collegamento dello schema su tabelle relazionali, ma con due complicazioni in più: i nomi dei conti sono percorsi gerarchici come Assets:US:Checking:Bank, e lo schema rilevante dipende dal tipo di query che l'utente sta chiedendo (conto economico, stato patrimoniale, flusso di cassa). Il modulo di classificazione di DIN-SQL suggerisce un adattamento diretto: classificare prima l'intento della query (saldo vs. flusso vs. ricerca prezzo), poi instradare verso diversi modelli di prompt.
Il risultato del benchmark BIRD secondo cui il disordine del mondo reale danneggia il text-to-SQL degli LLM è direttamente rilevante. Anche un libro mastro di Beancount è "disordinato" — nomi di conti definiti dall'utente, simboli di merce incoerenti, chiavi di metadati personalizzate. Il miglioramento di 4,4 punti su BIRD rispetto al miglioramento di 6,8 punti su Spider mi dice che il regime di schema strutturato e pulito sopravvaluta quanto la decomposizione aiuterà sulle query BQL effettive. Aspettati guadagni minori nella pratica.
Il vincolo di costo è reale ma meno vincolante qui. Un utente di finanza personale che esegue 10–20 query al giorno può tollerare costi API di $5–10/giorno se l'interfaccia è genuinamente utile. La latenza (60 secondi) è più un problema per l'uso interattivo; l'elaborazione batch di query analitiche potrebbe aggirarlo.
Cosa leggere dopo
- DAIL-SQL: Text-to-SQL Empowered by Large Language Models: A Benchmark Evaluation (arXiv:2308.15363) — studio sistematico delle strategie di ingegneria dei prompt; raggiunge l'86,6% su Spider concentrandosi sulla selezione degli esempi anziché sulla decomposizione architetturale, un utile contrappunto a DIN-SQL
- RESDSQL: Decoupling Schema Linking and Skeleton Parsing for Text-to-SQL (arXiv:2302.05965, AAAI 2023) — la baseline ottimizzata che DIN-SQL ha battuto; capire cosa fa bene l'approccio ottimizzato chiarisce dove il prompting è ancora carente
- MAC-SQL: A Multi-Agent Collaborative Framework for Text-to-SQL (arXiv:2312.11242) — estende l'idea di decomposizione multi-step in una pipeline multi-agente esplicita con un Selettore, un Decompositore e un Raffinatore; raggiunge il 59,59% su BIRD con GPT-4 ed è l'approccio più incentrato sugli agenti nel settore