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

Nous avons exécuté 36 large language models sur 759 questions de BIRD-SQL, chaque model écrivant SQL contre une base de données qu’il devait identifier lui-même parmi 11 candidates. Toute requête analysable a été exécutée sur la base de données réelle et son ensemble de résultats comparé à l’ensemble de résultats de la requête de référence de BIRD. Les requêtes manquantes, mal formées ou en échec d’exécution ont été comptées comme des échecs.

Chaque exécution a été réalisée à température 0, en zero-shot, avec l’indice de domaine de BIRD masqué. Dix-neuf des 36 exécutions ont utilisé la couche de récupération d’appels d’outils décrite sur la page de routage, qui analyse les appels d’outils que le parseur standard rejette. Quinze exécutions sont antérieures à cette couche et deux chevauchent le changement.

Métriques expliquées :

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

Gold-clean : La même mesure avec les questions dont le gold SQL que nous avons jugé cassé retiré du dénominateur. Ces questions ne sont pas comptées comme des réussites, elles sont supprimées.

Adjudiqué : La borne supérieure. Un jury aveugle de trois models, issu de familles autres que celle du model testé, examine chaque réponse rejetée par la comparaison stricte, lorsque le model a routé correctement, que le SQL s’exécute, et que ses lignes chevauchent celles de la référence de moins de la moitié. Il décide si la requête est une formulation différente mais équivalente, si la référence est erronée, ou si le model a tort. Les réponses équivalentes et les références cassées sont créditées.

Les trois partent de l’ensemble complet des 759 questions plutôt que du sous-ensemble difficile, et aucune n’utilise 759 comme dénominateur. Chacune est mesurée sur les questions que le model a routées correctement, et la colonne gold-clean retire ensuite les références signalées. Le hasard ne s’applique pas à cet axe, car une requête soit renvoie l’ensemble de résultats de référence, soit ne le renvoie pas.

Résultats du benchmark Text-to-SQL

Les bonnes réponses dans la mauvaise forme coûtent 22.7 points à un model

claude-sonnet-5 enregistre 0.311 en correspondance d’exécution stricte, 33rd sur les 36 models et le plus bas de toutes les lignes Anthropic. En adjudication à l’aveugle, la même exécution obtient 0.710, soit 0.007 de moins que les 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 lues comme équivalentes à la référence dans une forme différente. 117 autres, soit 17.2 points, sont des questions où le jury a jugé la référence elle-même cassée. Le style de réponse explique la première de ces deux parts, pas la somme. Aucune défaillance du harnais n’en rend compte, car l’exécution n’a enregistré aucune requête manquante, un seul crash et aucune réponse non récupérée.

Ces mêmes 154 réponses représentent 34 % des 453 échecs de sonnet-5 parvenus à l’adjudication. L’équivalence de 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ù la référence renvoyait les lignes. La correspondance d’exécution stricte note cela comme un échec.

La tendance varie selon la famille de models plutôt que selon le niveau de capacité. Les familles à projection riche perdent ainsi entre un quart et un tiers de leurs échecs adjudiqués, à Claude de 25 à 34 %, Kimi de 24 à 34 %, la lignée de raisonnement 5.x d’OpenAI de 26 à 32 %, DeepSeek 31 %, MiniMax de 26 à 30 % et GLM-5.x 28 %. Les rédacteurs conformes à la référence en perdent bien moins, à Google de 9 à 17 %, Llama 9 %, Mistral 18 %, Grok 19 % et les petits models d’OpenAI de 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 adjudiquée place sonnet-5 17, soit un écart de 16 positions.

Le jury constate que 46 % des réponses rejetées d’un model ne sont pas des erreurs du model

Nous avons pris 314 des 346 réponses que la comparaison stricte a rejetées pour gemini-3.5-flash-lite sur des questions qu’il a routées correctement, celles dont le SQL s’exécutait et dont les lignes chevauchaient celles de la référence de moins de la moitié, et les avons envoyées au jury aveugle de trois models, avec permutation des positions. Ces 346 réponses couvrent chaque niveau de difficulté plutôt que les seules difficiles, de sorte qu’elles correspondent à la population couverte par les colonnes SQL.

