Services
Contactez-nous

Text-to-SQL: Comparaison de la précision des LLM

Ekrem Sarı
Ekrem Sarı
mis à jour le 7 août 2026

Nous avons exécuté 36 grands modèles de langage sur 759 questions de BIRD-SQL, chaque modèle écrivant du SQL contre une base de données qu'il devait identifier par lui-même parmi 11 candidates. Chaque requête analysable a été exécutée contre la base de données réelle et son ensemble de résultats comparé à l'ensemble de résultats de la requête gold de BIRD. Les requêtes manquantes, mal formées ou ayant échoué à l'exécution ont été comptées comme des échecs.

Loading Chart

Chaque exécution a été réalisée à température 0, en zero-shot, avec l'indice de domaine de BIRD retenu. Dix-neuf des 36 exécutions ont utilisé la couche de récupération des appels d'outils décrite sur la page de routage, qui analyse les appels d'outils que l'analyseur standard rejette. Quinze exécutions la précèdent et deux chevauchent le changement.

Métriques expliquées

Correspondance stricte d'exécution. Correspondance d'exécution sur les questions que le modèle a routées correctement. Le conditionnement sur la route correcte élimine les échecs directs dus à une mauvaise base de données, mais cela n'isole pas entièrement la capacité en SQL, car chaque modèle atteint un sous-ensemble différent de questions.

Gold nettoyé. La même mesure avec les questions dont le SQL gold a été jugé défectueux par nos soins, retirées du dénominateur. Ces questions ne sont pas comptées comme des réussites, elles sont supprimées.

Arbitré. L'extrémité supérieure. Un jury aveugle de trois modèles, issus de familles autres que celle du modèle testé, examine chaque réponse que la comparaison stricte a rejetée, lorsque le modèle a routé correctement, que le SQL s'exécute et que ses lignes chevauchent celles du gold à moins de la moitié. Il décide si la requête est une formulation différente mais équivalente, si le gold est erroné ou si le modèle est erroné. Les réponses équivalentes et les golds défectueux sont crédités.

Tous les trois partent de l'ensemble complet de 759 questions plutôt que du sous-ensemble difficile, et aucun d'eux n'utilise 759 comme dénominateur. Chacun est mesuré sur les questions que le modèle a routées correctement, et la colonne gold nettoyé retire ensuite les golds signalés. Le hasard ne s'applique pas à cet axe, car une requête renvoie soit l'ensemble de résultats gold, soit elle ne le renvoie pas.

Résultats du benchmark Text-to-SQL

Des réponses correctes dans la mauvaise forme coûtent 22,7 points à un modèle

claude-sonnet-5 enregistre 0 311 en correspondance stricte d'exécution, 33e sur les 36 modèles et le plus bas de toutes les lignes Anthropic. Sous arbitrage aveugle, la même exécution obtient 0 710, soit 0 007 en dessous des 0 717 de qwen3.6-27b.

Le gain de 39,9 points se divise en deux. 154 de ses 679 questions notées, soit 22,7 points, sont des réponses que le jury a jugées équivalentes au gold dans une forme différente. 117 autres, soit 17,2 points, sont des questions où le jury a jugé le gold lui-même défectueux. Le style de réponse explique le premier de ces deux éléments, pas la somme. L'infrastructure de test n'explique rien de tout cela, car l'exécution n'a enregistré aucune requête manquante, un seul plantage et aucune réponse non récupérée.

Figure 1 : Une exécution de claude-sonnet-5 notée de deux manières, et pourquoi la troisième mesure utilise un dénominateur différent

Ces mêmes 154 réponses représentent 34 % des 453 échecs de sonnet-5 qui ont atteint l'arbitrage. Équivalent en format signifie que la requête renvoie la bonne information dans une projection différente, une colonne supplémentaire, un ordre de colonnes différent, ou un comptage là où le gold renvoyait les lignes. La correspondance stricte d'exécution note cela comme un échec.

