AIM-Text-to-SQL Benchmark: SQL Precisione su oltre 70 LLM
We evaluated SQL answers from 70+ LLMs on a 759-question BIRD-SQL subset. Each model selected a database from 11 candidates, then produced a query.
L'accuratezza SQL è la percentuale di query valutate che restituiscono il risultato di riferimento. I percorsi errati e i riferimenti contrassegnati come non validi sono esclusi. Una query di riferimento è il SQL fornito come risposta attesa.
Ogni modello raggiunge un diverso insieme di domande SQL perché la valutazione dipende dalle sue scelte di database. Le differenze in questi sottoinsiemi e nella configurazione di esecuzione limitano i confronti.
Risultati Text-to-SQL
Opus 5.5 ha registrato un'accuratezza SQL dell'87,8%
claude-opus-5.5 ha eguagliato il risultato di riferimento su 444 delle 506 domande valutate. gemini-4-argon lo segue con il 78,6% (407 su 518), quindi gemini-3.8-flash con il 77,2% (342 su 443). Questi sono stati i tre punteggi di accuratezza SQL più alti nel pannello di 76 modelli. Muse Wonder ha registrato il 56,4% (285 su 505).
Il punteggio esclude le scelte di database errate e i riferimenti contrassegnati come non validi. Opus 5.5 ha usato Claude Code. Gemini 4 Argon e Gemini 3.8 Flash hanno usato OpenRouter. La classifica riflette sia le condizioni di esecuzione sia le differenze nelle domande instradate correttamente da ciascun modello.
Tre varianti Pro hanno ottenuto punteggi inferiori ai loro modelli base
gpt-6.1-sol-pro ha registrato un'accuratezza SQL del 63,6%, rispetto al 65,1% di gpt-6.1-sol. gpt-6-sol-pro ha ottenuto il 53,6% contro il 53,8% di gpt-6-sol. gpt-6-luna-pro ha ottenuto il 44,2% contro il 45,4% di gpt-6-luna.
Tutti e sei i modelli hanno usato OpenRouter. Questi punteggi derivano da una singola esecuzione per modello e da sottoinsiemi diversi di domande instradate correttamente. Sarebbero necessarie esecuzioni ripetute sulle stesse domande SQL per valutare se i piccoli divari persistano.
Costo vs. accuratezza SQL
Il costo di esecuzione copre le risposte di routing e SQL conservate da ciascuna esecuzione del benchmark. L'obiettivo era di 759 domande. Sette esecuzioni hanno un numero inferiore di risposte conservate. Test preliminari separati, tentativi di retry scartati e chiamate della giuria sono esclusi. L'accuratezza SQL utilizza le domande instradate correttamente da ciascun modello dopo aver escluso i riferimenti contrassegnati come non validi.
gemini-3-flash-preview ha registrato un'accuratezza SQL del 67,7% a $7,67 per esecuzione. gemini-3.8-flash ha raggiunto il 77,2% a $26.48. Opus 5.5 ha un punteggio dell'87,8% abbinato a un costo stimato equivalente API di $188.71. Gemini 4 Argon ha raggiunto il 78,6% a $41,41 nei costi di esecuzione conservati. Muse Wonder ha raggiunto il 56,4% a $77,44 nei costi di esecuzione conservati.
I 73 modelli API utilizzano costi misurati. Opus 5.5, Fable 5.1 e GPT-6 Astra hanno stime etichettate separatamente basate sui loro token CLI registrati e sui prezzi OpenRouter verificati il 1 ottobre 2026, con l'utilizzo registrato della cache preservato.
I costi includono l'esplorazione del database e i punteggi SQL coprono sottoinsiemi di domande diversi. Questo confronto descrive quindi il costo e l'accuratezza del flusso di lavoro combinato del benchmark. I costi isolati di generazione SQL non sono stati misurati. Il benchmark RAG agentico riporta separatamente la selezione del database.
Risultati di accuratezza SQL
Prima della revisione dei riferimenti misura la corrispondenza esatta dei risultati su tutte le domande instradate correttamente. La revisione delle risposte aggiunge credito per le risposte accettate dalla giuria. Entrambe le colonne di confronto usano il denominatore originale, mentre l'accuratezza SQL esclude i riferimenti contrassegnati.
Condizioni che influenzano l'accuratezza SQL
I suggerimenti di BIRD hanno aumentato l'accuratezza SQL di Gemini Flash di 8.7 punti
Abbiamo ripetuto gemini-3-flash-preview con le prove supplementari di BIRD. Sulle domande instradate correttamente in entrambe le condizioni, l'accuratezza SQL è salita dal 67,5% al 76,2%. L'accuratezza stretta, prima della revisione dei riferimenti, è salita dal 55,0% al 61,6%.
Si è trattato di un esperimento su un singolo modello. Non stabilisce un miglioramento comune per il pannello di 74 modelli. Il pannello principale omette i suggerimenti perché possono anche rivelare quale database selezionare.
I modelli hanno raggiunto insiemi diversi di domande SQL
Le scelte di database di ciascun modello determinano quali domande raggiungono la valutazione SQL. Per claude-opus-5, il denominatore stretto contiene 717 domande, incluse 156 dal gruppo di instradamento più difficile. Per nova-lite-v1, contiene 285 domande, incluse 22 da quel gruppo. Le quote sono 21,8% e 7,7%.
Le loro percentuali SQL combinano quindi la capacità di scrittura delle query con la difficoltà dei casi che hanno raggiunto la valutazione. Un confronto SQL controllato fornirebbe a ogni modello il database corretto per le stesse domande. Tale esperimento non è stato eseguito.
Anche la selezione delle domande è importante quando si confrontano benchmark IA che forniscono schemi, suggerimenti o budget di strumenti diversi.
Risultati della revisione dei riferimenti e delle risposte
L'audit dei riferimenti ha contrassegnato 236 query su 759
Cinque modelli hanno valutato ogni query di riferimento rispetto alla sua domanda e alle informazioni di schema disponibili. Non hanno visto alcuna risposta candidata del modello. Una maggioranza di almeno tre ha contrassegnato 236 riferimenti come non validi, pari al 31,1% dell'insieme.
Dopo l'audit, il proprietario del benchmark ha esaminato le segnalazioni. Annotatori umani indipendenti non hanno ripetuto tale revisione. Queste percentuali descrivono il sottoinsieme controllato. Non dovrebbero essere generalizzate a tutto BIRD.
Le risposte equivalenti hanno aggiunto 22.7 punti al punteggio di claude-sonnet-5
claude-sonnet-5 ha superato 211 delle 679 domande con valutazione stretta, pari al 31,1%. Una giuria ha accettato altre 154 risposte come equivalenti al riferimento. Queste hanno contribuito con 22.7 punti percentuali.
Altre 117 risposte hanno ricevuto credito perché la giuria ha accettato la query del modello e rifiutato il riferimento. Questi hanno contribuito con 17.2 punti. Together, le due categorie hanno portato il punteggio al 71,0%, con un aumento di 39.9 punti.
Le risposte equivalenti possono restituire le informazioni richieste con una colonna aggiuntiva o una proiezione diversa. Il confronto stretto può rifiutare tale risultato anche quando un revisore lo accetta come risposta alla domanda. Dell'aumento, 22.7 punti derivano dalle decisioni della giuria su questi casi. I difetti dei riferimenti rappresentano i restanti 17.2 punti.
Metodologia del benchmark Text-to-SQL
Questions and execution
BIRD-SQL fornisce domande in linguaggio naturale, riferimenti SQL e contenuti di database.1 Abbiamo utilizzato una selezione congelata di 759 domande da 11 database, comprendente 560 esempi di addestramento e 199 di sviluppo.
I modelli hanno ricevuto brevi descrizioni dei database e strumenti per elencare tabelle, leggere le definizioni delle colonne ed eseguire SQL. Ogni domanda consentiva fino a nove chiamate con gli strumenti e una risposta finale contenente il database scelto e il SQL. Il limite di anteprima dello schema era di 4.000 caratteri e le anteprime delle query erano limitate a 50 righe.
La query candidata finale e il riferimento sono stati eseguiti sullo stesso file di database. Il punteggio stretto ha confrontato i loro risultati, inclusa una modalità sensibile all'ordine per le domande che richiedono una risposta ordinata. Le query candidate mancanti, malformate o che non sono riuscite nell'esecuzione non hanno ricevuto credito stretto su domande altrimenti idonee e instradate correttamente.
Per le 46 esecuzioni OpenRouter abbiamo richiesto temperatura 0. Ventinove hanno usato il livello di recupero delle chiamate agli strumenti v3, 15 lo precedevano e due hanno combinato registrazioni di entrambe le versioni. GPT-6 Astra è stato eseguito tramite Codex CLI. Opus 5.5 e Fable 5.1 hanno usato Claude Code. Tutte e tre le esecuzioni CLI hanno usato uno sforzo di ragionamento medio. Le esecuzioni di GPT-6 Luna, Luna Pro, Sol e Sol Pro e GPT-5.2 hanno usato OpenRouter. Queste differenze di esecuzione impediscono di attribuire un divario di punteggio al solo modello.
Sette esecuzioni hanno completato meno di 759 domande. I record mancanti sono assenti dai denominatori di punteggio. La tabella riporta le dimensioni effettive del campione per i punteggi principali e supplementari. Le dieci aggiunte API hanno completato tutte le 759 domande dopo i tentativi ripetuti delle richieste non riuscite, preservando le risposte corrette precedenti.
Punteggio SQL
Il punteggio principale esclude le domande contrassegnate sia dal numeratore sia dal denominatore. Tre riferimenti contrassegnati come incerti rimangono nel calcolo. I file dei risultati chiamano questa metrica ex_gold_clean.
Due punteggi supplementari mostrano come la revisione cambia il risultato:
Prima della revisione dei riferimenti, il punteggio stretto misura la corrispondenza esatta di esecuzione su tutte le domande instradate correttamente. Include le domande con riferimenti contrassegnati.
Dopo la revisione delle risposte, il punteggio aggiunge credito quando una giuria separata accetta una risposta mancata idonea. Usa lo stesso denominatore del punteggio stretto. I file dei risultati chiamano questa accuratezza aggiudicata.
La dimensione del campione (n) è il numero di domande valutate. Il punteggio principale utilizza un sottoinsieme più piccolo rispetto ai due punteggi supplementari.
Per claude-sonnet-5, l'esclusione dei riferimenti contrassegnati ha ridotto le risposte accettate da 211 a 180 e le domande valutate da 679 a 468. La sua accuratezza SQL è stata del 38,5%.
L'esclusione modifica entrambi i conteggi. La revisione delle risposte mantiene invece il denominatore originale e aggiunge credito per le risposte mancate accettate.
Revisione dei riferimenti e delle risposte
L'audit dei riferimenti e la revisione delle risposte candidate richiedono input diversi.
I revisori dei riferimenti erano claude-opus-4.8, gpt-5.6-sol, gemini-3.1-pro-preview, grok-4.5 e deepseek-v4-pro. Le risposte candidate sono state nascoste per mantenere le segnalazioni indipendenti dal modello valutato.
L'aggiudicazione delle risposte ha utilizzato tre giurati provenienti da famiglie di modelli diverse da quella del candidato. Le query di riferimento e candidate sono apparse in posizioni A/B randomizzate senza etichette che rivelassero i loro ruoli. I casi ambigui e quelli con voti validi insufficienti non hanno ricevuto credito aggiuntivo.
La copertura della revisione è asimmetrica. I superamenti stretti rimangono accettati, mentre le risposte mancate idonee ricevono un'altra valutazione. Di conseguenza, l'aggiudicazione può conservare i falsi positivi del punteggio stretto e aggiungerne di propri. È una stima supplementare, senza correttezza garantita né un limite superiore garantito all'accuratezza reale.
Una risposta mancata era idonea all'aggiudicazione quando la query candidata veniva eseguita e la sovrapposizione F1 tra le sue righe di risultato e il riferimento era inferiore a 0.5. L'F1 combina la proporzione di righe candidate trovate nel riferimento con la proporzione di righe di riferimento recuperate dal candidato.
Ad esempio, gemini-3.5-flash-lite ha avuto 346 risposte mancate in valutazione stretta. Di queste, 314 erano idonee alla revisione. La giuria ha accettato la candidata in 144 casi: 92 con riferimento rifiutato e 52 con entrambe le risposte accettate. Ha classificato 105 come errori del modello e ha lasciato 65 ambigue. Le altre 32 mancate comprendevano 27 con maggiore sovrapposizione dei risultati e cinque errori di esecuzione.
I 144 casi accettati rappresentano il 45,9% delle risposte mancate esaminate, non di tutte le risposte non riuscite.
Aggiungi come fonte preferitaLimitazioni
Gli errori di riferimento rimangono incerti. L'audit a cinque modelli ha ispezionato le colonne delle tabelle utilizzate da ciascuna query di riferimento, quindi potrebbe non rilevare una risposta situata in una tabella diversa. L'audit può anche rifiutare un riferimento valido. È necessaria una revisione ripetuta da parte di annotatori umani indipendenti per stimare entrambi i tipi di errore.
I giudizi della giuria dipendono dall'interpretazione degli LLM. Nessuna revisione umana indipendente ha verificato tutti i verdetti di aggiudicazione. Nel controllo nova-lite-v1, l'accuratezza è salita dal 18,9% nel punteggio stretto al 31,6% dopo l'aggiudicazione, mostrando che la revisione non ha prodotto automaticamente un punteggio elevato. Tale controllo da solo non può stabilire l'accuratezza della giuria.
Il confronto stretto può fallire in entrambe le direzioni. Colonne aggiuntive o un diverso ordine delle colonne possono far rifiutare una risposta utile. La normalizzazione delle maiuscole e l'arrotondamento dei valori in virgola mobile a sei cifre significative possono far accettare differenze rilevanti.
Gli intervalli di campionamento delle domande sono disponibili per i punteggi stretti e per l'accuratezza SQL nell'esportazione dei risultati. Omettono l'incertezza delle etichette dei riferimenti, l'errore della giuria e la variazione tra esecuzioni SQL ripetute. Nessuna analisi ripetuta SQL è riportata qui.
Si tratta di risultati per un carico di lavoro selezionato e privo di suggerimenti (gratuito), con un requisito di instradamento del database. Non sono direttamente confrontabili con la classifica BIRD. I dati di addestramento pubblici comportano inoltre un rischio di sovrapposizione dei dati di addestramento, come discusso nell'articolo sull'instradamento.
Conclusione
claude-opus-5.5 ha guidato l'accuratezza SQL con il 87,8%, seguito da gemini-4-argon con il 78,6% e da gemini-3.8-flash con il 77,2%.
Ogni punteggio SQL riflette le domande che il modello ha instradato correttamente e i riferimenti conservati dopo la revisione. Un confronto SQL controllato darebbe a ogni modello le stesse domande e informazioni di database, con verifiche indipendenti delle etichette dei riferimenti e delle decisioni della giuria.
Ulteriori letture
- Benchmark RAG agentico: instradamento multi-database
- Oltre 800 benchmark IA leader
- HALC-Bench: allucinazioni LLM nel benchmark di recupero su contesto lungo
Cita questo benchmark
Scegli il formato adatto a dove pubblicherai. Incollare la versione con link nel tuo CMS preserva il backlink.
@misc{sari2026,
author = {Sarı, Ekrem},
title = {{AIM-Text-to-SQL Benchmark: SQL Precisione su oltre 70 LLM}},
year = {2026},
month = oct,
howpublished = {\url{https://aimultiple.com/text-to-sql}},
note = {AIMultiple. Consultato il 1 ottobre 2026}
}Risultati e timestamp di 1.4 mila punti dati. Scarica i dati di sintesi mostrati nei grafici e nelle tabelle di questo articolo come file ZIP contenente 4 file CSV e un README.
Vuoi i dati granulari che ci stanno dietro? Passa a Premium
Registro delle modifiche
9 aggiornamentiSostituiti i risultati del benchmark text-to-SQL con un panel di 36 modelli valutato tramite corrispondenza di esecuzione strict, gold-clean e adjudicated.
Aggiunto un changelog alla sezione "Agentic RAG benchmark: multi-database routing and query generation".
Sostituita la sezione metodologia con un riassunto e un riferimento a un altro articolo.
Collegamenti di riferimento
Prossimo da leggere
Benchmark di riconoscimento vocale: Deepgram vs. Whisper
Generazione di testi con IA: i migliori 17 casi d'uso e 5 casi di studio
OCR Confronto: Estrazione del testo / Accuratezza della cattura
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.
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.