Servizi
Contattaci

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

Ekrem Sarı
Ekrem Sarı
aggiornato il 7 ago. 2026

Abbiamo eseguito 36 grandi modelli linguistici su 759 domande del dataset BIRD-SQL, ciascun modello scrivendo SQL su un database che doveva identificare autonomamente tra 11 candidati. Ogni query analizzabile è stata eseguita sul database reale e il suo set di risultati confrontato con quello della query gold di BIRD. Le query mancanti, malformate o che non sono riuscite a essere eseguite sono state considerate errori.

Ogni esecuzione è stata fatta a temperatura 0, zero-shot, nascondendo il suggerimento di dominio di BIRD. Diciannove delle 36 esecuzioni hanno utilizzato il livello di recupero delle chiamate-tool descritto nella pagina di routing, che analizza le chiamate-tool che il parser standard rifiuta. Quindici esecuzioni sono precedenti e due si collocano a cavallo del cambiamento.

Metriche spiegate

Corrispondenza rigorosa dell'esecuzione. Corrispondenza dell'esecuzione sulle domande per cui il modello ha instradato correttamente. Condizionare sul percorso corretto elimina i fallimenti diretti dovuti a database sbagliato, ma non isola completamente l'abilità SQL, perché ogni modello raggiunge un sottoinsieme diverso di domande.

Pulito-oro. La stessa misurazione con le domande la cui query SQL gold è stata giudicata difettosa rimosse dal denominatore. Quelle domande non vengono conteggiate come successi; vengono rimosse.

Aggiudicato. L'estremo superiore. Una giuria cieca di tre modelli, scelti tra famiglie diverse dal modello in esame, esamina ogni risposta che il confronto rigoroso ha rifiutato, quando il modello ha instradato correttamente, la SQL viene eseguita e le sue righe si sovrappongono a quelle gold per meno della metà. Decide se la query è una formulazione diversa ma equivalente, se il gold è sbagliato o se il modello è sbagliato. Le risposte equivalenti e i gold difettosi vengono accreditati.

Tutte e tre partono dall'intero set di 759 domande anziché dal sottoinsieme difficile, e nessuna di esse usa 759 come denominatore. Ciascuna è misurata sulle domande che il modello ha instradato correttamente, e la colonna pulito-oro poi esclude i gold segnalati. Il caso non si applica a questo asse, perché una query o restituisce il result set gold oppure no.

Risultati del benchmark Text-to-SQL

Le risposte giuste nella forma sbagliata costano a un modello 22.7 punti

claude-sonnet-5 registra 0.311 sulla corrispondenza rigorosa dell'esecuzione, 33° sui 36 modelli e il più basso di qualsiasi riga Anthropic. Con l'aggiudicazione cieca lo stesso run ottiene 0.710, 0.007 sotto il 0.717 di qwen3.6-27b.

Il guadagno di 39.9 punti si divide in due. 154 delle sue 679 domande valutate, 22.7 punti, sono risposte che la giuria ha letto come equivalenti al gold ma in forma diversa. Altre 117, 17.2 punti, sono domande per cui la giuria ha giudicato il gold stesso difettoso. Lo stile della risposta spiega la prima delle due, non la somma. Il fallimento del sistema di esecuzione non spiega nulla, poiché il run non ha registrato query mancanti, un crash e nessuna risposta non recuperata.

Figura 1: Una esecuzione di claude-sonnet-5 valutata in due modi e perché la terza misurazione usa un denominatore diverso

Quelle stesse 154 risposte rappresentano il 34% delle 453 mancate risposte di sonnet-5 che sono arrivate all'aggiudicazione. Equivalenza di formato significa che la query restituisce le informazioni giuste con una proiezione diversa, una colonna in più, un ordine delle colonne diverso, oppure un conteggio dove il gold restituiva le righe. La corrispondenza rigorosa dell'esecuzione lo valuta come un fallimento.