La tendance s'exerce par famille de modèles plutôt que par niveau de capacité. Les familles à projection riche perdent entre un quart et un tiers de leurs échecs arbitrés de cette manière, à Claude 25 à 34 %, Kimi 24 à 34 %, la gamme de raisonnement 5.x d'OpenAI 26 à 32 %, DeepSeek 31 %, MiniMax 26 à 30 % et GLM-5.x 28 %. Les rédacteurs conformes au gold perdent bien moins, à Google 9 à 17 %, Llama 9 %, Mistral 18 %, Grok 19 % et les propres petits modèles d'OpenAI 19 à 20 %. Grok a brisé notre première explication de ce schéma. Il se situe dans le niveau de raisonnement et perd 19 %.

La mesure arbitrÉe place sonnet-5 17e, un écart de 16 positions.

Le jury estime que 46 % des réponses rejetées d'un modèle ne sont pas des erreurs du modèle

Nous avons pris 314 des 346 réponses que la comparaison stricte a rejetées pour gemini-3.5-flash-lite sur les questions qu'il a routées correctement, celles dont le SQL s'exécutait et dont les lignes chevauchaient celles du gold à moins de la moitié, et les avons envoyées au jury aveugle de trois modèles, avec positions mélangées. Ces 346 couvrent tous les niveaux de difficulté plutôt que les seuls difficiles, de sorte qu'elles correspondent à la population couverte par les colonnes SQL.

Le jury les a réparties en quatre catégories. Défaut du gold, où le modèle a raison et la requête gold de BIRD est erronée, a représenté 29,3 %. Équivalent en format a représenté 16,6 %, erreur véritable du modèle 33,4 %, et ambigu 20,7 %. En additionnant les deux premières, 144 des 314 échecs arbitrés (46 %) ne sont pas des erreurs du modèle. Cette part est calculée sur les 314 qui ont atteint le jury, pas sur l'ensemble des 346 réponses rejetées. Les 32 retenues ont soit échoué à s'exécuter, soit trop chevauché le gold pour constituer un désaccord net.

La rigueur du comparateur n'explique pas l'écart. Assouplir la correspondance d'ordre des colonnes ne rapporte que 0,5 point, et 92 % des échecs chevauchent le résultat gold à moins de 0,5. L'arbitrage, plutôt qu'un comparateur plus souple, place ce modèle dans une fourchette de 0 606 à 0 687, contre un score strict de 0 464.

Les échecs que le jury a qualifiés de défauts du gold se concentrent là où aucune correction publiée ne parvient, à 33 % des échecs de la partition d'entraînement de ce modèle contre 20 % de ses échecs de la partition de développement. Toute correction déterministe à notre disposition avait déjà été utilisée. La renotation par rapport à la version de développement corrigée de BIRD a retourné 0 des 92 échecs de développement, un ensemble de corrections externes en a couvert 39 et en a retourné 1, et un audit moteur MySQL contre SQLite a trouvé 4 golds divergents sur l'ensemble complet, soit environ 1 % des 314.

Notre audit à cinq modèles signale 31,1 % des requêtes gold de BIRD comme défectueuses

Nous avons audité le gold lui-même. Cinq modèles frontières, un par famille, ont évalué les 759 requêtes gold par rapport à leurs questions et schémas. Aucun juré n'a jamais vu la sortie d'aucun modèle. Le panel a signalé 236 des 759 golds comme défectueux, soit 31,1 %, pour un coût de 20,55 $ et sans aucun appel de jury échoué.

Le taux se divise par partition BIRD, à 204 des 560 golds d'entraînement (36 %) contre 32 des 199 golds de développement (16 %). Un panel indépendant de trois modèles exécuté plus tôt avait atteint 29,1 %, et 207 de ses 221 signalements de défauts, soit 94 %, sont défectueux dans celui-ci. Sur l'ensemble des 759 questions, les deux panels s'accordent à 92,9 %.

Une estimation publiée couvre la partition d'entraînement de BIRD, l'audit de MotherDuck sur 151 exemples, et elle fixe le taux à 32,5 %. Les audits évalués par les pairs de BIRD couvrent la partition de développement par conception explicite, de sorte que les 151 exemples de MotherDuck constituent la seule vérification externe sur les 560 questions d'entraînement de notre ensemble gelé, soit 73,8 % de celui-ci.1

Retirer les golds défectueux du dénominateur fait passer le meilleur rédacteur strict de 0 551 à 0 677, et les gains par modèle s'étendent de +4,5 à +13,3 points. Le peloton de tête conserve son ordre et les voisins de milieu de tableau se déplacent de jusqu'à trois positions.

