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

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

Abbiamo utilizzato la nostra metodologia di benchmark text-to-SQL su 34 grandi modelli linguistici (LLM) per valutarne le prestazioni nella generazione di comandi SQL:

Errori comuni nei LLM-generati SQL

I LLM spesso commettono quattro tipi di errori: join difettosi, 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 completamente o utilizzando in modo errato subquery meno ottimali.

Il LLM non è riuscito a unire correttamente le tabelle `frpm` e `schools` utilizzando il `CDSCode`. Ha anche allucinato i nomi delle colonne (`Charter`) e i valori dei filtri (`County = 'Fresno'`).

Gli errori nella logica di join compromettono fondamentalmente l'aspetto relazionale della query, portando al recupero di dati incompleti o errati quando sono coinvolte più tabelle.

Errori di aggregazione e raggruppamento

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

Il LLM ha correttamente identificato che la frase "punteggio medio più alto" richiede di raggruppare i dati per distretto (GROUP BY dname) e 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 "active". Per soddisfare questo requisito, la query doveva JOIN la tabella satscores con la tabella schools e poi filtrare i risultati con una clausola WHERE T1.StatusType = 'Active'.

Questo evidenzia un comune fallimento dei LLM: eseguire correttamente un'istruzione primaria e ovvia (calcolare una media) mentre si manca una condizione secondaria ma ugualmente importante (filtrare per stato). Questo mostra una debolezza nel sintetizzare più vincoli in una singola query corretta.

Filtri mancanti o errati

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

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

Questi errori spesso derivano da un'analisi incompleta della richiesta dell'utente o dal mancato mappaggio di tutte le parti della richiesta sui componenti finali della query SQL.

Errori di sintassi

Oltre agli errori semantici, si sono verificati errori di sintassi palesi, 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 una stringa letterale incompleta (`'POPLATEK PO OBRATU…'`), risultando in una sintassi SQL non valida.

Questi problemi di sintassi evidenziano le sfide nella generazione di codice che aderisce strettamente alla grammatica SQL e alle convenzioni specifiche del database.

Perché alcuni LLM sono migliori in SQL

Alcune cose chiave determinano quanto bene un Large Language Model (LLM) possa trasformare una domanda in inglese semplice in una corretta query di database SQL.

1. Dimensione del modello e dati di addestramento

• Dimensione e design: 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 imparato: I dati utilizzati per addestrare il 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), probabilmente avrà prestazioni migliori.

2. Fine-Tuning per compiti SQL

• I modelli possono ricevere un addestramento aggiuntivo specificamente focalizzato sui compiti text-to-SQL. Questo "fine-tuning" aiuta a comprendere le strutture del database e le regole SQL in modo più efficace rispetto ai modelli addestrati solo su testo generale. L'addestramento su istruzioni specifiche aiuta anche.

3. Capacità di ragionamento e mappatura dello schema

• Ragionamento: Quanto bene può il LLM capire i passaggi esatti necessari da una domanda a volte vaga? Creare SQL spesso richiede passaggi logici.
• Comprendere la mappa del database (Schema): Alcuni LLM sono migliori nel collegare i concetti nella domanda (come "clienti" o "vendite totali") ai nomi effettivi delle tabelle e delle colonne nel database, anche se i nomi non sono immediatamente ovvi.

Come i LLM generano SQL: Una visione passo dopo passo

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

Fase 1: Analisi iniziale e selezione del database

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

• Domanda: "Quanti account hanno una disposizione del proprietario e una richiesta per la generazione di un estratto conto su una transazione?"
• Azione del LLM: Il modello identifica parole chiave come "accounts", "disposition" e "transaction". 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 che il modello sceglie uno strumento, ha bisogno della "mappa" del database: lo schema. Non ha queste informazioni memorizzate. Invece, il sistema RAG lo recupera in tempo reale.

1. Recupero: La domanda dell'utente viene utilizzata per cercare 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 accounts e disp.
2. Augmentazione: Questo testo dello schema recuperato viene automaticamente inserito nel prompt insieme alla domanda originale.
3. Generazione: Il LLM ha ora tutto il contesto di cui ha bisogno per procedere.

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

Fase 3: Ragionamento e costruzione della query