Le jury les a réparties en quatre catégories. Les défauts de référence, où le model a raison et la requête de référence de BIRD a tort, ont représenté 29.3 %. Les équivalences de format ont représenté 16.6 %, les véritables erreurs de model 33.4 %, et les cas ambigus 20.7 %. En additionnant les deux premières catégories, 144 des 314 échecs adjudiqués (46 %) ne sont pas des erreurs de model. Cette part porte sur les 314 réponses parvenues au jury, et non sur la totalité des 346 réponses rejetées. Les 32 réponses écartées soit n’ont pas pu s’exécuter, soit chevauchaient trop étroitement la référence pour constituer un désaccord net.

La sévérité du comparateur n’explique pas l’écart. Assouplir la correspondance de l’ordre des colonnes ne rapporte que 0.5 point, et 92 % des échecs chevauchent le résultat de référence à moins de 0.5. L’adjudication, plutôt qu’un comparateur plus souple, place ce model dans une fourchette de 0.606 à 0.687, contre 0.464 en strict.

Les échecs que le jury a qualifiés de défauts de référence se concentrent là où aucune correction publiée ne parvient, avec 33 % des échecs de la partition train de ce model contre 20 % de ses échecs de la partition dev. Toute correction déterministe à notre disposition était déjà épuisée. Une nouvelle notation avec la version dev corrigée de BIRD a retourné 0 échec sur les 92 échecs dev, un jeu de corrections externe en couvrait 39 et en a retourné 1, et un audit du moteur MySQL par rapport à SQLite a trouvé 4 références divergentes sur l’ensemble, soit environ 1 % des 314.

Notre audit à cinq models signale 31.1 % des requêtes de référence de BIRD comme cassées

Nous avons audité la référence elle-même. Cinq models frontières, un par famille, ont noté l’ensemble des 759 requêtes de référence par rapport à leurs questions et schémas. Aucun juré n’a jamais vu la sortie d’un model. Le panel a signalé 236 des 759 références comme cassées, soit 31.1 %, pour un coût de $20,55 et sans aucun échec d’appel du jury.

Le taux se répartit selon la partition BIRD, avec 204 des 560 références train (36 %) contre 32 des 199 références dev (16 %). Un panel indépendant de trois models exécuté plus tôt avait atteint 29.1 %, et 207 de ses 221 signalements de références cassées, soit 94 %, sont également cassées dans celui-ci. Sur l’ensemble des 759 questions, les deux panels s’accordent sur 92.9 %.

Une estimation publiée couvre la partition train de BIRD, l’audit de MotherDuck de 151 exemples, et fixe le taux à 32.5 %. Les audits de BIRD revus par les pairs couvrent la partition dev de manière explicite, de sorte que les 151 exemples de MotherDuck constituent le seul contrôle externe sur les 560 questions train de notre ensemble figé, soit 73.8 % de celui-ci.¹

Supprimer les références cassées du dénominateur fait passer le meilleur rédacteur strict de 0.551 à 0.677, et les gains par model s’étendent de +4.5 à +13.3 points. Le premier rang conserve son ordre et les voisins du milieu de tableau se déplacent d’au plus trois positions.

Un model 27B se classe cinquième en précision SQL stricte

qwen3.6-27b enregistre 0.471 en strict et 0.590 en gold-clean, 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 de chaque model, 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 dès que l’on utilise la borne supérieure de la fourchette. Sur les scores adjudiqués, qwen3.6-27b est quatorzième à 0.717, tandis que claude-opus-5 mène avec 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 à égalité avec qwen3.8-max, et écrit du SQL gold-clean à 0.482 contre un meilleur panel de 0.677. gemini-3-flash-preview inverse la relation, routant 0.753 avec ce meilleur SQL gold-clean du panel. gpt-5.6-terra route à 0.772 et écrit 0.447.

Les deux axes ne sont pas mesurés sur un même dénominateur. Chaque model é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 vers le bas toute association mesurée entre les axes.

L’audit de la référence et le jury d’adjudication

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

Le jury de validité de la référence note les requêtes de référence. 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, la SQL de référence et les listes de colonnes des tables touchées par cette requête, et répondent si la référence répond à la question. Aucune sortie de model n’est jamais montrée. Ses verdicts sont figés dans un fichier hash-pinned et alimentent la colonne gold-clean.

Le jury d’adjudication note l’échec d’un model particulier. Trois models issus de familles autres que celle du model testé voient la question, la requête et le résultat de référence, ainsi que la requête et le résultat candidats, avec permutation des positions, et votent pour l’une des quatre catégories auxquelles l’échec appartient. Il coûte environ 6 $ par model, et ses verdicts alimentent la colonne adjudiquée. L’adjudication sur l’ensemble du panel de 36 models a coûté $208.81.

