Text-to-SQL : Comparaison de la précision LLM
J'utilise SQL pour l'analyse de données depuis 18 ans, et ce, depuis mes débuts comme consultant. La traduction des requêtes en langage naturel en SQL rend les données plus accessibles, permettant à tous, même aux personnes sans compétences techniques, de travailler directement avec les bases de données.
Nous avons utilisé notre méthodologie de référence texte-SQL sur 34 grands modèles de langage (LLM) pour évaluer leurs performances dans la génération de commandes SQL :
Erreurs courantes dans les requêtes SQL générées par LLM
Les LLM commettent souvent quatre types d'erreurs : des jointures erronées, des erreurs d'agrégation, des filtres manquants et des erreurs de syntaxe.
Logique de jointure incorrecte
Les modèles avaient souvent du mal à identifier et à implémenter correctement les opérations `JOIN` nécessaires entre les tables, les omettant parfois complètement ou utilisant mal des sous-requêtes moins optimales.
Le LLM n'a pas réussi à joindre correctement les tables `frpm` et `schools` à l'aide du `CDSCode`. Il a également affiché des noms de colonnes erronés (« Charter ») et des valeurs de filtre incorrectes (« County = 'Fresno' »).
Les erreurs dans la logique de jointure compromettent fondamentalement l'aspect relationnel de la requête, ce qui entraîne 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` était un autre point d'échec courant, conduisant à 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 du raisonnement est correcte.
Cependant, la requête LLM n'a pas intégré un filtre essentiel de la question : le mot « actif ». Pour satisfaire cette exigence, la requête devait joindre la table satscores à la table schools, puis filtrer les résultats avec une clause WHERE T1.StatusType = 'Active'.
Ceci met en évidence une erreur fréquente des algorithmes de modélisation linéaire : l’exécution correcte d’une instruction principale et évidente (le calcul d’une moyenne) sans prendre en compte une condition secondaire, pourtant tout aussi importante (le filtrage par statut). Cela révèle une faiblesse dans la synthèse de plusieurs contraintes au sein d’une seule requête correcte.
Filtres manquants ou incorrects
Il arrivait que les modèles n'incluent pas les clauses `WHERE` nécessaires ou sélectionnent les mauvaises colonnes dans l'instruction `SELECT`, ne répondant ainsi pas pleinement aux contraintes ou aux informations explicitement demandées dans l'invite.
Le LLM a correctement identifié la logique pour trouver l'école (`ORDER BY NumGE1500 DESC LIMIT 1`), mais n'a pas réussi à sélectionner le numéro `Phone` demandé et a omis la jointure nécessaire à la table `schools` pour le récupérer.
Ces erreurs proviennent souvent d'une analyse incomplète de la requête de l'utilisateur ou d'une incapacité à faire correspondre 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 sont produites, comme l'utilisation d'alias de table incorrects ou la production d'instructions SQL incomplètes, ce qui empêche l'exécution de la requête.
Le LLM a utilisé des alias incorrects (« accounts » au lieu de « account ») et a inclus une chaîne littérale incomplète (« POPLATEK PO OBRATU… »), ce qui a entraîné une syntaxe SQL invalide.
Ces problèmes de syntaxe mettent en évidence les difficultés liées à la génération de code respectant strictement la grammaire SQL et les conventions spécifiques à la base de données.
Pourquoi certains titulaires d'un LLM sont-ils meilleurs en SQL ?
Plusieurs éléments clés déterminent dans quelle mesure un modèle de langage étendu (LLM) peut transformer une question en anglais simple 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 grands ou ceux construits avec des structures spécifiques peuvent gérer plus efficacement des tâches complexes, telles que la génération de requêtes SQL.
- Ce que le modèle a appris : les données utilisées pour son entraînement sont essentielles. Plus il est exposé à des exemples de questions liées à des réponses SQL, notamment celles impliquant des opérations complexes comme les jointures ou les calculs (SOMME, MOYENNE), plus ses performances seront élevées.
2. Optimisation des tâches SQL
- Les modèles peuvent bénéficier d'un entraînement supplémentaire spécifiquement axé sur les tâches de conversion de texte en SQL. Ce « réglage fin » leur permet de 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. Un entraînement sur des instructions spécifiques est également utile.
3. Capacités de raisonnement et de modélisation schématique
- 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 requêtes SQL nécessite souvent des étapes logiques .
- Comprendre le schéma de la base de données : certains LLM sont plus à même de relier les concepts de la question (tels que « clients » ou « ventes totales ») aux noms réels des tables et des colonnes de la base de données, même si ces noms ne sont pas immédiatement évidents.
Comment les LLM génèrent du SQL : un aperçu étape par étape
Pour observer concrètement des facteurs comme le « raisonnement » et le « mappage de schéma », examinons les étapes suivies par un modèle pour générer une requête. Ce flux de travail repose sur une technique appelée génération augmentée par la recherche (RAG).
Étape 1 : Analyse initiale et sélection de la base de données
Face à une question, 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 comportent une disposition du propriétaire et une demande de génération d'un relevé lors d'une transaction ? »
- Action de 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 bon choix par rapport à d’autres commecalifornia_schoolsousuperhero.
Étape 2 : Récupération du schéma via RAG
Une fois l'outil sélectionné par le modèle, celui-ci a besoin du schéma de la base de données. Ces informations ne sont pas mémorisées ; le système RAG les récupère en temps réel.
- Extraction : La question de l’utilisateur est utilisée pour interroger une base de données vectorielle contenant des informations de schéma. La recherche trouve et extrait 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 l’invite à côté de la question originale.
- Génération : Le LLM dispose désormais de tout le contexte nécessaire pour poursuivre.
Ce processus RAG garantit que le modèle ne reçoit que les informations de schéma nécessaires, ce qui rend sa tâche plus ciblée et efficace.
Étape 3 : Raisonnement et construction de la requête
À partir de la question et du schéma fourni par RAG, le modèle associe les concepts de la requête de l'utilisateur aux noms de tables et de colonnes spécifiques qu'il vient de recevoir.
Monologue intérieur de LLM :
- Objectif : L'utilisateur souhaite un décompte, je vais donc commencer par
SELECT COUNT(...). - Conditions :
- « …disposition du propriétaire… » -> Le schéma de la table
dispcomporte une colonnetype. J’ai besoin d’une clauseWHEREpourtype = 'OWNER'. - « …relevé à générer lors d’une transaction… » -> Le schéma de la table
accountscomporte une colonnefrequency. Le filtre devrait ê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, je dois donc 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 : aptitude du modèle à relier logiquement la requête de l’utilisateur au schéma fourni.
- Connaissances SQL acquises lors de la formation : Compréhension fondamentale du modèle en matière de syntaxe et de fonctions SQL.
Ce processus explique l'origine des erreurs. 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 entraîner les erreurs analysées précédemment.
Qu'est-ce que text-to-SQL ?
Text-to-SQL est une technologie de traitement automatique du langage naturel qui convertit le langage courant en une requête SQL rédigée en langage structuré. Au lieu d'écrire manuellement du code SQL, l'utilisateur pose une question en langage naturel, et le système génère une instruction SQL exécutable sur une base de données.
L'objectif principal de la conversion de texte en SQL est de réduire l'écart entre la façon dont les utilisateurs conçoivent les données et la manière dont les bases de données exigent la rédaction des requêtes. Ceci est particulièrement pertinent pour les utilisateurs non techniques et les analystes de données qui comprennent le contexte métier mais qui ne sont pas forcément à l'aise avec la syntaxe SQL.
En termes simples, lorsqu'un utilisateur pose une question telle que :
- « Afficher tous les clients de New York qui ont effectué des achats le mois dernier. »
Le système traduit cette requête en une requête SQL générée qui sélectionne les colonnes appropriées, filtre les lignes selon des contraintes de date et de lieu, et joint les tables de la 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 qui reflètent à la fois l'intention de l'utilisateur et le schéma de la base de données.
Où la conversion de texte en SQL est utile aujourd'hui
La conversion de texte en SQL fonctionne assez bien pour :
- Générez des ébauches de requêtes que les analystes de données pourront examiner et ajuster.
- Soutenir l'analyse exploratoire des données lorsque la rapidité prime sur 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 de SQL en réduisant la nécessité d'écrire des requêtes répétitives.
Dans ces cas, la conversion de texte en SQL fonctionne comme un outil d'IA d'assistance plutôt que comme un système autonome. La vérification humaine reste une étape essentielle du processus, notamment lorsque l'exactitude des données est primordiale.
Comment fonctionne la conversion de texte en SQL ?
Les systèmes modernes de conversion texte-SQL s'appuient sur de vastes 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 schémas 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 les données saisies par l'utilisateur afin de déterminer son intention, les contraintes et les entités concernées. Cette étape comprend :
- Identifier ce que demande l'utilisateur (par exemple, des totaux, des filtres, des comparaisons).
- Extraction des conditions pertinentes telles que les plages horaires, les lieux ou les catégories
- Interpréter des phrases ambiguës pouvant nécessiter un contexte commercial
Les erreurs à ce stade conduisent souvent à une requête SQL d'apparence correcte qui répond à la mauvaise question.
Cartographie schématique
Ensuite, le système associe les termes de la question au schéma de la base de données. Cela comprend :
- Associer les concepts de la question aux noms des tableaux et aux 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 de schémas devient plus complexe à mesure que le nombre de tables augmente ou lorsque les noms de colonnes ne correspondent pas exactement à la façon dont les utilisateurs décrivent les données dans leurs questions en langage naturel.
construction de requêtes SQL
Une fois l'intention et les éléments de schéma identifiés, le système construit la requête SQL. Cela peut impliquer :
- Sélectionner les tables et les colonnes appropriées
- Ajouter des jointures à toutes les tables nécessaires
- Application de filtres, d'agrégations et de logique de regroupement
- Générer du code SQL syntaxiquement valide pour des systèmes tels que MySQL ou PostgreSQL
À ce stade, le système peut facilement produire du SQL valide mais logiquement incorrect, par exemple en utilisant une condition de jointure ou d'agrégation incorrecte.
Validation et exécution
Certains systèmes intègrent 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 garantit rarement une réponse correcte. Une requête peut s'exécuter avec succès tout en étant incorrecte de manière subtile.
Limitations et risques pratiques
Malgré d'excellents résultats aux tests de référence, l'utilisation dans le monde réel révèle plusieurs limitations qu'il est impossible d'ignorer.
Fiabilité et exactitude
Même les modèles les plus performants ne parviennent pas à générer du SQL correct pour une part importante des 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, des filtres ou des 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 les résultats sont corrects.
Dépendance à l'égard de la surveillance humaine
Compte tenu des performances actuelles, le code SQL généré doit être vérifié par une personne maîtrisant le SQL et les bases de données. Sans cette vérification :
- Les utilisateurs peuvent faire confiance à une requête incorrecte car elle s'exécute avec succès.
- Les erreurs peuvent se propager aux tableaux de bord, aux rapports ou aux systèmes en aval.
- La question des responsabilités devient floue lorsque les décisions reposent sur des résultats générés par l'IA.
La conversion de texte en SQL ne supprime pas le besoin d'expertise en SQL ; elle déplace simplement le domaine d'application de cette expertise.
Plafond de complexité
À mesure que la complexité des requêtes augmente, les performances chutent brutalement. Les modèles peinent à gérer :
- Jointures multiples sur de nombreuses tables
- Logique imbriquée et sous-requêtes
- calculs spécifiques au domaine
- Requêtes nécessitant une connaissance approfondie du schéma de la base de données
Des benchmarks tels que BIRD-SQL soulignent que les requêtes complexes restent le principal point de défaillance, même pour les modèles avancés.
variabilité du modèle
Les différences de performance entre les modèles sont importantes. Certains modèles de langage fonctionnent assez 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.
- Le réglage fin et les données d'entraînement sont importants.
- Les modèles à usage général peuvent ne pas fonctionner correctement sans adaptation au domaine.
Il n'existe pas de solution universelle qui fonctionne aussi bien pour toutes les bases de données et tous les cas d'utilisation.
Gouvernance et confidentialité des données
Les systèmes de conversion de texte en SQL introduisent des risques d'accès supplémentaires :
- Les utilisateurs peuvent interroger des tables sensibles sans en comprendre les conséquences.
- 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, la conversion de texte en SQL peut affaiblir les pratiques de gouvernance existantes.
Méthodologie de référence pour la conversion de texte en SQL
Ce référentiel partage son cadre d'évaluation avec notre référentiel RAG agentique , qui décrit en détail la construction de l'ensemble 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 tests de performance utilisent le même questionnaire BIRD-SQL de 500 questions. 1 sous-ensemble, un pipeline agentique, une récupération de schéma basée sur ChromaDB et une évaluation LLM-as-Judge avec Claude 4 Sonnet. La métrique présentée ici, le taux de génération de commandes SQL correctes, correspond au pourcentage de questions pour lesquelles le modèle a à la fois dirigé le modèle vers la base de données appropriée et généré une requête SQL sémantiquement correcte. Tous les modèles ont été évalués dans des conditions identiques de zéro-shot, avec une température de 0 et sans indications spécifiques au domaine.
Pour en savoir plus
Explorez d'autres indicateurs RAG, tels que :
- Modèles d'intégration : OpenAI vs Gemini vs Cohere
- Meilleure base de données vectorielles pour RAG : Qdrant vs Weaviate vs Pinecone
- Hybrid RAG : Amélioration de la précision RAG
- Analyse comparative d'Agentic RAG : routage multi-bases de données et génération de requêtes
- Les 10 meilleurs modèles d'intégration multilingues pour RAG
Journal des modifications
20 février 2026
Deux nouveaux modèles ont été ajoutés au banc d'essai :
- Google: Aperçu de Gemini 3.1 Pro (google/gemini-3.1-pro-preview)
- Anthropic: Claude Sonnet 4.6 (anthropique/claude-sonnet-4.6)
10 février 2026
Deux nouveaux modèles ont été ajoutés au banc d'essai :
- Claude Opus 4.6 (anthropique/claude-opus-4.6)
- Kimi K2.5 (moonshotai/kimi-k2.5)
FAQ
D'après nos conclusions, il est déconseillé de se fier aveuglément aux requêtes complexes générées par les LLM actuels sans validation. Bien qu'utiles pour la rédaction et les requêtes simples, même les modèles les plus performants présentent des taux d'erreur importants (jusqu'à 20 % pour les tâches complexes). Il est donc impératif de toujours examiner et vérifier le code SQL généré, notamment pour les applications critiques.
Oui, de nombreux LLM possèdent des compétences qui vont au-delà de la simple génération de requêtes SELECT. Ils peuvent souvent aider à comprendre et à suggérer des modifications au code SQL existant, voire générer des instructions DDL (langage de définition de données) telles que CREATE TABLE à partir de descriptions, bien que l'exactitude de ces tâches nécessite également une vérification.
Il est essentiel de fournir un contexte clair. Assurez-vous que le responsable de la maîtrise en droit (LLM) ait accès au schéma de la base de données (noms des tables, des colonnes et des relations). Énoncer clairement le résultat souhaité et, si possible, fournir quelques exemples de requêtes pertinentes (questions préliminaires) pour faciliter son apprentissage peuvent grandement améliorer sa capacité à sélectionner les tables appropriées et à construire des requêtes précises.
Bien que les LLM puissent masquer certaines différences syntaxiques mineures entre les dialectes de bases de données, ils ne résolvent pas entièrement les problèmes de compatibilité entre les versions de bases de données. Ils peuvent toujours générer du SQL spécifique à un dialecte (par exemple, PostgreSQL au lieu de MySQL) ou ne pas utiliser les fonctions compatibles avec les anciennes versions, sauf si elles sont explicitement configurées ou entraînées à cet effet. La validation par rapport à la base de données cible demeure donc essentielle.
Liens de référence
Commentaires 1
Partagez vos idées
Votre adresse courriel ne sera pas publiée. Tous les champs sont obligatoires.
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.