Text-to-SQL: Confronto dell'accuratezza dei LLM

Ho fatto affidamento su SQL per l'analisi dei dati per 18 anni, a partire dai miei giorni come consulente. Tradurre domande in linguaggio naturale in SQL rende i dati più accessibili, consentendo a chiunque, anche a chi non ha competenze tecniche, di lavorare direttamente con i database.

Abbiamo utilizzato la nostra text-to-SQL metodologia di benchmark su oltre 35 modelli linguistici di grandi dimensioni (LLMs) per valutare le loro prestazioni nella generazione di comandi SQL:

Errori comuni nel SQL generato da LLM

I LLMs commettono spesso quattro tipi di errori: join errati, errori di aggregazione, filtri mancanti ed errori di sintassi.

Logica di join errata

I modelli spesso hanno difficoltà a identificare e implementare correttamente le operazioni di `JOIN` necessarie tra le tabelle, a volte omettendole completamente o utilizzando in modo errato sottoquery meno ottimali.

Il LLM non è riuscito a unire correttamente le tabelle `frpm` e `schools` utilizzando il `CDSCode`. Ha anche allucinato nomi di colonne (`Charter`) e valori di filtro (`County = ‘Fresno’`).

Gli errori nella logica di join compromettono fondamentalmente l'aspetto relazionale della query, portando a un recupero dei dati incompleto o errato quando sono coinvolte più tabelle.

Errori di aggregazione e raggruppamento

Applicare in modo errato le funzioni di aggregazione (come `MAX`, `AVG`, `COUNT`, `SUM`) o le clausole `GROUP BY` è stato un altro punto di errore comune, portando a risultati che non corrispondevano semanticamente all'intento dell'utente.

Il LLM ha identificato correttamente che la frase "punteggio medio più alto" richiede di raggruppare i dati per distretto (GROUP BY dname) e di utilizzare una funzione di aggregazione (AVG(AvgScrRead)). Questa parte della logica è corretta.

Tuttavia, il LLM non è riuscito a incorporare un filtro critico dalla domanda: la parola "attivo". Per soddisfare questo requisito, la query avrebbe dovuto unire la tabella satscores con la tabella schools e poi filtrare i risultati con una clausola WHERE T1.StatusType = 'Active'.

Questo evidenzia un errore comune dei LLM: eseguire correttamente un'istruzione primaria e ovvia (calcolare una media) mancando una condizione secondaria ma altrettanto importante (filtrare per stato). Ciò mostra una debolezza nel sintetizzare più vincoli in un'unica query corretta.

Filtri mancanti o errati

I modelli a volte non riuscivano a includere le clausole `WHERE` necessarie o selezionavano le colonne sbagliate nell'istruzione `SELECT`, non affrontando completamente i vincoli o le informazioni esplicitamente richieste nel prompt.

Il LLM ha identificato correttamente la logica per trovare la scuola (`ORDER BY NumGE1500 DESC LIMIT 1`), ma non è riuscito a selezionare il numero `Phone` richiesto e ha omesso il join necessario alla tabella `schools` per recuperarlo.

Questi errori spesso derivano da un'analisi incompleta della richiesta dell'utente o dalla mancata mappatura di tutte le parti della richiesta ai componenti finali della query SQL.

Errori di sintassi

Oltre agli errori semantici, si sono verificati errori di sintassi veri e propri, come l'uso di alias di tabella errati o la produzione di istruzioni SQL incomplete, che impediscono l'esecuzione della query.

Il LLM ha utilizzato alias errati (`accounts` invece di `account`) e ha incluso un valore stringa incompleto (`'POPLATEK PO OBRATU…'`), risultando in una sintassi SQL non valida.

Questi problemi di sintassi evidenziano le difficoltà nel generare codice che aderisca rigorosamente alla grammatica SQL e alle convenzioni specifiche del database.

Perché alcuni LLM sono migliori con SQL

Diversi fattori chiave determinano quanto bene un modello linguistico di grandi dimensioni (LLM) possa trasformare una semplice domanda in inglese in una query SQL corretta per il database.

1. Dimensioni del modello e dati di addestramento