Un modèle de 27B se classe cinquième en précision SQL stricte

qwen3.6-27b enregistre 0 471 en strict et 0 590 en gold nettoyé, cinquième du panel derrière gemini-3-flash-preview (0 551 / 0 677), gemini-3.1-pro-preview (0 536 / 0 669), claude-fable-5 (0 531 / 0 655) et claude-opus-5 (0 523 / 0 643). Chaque ligne OpenAI, Kimi et DeepSeek enregistre un score strict inférieur, et l'exécution a coûté 15,28 $.

La colonne est mesurée sur les routes correctes propres à chaque modèle, de sorte qu'un routeur plus faible est noté sur une sélection plus facile. qwen3.6-27b route 0 679, et la section des limitations mesure cet effet à une corrélation de 0,96 entre la précision de routage et la difficulté du dénominateur.

L'ordre change une fois l'extrémité supérieure du bracket utilisée. Sur les scores arbitrÉs, qwen3.6-27b est quatorzième à 0 717 tandis que claude-opus-5 mène à 0 824.

La compétence de routage et la compétence d'écriture SQL sont des axes distincts

kimi-k3 route 0 832, derrière claude-opus-5 à 0 848 et au même niveau que qwen3.8-max, et écrit du 0 482 gold nettoyé SQL contre un meilleur score du panel de 0 677. gemini-3-flash-preview l'inverse, routant 0 753 avec ce meilleur score gold nettoyé en SQL du panel. gpt-5.6-terra route à 0 772 et écrit 0 447.

Les deux axes ne sont pas mesurés sur un seul dénominateur. Chaque modèle écrit du SQL pour les questions qu'il a routées correctement et aucune autre, et les meilleurs routeurs obtiennent un ensemble plus difficile, ce qui tire toute association mesurée entre les axes vers le bas.

L'audit des golds et le jury d'arbitrage

Deux jurys ont effectué deux tâches différentes.

Figure 2 : Le jury de validité des golds et le jury d'arbitrage, ce que chacun voit et quelle métrique il alimente

Le jury de validité des golds évalue les requêtes gold. Ses cinq jurés (claude-opus-4.8, gpt-5.6-sol, gemini-3.1-pro-preview, grok-4.5, deepseek-v4-pro) voient chacun une question, le SQL gold et les listes de colonnes des tables que cette requête touche, et répondent si le gold répond à la question. Aucune sortie de modèle n'est jamais montrée. Ses verdicts sont figés dans un fichier horodaté par hachage et alimentent la colonne gold nettoyé.

Le jury d'arbitrage évalue l'échec d'un modèle spécifique. Trois modèles issus de familles autres que celle du modèle testé voient la question, la requête et le résultat gold, ainsi que la requête et le résultat candidats, avec les positions mélangées, et votent sur la catégorie à laquelle l'échec appartient parmi quatre. Il s'exécute par modèle pour environ 6 $, et ses verdicts alimentent la colonne arbitrÉe. L'arbitrage sur l'ensemble du panel de 36 modèles a coûté 208,81 $.

La colonne arbitrÉe est un point d'arrivée optimiste ajusté par arbitrage plutôt qu'une vérité terrain indépendante. Elle peut errer dans les deux sens. Une réponse ambiguë qui était en réalité correcte n'obtient aucun crédit, et un faux positif du jury en crédite une qui ne l'était pas. Trois propriétés mesurées encadrent jusqu'où elle peut être poussée.

L'examen est asymétrique. Les échecs bénéficient d'un second regard et les réussites jamais, de sorte qu'une erreur dans le sens de la réussite ne peut pas être détectée. Les verdicts ambigus, 15 à 23 % selon le modèle, ne sont jamais crédités, et les quasi-échecs et les requêtes qui ne s'exécutent pas restent des échecs.

Il n'efface pas le plancher des modèles faibles. Comme contrôle négatif, nous avons arbitré nova-lite-v1, la ligne la plus faible du panel. Son score passe de 0 190 à 0 316 et reste 0 150 en dessous de la ligne suivante. Le plancher tient à llama 0 466, mistral 0 509 et gpt-5.4-nano 0 512.

