Text-to-SQL: Comparaison de la précision des LLM
J'utilise SQL pour l'analyse de données depuis 18 ans, depuis mes débuts en tant que consultant. Traduire des questions en langage naturel en SQL rend les données plus accessibles, permettant à n'importe qui, même sans compétences techniques, de travailler directement avec les bases de données.
Nous avons appliqué notre méthodologie de benchmark text-to-SQL à 34 grands modèles de langage (LLMs) afin d'évaluer leurs performances dans la génération de commandes SQL :
Erreurs fréquentes dans les requêtes LLM générées en SQL
Les LLMs commettent souvent quatre types d'erreurs : jointures incorrectes, erreurs d'agrégation, filtres manquants et erreurs de syntaxe.
Logique de jointure incorrecte
Les modèles ont souvent du mal à identifier et à implémenter correctement les opérations `JOIN` nécessaires entre les tables, les omettant parfois entièrement ou utilisant de manière incorrecte des sous-requêtes moins optimales.
Le LLM n'a pas correctement joint les tables `frpm` et `schools` à l'aide de `CDSCode`. Il a également halluciné des noms de colonnes (`Charter`) et des valeurs de filtre (`County = ‘Fresno’`).
Les erreurs dans la logique de jointure compromettent fondamentalement l'aspect relationnel de la requête, entraînant une récupération de données incomplète ou incorrecte lorsque plusieurs tables sont impliquées.
Erreurs d'agrégation et de regroupement
L'application incorrecte de fonctions d'agrégation (comme `MAX`, `AVG`, `COUNT`, `SUM`) ou de clauses `GROUP BY` constituait un autre point d'échec fréquent, produisant des résultats qui ne correspondaient pas sémantiquement à l'intention de l'utilisateur.
Le LLM a correctement identifié que l'expression « score moyen le plus élevé » nécessite de regrouper les données par district (GROUP BY dname) et d'utiliser une fonction d'agrégation (AVG(AvgScrRead)). Cette partie de la logique est correcte.
Cependant, le LLM a échoué à intégrer un filtre critique issu de la question : le mot « actif ». Pour satisfaire cette condition, la requête devait effectuer une jointure entre la table satscores et la table schools, puis filtrer les résultats avec une clause WHERE T1.StatusType = ‘Active’.
Cela illustre un échec courant des LLM : exécuter correctement une instruction principale et évidente (calculer une moyenne) tout en omettant une condition secondaire mais tout aussi importante (filtrer par statut). Cela révèle une faiblesse dans la capacité à synthétiser plusieurs contraintes en une seule requête correcte.
Filtres manquants ou incorrects
Les modèles ont parfois omis d'inclure les clauses `WHERE` nécessaires ou ont sélectionné les mauvaises colonnes dans l'instruction `SELECT`, ne répondant pas pleinement aux contraintes ou aux informations explicitement demandées dans la requête.
Le LLM a correctement identifié la logique pour trouver l'école (`ORDER BY NumGE1500 DESC LIMIT 1`), mais n'a pas sélectionné le numéro de `Phone` demandé et a omis la jointure nécessaire avec la table `schools` pour l'obtenir.
Ces erreurs proviennent souvent d'un parsing incomplet de la demande de l'utilisateur ou d'une incapacité à mapper toutes les parties de la requête aux composants finaux de la requête SQL.
Erreurs de syntaxe
Au-delà des erreurs sémantiques, des erreurs de syntaxe flagrantes se produisent, comme l'utilisation d'alias de table incorrects ou la génération d'instructions SQL incomplètes, empêchant l'exécution de la requête.
Le LLM a utilisé des alias incorrects (`accounts` au lieu de `account`) et inclus un littéral de chaîne incomplet (`’POPLATEK PO OBRATU…’`), ce qui donne une syntaxe SQL invalide.
Ces problèmes de syntaxe mettent en évidence les difficultés à générer du code qui respecte strictement la grammaire SQL et les conventions spécifiques à chaque base de données.
Pourquoi certains LLMs sont meilleurs en SQL
Plusieurs facteurs clés déterminent dans quelle mesure un LLM (LLM) peut transformer une question en anglais courant en une requête de base de données SQL correcte.
1. Taille du modèle et données d'entraînement
- Taille et conception : Les modèles plus volumineux ou conçus avec des structures spécifiques peuvent gérer plus efficacement des tâches complexes, telles que la génération de SQL.
- Ce qu'il a appris : Les données utilisées pour entraîner le LLM sont essentielles. S'il a vu de nombreux exemples de questions associées à des réponses SQL, en particulier ceux impliquant des opérations complexes telles que des jointures ou des calculs (SUM, AVG), il aura probablement de meilleures performances.
2. Ajustement fin pour les tâches SQL
- Les modèles peuvent recevoir un entraînement supplémentaire spécifiquement axé sur les tâches text-to-SQL. Cet « ajustement fin » les aide à mieux comprendre les structures de bases de données et les règles SQL que les modèles entraînés uniquement sur du texte général. L'entraînement sur des instructions spécifiques est également utile.
3. Capacités de raisonnement et de mappage du schéma
- Raisonnement : Dans quelle mesure le LLM peut-il déterminer les étapes exactes nécessaires à partir d'une question parfois vague ? La création de SQL nécessite souvent des étapes logiques.
- Compréhension de la structure de la base de données (schéma) : Certains LLMs sont meilleurs pour relier les concepts de la question (comme « clients » ou « ventes totales ») aux noms réels des tables et des colonnes dans la base de données, même si les noms ne sont pas immédiatement évidents.
Comment les LLMs génèrent-ils du SQL ? Une analyse étape par étape
Pour observer en action des facteurs tels que le « raisonnement » et le « mappage du schéma », examinons le processus étape par étape qu'un modèle suit pour générer une requête. Ce flux de travail entier est alimenté par une technique appelée génération augmentée par récupération (RAG).
Étape 1 : Analyse initiale et sélection de la base de données
Lorsqu'une question est posée, le LLM analyse d'abord l'intention de l'utilisateur afin de sélectionner l'outil de base de données le plus pertinent.
- Question : « Combien de comptes ont une disposition de propriétaire et une demande de génération d'un relevé lors d'une transaction ? »
- Action du LLM : Le modèle identifie des mots-clés comme « comptes », « disposition » et « transaction ». Il conclut que l'outil de base de données
financialest le choix approprié, plutôt que d'autres commecalifornia_schoolsousuperhero.
Étape 2 : Récupération du schéma via RAG
Une fois que le modèle a choisi un outil, il a besoin de la « carte » de la base de données, c'est-à-dire du schéma. Il ne mémorise pas cette information. Au lieu de cela, le système RAG la récupère en temps réel.
- Récupération : La question de l'utilisateur est utilisée pour rechercher dans une base de données vectorielle contenant les informations du schéma. La recherche trouve et récupère les détails de schéma les plus pertinents, tels que les définitions des tables
accountsetdisp. - Augmentation : Ce texte de schéma récupéré est automatiquement inséré dans la requête, accompagné de la question d'origine.
- Génération : Le LLM dispose désormais de tout le contexte nécessaire pour avancer.
Ce processus RAG garantit que le modèle reçoit uniquement les informations de schéma nécessaires, rendant sa tâche plus ciblée et efficace.
Étape 3 : Raisonnement et construction de la requête
Avec la question et le schéma fourni par RAG, le modèle associe les concepts de la demande de l'utilisateur aux noms spécifiques de tables et de colonnes qu'il vient de recevoir.
Monologue interne du LLM :
- Objectif : L'utilisateur veut un décompte, donc je vais commencer par
SELECT COUNT(...). - Conditions :
- « …disposition du propriétaire… » → Le schéma de la table
dispcontient une colonnetype. J'ai besoin d'une clauseWHEREpourtype = 'OWNER'. - « …génération d'un relevé lors d'une transaction… » → Le schéma de la table
accountscontient une colonnefrequency. Le filtre doit êtrefrequency = 'POPLATEK PO OBRATU'.
- « …disposition du propriétaire… » → Le schéma de la table
- Jointures : Les informations sont réparties entre les tables
accountsetdisp. Le schéma indique qu'elles sont liées paraccount_id, donc je dois lesJOIN.
Étape 4 : Génération de la requête SQL finale
Enfin, le modèle assemble ces éléments logiques en une requête SQL syntaxiquement correcte. La qualité de ce résultat dépend de :
- Capacité de raisonnement : La capacité du modèle à relier logiquement la demande de l'utilisateur au schéma fourni.
- Connaissances en SQL issues de l'entraînement : La compréhension fondamentale du modèle concernant la syntaxe et les fonctions SQL.
Ce processus explique pourquoi des erreurs se produisent. Si le schéma récupéré est ambigu ou si un terme de la question ne correspond pas clairement, le LLM doit faire une supposition éclairée, ce qui peut conduire aux erreurs que nous avons analysées précédemment.
Qu'est-ce que le text-to-SQL ?
Le text-to-SQL est une technologie de traitement du langage naturel qui convertit le langage courant en une requête SQL écrite en langage de requête structuré. Au lieu d'écrire manuellement du code SQL, un utilisateur pose une question en langage naturel, et le système génère une instruction SQL pouvant être exécutée sur une base de données.
L'objectif principal du text-to-SQL est de réduire l'écart entre la manière dont les gens pensent les données et la manière dont les bases de données exigent que les requêtes soient écrites. Cela est particulièrement pertinent pour les utilisateurs non techniques et les analystes de données qui comprennent le contexte métier mais peuvent ne pas être à l'aise pour écrire la syntaxe SQL à partir de zéro.
À un niveau de base, lorsque l'utilisateur pose une question telle que :
- « Afficher tous les clients de New York ayant effectué des achats le mois dernier. »
Le système traduit cette demande en une requête SQL générée qui sélectionne les bonnes colonnes, filtre les lignes à l'aide de contraintes de date et de localisation, et joint les tables de base de données nécessaires. La qualité du résultat dépend de la capacité du système à générer des requêtes précises reflétant à la fois l'intention de l'utilisateur et le schéma de la base de données.
Où le text-to-SQL est-il utile aujourd'hui ?
Le text-to-SQL fonctionne raisonnablement bien pour :
- Générer des requêtes préliminaires que les analystes de données peuvent examiner et ajuster.
- Faciliter l'analyse exploratoire des données lorsque la rapidité est plus importante que la précision.
- Permettre aux utilisateurs non techniques d'accéder à des données simples via des schémas prédéfinis.
- Aider les utilisateurs SQL en réduisant la nécessité d'écrire des requêtes répétitives.
Dans ces cas, le text-to-SQL fonctionne comme un outil d'IA assistive plutôt qu'un système autonome. La révision humaine reste une partie intégrante du flux de travail, surtout lorsque la justesse est essentielle.
Comment fonctionne le text-to-SQL ?
Les systèmes modernes de text-to-SQL s'appuient sur des grands modèles de langage entraînés sur des paires de questions en langage naturel et de requêtes SQL. Ces modèles apprennent des motifs qui relient le langage courant aux structures SQL, aux noms de tables, aux colonnes et aux relations. Le processus suit généralement une séquence d'étapes :
Compréhension du langage naturel
Le système analyse d'abord la saisie de l'utilisateur pour déterminer l'intention, les contraintes et les entités. Cette étape implique :
- Identifier ce que l'utilisateur demande (par exemple, totaux, filtres, comparaisons)
- Extraire les conditions pertinentes telles que les plages de dates, les lieux ou les catégories
- Interpréter les expressions ambiguës pouvant nécessiter un contexte métier
Les erreurs à ce stade conduisent souvent à une requête SQL correcte en apparence mais répondant à la mauvaise question.
Mappage du schéma
Ensuite, le système associe les termes de la question au schéma de la base de données. Cela inclut :
- Faire correspondre les concepts de la question aux noms de tables et de colonnes
- Comprendre les relations entre les tables
- Respecter les types de données, tels que les dates, les champs numériques ou les catégories
Le mappage du schéma devient plus difficile à mesure que le nombre de tables augmente ou lorsque les noms de colonnes ne correspondent pas étroitement à la manière dont les utilisateurs décrivent les données en langage naturel.
Construction de la requête SQL
Une fois les éléments d'intention et de schéma identifiés, le système construit la requête SQL. Cela peut impliquer :
- Sélectionner les bonnes tables et colonnes
- Ajouter des jointures entre toutes les tables nécessaires
- Appliquer des filtres, des agrégations et une logique de regroupement
- Générer du code SQL syntaxiquement valide pour des systèmes comme MySQL ou PostgreSQL
À ce stade, le système peut facilement produire du SQL valide mais logiquement incorrect, par exemple en utilisant une mauvaise condition de jointure ou une mauvaise agrégation.
Validation et exécution
Certains systèmes incluent des couches de validation qui vérifient que la requête SQL générée peut s'exécuter et renvoyer des résultats. Des outils plus avancés peuvent tenter une optimisation limitée ou poser des questions complémentaires lorsque la requête est ambiguë.
Cependant, la validation ne garantit presque jamais une réponse correcte. Une requête peut s'exécuter avec succès tout en étant incorrecte de manière subtile.
Limites et risques pratiques
Malgré des scores élevés aux benchmarks, l'utilisation en conditions réelles révèle plusieurs limitations impossibles à ignorer.
Fiabilité et justesse
Même les modèles les plus performants échouent à produire du SQL correct pour une part significative de requêtes complexes. Un taux d'erreur de 20 % ou plus signifie :
- Une requête générée sur cinq peut renvoyer des résultats trompeurs
- Les erreurs sont souvent sémantiques plutôt que syntaxiques
- Des jointures, filtres ou agrégations incorrects peuvent passer inaperçus
Cela est particulièrement risqué dans les systèmes de reporting, de prévision ou d'aide à la décision, où les utilisateurs supposent que le résultat est correct.
Dépendance à la supervision humaine
Compte tenu des performances actuelles, la requête SQL générée doit être revue par une personne comprenant le SQL et la base de données. Sans cette supervision :
- Les utilisateurs peuvent faire confiance à une requête incorrecte parce qu'elle s'exécute avec succès
- Les erreurs peuvent se propager dans les tableaux de bord, les rapports ou les systèmes en aval
- La responsabilité devient floue lorsque des décisions reposent sur des sorties générées par l'IA
Le text-to-SQL ne supprime pas le besoin d'expertise en SQL ; il déplace simplement l'endroit où cette expertise est appliquée.
Plafond de complexité
Lorsque la complexité de la requête augmente, les performances chutent fortement. Les modèles ont du mal avec :
- Plusieurs jointures entre de nombreuses tables
- Logique imbriquée et sous-requêtes
- Calculs spécifiques à un domaine
- Requêtes nécessitant une connaissance approfondie du schéma de la base de données
Des benchmarks comme BIRD-SQL montrent que les requêtes complexes restent le principal point d'échec, même pour les modèles les plus avancés.
Variabilité des modèles
Les différences de performance entre les modèles sont significatives. Certains modèles linguistiques fonctionnent raisonnablement bien, tandis que d'autres échouent fréquemment sur le même jeu de données. Cela signifie :
- Le choix du modèle a un impact direct sur la précision
- L'ajustement fin et les données d'entraînement sont déterminants
- Les modèles généralistes peuvent ne pas fonctionner bien sans adaptation au domaine
Il n'existe aucune solution universelle qui fonctionne aussi bien pour toutes les bases de données et tous les cas d'utilisation.
Gouvernance des données et confidentialité
Les systèmes text-to-SQL introduisent des risques d'accès supplémentaires :
- Les utilisateurs peuvent interroger des tables sensibles sans en comprendre les implications
- Le SQL généré peut exposer des métadonnées sur le schéma de la base de données
- Les contrôles de confidentialité des données doivent être appliqués en dehors du modèle de langage
Sans contrôles d'accès stricts, le text-to-SQL peut affaiblir les pratiques de gouvernance existantes.
Ajouter comme source préféréeMéthodologie de benchmark pour le text-to-SQL
Ce benchmark partage son cadre d'évaluation avec notre benchmark sur le RAG agentic, qui décrit en détail la construction du jeu de données, l'architecture de l'agent, le défi de l'ambiguïté sémantique et la grille d'évaluation complète.
Les deux benchmarks utilisent le même sous-ensemble de 500 questions BIRD-SQL1 , un pipeline agentic, une récupération de schéma basée sur ChromaDB, et une évaluation LLM-as-Judge avec Claude 4 Sonnet. La métrique rapportée ici, le taux de génération de commandes SQL correctes, est le pourcentage de questions pour lesquelles le modèle a à la fois dirigé vers la bonne base de données et généré une requête SQL sémantiquement correcte. Tous les modèles ont été évalués dans des conditions identiques de type zero-shot, avec une température de 0 et sans indices spécifiques au domaine.
Pour aller plus loin
Découvrez d'autres benchmarks RAG, tels que :
- Modèles d'intégration : OpenAI vs Gemini vs Cohere
- Meilleure base de données vectorielle pour RAG : Qdrant vs Weaviate vs Pinecone
- Hybrid RAG : Améliorer la précision du RAG
- Benchmark du RAG agentic : routage multi-base et génération de requêtes
- Top 10 des modèles d'intégration multilingues pour RAG
Journal des modifications
20 avril 2026
Ajout d'un nouveau modèle au benchmark :
- Anthropic : Claude Opus 4.7 (anthropic/claude-opus-4.7)
20 février 2026
Ajout de 2 nouveaux modèles au benchmark :
- Google : Gemini 3.1 Pro Preview (google/gemini-3.1-pro-preview)
- Anthropic : Claude Sonnet 4.6 (anthropic/claude-sonnet-4.6)
10 février 2026
Ajout de 2 nouveaux modèles au benchmark :
- Claude Opus 4.6 (anthropic/claude-opus-4.6)
- Kimi K2.5 (moonshotai/kimi-k2.5)
FAQ
D'après nos résultats, vous ne devriez pas faire entièrement confiance aux requêtes complexes générées par les LLMs actuels sans validation. Bien utiles pour les brouillons et les requêtes simples, même les modèles les plus performants ont des taux d'erreur significatifs (jusqu'à 20 % sur des tâches complexes). Vérifiez toujours et validez la requête SQL générée, surtout pour des applications critiques.
Oui, de nombreux LLMs ont des capacités allant au-delà de la génération simple de SELECT. Ils peuvent souvent aider à comprendre et suggérer des modifications de code SQL existant, ou même générer du DDL (langage de définition de données) comme des instructions CREATE TABLE à partir de descriptions, bien que la précision de ces tâches nécessite également une vérification.
Fournir un contexte clair est essentiel. Assurez-vous que le LLM a accès au schéma de la base de données (noms des tables, noms des colonnes, relations). En indiquant clairement le résultat souhaité et en fournissant éventuellement quelques exemples pertinents de requêtes (prompting en contexte limité) pour que le LLM puisse en tirer des leçons, vous pouvez considérablement améliorer sa capacité à sélectionner les bonnes tables et à construire des requêtes précises.
Bien que les LLMs puissent masquer certaines légères différences de syntaxe entre les dialectes de bases de données, ils ne résolvent pas entièrement les problèmes de compatibilité entre types et versions. Ils peuvent encore générer du SQL spécifique à un dialecte (par exemple, PostgreSQL vs MySQL) ou ne pas utiliser de fonctions compatibles avec les anciennes versions, sauf s'ils sont explicitement guidés ou entraînés à cet effet. La validation contre la base de données cible reste importante.
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{dilmegani2026,
author = {Dilmegani, Cem and Sarı, Ekrem},
title = {{Text-to-SQL: Comparaison de la précision des LLM}},
year = {2026},
month = jun,
howpublished = {\url{https://aimultiple.com/text-to-sql}},
note = {AIMultiple. Consulté le 30 Juin 2026}
}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.