Con la domanda e lo schema fornito da RAG, il modello mappa i concetti dalla richiesta dell'utente ai nomi specifici delle tabelle e delle 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 su una transazione..." -> Lo schema della tabella accounts ha una colonna frequency. Il filtro dovrebbe essere frequency = 'POPLATEK PO OBRATU'.
3. Join: Le informazioni sono divise tra le tabelle accounts e disp. Lo schema mostra che sono collegate da account_id, quindi devo 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 SQL dall'addestramento: La comprensione di base 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 si mappa in modo pulito, il LLM deve fare un'ipotesi ragionata, che può portare agli errori che abbiamo analizzato 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 il modo in cui le persone pensano ai dati e il modo in cui i database richiedono che le query siano scritte. Questo è particolarmente rilevante per gli utenti non tecnici e gli analisti di dati che comprendono il contesto aziendale ma potrebbero non essere a loro agio a scrivere la sintassi SQL da zero.

A un 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 del database necessarie. La qualità dell'output dipende dal fatto che il sistema possa 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.
• Permettere 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 funge da strumento AI assistivo piuttosto che da 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 grandi modelli linguistici addestrati su coppie di domande in linguaggio naturale e query SQL. Questi modelli imparano modelli che collegano il linguaggio quotidiano alle strutture SQL, ai nomi delle tabelle, alle colonne e alle relazioni. Il processo segue tipicamente una sequenza di passaggi:

Comprensione del linguaggio naturale

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

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

Gli errori in questa fase spesso portano a una query SQL che sembra corretta ma risponde alla domanda sbagliata.

Mappatura dello schema

Successivamente, il sistema mappa i termini dalla domanda allo schema del database. Questo include:

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

La mappatura dello schema diventa più difficile man mano che il numero di tabelle cresce o quando i nomi delle colonne non corrispondono da vicino a come 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. Questo può comportare:

• Selezionare le tabelle e le colonne corrette
• Aggiungere join su 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 sbagliata o l'aggregazione.

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 di benchmark elevati, l'uso nel mondo reale espone diverse limitazioni che non possono essere ignorate.

Affidabilità e correttezza

Anche i modelli migliori 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

Questo è particolarmente rischioso nella reportistica, nelle previsioni o nei sistemi di supporto alle decisioni, dove gli utenti assumono che l'output sia corretto.

Dipendenza dalla supervisione umana

Data le prestazioni attuali, il SQL generato deve essere revisionato da qualcuno che comprende 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'AI

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

Soffitto di complessità

Man mano che la complessità della query aumenta, le prestazioni crollano bruscamente. I modelli faticano con:

• Molti join su molte tabelle
• Logica annidata e subquery
• 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 fallimento, 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. Questo significa:

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

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

Governance dei dati e privacy

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

• 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 forti controlli di accesso, il text-to-SQL può indebolire le pratiche di governance esistenti.

Non perderti i nostri benchmark e approfondimenti basati sui dati. Il pulsante apre Google; selezionare AIMultiple conferma che desideri vedere AIMultiple più spesso nei risultati di ricerca di Google.

Aggiungi come fonte preferita

Metodologia di benchmark per il text-to-SQL

Questo benchmark condivide il proprio 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 rubrica di punteggio completa.

Entrambi i benchmark utilizzano lo stesso sottoinsieme di 500 domande BIRD-SQL¹ , pipeline agentic, recupero dello schema supportato da ChromaDB e valutazione LLM-as-Judge con Claude 4 Sonnet. La metrica riportata qui, il tasso di generazione corretto dei comandi SQL, è 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 condizioni zero-shot identiche con temperatura 0 e senza suggerimenti specifici per il 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
• Hybrid RAG: Aumentare l'accuratezza RAG
• Benchmark Agentic RAG: instradamento multi-database e generazione di query
• Top 10 modelli di embedding multilingue per RAG

Changelog

20 aprile 2026

Aggiunto 1 nuovo modello al benchmark:

• Anthropic: Claude Opus 4.7 (anthropic/claude-opus-4.7)

20 febbraio 2026

Aggiunti 2 nuovi modelli al benchmark:

• Google: Gemini 3.1 Pro Preview (google/gemini-3.1-pro-preview)
• Anthropic: Claude Sonnet 4.6 (anthropic/claude-sonnet-4.6)

10 febbraio 2026

Aggiunti 2 nuovi modelli al benchmark:

• Claude Opus 4.6 (anthropic/claude-opus-4.6)
• Kimi K2.5 (moonshotai/kimi-k2.5)

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  = jun,
  howpublished    = {\url{https://aimultiple.com/text-to-sql}},
  note   = {AIMultiple. Consultato il 30 Giugno 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