La part de défauts du gold suit la force du modèle avec une corrélation de rang de 0 906, mesurée sur 33 modèles. Les échecs de gpt-5.6-sol sont à 40 % des défauts du gold et à 19 % des erreurs véritables, là où ceux de llama-4-maverick sont à 13 % et 50 %.

Vingt-quatre des 36 modèles se situent à ou au-dessus de 0,68 en arbitré.

Comment la génération SQL fonctionne dans ce benchmark

Le modèle ne reçoit jamais de schéma à l'avance. Il choisit l'un des 11 outils de base de données, lit la liste de tables qui lui est renvoyée, demande les colonnes d'une table lorsqu'il en a besoin, et peut exécuter des requêtes exploratoires contre la base de données sur laquelle il s'est arrêté avant de s'engager. La sortie du schéma est plafonnée à 4 000 caractères et les résultats de requêtes à 50 lignes.

La requête finale arrive lors d'un appel de finalisation obligatoire envoyé sans outils attachés, accompagnée de la base de données que le modèle déclare. La notation exécute cette requête et la requête gold de BIRD contre le même fichier de base de données et compare les deux ensembles de résultats, avec une sentinelle NULL et un mode sensible à l'ordre pour les questions qui spécifient un ordre.

La comparaison est l'étape stricte, et c'est là qu'une réponse correcte peut être notée comme un échec. Une requête renvoyant les mêmes lignes avec une colonne supplémentaire, dans un ordre de colonnes différent, ou sous forme de comptage là où le gold renvoyait les lignes, échoue à la comparaison. C'est cet écart que le jury d'arbitrage mesure plutôt que celui qu'un comparateur plus souple comblerait, ce qui ne rapporte que 0,5 point.

Méthodologie du benchmark pour le text-to-SQL

Ce benchmark partage son infrastructure avec le benchmark agentic RAG, qui décrit la sélection de base de données, la taxonomie de difficulté, l'anonymisation, la boucle agentic et le budget de tours dans leur intégralité. Les deux pages rapportent le même sous-ensemble gelé de 759 questions BIRD-SQL, exécuté sur 11 bases de données parmi lesquelles le modèle doit choisir, à température 0 avec l'indice de domaine retenu. La page de routage porte l'axe de routage, et cette page porte l'axe SQL.

Notation : correspondance d'exécution. La requête finale du modèle et la requête gold de BIRD sont toutes deux exécutées contre la base de données réelle et leurs ensembles de résultats comparés, avec une sentinelle NULL et un mode sensible à l'ordre pour les requêtes dont la question spécifie un ordre. Dénominateur : questions que le modèle a routées correctement. Forme rapportée : un bracket à trois valeurs, correspondance stricte d'exécution, puis gold nettoyé, puis arbitré. Audit des golds : 5 familles frontières, un modèle chacune, 759 golds évalués, 236 signalés défectueux, horodatés par hachage. Arbitrage : 3 modèles par candidat, disjoints de la famille du modèle testé, aveugle et positions mélangées. Panel : 36 modèles, une seule exécution chacun, 874,53 $ pour les exécutions et 208,81 $ pour l'arbitrage

Pourquoi aucun juge LLM n'évalue la justesse au plancher. Nous avons mesuré l'alternative avant de choisir. Sur 2 203 enregistrements du benchmark précédent, un juge LLM n'a jamais échoué une requête que l'exécution avait réussie, à aucun seuil. Ce juge voyait les deux ensembles de résultats, son verdict n'est donc pas indépendant du résultat d'exécution et le zéro n'établit pas qu'un juge ne puisse pas être plus strict. L'exécution reste au plancher et le jury apparaît plus haut dans le bracket là où sa clémence est le propos.

Pourquoi l'indice est retenu. BIRD fournit un indice de domaine avec chaque question. Le fournir vaut de 6 à 9 points de correspondance d'exécution, et il déplace également la précision de routage de 5,7 points, ce qui en fait une fuite sur l'axe de routage. Les deux pages rapportent donc la condition sans indice, et les chiffres SQL ici se situent en dessous de ce que les mêmes modèles obtiendraient dans les conditions standard de BIRD.

Laissez notre équipe automatiser l'un de vos processus métier avec des agents IA, gratuitement.
Automatiser un processus

