Création d'un système Text-to-SQL prêt pour la production : obtention d'un score de 88.15 % sur Spider 1.0

La mise en place d'un système Text-to-SQL opérationnel exige bien plus que la simple génération de SQL à l'aide d'un modèle de langage étendu. Les applications d'entreprise nécessitent une compréhension précise du schéma, la récupération du contexte, la validation et la correction des erreurs afin de produire des résultats fiables sur des bases de données inconnues.

Dans cette étude, nous comparons nos Agent de données on Araignée 1.0 et réaliser Précision d'exécution : 88.15 % en utilisant la fonction  Gemma 4 26B Au lieu de se concentrer uniquement sur les scores de référence, cet article présente les choix architecturaux, les enseignements d'ingénierie et les analyses comparatives qui sous-tendent ces résultats.

Les grands modèles de langage ont considérablement amélioré la génération de requêtes SQL, mais la mise en place d'un système Text-to-SQL opérationnel exige bien plus que la simple traduction du langage naturel en SQL. Les applications d'entreprise doivent comprendre des schémas de base de données complexes, extraire le contexte approprié, valider les requêtes générées et produire des résultats fiables sur des bases de données inconnues.

Pour évaluer ces capacités, nous avons comparé nos Agent de données sur Spider 1.0, le benchmark Text-to-SQL le plus utilisé. En utilisant Gemma 4 26B modèle, notre système a atteint Précision d'exécution : 88.15 %, démontrant ainsi que l'architecture et la gestion du contexte sont tout aussi importantes que la sélection du modèle.

Choisir le bon jeu de données de référence est tout aussi important que choisir le bon modèle. Bien que des jeux de données plus récents comme Spider 2.0 et BIRD introduisent des scénarios d'entreprise plus complexes, Spider 1.0 reste le jeu de données de référence le plus largement utilisé pour évaluer les systèmes Text-to-SQL et comparer les résultats dans la littérature.

Pour notre évaluation initiale, nous avons choisi Spider 1.0 car il fournit une base de référence standardisée et bien établie. Il nous permet de mesurer l'efficacité avec laquelle notre agent de données comprend des schémas de bases de données inédits et génère du code SQL correct dans des conditions réalistes.

La figure 2 résume comment Spider 1.0 se compare à d'autres benchmarks Text-to-SQL couramment utilisés.

L'obtention d'une précision élevée pour la conversion de texte en SQL ne se résume pas à l'utilisation d'un modèle de langage plus étendu. Au cours de notre processus d'évaluation comparative, nous avons constaté que l'architecture et la gestion du contexte avaient un impact plus important sur les performances que le seul choix du modèle.

Notre Agent de données Ce système est conçu comme un pipeline à plusieurs étapes qui affine progressivement le problème avant de demander au LLM de générer la requête SQL. Au lieu d'exposer l'intégralité du schéma de la base de données au modèle, le système récupère d'abord uniquement le schéma pertinent et les informations contextuelles, puis génère une requête SQL, valide le résultat et corrige automatiquement les erreurs courantes avant son exécution.

Comme illustré dans Figure 3, l'architecture se compose de trois étapes principales :

• Récupération de l'information – La question de l'utilisateur est analysée afin d'identifier les objets de base de données pertinents, et seules les informations de schéma nécessaires sont extraites du magasin de métadonnées.
• Agent d'auto-raffinement – Le modèle de langage génère du SQL, valide la requête par rapport au schéma récupéré et l'affine automatiquement en cas d'échec de la validation.
• Exécution et réponse – Une fois validée, la requête SQL est exécutée sur la base de données cible et les résultats sont renvoyés sous forme de données structurées ou de réponse en langage naturel.

Cette architecture axée sur la production s'inspire d'idées introduites dans DIN-SQL et SQL journalier, tout en étant adapté aux environnements d'entreprise où la fiabilité, l'explicabilité et la robustesse sont aussi importantes que la précision des références.