La tendenza si distribuisce per famiglia di modelli piuttosto che per livello di capacità. Le famiglie con proiezioni ricche perdono da un quarto a un terzo delle loro mancate risposte aggiudicate in questo modo: Claude dal 25 al 34%, Kimi dal 24 al 34%, la linea ragionamento 5.x di OpenAI dal 26 al 32%, DeepSeek 31%, MiniMax dal 26 al 30% e GLM-5.x 28%. I modelli che scrivono nella forma gold perdono molto meno: Google dal 9 al 17%, Llama 9%, Mistral 18%, Grok 19% e i modelli piccoli di OpenAI dal 19 al 20%. Grok ha infranto la nostra prima spiegazione di questo pattern. Si colloca nel livello di ragionamento e perde il 19%.

La misurazione aggiudicata colloca sonnet-5 al 17° posto, un divario di 16 posizioni.

La giuria trova che il 46% delle risposte rifiutate di un modello non sono errori del modello

Abbiamo preso 314 delle 346 risposte che il confronto rigoroso ha rifiutato per gemini-3.5-flash-lite sulle domande che aveva instradato correttamente, quelle la cui SQL è stata eseguita e le cui righe si sovrapponevano a quelle gold per meno della metà, e le abbiamo inviate alla giuria cieca di tre modelli con ordine delle posizioni mescolato. Quelle 346 coprono ogni fascia di difficoltà, non solo quelle difficili, quindi corrispondono alla popolazione coperta dalle colonne SQL.

La giuria le ha suddivise in quattro categorie. Difetto dell'oro, dove il modello ha ragione e la query gold di BIRD è sbagliata, ha preso il 29.3%. Equivalenza di formato il 16.6%, errore genuino del modello il 33.4% e ambiguo il 20.7%. Sommando le prime due, 144 delle 314 mancate aggiudicate (46%) non sono errori del modello. Questa percentuale è calcolata sulle 314 arrivate alla giuria, non su tutte le 346 risposte rifiutate. Le 32 trattenute o non sono state eseguite o si sovrapponevano troppo al gold per essere un disaccordo netto.

La rigidità del comparatore non spiega il divario. Allentare il confronto sull'ordine delle colonne guadagna 0.5 punti e 92% degli errori si sovrappongono al risultato gold per meno di 0.5. L'aggiudicazione, piuttosto che un comparatore più lasco, colloca quel modello in un intervallo da 0.606 a 0.687, contro uno strict di 0.464.

Le mancate risposte che la giuria ha definito difetto dell'oro si concentrano dove nessuna correzione pubblicata arriva, al 33% delle mancate di questo modello nel train split contro il 20% delle mancate nel dev split. Ogni correzione deterministica a nostra disposizione era già stata utilizzata. Rivalutare contro la release dev corretta di BIRD stessa ha ribaltato 0 dei 92 errori dev, un set di correzioni esterne ne ha coperti 39 ribaltandone 1, e un audit del motore MySQL contro SQLite ha trovato 4 gold divergenti sull'intero set, insieme circa l'1% dei 314.

Il nostro audit con cinque modelli segnala il 31.1% delle query gold di BIRD come difettose

Abbiamo sottoposto a audit l'oro stesso. Cinque modelli di frontiera, uno per famiglia, hanno valutato tutte le 759 query gold rispetto alle loro domande e schemi. A nessun giurato è mai stato mostrato l'output di alcun modello. Il panel ha segnalato 236 delle 759 query gold come difettose, il 31.1%, al costo di $20.55 e senza chiamate fallite della giuria.

Il tasso si divide per partizione BIRD: 204 delle 560 gold di train (36%) contro 32 delle 199 gold di dev (16%). Un panel indipendente di tre modelli eseguito in precedenza ha raggiunto il 29.1%, e 207 dei suoi 221 flag di difetto, il 94%, sono difettosi anche in questo. Su tutte le 759 domande i due panel concordano sul 92.9%.

Una stima pubblicata copre il train split di BIRD, l'audit di MotherDuck su 151 esempi, e pone il tasso al 32.5%. Gli audit peer-reviewed di BIRD coprono il dev split per progettazione esplicita, quindi i 151 esempi di MotherDuck rappresentano l'unico controllo esterno sulle 560 domande di train nel nostro set congelato, il 73.8% di esso.1

