AIM-Text-to-SQL Benchmark: précision SQL sur plus de 70 LLMs
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.
La précision SQL est le pourcentage de requêtes évaluées qui renvoient le résultat de référence. Les routages incorrects et les références signalées comme défectueuses sont exclus. Une requête de référence est le SQL fourni comme réponse attendue.
Chaque modèle atteint un ensemble différent de questions SQL, car la notation dépend de ses choix de base de données. Les différences entre ces sous-ensembles et la configuration d’exécution limitent les comparaisons.
Résultats Text-to-SQL
Opus 5.5 a enregistré 87,8 % de précision SQL
claude-opus-5.5 a obtenu le résultat de référence sur 444 des 506 questions évaluées. gemini-4-argon a suivi avec 78,6 % (407 sur 518), puis gemini-3.8-flash avec 77,2 % (342 sur 443). Il s’agissait des trois meilleurs scores de précision SQL du panel de 76 modèles. Muse Wonder a enregistré 56,4 % (285 sur 505).
Le score exclut les choix de base de données incorrects et les références signalées comme défectueuses. Opus 5.5 a utilisé Claude Code. Gemini 4 Argon et Gemini 3.8 Flash ont utilisé OpenRouter. Le classement reflète à la fois les conditions d’exécution et les différences entre les questions correctement routées par chaque modèle.
Trois variantes Pro ont obtenu des scores inférieurs à leurs modèles de base
gpt-6.1-sol-pro a enregistré 63,6 % de précision SQL, contre 65,1 % pour gpt-6.1-sol. gpt-6-sol-pro a obtenu 53,6 % contre 53,8 % pour gpt-6-sol. gpt-6-luna-pro a obtenu 44,2 % contre 45,4 % pour gpt-6-luna.
Les six modèles ont utilisé OpenRouter. Ces scores proviennent d’une seule exécution par modèle et de sous-ensembles différents de questions correctement routées. Des exécutions répétées sur les mêmes questions SQL seraient nécessaires pour évaluer si les petits écarts persistent.
Coût par rapport à la précision SQL
Le coût d’exécution couvre les réponses de routage et SQL conservées issues de l’exécution du benchmark de chaque modèle. La cible était de 759 questions. Sept exécutions comportent moins de réponses conservées. Les tests préliminaires séparés, les tentatives de réessai abandonnées et les appels au jury sont exclus. La précision SQL utilise les questions correctement routées de chaque modèle après exclusion des références signalées comme défectueuses.
gemini-3-flash-preview a enregistré 67,7 % de précision SQL pour un coût de 7.67 $ par exécution. gemini-3.8-flash a atteint 77,2 % pour 26.48 $. Opus 5.5 a un score de 87,8 % associé à un coût estimé équivalent API de 188.71 $. Gemini 4 Argon a atteint 78,6 % pour 41.41 $ en coûts d’exécution conservés. Muse Wonder a atteint 56,4 % pour 77.44 $ en coûts d’exécution conservés.
Les 73 modèles API utilisent des coûts mesurés. Opus 5.5, Fable 5.1 et GPT-6 Astra disposent d’estimations étiquetées séparément, fondées sur leurs tokens CLI enregistrés et les prix OpenRouter vérifiés le 1er octobre 2026, avec l’utilisation du cache enregistrée préservée.
Les coûts incluent l’exploration de la base de données, et les scores SQL couvrent différents sous-ensembles de questions. Cette comparaison décrit donc le coût et la précision du flux de travail combiné du benchmark. Les coûts isolés de génération SQL n’ont pas été mesurés. Le benchmark agentique RAG rapporte la sélection de la base de données séparément.
Résultats de précision SQL
Avant l’examen des références, la correspondance exacte des résultats est mesurée sur toutes les questions correctement routées. Après l’examen des réponses, un crédit est ajouté pour les réponses acceptées par le jury. Les deux colonnes de comparaison utilisent le dénominateur d’origine, tandis que la précision SQL exclut les références signalées.
Conditions affectant la précision SQL
Les indices de BIRD ont augmenté la précision de Gemini Flash en SQL de 8.7 points
Nous avons répété gemini-3-flash-preview avec les preuves supplémentaires de BIRD. Sur les questions correctement routées dans les deux conditions, la précision SQL est passée de 67,5 % à 76,2 %. La précision stricte, avant l’examen des références, est passée de 55,0 % à 61,6 %.
Il s’agissait d’une expérience sur un seul modèle. Elle ne permet pas d’établir un gain commun pour le panel de 74 modèles. Le panel principal ne fournit pas les indices, car ils peuvent aussi révéler quelle base de données sélectionner.
Les modèles ont atteint différents ensembles de questions SQL
Les choix de base de données de chaque modèle déterminent quelles questions parviennent à la notation SQL. Pour claude-opus-5, le dénominateur strict contient 717 questions, dont 156 du groupe de routage le plus difficile. Pour nova-lite-v1, il contient 285 questions, dont 22 de ce groupe. Les parts sont de 21,8 % et de 7,7 %.
Leurs pourcentages SQL combinent donc la performance de rédaction des requêtes avec la difficulté des cas qui sont parvenus à la notation. Une comparaison SQL contrôlée fournirait à chaque modèle la base de données correcte pour les mêmes questions. Cette expérience n’a pas été réalisée.
La sélection des questions importe également lors de la comparaison de benchmarks d’IA qui fournissent des schémas, des indices ou des budgets d’outils différents.
Résultats de l’examen des références et des réponses
L’audit des références a signalé 236 des 759 requêtes
Cinq modèles ont évalué chaque requête de référence par rapport à sa question et aux informations de schéma disponibles. Ils n’avaient vu aucune réponse candidate. Une majorité d’au moins trois modèles a signalé 236 références comme défectueuses, soit 31,1 % de l’ensemble.
Après l’audit, le propriétaire du benchmark a examiné les signalements. Des annotateurs humains indépendants n’ont pas répété cet examen. Ces pourcentages décrivent le sous-ensemble audité. Ils ne doivent pas être généralisés à l’ensemble de BIRD.
Des réponses équivalentes ont ajouté 22.7 points au score de claude-sonnet-5
claude-sonnet-5 a réussi 211 des 679 questions strictement évaluées, soit 31,1 %. Un jury a accepté 154 autres réponses comme équivalentes à la référence. Celles-ci ont apporté 22.7 points de pourcentage.
Encore 117 réponses ont reçu un crédit parce que le jury a accepté la requête du modèle et rejeté la référence. Celles-ci ont apporté 17.2 points. Ensemble, les deux catégories ont fait passer le score à 71,0 %, soit une augmentation de 39.9 points.
Les réponses équivalentes peuvent renvoyer les informations demandées avec une colonne supplémentaire ou une projection différente. La comparaison stricte peut rejeter ce résultat même lorsqu’un examinateur l’accepte comme réponse à la question. Sur l’augmentation, 22.7 points proviennent des décisions du jury concernant ces cas. Les défauts de référence représentent les 17.2 points restants.
Méthodologie du benchmark Text-to-SQL
Questions and execution
BIRD-SQL fournit des questions en langage naturel, des références SQL et le contenu des bases de données.1 Nous avons utilisé une sélection figée de 759 questions issues de 11 bases de données, couvrant 560 exemples d’entraînement et 199 exemples de développement.
Les modèles ont reçu de courtes descriptions de bases de données et des outils pour lister les tables, lire les définitions de colonnes et exécuter du SQL. Chaque question autorisait jusqu’à neuf appels avec des outils et une réponse finale contenant la base de données choisie et le SQL. La limite d’aperçu du schéma était de 4 000 caractères, et les aperçus de requêtes étaient plafonnés à 50 lignes.
La requête candidate finale et la référence ont été exécutées sur le même fichier de base de données. La notation stricte a comparé leurs résultats, y compris un mode sensible à l’ordre pour les questions demandant une réponse ordonnée. Les requêtes candidates manquantes, mal formées ou ayant échoué à l’exécution n’ont reçu aucun crédit strict pour les questions par ailleurs éligibles et correctement routées.
Pour les 46 exécutions OpenRouter, nous avons demandé une température de 0. Vingt-neuf ont utilisé la couche de reprise d’appels d’outils v3, 15 l’ont précédée, et deux ont combiné des enregistrements des deux versions. GPT-6 Astra a été exécuté via Codex CLI. Opus 5.5 et Fable 5.1 ont utilisé Claude Code. Les trois exécutions CLI ont utilisé un effort de raisonnement moyen. Les exécutions de GPT-6 Luna, Luna Pro, Sol et Sol Pro et de GPT-5.2 ont utilisé OpenRouter. Ces différences d’exécution empêchent d’attribuer un écart de score au seul modèle.
Sept exécutions ont traité moins de 759 questions. Les enregistrements manquants sont absents des dénominateurs de notation. Le tableau indique les tailles d’échantillon réelles pour les scores principal et supplémentaires. Les dix ajouts API ont chacun traité l’ensemble des 759 questions après de nouvelles tentatives pour les requêtes ayant échoué, en préservant les réponses antérieures réussies.
Notation SQL
Le score principal exclut les questions signalées à la fois de son numérateur et de son dénominateur. Trois références marquées comme incertaines restent dans le calcul. Les fichiers de résultats appellent cette métrique ex_gold_clean.
Deux scores supplémentaires montrent comment l’examen modifie le résultat :
Avant l’examen des références, le score strict mesure la correspondance d’exécution exacte sur toutes les questions correctement routées. Il inclut les questions avec des références signalées.
Après l’examen des réponses, le score ajoute un crédit lorsqu’un jury distinct accepte une réponse manquante éligible. Il utilise le même dénominateur que le score strict. Les fichiers de résultats appellent cette précision adjudiquée.
La taille de l’échantillon (n) est le nombre de questions évaluées. Le score principal utilise un sous-ensemble plus petit que les deux scores supplémentaires.
Pour claude-sonnet-5, l’exclusion des références signalées a réduit les réponses acceptées de 211 à 180 et les questions évaluées de 679 à 468. Sa précision SQL était de 38,5 %.
L’exclusion modifie les deux comptages. L’examen des réponses conserve en revanche le dénominateur d’origine et ajoute un crédit pour les réponses manquantes acceptées.
Examen des références et des réponses
L’audit des références et l’examen des réponses candidates nécessitent des entrées différentes.
Les auditeurs des références étaient claude-opus-4.8, gpt-5.6-sol, gemini-3.1-pro-preview, grok-4.5 et deepseek-v4-pro. Les réponses candidates ont été masquées afin que les signalements restent indépendants du modèle évalué.
L’adjudication des réponses a utilisé trois jurés issus de familles de modèles différentes de celle du candidat. Les requêtes de référence et candidates sont apparues dans des positions A/B aléatoires, sans étiquette révélant leur rôle. Les cas ambigus et les cas dont les votes valides étaient insuffisants n’ont reçu aucun crédit supplémentaire.
La couverture de l’examen est asymétrique. Les réussites strictes restent acceptées, tandis que les échecs éligibles reçoivent une autre évaluation. Par conséquent, l’adjudication peut conserver des faux positifs de la notation stricte et ajouter ses propres faux positifs. Il s’agit d’une estimation supplémentaire, sans exactitude garantie ni borne supérieure garantie pour la précision réelle.
Un échec était admissible à l’adjudication lorsque la requête candidate s’exécutait et que le chevauchement F1 entre ses lignes de résultat et la référence était inférieur à 0.5. Le F1 combine la proportion de lignes candidates trouvées dans la référence avec la proportion de lignes de référence récupérées par la candidate.
Par exemple, gemini-3.5-flash-lite a connu 346 échecs stricts. Parmi eux, 314 étaient admissibles à l’examen. Le jury a accepté la candidate dans 144 cas : 92 avec une référence rejetée et 52 avec les deux réponses acceptées. Il a classé 105 comme erreurs du modèle et laissé 65 cas ambigus. Les 32 autres échecs comprenaient 27 cas avec un chevauchement de résultats plus élevé et cinq échecs d’exécution.
Les 144 cas acceptés représentent 45,9 % des échecs examinés, et non de toutes les réponses échouées.
Ajouter comme source préféréeLimites
Les erreurs de référence restent incertaines. L’audit à cinq modèles a inspecté les colonnes des tables utilisées par chaque requête de référence, de sorte qu’il peut manquer une réponse située dans une autre table. L’audit peut aussi rejeter une référence valide. Un nouvel examen par des annotateurs humains indépendants est nécessaire pour estimer les deux types d’erreur.
Les jugements du jury dépendent de l’interprétation des LLM. Aucune revue humaine indépendante n’a vérifié tous les verdicts d’adjudication. Dans le contrôle nova-lite-v1, la précision est passée de 18,9 % en notation stricte à 31,6 % après adjudication, ce qui montre que l’examen n’a pas automatiquement produit un score élevé. Ce contrôle seul ne permet pas d’établir l’exactitude du jury.
La comparaison stricte peut échouer dans les deux sens. Des colonnes supplémentaires ou un ordre différent des colonnes peuvent rejeter une réponse utile. La normalisation de la casse et l’arrondi des valeurs à virgule flottante à six chiffres significatifs peuvent accepter des différences importantes.
Des intervalles d’échantillonnage des questions sont disponibles pour les scores stricts et la précision SQL dans l’export des résultats. Ils omettent l’incertitude des étiquettes de référence, l’erreur du jury et la variation entre des exécutions SQL répétées. Aucune analyse répétée SQL n’est rapportée ici.
Il s’agit de résultats pour une charge de travail sélectionnée, sans gratuit d’indices, avec une exigence de routage de base de données. Ils ne sont pas directement comparables au classement BIRD. Les données d’entraînement publiques laissent également un risque de chevauchement des données d’entraînement, comme indiqué dans l’article sur le routage.
Conclusion
claude-opus-5.5 a été en tête de la précision SQL avec 87,8 %, suivi de gemini-4-argon avec 78,6 % et de gemini-3.8-flash avec 77,2 %.
Chaque score SQL reflète les questions que ce modèle a correctement routées et les références conservées après examen. Une comparaison SQL contrôlée donnerait à chaque modèle les mêmes questions et les mêmes informations de base de données, avec des vérifications indépendantes des étiquettes de référence et des décisions du jury.
Pour aller plus loin
- Benchmark agentique RAG : routage multi-bases de données
- 800+ principaux benchmarks d’IA
- HALC-Bench : LLM hallucination sur le benchmark de récupération à long contexte
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 = {{AIM-Text-to-SQL Benchmark: précision SQL sur plus de 70 LLMs}},
year = {2026},
month = oct,
howpublished = {\url{https://aimultiple.com/text-to-sql}},
note = {AIMultiple. Consulté le 1 octobre 2026}
}Résultats et horodatages de 1.4 mille points de données. Téléchargez les données de synthèse présentées dans les graphiques et les tableaux de cet article sous forme de fichier ZIP contenant 4 fichiers CSV et un README.
Vous voulez les données détaillées derrière ? Rejoindre Premium
Journal des modifications
9 mises à jourRésultats du benchmark texte-vers-SQL remplacés par un panel de 36 modèles noté selon la correspondance d'exécution strict, gold-clean et adjudicated.
Ajout d'un journal des modifications à la section "Agentic RAG benchmark: multi-database routing and query generation".
Remplacé la section méthodologie par un résumé et une référence à un autre article.
Liens de référence
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.
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.