Le choix du modèle de langage approprié constituait une étape importante de notre processus d'évaluation comparative. Plutôt que d'évaluer un seul modèle, nous avons expérimenté un large éventail de modèles de langage open source, notamment Lama 3.1, Qwen 2.5, DeepSeek, SQLCoder, CodeGemma, Mistral, GPT-OSS, et Gemma 4.

Pour garantir une comparaison équitable, nous avons évalué chaque modèle en utilisant Précision d'exécution (EA)L'exactitude d'exécution est la métrique standard pour l'évaluation comparative des requêtes SQL générées. Contrairement aux métriques basées sur la syntaxe, elle mesure si le SQL généré renvoie le même résultat que la requête de référence, ce qui en fait un meilleur indicateur des performances réelles.

Notre démarche d'analyse comparative est illustrée dans Figure 4Nous avons commencé par expérimenter sur un poste de travail local équipé d'un RTX 4060 (8 Go de VRAM), où des modèles plus petits nous ont permis d'itérer rapidement et de valider notre pipeline. Après avoir établi une base de référence stable à l'aide d'un sous-ensemble de 233 questions sur Spider 1.0, Nous sommes passés aux GPU cloud pour évaluer des modèles plus volumineux sur l'ensemble du système. 2,147-question Cette approche par étapes nous a permis d'optimiser efficacement l'architecture avant d'investir dans des tests de performance à grande échelle.

Nous avons évalué les modèles finaux sur l'ensemble des données de test Spider 1.0, comprenant 2 147 questions. Comme le montre le tableau 1, Gemma 4 26B a obtenu le meilleur score (88.15 %), suivi de GPT-OSS 20B (86.63 %). Ces résultats démontrent que les modèles de langage open source modernes, associés à un pipeline de recherche et de validation efficace, peuvent atteindre des performances de conversion de texte en SQL très compétitives. 

Les scores de référence ne sont pertinents que s'ils peuvent être comparés à des travaux publiés antérieurement. Afin de mieux comprendre la portée de nos résultats, nous avons examiné des études récentes sur la conversion de texte en SQL ainsi que des articles de référence largement cités.

Tableau 2 : Les taux de précision des modèles à source fermée rapportés dans l'étude SQL-of-Thought sur un sous-ensemble de l'ensemble de données Spider ; il montre, en termes comparatifs, que le résultat de 88.15 % obtenu dans ce travail est positionné au-dessus de GPT-4o Mini (87 %) et à un niveau proche de GPT-5 (89 %).

Des travaux récents tels que SQL de la pensée [1] indique que les principaux modèles à code source fermé, y compris Claude Opus 3, GPT-5, et GPT-4o Mini—obtenir une précision élevée sur les sous-ensembles de référence Spider. Bien que les comparaisons directes doivent être interprétées avec prudence en raison des différences de paramètres d'évaluation, d'invites et de sous-ensembles de référence, notre Précision d'exécution : 88.15 % cela démontre que les modèles open source peuvent atteindre des performances comparables à celles des modèles concurrents.

Bien que ces résultats proviennent de contextes d'évaluation différents et ne soient pas directement comparables, ils offrent un éclairage utile sur les performances actuelles des systèmes Text-to-SQL. Notre analyse comparative démontre que les modèles open source peuvent désormais rivaliser avec les principales solutions propriétaires lorsqu'ils sont associés à une architecture bien conçue.

Nous avons également comparé nos résultats avec des frameworks Text-to-SQL orientés production tels que DIN-SQL[3] et DAIL-SQL, qui combinent de grands modèles de langage avec des techniques telles que la liaison de schémas, l'ingénierie des invites, l'autocohérence et la correction d'erreurs.

Tableau 3 : Les résultats de précision d'exécution de différentes méthodes sur Spider 1.0 dans l'étude « Text-to-SQL Empowered by Large Language Models : A Benchmark Evaluation » [2] ; il révèle l'impact sur la précision non seulement de la sélection du modèle, mais aussi de techniques telles que l'ingénierie des prompts, la liaison de schémas et l'auto-cohérence.