• Dimensioni e progettazione: I modelli più grandi o quelli costruiti con strutture specifiche possono gestire compiti complessi, come la generazione di SQL, in modo più efficace.
• Cosa ha appreso: I dati utilizzati per addestrare l'LLM sono essenziali. Se vede molti esempi di domande collegate a risposte SQL, specialmente quelle che coinvolgono operazioni complesse come join o calcoli (SUM, AVG), è probabile che ottenga prestazioni migliori.

2. Fine-tuning per compiti SQL

• I modelli possono essere sottoposti a un addestramento extra specificamente focalizzato sui compiti text-to-SQL. Questo “fine-tuning” li aiuta a comprendere le strutture dei database e le regole SQL in modo più efficace rispetto ai modelli addestrati su testo generale. Anche l'addestramento su istruzioni specifiche aiuta.

3. Capacità di ragionamento e mappatura dello schema

• Ragionamento: Quanto bene riesce l'LLM a capire i passaggi esatti necessari a partire da una domanda a volte vaga? Creare SQL spesso richiede passaggi logici.
• Comprendere la mappa del database (Schema): Alcuni LLMs sono più bravi a collegare i concetti della domanda (come "clienti" o "vendite totali") ai nomi effettivi di tabelle e colonne nel database, anche se i nomi non sono immediatamente ovvi.

Come i LLM generano SQL: Uno sguardo passo dopo passo

Per vedere in azione fattori come “ragionamento” e “mappatura dello schema”, vediamo passo dopo passo il processo che un modello segue per generare una query. L'intero flusso di lavoro è alimentato da una tecnica chiamata Retrieval-Augmented Generation (RAG).

Fase 1: Analisi iniziale e selezione del database

Quando gli viene presentata una domanda, il LLM analizza innanzitutto l'intento dell'utente per selezionare lo strumento di database più pertinente.

• Domanda: “Quanti account hanno una disposizione del proprietario e richiedono la generazione di un estratto conto in caso di transazione?”
• Azione del LLM: Il modello identifica parole chiave come “account”, “disposizione” e “transazione”. Conclude che lo strumento di database financial è la scelta corretta rispetto ad altri come california_schools o superhero.

Fase 2: Recupero dello schema tramite RAG

Una volta scelto uno strumento, il modello ha bisogno della “mappa” del database, lo schema. Non ha queste informazioni memorizzate. Invece, il sistema RAG le recupera in tempo reale.

1. Recupero: La domanda dell'utente viene utilizzata per cercare in un database vettoriale che memorizza le informazioni sullo schema. La ricerca trova e recupera i dettagli dello schema più pertinenti, come le definizioni delle tabelle accounts e disp.
2. Augmentazione: Il testo dello schema recuperato viene automaticamente inserito nel prompt insieme alla domanda originale.
3. Generazione: Il LLM ora dispone di tutto il contesto necessario per procedere.

Questo processo RAG garantisce che il modello riceva le informazioni sullo schema necessarie, rendendo il suo compito più mirato ed efficiente.

Fase 3: Ragionamento e costruzione della query

Con la domanda e lo schema fornito da RAG, il modello mappa i concetti della richiesta dell'utente sui nomi specifici di tabelle e colonne che ha appena ricevuto.

Monologo interno del LLM:

1. Obiettivo: L'utente vuole un conteggio, quindi inizierò con SELECT COUNT(...).
2. Condizioni:
   • “…disposizione del proprietario…” -> Lo schema della tabella disp ha una colonna type. Ho bisogno di una clausola WHERE per type = 'OWNER'.
   • “…estratto conto da generare in caso di transazione…” -> Lo schema della tabella accounts ha una colonna frequency. Il filtro dovrebbe essere frequency = 'POPLATEK PO OBRATU'.
3. Join: Le informazioni sono suddivise tra le tabelle accounts e disp. Lo schema mostra che sono collegate tramite account_id, quindi ho bisogno di JOIN.

Fase 4: Generazione del SQL finale

Infine, il modello assembla questi pezzi logici in una query SQL sintatticamente corretta. La qualità di questo output dipende da:

1. Capacità di ragionamento: La capacità del modello di collegare logicamente la richiesta dell'utente allo schema fornito.
2. Conoscenza di SQL dall'addestramento: La comprensione fondamentale da parte del modello della sintassi e delle funzioni SQL.

