Benchmark AIM-Text-to-SQL: Accuratezza SQL 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 insieme diverso di domande SQL perché la valutazione dipende dalle scelte di database effettuate. Le differenze tra questi sottoinsiemi e la configurazione di esecuzione limitano i confronti.
Risultati text-to-SQL
Opus 5.5 ha registrato un'accuratezza SQL del 87,8%
claude-opus-5.5 ha eguagliato il risultato di riferimento su 444 delle 506 domande valutate. gemini-3.8-flash segue con il 77,2% (342 su 443), poi claude-sonnet-5.5 con il 73,8% (368 su 499). Questi sono stati i tre punteggi di accuratezza SQL più alti nel panel di 74 modelli.
Il punteggio esclude le scelte di database errate e i riferimenti contrassegnati come non validi. Opus 5.5 è stato eseguito tramite Claude Code. Gemini 3.8 Flash e Sonnet 5.5 hanno utilizzato 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 rispettivi 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 utilizzato 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 persistono.
Costo vs. accuratezza SQL
Il costo di esecuzione copre le risposte di instradamento e SQL conservate da ogni esecuzione benchmark del modello. L'obiettivo era di 759 domande. Sette esecuzioni hanno un numero inferiore di risposte conservate. I tentativi scartati, le prove pilota e le chiamate della giuria sono esclusi. L'accuratezza SQL utilizza le domande instradate correttamente da ciascun modello dopo l'esclusione dei 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. Il punteggio di Opus 5.5 del 87,8% è associato a un costo stimato equivalente API di $188.71.
I 71 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 controllati il 1° ottobre 2026, con l'utilizzo della cache registrato preservato. Queste stime non misurano la spesa effettiva per gli abbonamenti.
I costi includono l'esplorazione dei database e i punteggi SQL coprono sottoinsiemi di domande diversi. Questo confronto descrive pertanto il costo e l'accuratezza del flusso di lavoro combinato del benchmark. I costi isolati di generazione SQL non sono stati misurati. Il benchmark agentic RAG riporta la selezione dei database separatamente.
Risultati di accuratezza SQL
La fase prima della revisione dei riferimenti misura la corrispondenza esatta dei risultati su tutte le domande instradate correttamente. La fase dopo la revisione delle risposte aggiunge credito per le risposte accettate dalla giuria. Entrambe le colonne di confronto utilizzano 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 è passata dal 67,5% al 76,2%. L'accuratezza rigorosa, prima della revisione dei riferimenti, è passata dal 55,0% al 61,6%.
Si è trattato di un esperimento su un singolo modello. Non stabilisce un miglioramento comune per il panel di 74 modelli. Il panel principale non fornisce 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 rigoroso contiene 717 domande, di cui 156 dal gruppo di instradamento più difficile. Per nova-lite-v1, contiene 285 domande, di cui 22 da tale gruppo. Le quote sono del 21,8% e del 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. Questo esperimento non è stato eseguito.
La selezione delle domande è importante anche quando si confrontano benchmark di intelligenza artificiale che forniscono schemi, suggerimenti o budget di strumenti diversi.
Risultati della revisione dei riferimenti e delle risposte
La verifica dei riferimenti ha contrassegnato 236 delle 759 query
Cinque modelli hanno valutato ogni query di riferimento rispetto alla relativa domanda e alle informazioni sullo 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% del set.
Dopo la verifica, il proprietario del benchmark ha esaminato le segnalazioni. Gli annotatori umani indipendenti non hanno ripetuto tale revisione. Queste percentuali descrivono il sottoinsieme verificato. 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 valutate in modo rigoroso, pari al 31,1%. Una giuria ha accettato altre 154 risposte come equivalenti al riferimento. Queste hanno contribuito con 22.7 punti percentuali.
Ulteriori 117 risposte hanno ricevuto credito perché la giuria ha accettato la query del modello e rifiutato il riferimento. Queste 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 rigoroso 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 dei database.1 Abbiamo utilizzato una selezione congelata di 759 domande da 11 database, che copre 560 esempi di train e 199 esempi di dev.
I modelli hanno ricevuto brevi descrizioni dei database e strumenti per elencare le 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 codice 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 rigoroso ha confrontato i relativi risultati, inclusa una modalità sensibile all'ordine per le domande che richiedono una risposta ordinata. Le query candidate mancanti, malformate o con errori di esecuzione non hanno ricevuto alcun credito rigoroso sulle domande altrimenti idonee e instradate correttamente.
Per le 46 esecuzioni OpenRouter, abbiamo richiesto temperatura 0. Ventinove hanno utilizzato il livello di ripristino delle chiamate agli strumenti v3, 15 lo hanno preceduto e due hanno combinato record di entrambe le versioni. GPT-6 Astra è stato eseguito tramite Codex CLI. Opus 5.5 e Fable 5.1 hanno utilizzato Claude Code. Tutte e tre le esecuzioni CLI hanno utilizzato uno sforzo di ragionamento medio. Le esecuzioni di GPT-6 Luna, Luna Pro, Sol e Sol Pro e GPT-5.2 hanno utilizzato 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 principale e supplementari. Le dieci aggiunte API hanno completato tutte le 759 domande dopo i tentativi ripetuti delle richieste non riuscite, preservando le risposte andate a buon fine in precedenza.
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 modifica il risultato:
Prima della revisione dei riferimenti, il punteggio rigoroso misura la corrispondenza esatta dell'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. Utilizza lo stesso denominatore del punteggio rigoroso. 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 conserva invece il denominatore originale e aggiunge credito per le risposte mancate accettate.
Revisione dei riferimenti e delle risposte
La verifica dei riferimenti e la revisione delle risposte candidate richiedono input diversi.
I revisori dei riferimenti sono stati 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 tenute nascoste per mantenere le segnalazioni indipendenti dal modello in valutazione.
Il giudizio delle risposte ha utilizzato tre giurati appartenenti a famiglie di modelli diverse da quella del candidato. Le query di riferimento e candidate sono apparse in posizioni A/B randomizzate senza etichette che ne rivelassero i ruoli. I casi ambigui e quelli con voti validi insufficienti non hanno ricevuto alcun credito aggiuntivo.
La copertura della revisione è asimmetrica. I superamenti rigorosi rimangono accettati, mentre le risposte mancate idonee ricevono un'altra valutazione. Di conseguenza, il giudizio può conservare i falsi positivi del punteggio rigoroso e aggiungerne di propri. È una stima supplementare, senza correttezza garantita né un limite superiore garantito sull'accuratezza reale.
Una risposta mancata era idonea al giudizio quando la query candidata veniva eseguita e la sovrapposizione F1 tra le righe del 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 dalla candidata.
Ad esempio, gemini-3.5-flash-lite ha avuto 346 risposte mancate rigorose. 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 casi come errori del modello e ha lasciato 65 casi ambigui. Le altre 32 risposte mancate comprendevano 27 casi con maggiore sovrapposizione dei risultati e cinque errori di esecuzione.
I 144 casi accettati rappresentano il 45,9% delle risposte mancate esaminate, non di ogni risposta non riuscita.
Aggiungi come fonte preferitaLimitazioni
Gli errori dei riferimenti restano incerti. La verifica 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. La verifica 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 dell'LLM. Nessuna revisione umana indipendente ha verificato tutti i verdetti di aggiudicazione. Nel controllo nova-lite-v1, l'accuratezza è passata dal 18,9% con il punteggio rigoroso al 31,6% dopo l'aggiudicazione, dimostrando che la revisione non ha prodotto automaticamente un punteggio elevato. Questo solo controllo non può stabilire l'accuratezza della giuria.
Il confronto rigoroso può fallire in entrambe le direzioni. Colonne aggiuntive o un ordine diverso delle colonne possono rifiutare una risposta utile. La normalizzazione delle maiuscole e l'arrotondamento dei valori a virgola mobile a sei cifre significative possono accettare differenze che contano.
Gli intervalli di campionamento delle domande sono disponibili per i punteggi rigorosi e per l'accuratezza SQL nell'esportazione dei risultati. Essi omettono l'incertezza delle etichette dei riferimenti, l'errore della giuria e la variazione tra esecuzioni SQL ripetute. Nessuna analisi ripetuta del SQL è riportata qui.
Si tratta di risultati per un carico di lavoro selezionato e hint-free con un requisito di instradamento dei database. Non sono direttamente confrontabili con la classifica BIRD. I dati di training pubblici comportano inoltre un rischio di sovrapposizione con i 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-3.8-flash con il 77,2% e claude-sonnet-5.5 con il 73,8%.
Ogni punteggio SQL riflette le domande che il modello ha instradato correttamente e i riferimenti conservati dopo la revisione. Un confronto SQL controllato fornirebbe a ogni modello le stesse domande e le stesse informazioni sui database, con controlli indipendenti delle etichette dei riferimenti e delle decisioni della giuria.
Ulteriori letture
- Benchmark Agentic RAG: instradamento multi-database
- 800+ benchmark IA leader
- HALC-Bench: allucinazione di LLM su benchmark di recupero a lungo contesto
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 = {{Benchmark AIM-Text-to-SQL: Accuratezza SQL 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
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.