La colonne adjudiquée est un point final optimiste ajusté par adjudication plutôt qu’une vérité terrain indépendante. Elle peut se tromper dans les deux sens. Une réponse ambiguë qui était en réalité correcte n’est pas créditée, et un faux positif du jury en crédite une qui ne l’était pas. Trois propriétés mesurées limitent l’étendue de cette colonne.

L’examen est asymétrique. Les échecs font l’objet d’un second regard, mais jamais les réussites, de sorte qu’une erreur dans le sens de la réussite ne peut pas être détectée. Les verdicts ambigus, de 15 à 23 % selon le model, ne sont jamais crédités, et les quasi-échecs et les requêtes non exécutées restent des échecs.

Elle n’efface pas le plancher des models faibles. En tant que contrôle négatif, nous avons adjudiqué 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 se maintient à llama 0.466, mistral 0.509 et gpt-5.4-nano 0.512.

La part des défauts de référence suit la force du model avec une corrélation de rang de 0.906, mesurée sur 33 models. Les échecs de gpt-5.6-sol sont à 40 % des défauts de référence et à 19 % de véritables erreurs, tandis que ceux de llama-4-maverick sont à 13 % et 50 %.

Vingt-quatre des 36 models se situent à 0.68 ou plus en adjudiqué.

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

Le model ne reçoit jamais de schéma à l’avance. Il choisit un des 11 outils de base de données, lit la liste des tables 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 retenue avant de s’engager. La sortie du schéma est plafonnée à 4 000 caractères et les résultats de requête à 50 lignes.

La requête finale arrive lors d’un appel de finalisation obligatoire envoyé sans outil attaché, accompagnée de la base de données que le model déclare. La notation exécute cette requête et la requête de référence 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 précisent un ordre.

La comparaison est l’étape stricte, et c’est là qu’une bonne réponse 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ù la référence renvoyait les lignes, échoue à la comparaison. C’est cet écart que mesure le jury d’adjudication, plutôt que celui que comblerait un comparateur plus souple, qui ne rapporte que 0.5 point.

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

Ce benchmark partage son harnais avec le benchmark RAG agentique, qui décrit en détail la sélection des bases de données, la taxonomie de difficulté, l’anonymisation, la boucle agentique et le budget de tours. Les deux pages présentent le même sous-ensemble figé BIRD-SQL de 759 questions, exécuté sur 11 bases de données parmi lesquelles le model doit choisir, à température 0 avec l’indice de domaine masqué. 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 model et la requête de référence de BIRD sont toutes deux exécutées sur la base de données réelle et leurs ensembles de résultats sont comparés, avec une sentinelle NULL et un mode sensible à l’ordre pour les requêtes dont la question précise un ordre. Dénominateur : les questions routées correctement par le model. Forme rapportée : une fourchette à trois valeurs, correspondance d’exécution stricte, puis gold-clean, puis adjudiqué. Audit de la référence : 5 familles frontières, un model chacune, 759 références notées, 236 signalées cassées, hash-pinned. Adjudication : 3 models par candidat, famille disjointe du model testé, aveugle et avec permutation des positions. Panel : 36 models, une seule exécution chacun, $874,53 pour les exécutions et $208,81 pour l’adjudication.

Pourquoi aucun juge LLM ne juge la correction 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 fait échouer une requête que l’exécution avait réussie, à aucun seuil. Ce juge voyait les deux ensembles de résultats, de sorte que son verdict n’est pas indépendant du résultat de l’exécution, et le zéro n’établit pas qu’un juge ne puisse pas être plus strict. L’exécution reste le plancher et le jury apparaît plus haut dans la fourchette, là où sa clémence est précisément recherchée.

Pourquoi l’indice est masqué. 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 gratuit, et les chiffres SQL présentés ici se situent en dessous de ce que les mêmes models obtiendraient dans les conditions standard de BIRD.

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

Classée selon la colonne adjudiquée. Six lignes ont manqué de 759 enregistrements après deux passes de nouvelle tentative, et les questions manquantes sont absentes de chaque dénominateur plutôt que comptées comme des échecs.

Limites de l’axe SQL

