Executive summary
Quando le informazioni critiche di un'organizzazione risiedono in basi di dati strutturate, la capacità di interrogarle ponendo domande in linguaggio naturale, senza conoscere il linguaggio tecnico delle interrogazioni, rappresenta un vantaggio operativo concreto. Questo articolo analizza lo stato attuale delle tecniche che traducono automaticamente una domanda formulata in lingua corrente nella corrispondente interrogazione strutturata, esaminando i progressi compiuti negli ultimi anni grazie a modelli di intelligenza artificiale sempre più avanzati. L'analisi evidenzia che, nonostante i risultati raggiunti sui banchi di prova accademici, la traduzione automatica in contesti reali con basi di dati complesse, dati incompleti e schemi articolati resta un problema largamente irrisolto, con tassi di successo che scendono drasticamente rispetto agli scenari semplificati di laboratorio.
Background
Il problema del Text-to-SQL consiste nella traduzione automatica di una domanda espressa in linguaggio naturale in un'interrogazione SQL eseguibile su un database relazionale. Si tratta di un'istanza specifica del più ampio problema del semantic parsing, in cui l'obiettivo è mappare un'espressione linguistica in una rappresentazione formale interpretabile da una macchina [1]. L'interesse per questo problema ha radici profonde nella comunità di ricerca: già negli anni '70, sistemi come LUNAR tentavano di fornire interfacce in linguaggio naturale a basi di dati strutturate. Tuttavia, la complessità intrinseca della lingua naturale, ambiguità lessicale, variabilità sintattica, riferimenti impliciti al contesto, ha reso il problema resistente a soluzioni generalizzabili per decenni.
Il panorama è cambiato radicalmente con l'avvento del deep learning e, più di recente, dei large language model (LLM). Il primo benchmark su larga scala, WikiSQL, introdotto da Zhong et al. nel 2017, ha fornito 80.654 coppie domanda-SQL su tabelle singole estratte da Wikipedia [2]. Sebbene WikiSQL abbia catalizzato la ricerca, le sue limitazioni, interrogazioni limitate a singole tabelle, assenza di JOIN, sotto-query e aggregazioni complesse, hanno motivato la creazione di Spider nel 2018 da parte di Yu et al. [3]. Spider ha introdotto 10.181 domande su 200 database multi-tabella che coprono 138 domini, con la caratteristica cruciale della valutazione cross-domain: i database del test set non compaiono nel training set, richiedendo capacità di generalizzazione autentica.
L'evoluzione dei benchmark riflette una crescente consapevolezza del divario tra scenari accademici e applicazioni reali. Il benchmark BIRD, presentato a NeurIPS 2023, ha introdotto 12.751 coppie su 95 database reali (33,4 GB complessivi) distribuiti su 37 domini professionali, enfatizzando tre sfide trascurate: dati sporchi o incompleti nei database, necessità di conoscenza esterna per collegare domande e contenuti, e efficienza delle query SQL generate su basi di dati massive [4]. Più recentemente, Spider 2.0, accettato come Oral a ICLR 2025, ha spostato ulteriormente l'asticella proponendo 632 problemi derivati da workflow enterprise reali, con database che spesso superano le 1.000 colonne e richiedono l'interazione con piattaforme cloud come BigQuery e Snowflake [5].
Tassonomia degli approcci
A partire dalla letteratura recente, inclusa la survey di Liu et al. su TKDE [6], è possibile identificare tre macro-categorie di approcci al Text-to-SQL nell'era dei LLM. La prima distinzione fondamentale riguarda il paradigma di utilizzo del modello: prompting di modelli pre-addestrati, fine-tuning su dati specifici del dominio, o architetture agentiche multi-componente.
Approcci basati su prompting
Il paradigma dominante nella ricerca recente sfrutta le capacità di in-context learning dei LLM senza modificarne i pesi. La strategia più elementare consiste nel fornire lo schema del database e la domanda in linguaggio naturale come prompt, lasciando al modello il compito di generare direttamente la query SQL. Tuttavia, questa configurazione zero-shot si rivela insufficiente per interrogazioni complesse. DIN-SQL, presentato a NeurIPS 2023, ha dimostrato che la decomposizione del problema in sotto-task, classificazione della difficoltà, schema linking, decomposizione della query e auto-correzione, migliora sistematicamente le prestazioni di circa il 10% rispetto al few-shot diretto, raggiungendo l'85,3% di execution accuracy su Spider [7].
DAIL-SQL ha ulteriormente raffinato il paradigma del prompting introducendo un meccanismo di selezione dinamica degli esempi few-shot (DAIL-Selection) che considera simultaneamente la similarità tra domande e tra query SQL, ottenendo l'86,6% di execution accuracy su Spider [8]. L'analisi sistematica condotta dagli autori, che ha coperto rappresentazione della domanda, selezione degli esempi e organizzazione del prompt, ha evidenziato come la scelta degli esempi few-shot influenzi le prestazioni in misura comparabile alla scelta del modello stesso.
Approcci basati su fine-tuning
Il fine-tuning di modelli open-source su dati Text-to-SQL rappresenta un'alternativa al prompting di modelli proprietari, con vantaggi significativi in termini di costo, latenza e controllo dei dati. OmniSQL, pubblicato su VLDB 2025, ha affrontato il collo di bottiglia della scarsità di dati di addestramento introducendo SynSQL-2.5M, il primo dataset sintetico su scala milionaria con 2,5 milioni di campioni distribuiti su oltre 16.000 database sintetici [9]. I modelli OmniSQL risultanti, disponibili nelle varianti da 7B, 14B e 32B parametri, raggiungono prestazioni competitive o superiori a GPT-4o e DeepSeek-V3 su nove benchmark, dimostrando che il fine-tuning su dati sintetici di alta qualità può colmare il divario con i modelli proprietari più avanzati.
L'approccio del fine-tuning presenta tuttavia limitazioni intrinseche. La generalizzazione cross-domain resta problematica: un modello fine-tuned su un insieme di schemi tende a degradare su schemi significativamente diversi. Inoltre, il costo di generazione e curazione di dati sintetici di qualità non è trascurabile, e la necessità di ri-addestrare il modello quando lo schema del database cambia introduce rigidità operativa.
Architetture agentiche multi-componente
La terza macro-categoria rappresenta l'evoluzione più recente: sistemi multi-agente che orchestrano componenti specializzati per le diverse fasi della pipeline Text-to-SQL. MAC-SQL, presentato a COLING 2025, articola il processo in tre agenti, Selector (riduzione dello schema), Decomposer (generazione SQL con chain-of-thought) e Refiner (correzione iterativa), raggiungendo il 59,59% di execution accuracy su BIRD con GPT-4 [10].
CHASE-SQL, sviluppato da ricercatori affiliati, tra gli altri, a Google e Stanford, ha portato questo paradigma a un livello superiore introducendo tre strategie di generazione parallele: decomposizione divide-and-conquer, ragionamento chain-of-thought basato su piani di esecuzione, e generazione sintetica di esempi instance-aware [11]. Un agente di selezione basato su confronti pairwise sceglie poi il candidato ottimale tra le query generate, raggiungendo il 73,0% di execution accuracy sul test set di BIRD e il 73,01% sul development set. Questo approccio sfrutta il test-time compute per migliorare la qualità della generazione, un principio che si sta affermando trasversalmente nel campo dei LLM.
Benchmark e metriche di valutazione
La valutazione dei sistemi Text-to-SQL si fonda su una gerarchia di benchmark di complessità crescente e su metriche che catturano aspetti complementari della correttezza.
Evoluzione dei benchmark
L'evoluzione dei benchmark traccia una traiettoria chiara verso il realismo. WikiSQL (2017) ha stabilito il formato fondamentale ma si limita a query su tabelle singole [2]. Spider (2018) ha introdotto la complessità multi-tabella e la valutazione cross-domain, diventando rapidamente il benchmark di riferimento [3]. BIRD (2023) ha aggiunto il realismo dei dati sporchi, della conoscenza esterna e della scala [4]. Spider 2.0 (2025) ha rappresentato un salto qualitativo verso workflow enterprise completi, con risultati che hanno nettamente ridimensionato le aspettative: il migliore agente basato su o1-preview risolve solo il 21,3% dei task, contro il 91,2% su Spider 1.0 e il 73,0% su BIRD [5].
Questa progressione rivela un pattern significativo: ogni nuovo benchmark che si avvicina alle condizioni reali produce un crollo delle prestazioni, suggerendo che i risultati sui benchmark più semplici sovrastimano sistematicamente le capacità effettive dei sistemi. Un'analisi recente presentata a CIDR 2026 ha inoltre identificato tassi di errore nelle annotazioni del 52,8% in BIRD e del 66,1% in Spider 2.0-Snow, con variazioni nelle prestazioni relative dei modelli fino al 31% dopo la correzione [12]. Questo dato solleva interrogativi sull'affidabilità delle classifiche stesse.
Metriche di valutazione
Le due metriche principali sono la exact match accuracy (EM) e la execution accuracy (EX). La prima confronta la query generata con la query di riferimento a livello sintattico, verificando la corrispondenza delle clausole SQL. La seconda verifica se la query generata, una volta eseguita sul database, produce lo stesso risultato della query di riferimento [6]. La execution accuracy è generalmente preferita perché tollera variazioni sintattiche equivalenti, due query SQL strutturalmente diverse possono produrre risultati identici. Tuttavia, entrambe le metriche presentano limiti: la EM penalizza query corrette ma formulate diversamente, mentre la EX può produrre falsi positivi quando query errate restituiscono casualmente il risultato corretto su un database specifico.
La test suite accuracy, proposta da Yu et al. [13], affronta parzialmente questo problema eseguendo le query su insiemi di database generati automaticamente per ridurre le coincidenze casuali. Più recentemente, la ricerca si è orientata verso metriche allineate al giudizio umano, riconoscendo che le metriche automatiche esistenti sottostimano la correttezza percepita dagli utenti.
Analisi critica della letteratura recente
L'analisi della letteratura degli ultimi due anni rivela dinamiche che meritano una lettura critica, al di là dei numeri riportati nelle classifiche.
Convergenza delle prestazioni sui benchmark classici
Su Spider, le prestazioni dei migliori sistemi si sono assestate sopra l'85% di execution accuracy, con margini di miglioramento incrementali. DAIL-SQL ha raggiunto l'86,6% [8], mentre approcci successivi hanno ottenuto guadagni dell'ordine di 1-2 punti percentuali. Questa convergenza suggerisce che Spider sia prossimo alla saturazione come strumento di discriminazione tra approcci, un fenomeno già osservato con WikiSQL. Su BIRD, la situazione è più dinamica: dal 40,08% di ChatGPT alla presentazione del benchmark [4] si è passati al 73,0% di CHASE-SQL [11], un progresso notevole ma ancora lontano dalla prestazione umana del 92,96%.
Il ruolo del modello sottostante
Un'osservazione trasversale alla letteratura è che il miglioramento dei risultati Text-to-SQL è correlato in misura sostanziale al progresso dei LLM sottostanti, piuttosto che alle sole innovazioni architetturali delle pipeline. DIN-SQL ha dimostrato un miglioramento del 10% passando da GPT-3.5 a GPT-4 sulla stessa pipeline [7]. Analogamente, RSL-SQL raggiunge il 67,2% su BIRD e l'87,9% su Spider utilizzando GPT-4o [14], ma i risultati calano sensibilmente con modelli meno capaci. Questo solleva una questione metodologica: quanto del progresso osservato è attribuibile alle innovazioni nella pipeline, e quanto alla crescente capacità dei modelli di base?
Dati sintetici e scalabilità dell'addestramento
L'approccio di OmniSQL [9] suggerisce che la generazione di dati sintetici su larga scala possa rappresentare un moltiplicatore di capacità per modelli open-source di dimensioni contenute. I modelli OmniSQL da 7B a 32B parametri, addestrati su SynSQL-2.5M, competono con modelli proprietari di ordini di grandezza superiori. Tuttavia, la qualità dei dati sintetici è critica: errori sistematici nella generazione si propagano come bias nel modello addestrato, e la copertura delle strutture SQL complesse richiede un design attento della pipeline di sintesi. È significativo osservare come questo risultato metta in discussione l'assunto secondo cui modelli più grandi siano necessariamente superiori per il Text-to-SQL: la qualità e la scala dei dati di addestramento possono compensare differenze di ordini di grandezza nella dimensione del modello, un'indicazione rilevante per il design di soluzioni cost-effective in contesti produttivi.
Schema linking: ruolo e controversie
Lo schema linking, il processo di identificazione delle tabelle e colonne del database rilevanti per una data domanda, rappresenta un componente tradizionalmente considerato essenziale nelle pipeline Text-to-SQL. La sua funzione è duplice: ridurre il rumore presentato al modello generativo e stabilire un collegamento esplicito tra gli elementi linguistici della domanda e gli elementi strutturali dello schema.
L'argomento a favore
In database di scala enterprise, lo schema può contenere centinaia o migliaia di colonne. Includere l'intero schema nel prompt non solo consuma una porzione significativa della finestra di contesto del LLM, ma introduce rumore semantico che degrada la qualità della generazione SQL. LinkAlign, presentato a EMNLP 2025, ha affrontato sistematicamente questa sfida proponendo un framework multi-round che combina riscrittura della query, allineamento semantico e filtraggio del rumore per ambienti multi-database reali [15]. RSL-SQL ha dimostrato che uno schema linking bidirezionale raggiunge un recall del 94% riducendo dell'83% il numero di colonne presentate al modello, con un impatto diretto sulla execution accuracy [14].
L'argomento contrario
Maamari e Abubaker, in un lavoro presentato a NeurIPS 2024, hanno provocatoriamente intitolato il loro studio "The Death of Schema Linking?" [16]. La tesi centrale è che i LLM di ultima generazione, dotati di capacità di ragionamento più sofisticate, sono in grado di identificare autonomamente gli elementi rilevanti dello schema durante la generazione SQL, anche in presenza di rumore sostanziale. Il loro approccio, che elimina completamente la fase di schema linking quando l'intero schema entra nella finestra di contesto, ha raggiunto il 71,83% di execution accuracy su BIRD, primo in classifica al momento della pubblicazione. L'analisi dimostra che il beneficio della riduzione del rumore diminuisce al migliorare delle capacità di ragionamento del modello.
Una sintesi critica
La tensione tra questi due orientamenti rivela un trade-off fondamentale. Lo schema linking introduce un rischio di perdita di informazione irreversibile: se una tabella o colonna necessaria viene scartata nella fase di filtro, la query risultante sarà necessariamente errata, indipendentemente dalla qualità del generatore SQL. D'altra parte, l'assenza di schema linking su database di grande scala impone vincoli stringenti sulla lunghezza del contesto e sul costo computazionale dell'inferenza. La risoluzione di questa tensione dipenderà probabilmente dall'evoluzione congiunta delle finestre di contesto dei LLM e delle tecniche di compressione degli schemi, piuttosto che da una vittoria definitiva di uno dei due paradigmi.
Problemi aperti e direzioni future
Nonostante i progressi documentati, diversi problemi fondamentali restano irrisolti e definiscono l'agenda di ricerca per i prossimi anni.
Il divario tra benchmark e produzione
Il risultato più eloquente della ricerca recente è il crollo delle prestazioni su Spider 2.0: dal 91,2% su Spider 1.0 al 21,3% su task enterprise reali [5]. Questo divario non è un artefatto metodologico, ma riflette la complessità autentica dei workflow SQL in contesti produttivi: query multi-dialetto che superano le 100 righe, necessità di navigare metadati e documentazione, interazione con sistemi cloud distribuiti. Colmare questo divario richiede non solo modelli più capaci, ma un ripensamento dell'architettura dei sistemi Text-to-SQL come agenti che interagiscono iterativamente con l'ambiente del database.
Robustezza e affidabilità
In un contesto enterprise, un sistema Text-to-SQL che produce query errate nel 30-40% dei casi non è semplicemente impreciso: è potenzialmente pericoloso. Una query errata su dati finanziari o operativi può portare a decisioni basate su informazioni incorrette senza che l'utente sia in grado di verificare la correttezza della traduzione. La ricerca sulla calibrazione dell'incertezza, la capacità del sistema di segnalare quando non è sicuro della traduzione, è ancora ai primi stadi. Meccanismi di auto-verifica come quelli introdotti in DIN-SQL [7] e nel Refiner di MAC-SQL [10] rappresentano passi nella direzione corretta, ma sono ancora lontani dal fornire garanzie formali.
Valutazione multi-dimensionale
L'inadeguatezza delle metriche correnti è un problema riconosciuto ma non risolto. La execution accuracy può produrre falsi positivi, la exact match penalizza variazioni legittime, e nessuna delle due cattura la correttezza semantica rispetto all'intento dell'utente [12]. La comunità sta convergendo verso la necessità di benchmark dinamici che evitino la contaminazione dei dati di addestramento, e di metriche composite che integrino correttezza sintattica, semantica e pragmatica.
Interazione conversazionale e contesto
I benchmark attuali valutano prevalentemente domande isolate, ma l'interazione reale con un database è intrinsecamente conversazionale. BIRD-Interact, accettato come Oral a ICLR 2026, ha iniziato ad affrontare questa dimensione con modalità conversazionali e agentiche, ma i risultati, 24,4% di success rate per o3-mini in modalità conversazionale e 17,78% per Claude-3.7-Sonnet in modalità agentica, evidenziano quanto il problema sia ancora aperto [17]. La gestione di riferimenti anaforici, correzioni incrementali e contesto accumulato lungo una sessione rappresenta una frontiera che richiede architetture significativamente diverse da quelle attuali.
Verso sistemi enterprise-ready
L'adozione in produzione richiede la risoluzione simultanea di problemi che la ricerca affronta tipicamente in isolamento: gestione di schemi che evolvono nel tempo, supporto per dialetti SQL multipli, integrazione con sistemi di autenticazione e autorizzazione, spiegabilità delle query generate, e costi computazionali sostenibili. La survey di Luo et al. su VLDB 2025 identifica il divario tra ricerca accademica e requisiti industriali come il problema aperto più critico per il campo [1]. L'emergere di soluzioni open-source come OmniSQL [9] e di framework agentici come CHASE-SQL [11] suggerisce una traiettoria verso sistemi modulari e componibili, ma la maturità per un deployment enterprise affidabile richiede ancora progressi sostanziali.
Riferimenti
[1] Y. Luo et al., "Natural Language to SQL: State of the Art and Open Problems," in Proc. VLDB Endowment, Vol. 18, 2025. https://www.vldb.org/pvldb/vol18/p5466-luo.pdf
[2] V. Zhong, C. Xiong, R. Socher, "Seq2SQL: Generating Structured Queries from Natural Language using Reinforcement Learning," arXiv:1709.00103, 2017. https://arxiv.org/abs/1709.00103
[3] T. Yu et al., "Spider: A Large-Scale Human-Labeled Dataset for Complex and Cross-Domain Semantic Parsing and Text-to-SQL Task," in Proc. EMNLP, 2018. https://aclanthology.org/D18-1425/
[4] J. Li et al., "Can LLM Already Serve as A Database Interface? A BIg Bench for Large-Scale Database Grounded Text-to-SQLs," in Proc. NeurIPS, 2023. https://arxiv.org/abs/2305.03111
[5] F. Lei et al., "Spider 2.0: Evaluating Language Models on Real-World Enterprise Text-to-SQL Workflows," in Proc. ICLR (Oral), 2025. https://arxiv.org/abs/2411.07763
[6] X. Liu et al., "A Survey of Text-to-SQL in the Era of LLMs: Where are we, and where are we going?," IEEE Trans. Knowledge and Data Engineering, 2025. https://arxiv.org/abs/2408.05109
[7] M. Pourreza, D. Rafiei, "DIN-SQL: Decomposed In-Context Learning of Text-to-SQL with Self-Correction," in Proc. NeurIPS, 2023. https://arxiv.org/abs/2304.11015
[8] D. Gao et al., "Text-to-SQL Empowered by Large Language Models: A Benchmark Evaluation," in Proc. VLDB Endowment, Vol. 17, No. 5, 2024. https://arxiv.org/abs/2308.15363
[9] H. Li et al., "OmniSQL: Synthesizing High-quality Text-to-SQL Data at Scale," in Proc. VLDB Endowment, Vol. 18, No. 11, 2025. https://arxiv.org/abs/2503.02240
[10] B. Wang et al., "MAC-SQL: A Multi-Agent Collaborative Framework for Text-to-SQL," in Proc. COLING, 2025. https://arxiv.org/abs/2312.11242
[11] M. Pourreza et al., "CHASE-SQL: Multi-Path Reasoning and Preference Optimized Candidate Selection in Text-to-SQL," arXiv:2410.01943, 2024. https://arxiv.org/abs/2410.01943
[12] F. Jin et al., "Text-to-SQL Benchmarks are Broken: An In-Depth Analysis of Annotation Errors," in Proc. CIDR, 2026. https://vldb.org/cidrdb/papers/2026/p5-jin.pdf
[13] R. Zhong, T. Yu, D. Klein, "Semantic Evaluation for Text-to-SQL with Distilled Test Suites," in Proc. EMNLP, 2020. https://aclanthology.org/2020.emnlp-main.29/
[14] R. Cao et al., "RSL-SQL: Robust Schema Linking in Text-to-SQL Generation," arXiv:2411.00073, 2024. https://arxiv.org/abs/2411.00073
[15] S. Gu et al., "LinkAlign: Scalable Schema Linking for Real-World Large-Scale Multi-Database Text-to-SQL," in Proc. EMNLP, 2025. https://aclanthology.org/2025.emnlp-main.51.pdf
[16] K. Maamari, A. Abubaker, "The Death of Schema Linking? Text-to-SQL in the Age of Well-Reasoned Language Models," arXiv:2408.07702, 2024. https://arxiv.org/abs/2408.07702
[17] J. Li et al., "BIRD-Interact: A Comprehensive Interactive Benchmark for Text-to-SQL," in Proc. ICLR (Oral), 2026. https://bird-bench.github.io/