Da testo a SQL: confronto dell'accuratezza di LLM
Utilizzo SQL per l'analisi dei dati da 18 anni, fin dai tempi in cui lavoravo come consulente. Tradurre le domande in linguaggio naturale in SQL rende i dati più accessibili, consentendo a chiunque, anche a chi non possiede competenze tecniche, di lavorare direttamente con i database.
Abbiamo utilizzato la nostra metodologia di benchmark text-to-SQL su 34 modelli linguistici di grandi dimensioni (LLM) per valutarne le prestazioni nella generazione di comandi SQL:
Errori comuni nel codice SQL generato da LLM
I modelli LLM spesso commettono quattro tipi di errori: join errati, errori di aggregazione, filtri mancanti ed errori di sintassi.
Logica di join errata
I modelli spesso faticavano a identificare e implementare correttamente le necessarie operazioni `JOIN` tra le tabelle, a volte omettendole del tutto o utilizzando in modo improprio subquery meno ottimali.
LLM non è riuscito a unire correttamente le tabelle `frpm` e `schools` utilizzando il `CDSCode`. Ha inoltre generato nomi di colonna errati (`Charter`) e valori di filtro errati (`County = 'Fresno'`).
Gli errori nella logica di join compromettono in modo fondamentale l'aspetto relazionale della query, portando a un recupero di dati incompleto o errato quando sono coinvolte più tabelle.
Errori di aggregazione e raggruppamento
Un altro punto critico comune era l'applicazione errata di funzioni di aggregazione (come `MAX`, `AVG`, `COUNT`, `SUM`) o di clausole `GROUP BY`, che portavano a risultati che non corrispondevano semanticamente all'intento dell'utente.
L'LLM ha correttamente identificato che la frase " punteggio medio più alto " richiede il raggruppamento dei dati per distretto (GROUP BY dname) e l'utilizzo di una funzione di aggregazione (AVG(AvgScrRead)). Questa parte della logica è corretta.
Tuttavia, il modello LLM non è riuscito a incorporare un filtro fondamentale richiesto dalla domanda: la parola " attivo ". Per soddisfare questo requisito, la query avrebbe dovuto unire la tabella satscores con la tabella schools e quindi filtrare i risultati con una clausola WHERE T1.StatusType = 'Active'.
Questo evidenzia un errore comune negli algoritmi LLM: l'esecuzione corretta di un'istruzione primaria e ovvia (il calcolo di una media) omettendo al contempo una condizione secondaria ma altrettanto importante (il filtraggio in base allo stato). Ciò dimostra una debolezza nella sintesi di vincoli multipli in un'unica query corretta.
Filtri mancanti o errati
A volte i modelli non includevano le clausole `WHERE` necessarie o selezionavano le colonne sbagliate nell'istruzione `SELECT`, non rispettando completamente i vincoli o le informazioni esplicitamente richieste nel prompt.
L'LLM ha identificato correttamente la logica per trovare la scuola (`ORDER BY NumGE1500 DESC LIMIT 1`), ma non è riuscito a selezionare il numero di telefono richiesto e ha omesso la necessaria join alla tabella `schools` per recuperarlo.
Questi errori derivano spesso 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 veri e propri errori di sintassi, come l'utilizzo di alias di tabella errati o la produzione di istruzioni SQL incomplete, che impediscono l'esecuzione della query.
L'LLM ha utilizzato alias errati (`accounts` invece di `account`) e ha incluso una stringa letterale incompleta (`'POPLATEK PO OBRATU…'`), con conseguente 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 più bravi con SQL
Diversi fattori chiave determinano l'efficacia con cui un modello linguistico di grandi dimensioni (LLM) è in grado di trasformare una domanda in linguaggio naturale in una query SQL corretta per un database.
1. Dimensioni del modello e dati di addestramento
- Dimensioni e design: i modelli più grandi o quelli costruiti con strutture specifiche possono gestire compiti complessi, come la generazione di query SQL, in modo più efficace.
- Cosa ha imparato: I dati utilizzati per addestrare l'LLM sono essenziali. Se l'LLM vede molti esempi di domande collegate a risposte SQL, soprattutto quelle che coinvolgono operazioni complesse come join o calcoli (SOMMA, MEDIA), è probabile che ottenga risultati migliori.
2. Ottimizzazione per le attività SQL
- È possibile fornire ai modelli un addestramento aggiuntivo specificamente focalizzato sulle attività di conversione da testo a SQL. Questa "messa a punto" li aiuta a comprendere le strutture dei database e le regole SQL in modo più efficace rispetto ai modelli addestrati solo su testo generico. Anche l'addestramento su istruzioni specifiche risulta utile.
3. Capacità di ragionamento e di mappatura degli schemi
- Ragionamento: Quanto bene il LLM riesce a capire i passaggi esatti necessari a partire da una domanda a volte vaga? La creazione di query SQL spesso richiede passaggi logici .
- Comprensione della mappa del database (Schema): Alcuni LLM sono più efficaci nel collegare i concetti presenti nella domanda (come "clienti" o "vendite totali") ai nomi effettivi di tabelle e colonne nel database, anche se i nomi non sono immediatamente ovvi.
Come gli LLM generano SQL: una guida passo passo
Per vedere in azione fattori come il "ragionamento" e la "mappatura dello schema", analizziamo passo passo il processo che un modello segue per generare una query. L'intero flusso di lavoro si basa su una tecnica chiamata Retrieval-Augmented Generation (RAG).
Fase 1: Analisi iniziale e selezione del database
Quando gli viene posta una domanda, il LLM analizza innanzitutto l'intento dell'utente per selezionare lo strumento di database più pertinente.
- Domanda: "Quanti conti hanno un titolare che dispone e richiede la generazione di un estratto conto a seguito di una transazione?"
- Azione di LLM: Il modello identifica parole chiave come "conti", "disposizione" e "transazione". Conclude che lo strumento di database
financialè la scelta corretta rispetto ad altri comecalifornia_schoolsosuperhero.
Fase 2: Recupero dello schema tramite RAG
Una volta che il modello sceglie uno strumento, ha bisogno della "mappa" del database che ne rappresenti lo schema. Non ha queste informazioni memorizzate. Il sistema RAG, invece, le recupera in tempo reale.
- 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ù rilevanti, come le definizioni per le tabelle
accountsedisp. - Arricchimento: il testo dello schema recuperato viene inserito automaticamente nel prompt accanto alla domanda originale.
- Generazione: L'LLM ora dispone di tutto il contesto necessario per procedere.
Questo processo RAG garantisce che il modello riceva solo le informazioni di schema necessarie, rendendo il suo compito più mirato ed efficiente.
Fase 3: Ragionamento e costruzione della query
Grazie alla domanda e allo schema fornito da RAG, il modello associa i concetti della richiesta dell'utente ai nomi specifici di tabelle e colonne appena ricevuti.
Il monologo interiore di LLM:
- Obiettivo: l'utente desidera un conteggio, quindi inizierò con
SELECT COUNT(...). - Condizioni:
- “…disposizione del proprietario…” -> Lo schema della tabella
dispha una colonnatype. Ho bisogno di una clausolaWHEREpertype = 'OWNER'. - “…dichiarazione da generare in seguito a una transazione…” -> Lo schema della tabella
accountsha una colonnafrequency. Il filtro dovrebbe esserefrequency = 'POPLATEK PO OBRATU'.
- “…disposizione del proprietario…” -> Lo schema della tabella
- Join: Le informazioni sono suddivise tra le tabelle
accountsedisp. Lo schema mostra che sono collegate daaccount_id, quindi devoJOIN.
Fase 4: Generazione dell'SQL finale
Infine, il modello assembla questi elementi logici in una query SQL sintatticamente corretta. La qualità di questo output dipende da:
- Capacità di ragionamento: la capacità del modello di collegare logicamente la richiesta dell'utente allo schema fornito.
- Conoscenza di SQL acquisita tramite formazione: la comprensione di base della sintassi e delle funzioni SQL da parte del modello.
Questo processo spiega perché si verificano gli errori. Se lo schema recuperato è ambiguo o un termine nella domanda non corrisponde in modo univoco, l'LLM deve fare una supposizione fondata, il che può portare agli errori che abbiamo analizzato in precedenza.
Che cos'è la conversione da testo a SQL?
La tecnologia Text-to-SQL è un'elaborazione del linguaggio naturale che converte il linguaggio di tutti i giorni in una query SQL scritta in linguaggio SQL (Structured Query Language). Invece di scrivere manualmente il codice SQL, l'utente pone una domanda in linguaggio naturale e il sistema genera un'istruzione SQL che può essere eseguita su un database.
Lo scopo principale della conversione da testo a SQL è quello di ridurre il divario tra il modo in cui le persone concepiscono i dati e il modo in cui i database richiedono che vengano scritte le query. Ciò è particolarmente rilevante per gli utenti non tecnici e per 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 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 la richiesta in una query SQL generata automaticamente, che seleziona le colonne corrette, filtra le righe utilizzando vincoli di data e posizione e unisce le tabelle del database necessarie. La qualità dell'output dipende dalla capacità del sistema di generare query accurate che riflettano sia l'intento dell'utente sia lo schema del database.
Dove la conversione da testo a SQL è utile oggi
La conversione da testo a SQL funziona abbastanza bene per:
- Genera bozze di query che gli analisti di dati possano esaminare e modificare.
- Supporto all'analisi esplorativa dei dati laddove la velocità è più importante della precisione.
- Consenti agli utenti non tecnici di accedere a dati semplici tramite schemi predefiniti.
- Aiuta gli utenti SQL riducendo la necessità di scrivere query ripetitive.
In questi casi, la conversione da testo a SQL funziona come uno strumento di intelligenza artificiale di supporto, piuttosto che come un sistema autonomo. La revisione umana rimane parte integrante del flusso di lavoro, soprattutto quando la correttezza è fondamentale.
Come funziona la conversione da testo a SQL?
I moderni sistemi di conversione da testo a 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 in genere segue una sequenza di passaggi:
Comprensione del linguaggio naturale
Il sistema analizza innanzitutto l'input dell'utente per determinarne l'intento, i vincoli e le entità. Questa fase prevede:
- Identificare ciò che l'utente sta chiedendo (ad esempio, totali, filtri, confronti)
- Estrazione di condizioni rilevanti quali intervalli di tempo, posizioni o categorie
- Interpretare frasi ambigue che possono richiedere un contesto aziendale
Gli errori in questa fase spesso portano a una query SQL apparentemente corretta che però risponde alla domanda sbagliata.
Mappatura Schema
Successivamente, il sistema associa i termini della domanda allo schema del database. Ciò include:
- Abbinamento dei concetti presenti nella domanda ai nomi delle tabelle e alle colonne
- Comprendere le relazioni tra le tabelle
- Rispettando i tipi di dati, come date, campi numerici o categorie.
La mappatura dello schema diventa più complessa all'aumentare del numero di tabelle o quando i nomi delle colonne non corrispondono esattamente al modo in cui gli utenti descrivono i dati nelle domande in linguaggio naturale.
Costruzione della query SQL
Una volta identificati l'intento e gli elementi dello schema, il sistema costruisce la query SQL. Ciò può includere:
- Selezione delle tabelle e delle colonne corrette
- Aggiunta di join a tutte le tabelle necessarie
- Applicazione di filtri, aggregazioni e logica di raggruppamento
- Generare codice SQL sintatticamente valido per sistemi come MySQL o PostgreSQL
In questa fase, il sistema può facilmente produrre codice SQL valido ma logicamente errato, ad esempio utilizzando una condizione di join o un'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 approfondimento quando la query è ambigua.
Tuttavia, la validazione raramente garantisce una risposta corretta. Una query può essere eseguita con successo e risultare comunque errata in modi sottili.
Limitazioni e rischi pratici
Nonostante gli ottimi punteggi ottenuti nei benchmark, l'utilizzo nel mondo reale mette in luce diverse limitazioni che non possono essere ignorate.
Affidabilità e correttezza
Anche i modelli più performanti non riescono a produrre codice SQL corretto per una quota significativa di query complesse. Un tasso di errore pari o superiore al 20% significa:
- Una query su cinque potrebbe restituire risultati fuorvianti.
- Gli errori sono spesso semantici piuttosto che sintattici.
- Collegamenti, filtri o aggregazioni errati potrebbero passare inosservati
Ciò è particolarmente rischioso nei sistemi di reporting, previsione o supporto alle decisioni, dove gli utenti presumono che il risultato sia corretto.
Dipendenza dalla supervisione umana
Viste le prestazioni attuali, il codice SQL generato deve essere esaminato da qualcuno che conosca SQL e il database. Senza questa supervisione:
- Gli utenti potrebbero fidarsi di una query errata perché viene eseguita correttamente.
- Gli errori possono propagarsi a dashboard, report o sistemi a valle.
- La responsabilità diventa poco chiara quando le decisioni si basano su risultati generati dall'intelligenza artificiale.
La tecnologia Text-to-SQL non elimina la necessità di competenze SQL; si limita a spostare il contesto in cui tali competenze vengono applicate.
Limite massimo di complessità
Con l'aumentare della complessità delle query, le prestazioni calano drasticamente. I modelli incontrano difficoltà con:
- Molteplici join tra più 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 critico, anche per i modelli più avanzati.
Variabilità del modello
Le differenze di prestazioni tra i modelli sono significative. Alcuni modelli linguistici funzionano abbastanza bene, mentre altri falliscono frequentemente sullo stesso set di dati. Ciò significa che:
- La scelta del modello ha un impatto diretto sulla precisione.
- La messa a punto e l'addestramento dei dati sono importanti
- I modelli generici potrebbero non funzionare bene senza un adattamento al dominio.
Non esiste una soluzione universale che funzioni ugualmente bene per tutti i database e i 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 codice SQL generato può esporre metadati relativi allo schema del database.
- I controlli sulla privacy dei dati devono essere applicati anche al di fuori del modello linguistico.
In assenza di solidi controlli di accesso, la conversione da testo a SQL può indebolire le pratiche di governance esistenti.
Metodologia di benchmarking per la conversione da testo a SQL
Questo benchmark condivide il suo quadro di valutazione con il nostro benchmark RAG agentico , 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 BIRD-SQL da 500 domande 1 sottoinsieme, 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 sia generato una query SQL semanticamente corretta. Tutti i modelli sono stati valutati in condizioni zero-shot identiche con temperatura 0 e senza suggerimenti specifici del dominio.
Per approfondire
Esplora altri parametri di riferimento RAG, come ad esempio:
- Modelli di embedding: OpenAI vs Gemini vs Cohere
- Principale database vettoriale per RAG: Qdrant vs Weaviate vs Pinecone
- RAG ibrido: miglioramento della precisione del RAG
- Benchmark RAG Agentico: routing multi-database e generazione di query
- I 10 migliori modelli di embedding multilingue per RAG
Registro delle modifiche
20 febbraio 2026
Sono stati aggiunti 2 nuovi modelli al benchmark:
- Google: Anteprima di Gemini 3.1 Pro (google/gemini-3.1-pro-preview)
- Anthropic: Claude Sonnet 4.6 (anthropic/claude-sonnet-4.6)
10 febbraio 2026
Sono stati aggiunti 2 nuovi modelli al benchmark:
- Claude Opus 4.6 (anthropic/claude-opus-4.6)
- Kimi K2.5 (moonshotai/kimi-k2.5)
FAQ
In base ai nostri risultati, non dovreste fidarvi completamente delle query complesse generate dagli attuali modelli LLM senza previa validazione. Sebbene utili per la stesura e per richieste semplici, anche i modelli più performanti presentano tassi di errore significativi (fino al 20% per attività complesse). È sempre consigliabile rivedere e verificare il codice SQL generato, soprattutto per le applicazioni critiche.
Sì, molti LLM hanno funzionalità che vanno oltre la semplice generazione di SELECT. Spesso possono aiutare a comprendere e suggerire modifiche al codice SQL esistente o persino a generare DDL (Data Definition Language) come istruzioni CREATE TABLE basate su descrizioni, sebbene l'accuratezza di queste attività richieda anche una verifica.
Fornire un contesto chiaro è fondamentale. Assicurarsi che il LLM abbia accesso allo schema del database (nomi delle tabelle, nomi delle colonne, relazioni). Indicare chiaramente il risultato desiderato e, se possibile, fornire alcuni esempi di query pertinenti (suggerimenti a breve termine) da cui il LLM possa apprendere, può migliorare significativamente la sua capacità di selezionare le tabelle corrette e costruire query accurate.
Sebbene i LLM possano astrarre alcune piccole differenze di sintassi tra i dialetti del database, non risolvono completamente i problemi di compatibilità tra le versioni dei tipi di database. Potrebbero comunque generare codice SQL specifico per un determinato dialetto (ad esempio, PostgreSQL rispetto a MySQL) o non utilizzare funzioni compatibili con le versioni precedenti, a meno che non vengano esplicitamente guidati o addestrati a farlo. La validazione rispetto al database di destinazione rimane quindi fondamentale.
Collegamenti di riferimento
Prossimo da leggere
Benchmark del generatore di testo in video
Generatori di testo in immagine: Nano Banana Pro e GPT Image 1.5
Come testare i proxy nel 2026: strumenti di verifica proxy gratuiti e a pagamento
Confronto tra la sintesi vocale e il testo: Deepgram vs. Whisper
Software di sintesi vocale: Hume ed ElevenLabs
Generazione di testo tramite intelligenza artificiale: 17 casi d'uso principali e 5 casi di studio
Commenti 1
Condividi i tuoi pensieri
Il tuo indirizzo email non verrà pubblicato. Tutti i campi sono obbligatori.
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 .
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.