La référence est empruntée et contestée. Notre chiffre de 31.1 % de références cassées provient de notre propre sous-ensemble audité, et non d’une vérité terrain multi-annotateurs. Il n’y a pas de passe dupliquée 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 touchées par la requête de référence, de sorte qu’une référence interrogeant la mauvaise table est indétectable depuis cette vue et ces défauts sont manqués. Le panel peut également signaler une référence valide, une erreur dans l’autre sens. Aucun annotateur indépendant n’a répété la passe, de sorte que l’erreur résiduelle n’est mesurée dans aucun des deux sens et le chiffre n’est pas un plancher.

La colonne adjudiquée est un instrument LLM, pas une seconde vérité terrain, ni une borne supérieure stricte. Ses trois jurés sont des models, de sorte que la colonne hérite de tout ce qu’un panel de models se trompe au sujet de l’équivalence SQL, et aucun humain n’a relu les verdicts.

Le comparateur se trompe dans les deux sens. L’ordre des colonnes et le nombre de colonnes provoquent des faux négatifs, tandis que l’insensibilité à la casse et l’arrondi des flottants à six chiffres significatifs provoquent des faux positifs. L’erreur du comparateur et l’erreur de la requête de référence sont des sources d’incertitude distinctes et peuvent faire évoluer un score dans des directions différentes.

La correspondance d’exécution stricte est mesurée sur les questions correctement routées par chaque model, et les meilleurs routeurs obtiennent un ensemble plus difficile. La précision de routage suit la difficulté des questions qui parviennent au dénominateur SQL d’un model. Sur les 36 models, cette corrélation est de 0.96 (Pearson, sur le nombre moyen de voisins entre bases de données), et de 0.97 contre la part des questions les plus difficiles dans ce dénominateur. Concrètement, claude-opus-5 écrit du SQL pour 717 questions, dont 21.8 % figurent parmi les 184 plus difficiles, tandis que nova-lite-v1 écrit du SQL pour 285 questions, dont 7.7 %. Un routeur faible est noté sur une sélection plus facile. Considérez cette colonne comme un diagnostic par model plutôt qu’un classement entre models, et lisez les trois colonnes comme des niveaux. Combler l’écart nécessite une exécution oracle-route, où chaque model écrit du SQL pour les mêmes questions. Cette exécution n’a pas été réalisée.

Les intervalles de confiance ne couvrent que le bruit d’échantillonnage. Le tableau ci-dessus présente des estimations ponctuelles, et des intervalles de Wilson pour les colonnes strict et gold-clean figurent dans le CSV publié à côté de chaque ligne. Les intervalles portent le bruit d’échantillonnage des questions et non l’incertitude des jurys ni celle des signalements de référence. 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 « hint-free » par construction, de sorte qu’ils ne sont pas comparables aux scores du classement BIRD pour les mêmes models.

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.

Ajouter comme source préférée

Pour aller plus loin

• Benchmark RAG agentique : routage multi-bases de données sur 36 LLMs
• 200+ principaux benchmarks d’IA
• HALC-Bench : Hallucination de LLM sur le benchmark de récupération à long contexte
• +100 Datasets pour le ML & des models d’IA
• Meilleurs RAG outils, frameworks et bibliothèques

FAQ

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.

@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}
}

Journal des modifications

8 mises à jour

Toutes8Général4Méthodologie4

1. 202625 Fév

   Ajout d'un journal des modifications à la section "Agentic RAG benchmark: multi-database routing and query generation".

2. 25 Fév

   Remplacé la section méthodologie par un résumé et une référence à un autre article.

3. 202529 Déc

   Mise à jour du nombre de grands modèles linguistiques dans l'introduction.

4. 29 Déc

   Mise à jour de la section Dataset et vérité terrain avec le niveau de difficulté du dataset BIRD-SQL.

5. 27 Août

   Remplacement de l'exemple de filtre manquant dans la section « Filtres manquants ou incorrects ».

6. 22 Août

   Ajout d'une section, « Comment les LLM génèrent du SQL : un aperçu étape par étape », à l'article.

7. 22 Août

   La section méthodologie a été remplacée par un cadre de génération augmentée par récupération (RAG) agentique.

8. 2 Juil

   La section « Méthodologie de référence pour le texte vers SQL » a été déplacée.

Liens de référence

1.

BIRD-bench

Ekrem Sarı

Chercheur en IA

Suivre

Ekrem est chercheur en IA et scientifique des 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.

Nom

Adresse email

Commentaire

0/450

Publier un commentaire

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 .

Répondre

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.

Répondre