Questo processo spiega perché si verificano errori. Se lo schema recuperato è ambiguo o un termine nella domanda non mappa chiaramente, l'LLM deve fare una supposizione informata, che può portare agli errori analizzati in precedenza.

Cos'è il text-to-SQL?

Il text-to-SQL è una tecnologia di elaborazione del linguaggio naturale che converte il linguaggio quotidiano in una query SQL scritta in linguaggio di query strutturato. Invece di scrivere manualmente il codice SQL, un utente pone una domanda in linguaggio naturale e il sistema genera un'istruzione SQL che può essere eseguita su un database.

Lo scopo principale del text-to-SQL è ridurre il divario tra come le persone pensano ai dati e come i database richiedono che le query vengano scritte. Ciò è particolarmente rilevante per gli utenti non tecnici e gli analisti di dati che comprendono il contesto aziendale ma potrebbero non sentirsi a proprio agio nello scrivere la sintassi SQL da zero.

A livello di base, quando un utente pone una domanda come:

• “Mostra tutti i clienti di New York che hanno effettuato acquisti il mese scorso.”

Il sistema traduce quella richiesta in una query SQL generata che seleziona le colonne corrette, filtra le righe utilizzando vincoli di data e posizione e unisce le tabelle di database necessarie. La qualità dell'output dipende dalla capacità del sistema di generare query accurate che riflettano sia l'intento dell'utente che lo schema del database.

Dove il text-to-SQL è utile oggi

Il text-to-SQL funziona ragionevolmente bene per:

• Generare bozze di query che gli analisti di dati possono rivedere e modificare.
• Supportare l'analisi esplorativa dei dati dove la velocità conta più della precisione.
• Consentire agli utenti non tecnici di accedere a dati semplici attraverso schemi predefiniti.
• Assistere gli utenti SQL riducendo la necessità di scrivere query ripetitive.

In questi casi, il text-to-SQL funziona come uno strumento di intelligenza artificiale assistiva piuttosto che come un sistema autonomo. La revisione umana rimane parte del flusso di lavoro, specialmente quando la correttezza è importante.

Come funziona il text-to-SQL?

I moderni sistemi text-to-SQL si basano su modelli linguistici di grandi dimensioni addestrati su coppie di domande in linguaggio naturale e query SQL. Questi modelli apprendono schemi che collegano il linguaggio quotidiano alle strutture SQL, ai nomi delle tabelle, alle colonne e alle relazioni. Il processo segue in genere una sequenza di passaggi:

Comprensione del linguaggio naturale

Il sistema analizza innanzitutto l'input dell'utente per determinare intento, vincoli ed entità. Questo passaggio comporta:

• Identificare ciò che l'utente sta chiedendo (ad esempio, totali, filtri, confronti)
• Estrarre condizioni rilevanti come intervalli di tempo, luoghi o categorie
• Interpretare frasi ambigue che potrebbero richiedere un contesto aziendale

Gli errori in questa fase spesso portano a una query SQL dall'aspetto corretto che risponde alla domanda sbagliata.

Mappatura dello schema

Successivamente, il sistema mappa i termini della domanda sullo schema del database. Ciò include:

• Abbinare i concetti nella domanda ai nomi di tabelle e colonne
• Comprendere le relazioni tra le tabelle
• Rispettare i tipi di dati, come date, campi numerici o categorie

La mappatura dello schema diventa più impegnativa man mano che il numero di tabelle aumenta o quando i nomi delle colonne non corrispondono strettamente a come gli utenti descrivono i dati nelle domande in linguaggio naturale.

Costruzione della query SQL

Una volta identificati intento ed elementi dello schema, il sistema costruisce la query SQL. Ciò può comportare:

• Selezionare le tabelle e le colonne corrette
• Aggiungere join tra tutte le tabelle necessarie
• Applicare filtri, aggregazioni e logica di raggruppamento
• Produrre codice SQL sintatticamente valido per sistemi come MySQL o PostgreSQL

In questa fase, il sistema può facilmente produrre SQL valido ma logicamente errato, ad esempio utilizzando la condizione di join o l'aggregazione sbagliata.

Validazione ed esecuzione

