De texte à 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 à quiconque, même sans compétences techniques, de travailler directement avec les bases de données.

Nous avons utilisé notre méthodologie de benchmark de texte vers SQL sur plus de 35 grands modèles de langage (LLMs) pour évaluer leurs performances dans la génération de commandes SQL :

Erreurs courantes dans le SQL généré par les LLM

LLMs font 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 eu du mal à identifier et implémenter correctement les opérations `JOIN` nécessaires entre les tables, parfois en les omettant entièrement ou en utilisant de manière incorrecte des sous-requêtes moins optimales.

Le LLM n'a pas réussi à joindre correctement les tables `frpm` et `schools` en utilisant le `CDSCode`. Il a également halluciné des noms de colonnes (`Charter`) et des valeurs de filtre (`County = ‘Fresno’`).

Les erreurs dans la logique de jointure brisent 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

Utiliser incorrectement des fonctions d'agrégation (comme `MAX`, `AVG`, `COUNT`, `SUM`) ou les clauses `GROUP BY` constituait un autre point de défaillance 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 de la logique est correcte.

Cependant, le LLM n'a pas réussi à intégrer un filtre critique de la question : le mot “active”. Pour satisfaire cette exigence, la requête devait joindre la table satscores avec la table schools, puis filtrer les résultats avec une clause WHERE T1.StatusType = ‘Active’.

Cela met en évidence une défaillance courante des LLM : exécuter correctement une instruction principale évidente (calculer une moyenne) tout en omettant une condition secondaire mais tout aussi importante (filtrer par statut). Cela montre une faiblesse dans la synthèse de multiples 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 réussi à sélectionner le numéro de `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 demande de l'utilisateur ou d'un échec à mapper toutes les parties de la demande aux composants finaux de la requête SQL.

Erreurs de syntaxe

Au-delà des erreurs sémantiques, des erreurs de syntaxe pure se sont produites, telles que 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…’`), entraînant une syntaxe SQL invalide.

Ces problèmes de syntaxe mettent en évidence les défis liés à la génération de code qui respecte strictement la grammaire SQL et les conventions spécifiques aux bases de données.

Pourquoi certains LLMs sont meilleurs en SQL