Nos résultats confortent une conclusion partagée par la littérature récente : Les performances élevées de la conversion de texte en SQL dépendent non seulement du modèle de langage, mais aussi de l'architecture environnante. La récupération efficace des schémas, la gestion du contexte, la validation et l'autocorrection sont souvent aussi importantes que le modèle lui-même.

L'analyse comparative ne se limite pas à la mesure de la précision ; elle vise également à comprendre les défaillances d'un système et leurs causes. Tout au long de notre évaluation, nous avons analysé les prédictions erronées et identifié plusieurs schémas récurrents ayant influencé les résultats finaux.

Certaines erreurs provenaient du test de référence lui-même. Dans quelques cas, des incohérences dans les requêtes SQL de référence (de référence) ont conduit à ce que des prédictions logiquement correctes soient considérées comme incorrectes. D'autres cas concernaient des questions en langage naturel ambiguës ou des situations de départage, où plusieurs requêtes SQL pouvaient légitimement produire des réponses tout aussi valides.

Nous avons également observé plusieurs comportements spécifiques au modèle, notamment des conversions de type inutiles, une gestion incohérente de la casse et une complexification excessive occasionnelle de requêtes SQL pourtant simples. Ces observations ont renforcé l'importance d'intégrer des mécanismes de validation et d'autocorrection au pipeline de l'agent de données.

Globalement, notre analyse a montré que de nombreuses erreurs restantes n'étaient pas dues aux limitations du modèle de langage lui-même, mais à des ambiguïtés dans le référentiel ou à des cas limites lors de la génération de requêtes SQL. Cela suggère que des améliorations supplémentaires au niveau de la récupération, de la validation et de la gestion du contexte pourraient permettre au système d'aller au-delà des limites actuelles. Précision d'exécution : 90 % seuil.

La haute précision n'est qu'un aspect d'un système Text-to-SQL prêt pour la production. En entreprise, le coût de l'infrastructure, la confidentialité des données et la flexibilité de déploiement sont des considérations tout aussi importantes.

L'un des principaux avantages de notre approche est qu'elle repose entièrement sur Modèles de langage open source. Tout au long du processus de développement, nous avons pu réaliser la plupart des expériences localement à l'aide d'un matériel grand public. RTX 4060 (8 Go de VRAM)Cela nous a permis d'itérer rapidement sans aucun coût d'API ni de jeton. Des tests de performance plus importants ont ensuite été exécutés sur des GPU cloud dédiés uniquement après validation de l'architecture.

Nous avons utilisé RunPod Secure Cloud pour l'évaluation complète de Spider 1.0. Le benchmark Gemma 4 26B a été exécuté sur un Carte graphique A100 PCIe 80 Go, tout en GPT-OSS 20B a couru sur un Carte graphique RTX 6000 48 Go.

Les coûts d'infrastructure sont résumés dans Tableau 4.

Bien que les tests de performance les plus exigeants aient nécessité une infrastructure cloud, le processus de développement global est resté rentable grâce à l'expérimentation locale et aux modèles open source. Plus important encore, l'architecture résultante peut être déployée intégralement au sein de l'infrastructure interne de l'organisation, éliminant ainsi la dépendance aux API externes et offrant un meilleur contrôle sur la confidentialité des données, la conformité et les coûts opérationnels.

Cette architecture est donc particulièrement adaptée aux organisations opérant dans des environnements sensibles à la protection de la vie privée, réglementés ou isolés du réseau, où la sécurité des données et la flexibilité de déploiement sont des exigences essentielles.

Les benchmarks offrent une méthode objective d'évaluation des systèmes d'IA, mais ils ne constituent pas une fin en soi. Un score élevé à un benchmark n'a de valeur que s'il se traduit par des performances fiables dans des applications concrètes.

Tout au long de cette étude, nous avons constaté que la création d'un système Text-to-SQL prêt pour la production ne se limite pas à la génération de SQL. La compréhension des schémas de base de données, la récupération du contexte approprié, la validation des requêtes générées et l'amélioration des résultats incorrects se sont avérées tout aussi importantes que le modèle de langage lui-même.