Précision SQL à travers le panel, de trois manières

Classé par la colonne arbitrÉe. Six lignes ont manqué d'enregistrements par rapport aux 759 après deux passages de reprise, et les questions manquantes sont absentes de chaque dénominateur plutôt que comptées comme des échecs.

Limites de l'axe SQL

Le gold est emprunté et contesté. Notre chiffre de 31,1 % de golds défectueux est notre propre sous-ensemble audité, pas une vérité terrain multi-annotateurs. Il n'y a pas de passage dupliqué en aveugle, pas de chiffre d'accord inter-annotateurs, et la vérification humaine a été effectuée par le propriétaire du benchmark plutôt que par un annotateur indépendant. Les jurés voyaient les listes de colonnes des tables que la requête gold touche, de sorte qu'un gold qui interroge la mauvaise table est indétectable depuis cette vue et de tels défauts sont manqués. Le panel peut également signaler un gold fonctionnel, une erreur dans l'autre sens. Aucun annotateur indépendant n'a répété le passage, donc l'erreur résiduelle n'est mesurée dans aucun sens et le chiffre n'est pas un plancher.

La colonne arbitrÉe est un instrument LLM, pas une seconde vérité terrain, et pas une borne supérieure stricte. Ses trois jurés sont des modèles, donc la colonne hérite de tout ce qu'un panel de modèles peut se tromper sur l'équivalence SQL, et aucun humain n'a relu les verdicts.

Le comparateur erre dans les deux sens. L'ordre et le nombre de colonnes causent des faux négatifs, tandis que la conversion de casse et l'arrondi des flottants à six chiffres significatifs causent des faux positifs. L'erreur du comparateur et l'erreur de la requête gold sont des sources d'incertitude distinctes et peuvent déplacer un score dans des directions différentes.

La correspondance stricte d'exécution est mesurée sur les questions correctement routées propres à chaque modèle, et les meilleurs routeurs obtiennent un ensemble plus difficile. La précision de routage suit la difficulté des questions qui atteignent le dénominateur SQL d'un modèle. Sur les 36 modèles, cette corrélation est de 0,96 (Pearson, sur le nombre moyen de voisins inter-bases de données), et de 0,97 par rapport à la part des questions les plus difficiles dans ce dénominateur. En termes concrets, claude-opus-5 écrit du SQL pour 717 questions dont 21,8 % font partie des 184 plus difficiles, tandis que nova-lite-v1 écrit du SQL pour 285 questions dont 7,7 % le sont. Un routeur faible est noté sur une sélection plus facile. Traitez cette colonne comme un diagnostic par modèle plutôt que comme un classement inter-modèles, et lisez les trois colonnes comme des niveaux. Combler l'écart nécessite une exécution avec route oracle, où chaque modèle écrit du SQL pour les mêmes questions. Cette exécution n'a pas été faite.

Les intervalles de confiance ne couvrent que le bruit d'échantillonnage. Le tableau ci-dessus imprime des estimations ponctuelles, et les intervalles de Wilson pour les colonnes strict et gold nettoyé figurent dans le CSV publié à côté de chaque ligne. Les intervalles portent le bruit d'échantillonnage des questions et ni l'incertitude des jurys ni celle des signalements de golds. Deux exécutions du panel répétées dans des conditions identiques ont déplacé la précision de routage de 1,6 à 2,7 points, et cette page ne rapporte aucune mesure répétée pour les colonnes SQL.

Ces chiffres sont sans indice par construction, ils ne sont donc pas comparables aux scores du classement BIRD pour les mêmes modèles.

Conclusion

La correspondance stricte d'exécution par rapport aux requêtes gold de BIRD s'étend de 0 190 à 0 551 sur les 36 modèles, et ce même panel s'étend de 0 316 à 0 824 une fois qu'un jury aveugle a relu chaque échec. La distance entre ces deux lectures est le constat. Pour claude-sonnet-5, elle est de 39,9 points, dont 22,7 proviennent de réponses qui renvoient la bonne information dans une forme que le comparateur rejette.