Plusieurs facteurs clés déterminent dans quelle mesure un modèle de langage de grande taille (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 des tâches complexes, telles que la génération de SQL, plus efficacement.
• Ce qu'il a appris : Les données utilisées pour entraîner le LLM sont essentielles. S'il voit de nombreux exemples de questions liées à des réponses SQL, en particulier celles impliquant des opérations complexes telles que des jointures ou des calculs (SUM, AVG), il est probable qu'il obtienne de meilleurs résultats.

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 de texte vers SQL. Cet « ajustement fin » les aide à comprendre les structures de base de données et les règles SQL plus efficacement que les modèles entraînés sur du texte général. L'entraînement sur des instructions spécifiques aide également.

3. Capacités de raisonnement et de correspondance de 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 du plan de la base de données (Schéma) : Certains LLMs sont meilleurs pour connecter les concepts de la question (tels que « 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 du SQL : un aperçu étape par étape

Pour voir des facteurs tels que le « raisonnement » et la « correspondance de schéma » en action, examinons le processus étape par étape suivi par un modèle pour générer une requête. L'ensemble de ce flux de travail 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'on lui présente une question, le LLM analyse d'abord l'intention de l'utilisateur pour sélectionner l'outil de base de données le plus pertinent.

• Question : « How many accounts have an owner disposition and request for a statement to be generated upon a transaction? »
• Action du LLM : Le modèle identifie des mots-clés comme « accounts », « disposition » et « transaction ». Il conclut que l'outil de base de données financial est le bon choix par rapport à d'autres comme california_schools ou superhero.

Étape 2 : Récupération du schéma via RAG

Une fois que le modèle a choisi un outil, il a besoin du « plan » de la base de données, le schéma. Il n'a pas ces informations mémorisées. Au lieu de cela, le système RAG les récupère en temps réel.

1. Récupération : La question de l'utilisateur est utilisée pour interroger une base de données vectorielle qui stocke les informations de 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 accounts et disp.
2. Augmentation : Ce texte de schéma récupéré est automatiquement inséré dans le prompt avec la question d'origine.
3. Génération : Le LLM dispose maintenant de tout le contexte nécessaire pour continuer.

Ce processus RAG garantit que le modèle reçoit 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 fait correspondre les concepts de la demande de l'utilisateur aux noms spécifiques des tables et des colonnes qu'il vient de recevoir.

Monologue interne du LLM :

1. Objectif : L'utilisateur veut un décompte, je vais donc commencer par SELECT COUNT(...).
2. Conditions :
   • « …owner disposition… » → Le schéma de la table disp a une colonne type. J'ai besoin d'une clause WHERE pour type = 'OWNER'.
   • « …statement to be generated upon a transaction… » → Le schéma de la table accounts a une colonne frequency. Le filtre devrait être frequency = 'POPLATEK PO OBRATU'.
3. Jointures : Les informations sont réparties entre les tables accounts et disp. Le schéma montre qu'elles sont liées par account_id, je dois donc les JOIN.

Étape 4 : Génération du SQL final

Enfin, le modèle assemble ces pièces logiques en une requête SQL syntaxiquement correcte. La qualité de ce résultat dépend de :

1. Capacité de raisonnement : La capacité du modèle à connecter logiquement la demande de l'utilisateur au schéma fourni.
2. Connaissances SQL issues de l'entraînement : La compréhension fondamentale par le modèle de la syntaxe et des 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 texte vers SQL ?

Le texte vers 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 qui peut être exécutée sur une base de données.

Le principal objectif du texte vers SQL est de réduire l'écart entre la façon dont les gens pensent aux 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 ne sont peut-être pas à l'aise pour écrire la syntaxe SQL à partir de zéro.

À un niveau de base, 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 demande en une requête SQL générée qui sélectionne les bonnes colonnes, filtre les lignes en utilisant des 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 qui reflètent à la fois l'intention de l'utilisateur et le schéma de la base de données.

Où le texte vers SQL est utile aujourd'hui

Le texte vers SQL fonctionne raisonnablement bien pour :

• Générer des requêtes ébauches que les analystes de données peuvent examiner et ajuster.
• Soutenir l'analyse exploratoire des données où la vitesse importe plus 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 de SQL en réduisant la nécessité d'écrire des requêtes répétitives.

Dans ces cas, le texte vers SQL fonctionne comme un outil d'IA d'assistance plutôt que comme un système autonome. La révision humaine reste une partie du flux de travail, en particulier lorsque l'exactitude est importante.

Comment fonctionne le texte vers SQL ?

Les systèmes modernes de texte vers SQL s'appuient sur de 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, des totaux, des filtres, des comparaisons)
• Extraire les conditions pertinentes telles que les plages de temps, les lieux ou les catégories
• Interpréter les expressions ambiguës qui peuvent nécessiter un contexte métier

Les erreurs à ce stade conduisent souvent à une requête SQL d'apparence correcte qui répond à la mauvaise question.

Correspondance de schéma

Ensuite, le système fait correspondre 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

La correspondance de schéma devient plus difficile à mesure que le nombre de tables augmente ou lorsque les noms de colonnes ne correspondent pas étroitement à la façon dont les utilisateurs décrivent les données dans les questions en langage naturel.

SQL : construction de la requête

Une fois que l'intention et les éléments du schéma sont identifiés, le système construit la requête SQL. Cela peut impliquer :

• Sélectionner les bonnes tables et colonnes
• Ajouter des jointures sur toutes les tables nécessaires
• Appliquer des filtres, des agrégations et une logique de regroupement
• Produire 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 d'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 de suivi 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 et être néanmoins incorrecte de manière subtile.

Limites et risques pratiques

Malgré des scores de benchmark élevés, l'utilisation dans le monde réel expose plusieurs limites qui ne peuvent être ignorées.

Fiabilité et exactitude

Même les modèles plus performants échouent à produire 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 le résultat est correct.

Dépendance à la supervision humaine

Compte tenu des performances actuelles, le SQL généré doit être examiné par une personne qui comprend 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 les décisions reposent sur des résultats générés par l'IA

Le texte vers 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é

À mesure que la complexité des requêtes augmente, les performances chutent fortement. Les modèles peinent avec :

• Des jointures multiples sur de nombreuses tables
• Une logique imbriquée et des sous-requêtes
• Des calculs spécifiques au domaine
• Des requêtes qui nécessitent 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é des modèles

Les différences de performances entre les modèles sont significatives. Certains modèles de langage obtiennent des résultats raisonnablement bons, tandis que d'autres échouent fréquemment sur le même ensemble 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 comptent
• Les modèles à usage général peuvent ne pas bien fonctionner 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 des données et confidentialité

Les systèmes de texte vers 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 solides, le texte vers SQL peut affaiblir les pratiques de gouvernance existantes.

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

Méthodologie de benchmark pour le texte vers SQL

Ce benchmark partage son cadre d'évaluation avec notre benchmark de 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 de notation complète.

Les deux benchmarks utilisent le même sous-ensemble de 500 questions BIRD-SQL¹ , le pipeline agentique, la récupération de schéma basée sur ChromaDB et l'évaluation par LLM-as-Judge avec Claude 4 Sonnet. La mesure rapportée ici, le taux de génération correcte de commandes SQL, est le pourcentage de questions où le modèle a à la fois acheminé 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 zero-shot avec une température de 0 et sans indices spécifiques au domaine.

Lectures complémentaires

Explorez d'autres benchmarks RAG, tels que :

• Modèles d'embedding : OpenAI vs Gemini vs Cohere
• Meilleure base de données vectorielle pour le RAG : Qdrant vs Weaviate vs Pinecone
• RAG hybride : améliorer la précision du RAG
• Benchmark de RAG agentique : routage multi-bases de données et génération de requêtes
• Top 10 des modèles d'embedding multilingues pour le RAG

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{dilmegani2026,
  author = {Dilmegani, Cem and Sarı, Ekrem},
  title  = {{De texte à SQL: Comparaison de la précision des LLM}},
  year   = {2026},
  month  = jul,
  howpublished    = {\url{https://aimultiple.com/text-to-sql}},
  note   = {AIMultiple. Consulté le 17 Juillet 2026}
}

Liens de référence

1.

[2305.03111] Can LLM Already Serve as A Database Interface? A BIg Bench for Large-Scale Database Grounded Text-to-SQLs

Cem Dilmegani

Analyste principal

Suivre

Cem est analyste principal chez AIMultiple depuis 2017. AIMultiple informe chaque mois des centaines de milliers d'entreprises (selon similarWeb), dont 55 % des entreprises du classement Fortune 500. Les travaux de Cem ont été cités par des publications internationales de premier plan telles que Business Insider, Forbes et le Washington Post, ainsi que par des entreprises mondiales comme Deloitte et HPE, des ONG comme le Forum économique mondial et des organisations supranationales comme la Commission européenne. Vous trouverez d'autres entreprises et ressources réputées ayant fait référence à AIMultiple. Tout au long de sa carrière, Cem a exercé les fonctions de consultant, d'acheteur et d'entrepreneur dans le secteur des technologies. Il a conseillé des entreprises sur leurs décisions technologiques chez McKinsey & Company et Altman Solon pendant plus de dix ans. Il a également publié un rapport McKinsey sur la numérisation. Il a dirigé la stratégie technologique et les achats d'un opérateur télécom, sous la responsabilité directe du PDG. Il a également piloté la croissance commerciale de la société de deep tech Hypatos, qui a atteint un chiffre d'affaires annuel récurrent à sept chiffres et une valorisation à neuf chiffres en seulement deux ans. Les travaux de Cem chez Hypatos ont été présentés dans des publications technologiques de référence telles que TechCrunch et Business Insider. Cem intervient régulièrement lors de conférences internationales sur les technologies. Diplômé en génie informatique de l'université de Bogazici, il est également titulaire d'un MBA de la Columbia Business School.

Voir le profil complet

Recherche effectuée par

Ekrem Sarı

Chercheur en IA

Suivre

Ekrem est chercheur en IA chez AIMultiple, spécialisé dans l'automatisation intelligente, les GPU, les agents IA et les frameworks RAG.

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