Rimuovendo i gold difettosi dal denominatore il miglior scrittore strict passa da 0.551 a 0.677, e i guadagni per modello vanno da +4.5 a +13.3 punti. Il livello superiore mantiene il suo ordine e i vicini di metà classifica si spostano al massimo di tre posizioni.

Un modello da 27B si classifica quinto per accuratezza SQL strict

qwen3.6-27b registra 0.471 strict e 0.590 pulito-oro, quinto nel panel dietro a gemini-3-flash-preview (0.551 / 0.677), gemini-3.1-pro-preview (0.536 / 0.669), claude-fable-5 (0.531 / 0.655) e claude-opus-5 (0.523 / 0.643). Ogni riga di OpenAI, Kimi e DeepSeek registra un punteggio strict inferiore, e il run è costato $15.28.

La colonna è misurata sui percorsi corretti di ciascun modello, quindi un router più debole viene valutato su una selezione più facile. qwen3.6-27b instrada 0.679, e la sezione limitazioni misura quell'effetto con una correlazione di 0.96 tra accuratezza di routing e difficoltà del denominatore.

L'ordinamento cambia quando si utilizza l'estremo superiore della forbice. Nei punteggi aggiudicati qwen3.6-27b è quattordicesimo a 0.717 mentre claude-opus-5 guida con 0.824.

L'abilità di routing e l'abilità di scrittura SQL sono assi separati

kimi-k3 instrada 0.832, dietro a claude-opus-5 a 0.848 e allo stesso livello di qwen3.8-max, e scrive 0.482 SQL pulito-oro contro un miglior panel di 0.677. gemini-3-flash-preview inverte la situazione, instradando 0.753 con quel miglior pulito-oro SQL. gpt-5.6-terra instrada a 0.772 e scrive 0.447.

I due assi non sono misurati su un unico denominatore. Ogni modello scrive SQL per le domande che ha instradato correttamente e nessun'altra, e i router migliori si guadagnano un insieme più difficile, il che deprime qualsiasi associazione misurata tra gli assi.

L'audit dell'oro e la giuria di aggiudicazione

Due giurie hanno svolto due compiti diversi.

Figura 2: La giuria di validità dell'oro e la giuria di aggiudicazione, cosa vede ciascuna e quale metrica alimenta

La giuria di validità dell'oro valuta le query gold. I suoi cinque giurati (claude-opus-4.8, gpt-5.6-sol, gemini-3.1-pro-preview, grok-4.5, deepseek-v4-pro) vedono ciascuno una domanda, la SQL gold e gli elenchi delle colonne delle tabelle toccate da quella query, e rispondono se la gold risponde alla domanda. Nessun output di modello viene mai mostrato. I suoi verdetti sono congelati in un file vincolato da hash e alimentano la colonna pulito-oro.

La giuria di aggiudicazione valuta uno specifico errore di un modello. Tre modelli scelti da famiglie diverse dal modello in esame vedono la domanda, la query e il risultato gold, e la query e il risultato candidato, con le posizioni mescolate, e votano a quale delle quattro categorie appartiene l'errore. Viene eseguita per modello a circa $6, e i suoi verdetti alimentano la colonna aggiudicato. L'aggiudicazione sull'intero panel di 36 modelli è costata $208.81.

La colonna aggiudicato è un endpoint ottimistico aggiustato dall'aggiudicazione, non una verità fondante indipendente. Può sbagliare in entrambe le direzioni. Una risposta ambigua che in realtà era corretta non riceve credito, e un falso positivo della giuria accredita una che non lo era. Tre proprietà misurate delimitano quanto può essere spinta.

La revisione è asimmetrica. Gli errori ricevono un secondo sguardo mentre i successi mai, quindi un errore nella direzione del passaggio non può essere rilevato. I verdetti ambigui, dal 15 al 23% a seconda del modello, non vengono mai accreditati, e i quasi-errori e le query non eseguite restano errori.

Non cancella il pavimento dei modelli deboli. Come controllo negativo abbiamo aggiudicato nova-lite-v1, la riga più debole del panel. Il suo punteggio sale da 0.190 a 0.316 e rimane 0.150 al di sotto della riga successiva. Il pavimento regge a llama 0.466, mistral 0.509 e gpt-5.4-nano 0.512.