Alcuni sistemi includono livelli di validazione che verificano che la query SQL generata possa essere eseguita e restituire risultati. Strumenti più avanzati possono tentare un'ottimizzazione limitata o porre domande di follow-up quando la query è ambigua.

Tuttavia, la validazione raramente garantisce una risposta corretta. Una query può essere eseguita con successo ed essere comunque errata in modi sottili.

Limitazioni e rischi pratici

Nonostante i punteggi elevati dei benchmark, l'uso nel mondo reale espone diverse limitazioni che non possono essere ignorate.

Affidabilità e correttezza

Anche i modelli con le migliori prestazioni non riescono a produrre SQL corretto per una quota significativa di query complesse. Un tasso di errore del 20% o superiore significa:

• Una query generata su cinque può restituire risultati fuorvianti
• Gli errori sono spesso semantici piuttosto che sintattici
• Join, filtri o aggregazioni errati possono passare inosservati

Ciò è particolarmente rischioso nei sistemi di reporting, previsione o supporto decisionale, dove gli utenti presumono che l'output sia corretto.

Dipendenza dalla supervisione umana

Date le prestazioni attuali, il SQL generato deve essere rivisto da qualcuno che comprenda SQL e il database. Senza questa supervisione:

• Gli utenti potrebbero fidarsi di una query errata perché viene eseguita con successo
• Gli errori possono propagarsi in dashboard, report o sistemi a valle
• La responsabilità diventa poco chiara quando le decisioni si basano su output generati dall'IA

Il text-to-SQL non elimina la necessità di competenze in SQL; sposta dove tale competenza viene applicata.

Tetto di complessità

All'aumentare della complessità delle query, le prestazioni calano drasticamente. I modelli hanno difficoltà con:

• Join multipli su molte tabelle
• Logica annidata e sottoquery
• Calcoli specifici del dominio
• Query che richiedono una conoscenza approfondita dello schema del database

Benchmark come BIRD-SQL evidenziano che le query complesse rimangono il principale punto di errore, anche per i modelli avanzati.

Variabilità del modello

Le differenze di prestazioni tra i modelli sono significative. Alcuni modelli linguistici funzionano ragionevolmente bene, mentre altri falliscono frequentemente sullo stesso dataset. Ciò significa:

• La selezione del modello ha un impatto diretto sull'accuratezza
• Il fine-tuning e i dati di addestramento sono importanti
• I modelli generici potrebbero non funzionare bene senza un adattamento al dominio

Non esiste una soluzione universale che funzioni ugualmente bene su tutti i database e casi d'uso.

Governance dei dati e privacy

I sistemi text-to-SQL introducono ulteriori rischi di accesso:

• Gli utenti potrebbero interrogare tabelle sensibili senza comprenderne le implicazioni
• Il SQL generato può esporre metadati sullo schema del database
• I controlli sulla privacy dei dati devono essere applicati al di fuori del modello linguistico

Senza controlli di accesso efficaci, il text-to-SQL può indebolire le pratiche di governance esistenti.

Scopri altri nostri benchmark e approfondimenti basati sui dati nella Ricerca Google.

Aggiungi come fonte preferita

Metodologia di benchmark per text-to-SQL

Questo benchmark condivide il suo framework di valutazione con il nostro benchmark agentic RAG, che descrive in dettaglio la costruzione del dataset, l'architettura dell'agente, la sfida dell'ambiguità semantica e la griglia di punteggio completa.

Entrambi i benchmark utilizzano lo stesso sottogruppo di 500 domande BIRD-SQL¹ , pipeline agentica, recupero dello schema basato su ChromaDB e valutazione LLM-as-Judge con Claude 4 Sonnet. La metrica qui riportata, tasso di generazione di comandi SQL corretti, è la percentuale di domande in cui il modello ha sia instradato al database corretto che generato una query SQL semanticamente corretta. Tutti i modelli sono stati valutati in identiche condizioni zero-shot con temperatura 0 e senza suggerimenti specifici del dominio.

Ulteriori letture

Esplora altri benchmark RAG, come:

• Modelli di Embedding: OpenAI vs Gemini vs Cohere
• Miglior database vettoriale per RAG: Qdrant vs Weaviate vs Pinecone
• RAG ibrido: Migliorare l'accuratezza del RAG
• Benchmark agentic RAG: routing multi-database e generazione di query
• I migliori 10 modelli di embedding multilingue per RAG