Notre Précision d'exécution : 88.15 % L'expérience Spider 1.0 démontre que les modèles open source, associés à une architecture bien conçue, peuvent offrir des performances très compétitives pour les tâches de conversion de texte en SQL en entreprise. Plus important encore, elle valide les principes de conception qui sous-tendent notre approche. Agent de données, conçu pour fonctionner de manière fiable sur des bases de données d'entreprise complexes et non pas seulement sur des ensembles de données de référence.

Spider 1.0 représente une étape importante, mais ce n'est que le début de notre aventure. Nos prochaines étapes consistent à évaluer l'agent de données sur Araignée 2.0, des benchmarks à plus grande échelle pour les entreprises, et, surtout, des environnements clients réels où les schémas de bases de données sont nettement plus importants et les questions commerciales beaucoup plus complexes.

Notre vision à long terme ne se limite pas à la création d'un générateur SQL plus performant. Nous ambitionnons de concevoir des agents de données intelligents permettant aux organisations d'interagir avec leurs données d'entreprise aussi naturellement qu'avec un collègue, en combinant extraction, raisonnement, validation et IA explicable au sein d'une plateforme d'aide à la décision fiable.

L’analyse comparative ne se limite pas à mesurer la précision ; il s’agit aussi de comprendre pourquoi un système réussit ou échoue.

Tout au long de notre évaluation, nous avons identifié plusieurs schémas d'erreurs récurrents. Certains provenaient d'ambiguïtés dans le référentiel lui-même, notamment des incohérences dans les requêtes SQL de référence et des conditions de tri insuffisamment spécifiées. D'autres reflétaient des comportements courants de LLM, tels que des conversions de type inutiles ou une gestion incohérente des valeurs sensibles à la casse.

Ces observations ont renforcé l'une des principales conclusions de nos travaux : L'architecture est tout aussi importante que le choix du modèle. La récupération, la liaison des schémas, la validation et l'autocorrection ont autant contribué à la performance finale que le modèle de langage sous-jacent.

Bien que les limitations des critères de référence affectent inévitablement le score final, notre analyse suggère que des améliorations supplémentaires en matière de gestion du contexte et de validation pourraient permettre au système de dépasser les limites du système. Note de précision d'exécution de 90 %.

Spider 1.0 a fourni une base de référence importante pour l'évaluation de notre agent de données, mais il ne représente que la première étape vers une IA d'entreprise prête pour la production.

Notre prochain objectif est d'évaluer l'architecture sur des benchmarks plus exigeants, tels que : Araignée 2.0 et, plus important encore, sur les véritables bases de données d'entreprise où les schémas sont nettement plus volumineux, la documentation est souvent incomplète et les questions métier sont bien plus complexes.

Notre objectif n'est pas simplement de créer un autre système de conversion texte-SQL. Nous développons des systèmes intelligents. Agents de données qui combinent récupération, raisonnement, validation et explicabilité pour aider les organisations à interagir avec les données d'entreprise de manière naturelle et fiable.

Références

[1] Saumya Chaturvedi, Aman Chadha, Laurent Bindschaedler arXiv. « SQL-of-Thought : Multi-agentic Text-to-SQL with Guided Error Correction. » arXiv. Juin 2026 https://arxiv.org/abs/2509.00581

[2] Dawei Gao, Haibin Wang, Yaliang Li, Xiuyu Sun, Yichen Qian, Bolin Ding, Jingren Zhou « Text-to-SQL renforcé par de grands modèles linguistiques : une évaluation de référence » arXiv. Juin 2026

https://arxiv.org/pdf/2308.15363 

[3] Mohammadreza Pourreza, Davood Rafiei. « DIN-SQL : Apprentissage décomposé et contextuel de la conversion de texte en SQL avec auto-correction », arXiv, juin 2026.

https://arxiv.org/pdf/2304.11015

Dilşen YILDAR HAVAYLAR, 

Ingénieur logiciel senior, MSc.