La quota di difetto dell'oro segue la forza del modello con una correlazione di rango di 0.906, misurata su 33 modelli. Le mancate di gpt-5.6-sol sono per il 40% difetto dell'oro e per il 19% errore genuino, mentre quelle di llama-4-maverick sono il 13% e il 50%.

Ventiquattro dei 36 modelli si collocano a o sopra 0.68 nell'aggiudicato.

Come funziona la generazione SQL in questo benchmark

Il modello non riceve mai uno schema in anticipo. Sceglie uno degli 11 strumenti database, legge l'elenco delle tabelle che ne deriva, chiede le colonne di una tabella quando ne ha bisogno e può eseguire query esplorative sul database su cui si è stabilito prima di impegnarsi. L'output dello schema è limitato a 4.000 caratteri e i risultati delle query a 50 righe.

La query finale arriva su una chiamata di finalizzazione obbligatoria inviata senza strumenti allegati, insieme al database che il modello dichiara. Il punteggio esegue quella query e la query gold di BIRD sullo stesso file di database e confronta i due set di risultati, con un sentinella NULL e una modalità sensibile all'ordine per le domande che specificano un ordine.

Il confronto è il passo rigoroso, ed è lì che una risposta giusta può essere valutata come un errore. Una query che restituisce le stesse righe con una colonna in più, in un ordine di colonne diverso o come conteggio quando il gold restituiva le righe, fallisce il confronto. Questo è il divario che la giuria di aggiudicazione misura, non quello che un comparatore più lasco colmerebbe, il quale guadagna 0.5 punti.

Metodologia del benchmark per text-to-SQL

Questo benchmark condivide il suo sistema di esecuzione con il benchmark agentic RAG, che descrive la selezione del database, la tassonomia della difficoltà, l'anonimizzazione, il ciclo agentico e il budget di turni per intero. Entrambe le pagine riportano lo stesso sottoinsieme congelato di 759 domande BIRD-SQL, eseguito su 11 database tra cui il modello deve scegliere, a temperatura 0 con il suggerimento di dominio nascosto. La pagina di routing riporta l'asse di routing, e questa pagina riporta l'asse SQL.

Punteggio: corrispondenza dell'esecuzione. La query finale del modello e la query gold di BIRD vengono entrambe eseguite sul database reale e i loro set di risultati confrontati, con un sentinella NULL e una modalità sensibile all'ordine per le query la cui domanda specifica un ordine. Denominatore: domande che il modello ha instradato correttamente. Forma riportata: una forbice a tre valori, corrispondenza rigorosa dell'esecuzione, poi pulito-oro, poi aggiudicato. Audit dell'oro: 5 famiglie di frontiera, un modello ciascuna, 759 query gold valutate, 236 segnalate come difettose, vincolato da hash. Aggiudicazione: 3 modelli per candidato, disgiunti per famiglia dal modello in esame, cieca e con posizioni mescolate. Panel: 36 modelli, singola esecuzione ciascuno, $874.53 per le esecuzioni e $208.81 per l'aggiudicazione.

Perché nessun giudice LLM valuta la correttezza al piano inferiore. Abbiamo misurato l'alternativa prima di scegliere. Su 2.203 record del benchmark precedente, un giudice LLM non ha mai bocciato una query che l'esecuzione aveva superato, a nessuna soglia. Quel giudice vedeva entrambi i set di risultati, quindi il suo verdetto non è indipendente dall'esito dell'esecuzione e lo zero non dimostra che un giudice non possa essere più severo. L'esecuzione rimane come piano inferiore e la giuria appare più in alto nella forbice dove la sua indulgenza è il punto.

Perché il suggerimento è nascosto. BIRD fornisce un suggerimento di dominio con ogni domanda. Fornirlo vale da 6 a 9 punti di corrispondenza dell'esecuzione, e sposta anche l'accuratezza di routing di 5.7 punti, il che lo rende una fuga di informazioni sull'asse di routing. Entrambe le pagine riportano quindi la condizione senza suggerimento, e i numeri SQL qui riportati sono al di sotto di ciò che gli stessi modelli otterrebbero in condizioni standard BIRD.