FAQ

Cita questo benchmark

Scegli il formato adatto a dove pubblicherai. Incollare la versione con link nel tuo CMS preserva il backlink.

@misc{dilmegani2026,
  author = {Dilmegani, Cem and Sarı, Ekrem},
  title  = {{Text-to-SQL: Confronto dell'accuratezza dei LLM}},
  year   = {2026},
  month  = jul,
  howpublished    = {\url{https://aimultiple.com/text-to-sql}},
  note   = {AIMultiple. Consultato il 17 Luglio 2026}
}

Collegamenti di riferimento

1.

[2305.03111] Can LLM Already Serve as A Database Interface? A BIg Bench for Large-Scale Database Grounded Text-to-SQLs

Cem Dilmegani

Analista principale

Segui

Cem è analista principale presso AIMultiple dal 2017. AIMultiple fornisce informazioni a centinaia di migliaia di aziende (secondo SimilarWeb), tra cui il 55% delle aziende Fortune 500, ogni mese. Il lavoro di Cem è stato citato da importanti pubblicazioni globali come Business Insider, Forbes, Washington Post, società globali come Deloitte e HPE, ONG come il World Economic Forum e organizzazioni sovranazionali come la Commissione Europea. È possibile consultare l'elenco di altre aziende e risorse autorevoli che hanno citato AIMultiple. Nel corso della sua carriera, Cem ha lavorato come consulente tecnologico, responsabile acquisti tecnologici e imprenditore nel settore tecnologico. Ha fornito consulenza alle aziende sulle loro decisioni tecnologiche presso McKinsey & Company e Altman Solon per oltre un decennio. Ha anche pubblicato un report di McKinsey sulla digitalizzazione. Ha guidato la strategia tecnologica e gli acquisti di un'azienda di telecomunicazioni, riportando direttamente al CEO. Ha inoltre guidato la crescita commerciale dell'azienda deep tech Hypatos, che ha raggiunto un fatturato annuo ricorrente a 7 cifre e una valutazione a 9 cifre partendo da zero in soli 2 anni. Il lavoro di Cem in Hypatos è stato oggetto di articoli su importanti pubblicazioni tecnologiche come TechCrunch e Business Insider. Cem partecipa regolarmente come relatore a conferenze internazionali di settore. Si è laureato in ingegneria informatica presso l'Università di Bogazici e ha conseguito un MBA presso la Columbia Business School.

Visualizza il profilo completo

Ricercato da

Ekrem Sarı

Ricercatore di intelligenza artificiale

Segui

Ekrem è un ricercatore di intelligenza artificiale presso AIMultiple, specializzato in automazione intelligente, GPU, agenti di intelligenza artificiale e framework RAG.

Visualizza il profilo completo

Commenti 1

Condividi i tuoi pensieri

Il tuo indirizzo email non verrà pubblicato. Tutti i campi sono obbligatori. I commenti vengono lasciati nella loro lingua originale.

Nome

Indirizzo e-mail

Commento

0/450

Pubblica un commento

PFJ Rofgowski

Dec 10, 2025 at 20:04

Curious, how much of the context engineering and specific prompting did you apply in your benchmarks. Or, was it to review the models only? I have found much higher return of correct and consistent responses. A higher fidelity. To do that, I needed to provide a most sophisticated prompt that fed the context window as the question was being asked. Not perfect, but better than those scores represented in this article when using the Grok 4.x .

Rispondere

Ekrem Sarı

Feb 10, 2026 at 08:46

Great point. This benchmark intentionally uses zero-shot, minimal prompting with temperature=0. No few-shot examples, no domain-specific instructions, no iterative refinement. The goal was to measure each model's baseline text-to-SQL capability. So your experience with Grok 4 getting higher fidelity through sophisticated context engineering is completely expected. A well-crafted prompt with detailed schema descriptions, few-shot examples, and domain-specific rules will improve any model's performance significantly. What this benchmark isolates is how well the model performs out-of-the-box when given only the raw question and retrieved schema, which helps compare the models' inherent SQL reasoning abilities on a level playing field.           We'll make this clearer in the methodology section. Thanks for raising it.

Rispondere