Pour une charge de travail notée par correspondance stricte d'exécution, gemini-3-flash-preview a enregistré 0 551 brut et 0 677 gold nettoyé à 7,67 $ par exécution. Pour une charge de travail où une réponse équivalente dans une projection différente est acceptable, claude-opus-5 a enregistré 0 824 en arbitré contre les 0 785 de gpt-5.6-sol, à l'intérieur d'un intervalle de confiance. Pour toute comparaison par modèle, le dénominateur diffère selon le modèle, de sorte que les trois colonnes sont des diagnostics plutôt qu'un classement contrôlé.

Le plafond sur cet axe est le gold, pas les modèles. Un tiers des requêtes gold de BIRD échouent à notre audit, les défauts se concentrent dans la partition d'entraînement où aucune correction publiée ne parvient, et les deux instruments qui voient au-delà sont tous deux des jurys LLM plutôt que des annotateurs humains. Faire avancer l'axe nécessite une exécution avec route oracle pour que chaque modèle écrive du SQL pour les mêmes questions, et une double annotation humaine indépendante d'un échantillon stratifié de golds. Ni l'un ni l'autre n'a été fait.

Ne manquez pas nos benchmarks et analyses basées sur les données. Le bouton ouvre Google ; sélectionner AIMultiple confirme que vous souhaitez voir AIMultiple plus souvent dans les résultats de recherche Google.
GoogleAjouter comme source préférée

Pour aller plus loin

FAQ

Parce que les requêtes gold sont celles de BIRD et qu'un tiers d'entre elles échouent à notre audit. La correspondance stricte d'exécution est le plancher, la colonne gold nettoyé retire les questions dont le gold a été jugé défectueux par nos soins, et la colonne arbitrÉe crédite les réponses qu'un jury aveugle a jugées équivalentes. claude-sonnet-5 passe de 0 311 à 0 710 sur ce bracket, de sorte qu'un seul chiffre déformerait le panel jusqu'à 39,9 points.

Non. BIRD fournit un indice de domaine avec chaque question et fournit la base de données. Ce benchmark retient l'indice et oblige le modèle à choisir la base de données parmi 11. L'indice seul vaut de 6 à 9 points de correspondance d'exécution.

Pas sur ce panel. Chaque modèle écrit du SQL pour les questions qu'il a routées correctement, de sorte qu'un meilleur routeur obtient un dénominateur plus difficile, avec une corrélation de 0,96 entre la précision de routage et la difficulté du dénominateur. kimi-k3 route 0 832 et écrit 0 482 en gold nettoyé, tandis que gemini-3-flash-preview route 0 753 et écrit le meilleur score du panel à 0 677.

Une requête gold qui ne répond pas à sa propre question, telle qu'évaluée par cinq modèles frontières de cinq familles différentes, sans qu'aucun d'eux n'ait vu de réponse candidate. Le panel a signalé 236 des 759, et un panel antérieur de trois modèles en avait indépendamment signalé 221, dont 207 se chevauchent.

Citez ce benchmark

Choisissez le format qui correspond à votre lieu de publication. Coller la version avec lien dans votre CMS préserve le lien retour.

Ekrem Sarı (2026) - "Text-to-SQL: Comparaison de la précision des LLM". Publié en ligne sur AIMultiple.com. Consulté le 7 Août 2026, à : https://aimultiple.com/text-to-sql [Ressource en ligne]

Sarı, E. (2026, 7 Août). Text-to-SQL: Comparaison de la précision des LLM. AIMultiple. https://aimultiple.com/text-to-sql

@misc{sari2026,
  author = {Sarı, Ekrem},
  title  = {{Text-to-SQL: Comparaison de la précision des LLM}},
  year   = {2026},
  month  = aug,
  howpublished    = {\url{https://aimultiple.com/text-to-sql}},
  note   = {AIMultiple. Consulté le 7 Août 2026}
}

Liens de référence

1.
BIRD-bench
Ekrem Sarı
Ekrem Sarı
Chercheur en IA
Ekrem est chercheur en IA et analyste de données chez AIMultiple. Il conçoit et exécute des benchmarks pratiques pour les systèmes d'IA et de LLM.
Voir le profil complet

Commentaires 1

Partagez vos idées

Votre adresse courriel ne sera pas publiée. Tous les champs sont obligatoires. Les commentaires sont laissés dans leur langue d'origine.

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.