Lascia che il nostro team automatizzi uno dei tuoi processi aziendali con agenti IA, gratuitamente.
Automatizza un processo

Accuratezza SQL nel panel, tre modi

Ordinato per la colonna aggiudicato. Sei righe hanno avuto meno di 759 record dopo due tentativi di ripetizione, e le domande mancanti sono assenti da ogni denominatore anziché essere contate come fallimenti.

Limitazioni dell'asse SQL

L'oro è preso in prestito e contestato. Il nostro dato del 31.1% di query gold difettose è il nostro sottoinsieme sottoposto a audit, non una verità fondante multi-annotatore. Non c'è un passaggio duplicato in cieco, nessun dato di accordo inter-annotatore, e la verifica umana è stata fatta dal proprietario del benchmark anziché da un annotatore indipendente. I giurati hanno visto gli elenchi delle colonne delle tabelle toccate dalla query gold, quindi una gold che interroga la tabella sbagliata è irrilevabile da quella vista e tali difetti restano inosservati. Il panel può anche segnalare una gold funzionante, un errore nella direzione opposta. Nessun annotatore indipendente ha ripetuto il passaggio, quindi l'errore residuo non è misurato in nessuna direzione e la cifra non è un pavimento.

La colonna aggiudicato è uno strumento LLM, non una seconda verità fondante, e non un limite superiore rigoroso. I suoi tre giurati sono modelli, quindi la colonna eredita tutto ciò che un panel di modelli sbaglia sull'equivalenza SQL, e nessun umano ha riletto i verdetti.

Il comparatore sbaglia in entrambe le direzioni. L'ordine delle colonne e il numero di colonne causano falsi negativi, mentre l'unificazione delle maiuscole e l'arrotondamento dei float a sei cifre significative causano falsi positivi. L'errore del comparatore e l'errore della query gold sono fonti separate di incertezza e possono spostare un punteggio in direzioni diverse.

La corrispondenza rigorosa dell'esecuzione è misurata sulle domande instradate correttamente da ciascun modello, e i router migliori si guadagnano un insieme più difficile. L'accuratezza di routing traccia la difficoltà delle domande che raggiungono il denominatore SQL di un modello. Sui 36 modelli quella correlazione è 0.96 (Pearson, sulla media del conteggio dei vicini cross-database), e 0.97 contro la quota di domande più difficili in quel denominatore. In termini concreti claude-opus-5 scrive SQL per 717 domande di cui il 21.8% sono tra le 184 più difficili, mentre nova-lite-v1 scrive SQL per 285 domande di cui il 7.7% lo sono. Un router debole viene valutato su una selezione più facile. Trattate questa colonna come una diagnostica per modello piuttosto che come una classifica tra modelli, e leggete le tre colonne come livelli. Per colmare il divario serve un'esecuzione con instradamento oracolare, in cui ogni modello scrive SQL per le stesse domande. Quell'esecuzione non è stata fatta.

Gli intervalli di confidenza coprono solo il rumore di campionamento. La tabella sopra stampa stime puntuali, e gli intervalli di Wilson per le colonne strict e pulito-oro sono disponibili nel CSV pubblicato accanto a ogni riga. Gli intervalli portano il rumore di campionamento delle domande e non l'incertezza delle giurie né quella dei flag dell'oro. Due esecuzioni del panel ripetute in condizioni identiche hanno spostato l'accuratezza di routing di 1.6 a 2.7 punti, e questa pagina non riporta alcuna misura ripetuta per le colonne SQL.

Questi numeri sono per costruzione senza suggerimento, quindi non sono confrontabili con i punteggi della classifica BIRD per gli stessi modelli.

Conclusione

La corrispondenza rigorosa dell'esecuzione contro le query gold di BIRD va da 0.190 a 0.551 tra i 36 modelli, e lo stesso panel va da 0.316 a 0.824 una volta che una giuria cieca ha riletto ogni errore. La distanza tra queste due letture è il risultato. Per claude-sonnet-5 è di 39.9 punti, di cui 22.7 provengono da risposte che restituiscono le informazioni giuste in una forma che il comparatore rifiuta.

Per un carico di lavoro valutato con la corrispondenza rigorosa dell'esecuzione, gemini-3-flash-preview ha registrato 0.551 grezzo e 0.677 pulito-oro a $7.67 per esecuzione. Per un carico di lavoro in cui una risposta equivalente in una proiezione diversa è accettabile, claude-opus-5 ha registrato 0.824 aggiudicato contro lo 0.785 di gpt-5.6-sol, all'interno di un intervallo di confidenza. Per qualsiasi confronto per modello, il denominatore differisce da modello a modello, quindi le tre colonne sono diagnostiche piuttosto che una classifica controllata.

Il soffitto su questo asse è l'oro, non i modelli. Un terzo delle query gold di BIRD non supera il nostro audit, i difetti si concentrano nel train split dove nessuna correzione pubblicata arriva, e i due strumenti che vedono oltre sono entrambi giurie LLM piuttosto che annotatori umani. Per far progredire l'asse serve un'esecuzione con instradamento oracolare in modo che ogni modello scriva SQL per le stesse domande, e un'annotazione umana doppia indipendente di un campione stratificato dell'oro. Nessuna delle due è stata fatta.

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.
GoogleAggiungi come fonte preferita

Ulteriori letture

FAQ

Perché le query gold sono quelle di BIRD e un terzo di esse non supera il nostro audit. La corrispondenza rigorosa dell'esecuzione è il pavimento, la colonna pulito-oro rimuove le domande il cui gold abbiamo giudicato difettoso, e la colonna aggiudicato accredita le risposte che una giuria cieca ha letto come equivalenti. claude-sonnet-5 passa da 0.311 a 0.710 in quella forbice, quindi un singolo numero falserebbe il panel fino a 39.9 punti.

No. BIRD fornisce un suggerimento di dominio con ogni domanda e fornisce il database. Questo benchmark nasconde il suggerimento e fa scegliere al modello il database tra 11. Il solo suggerimento vale da 6 a 9 punti di corrispondenza dell'esecuzione.

Non in questo panel. Ogni modello scrive SQL per le domande che ha instradato correttamente, quindi un router migliore si guadagna un denominatore più difficile, con una correlazione di 0.96 tra accuratezza di routing e difficoltà del denominatore. kimi-k3 instrada 0.832 e scrive 0.482 pulito-oro, mentre gemini-3-flash-preview instrada 0.753 e scrive il miglior panel di 0.677.

Una query gold che non risponde alla propria domanda, come valutato da cinque modelli di frontiera di cinque famiglie diverse, a nessuno dei quali è stata mostrata alcuna risposta candidata. Il panel ha segnalato 236 delle 759 query, e un precedente panel di tre modelli ne ha segnalate indipendentemente 221, di cui 207 si sovrappongono.

Cita questo benchmark

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

Ekrem Sarı (2026) - "Text-to-SQL: Confronto dell'accuratezza degli LLM". Pubblicato online su AIMultiple.com. Consultato il 7 Agosto 2026, da: https://aimultiple.com/text-to-sql [Risorsa online]

Sarı, E. (2026, 7 Agosto). Text-to-SQL: Confronto dell'accuratezza degli LLM. AIMultiple. https://aimultiple.com/text-to-sql

@misc{sari2026,
  author = {Sarı, Ekrem},
  title  = {{Text-to-SQL: Confronto dell'accuratezza degli LLM}},
  year   = {2026},
  month  = aug,
  howpublished    = {\url{https://aimultiple.com/text-to-sql}},
  note   = {AIMultiple. Consultato il 7 Agosto 2026}
}

Collegamenti di riferimento

1.
BIRD-bench
Ekrem Sarı
Ekrem Sarı
Ricercatore AI
Ekrem è Ricercatore AI e analista di dati presso AIMultiple. Progetta ed esegue benchmark pratici per sistemi di AI e LLM.
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.

0/450
PFJ Rofgowski
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 .

Ekrem Sarı
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.