Comment obtenir du code SQL de qualité avec l’IA : décryptage des techniques de Text-to-SQL

Pour prendre de bonnes décisions, les entreprises doivent pouvoir exploiter rapidement et avec précision leurs données. Et, dans ce domaine, le langage SQL reste la référence. Avec Gemini, Google peut générer du code SQL directement à partir de requêtes en langage naturel. C’est le principe du « Text-to-SQL ». Cette approche accroît la productivité des développeurs et des analystes, tout en donnant la possibilité aux utilisateurs non techniques d’interagir directement avec les données dont ils ont besoin.

Ainsi, les fonctionnalités Text-to-SQL sont-elles désormais directement présentes dans de nombreux produits Google Cloud :

• BigQuery Studio, à la fois dans l’éditeur SQL et l’outil de génération SQL, ainsi que dans  SQL node de Data Canvas.
• La fonction « Help me code » dans Cloud SQL Studio (Postgres, MySQL et SQL Server), AlloyDB Studio et Cloud Spanner Studio.
• AlloyDB AI, qui propose une interface en langage naturel directement connectée à la base de données.
• Et via Vertex AI, qui permet d’accéder directement aux modèles Gemini sur lesquels reposent ces différents produits.

Les LLM comme Gemini 2.5, grâce à leurs puissantes capacités de raisonnement et de synthèse, ont permis de réaliser des avancées remarquables dans le domaine du « Text-to-SQL ». À travers cet article, premier d’une série à venir, nous vous proposons d’explorer les rouages techniques des agents Text-to-SQL de Google Cloud. Nous y aborderons les approches les plus avancées pour la construction de contexte et la récupération de tables, la manière d’évaluer efficacement la qualité du Text-to-SQL grâce aux techniques de type LLM-as-a-Judge (des méthodes d’évaluation automatisée où un LLM est utilisé pour juger les performances d’un autre modèle ou de ses propres réponses), les meilleures pratiques en matière de prompting et de post-traitement des LLM, ainsi que les méthodes qui permettent au système de fournir des réponses certifiées correctes avec une fiabilité proche de 100 %.

Relever les défis de la technologie text-to-SQL

Les LLM les plus avancés, comme Gemini 2.5, disposent de capacités de raisonnement qui les rendent particulièrement efficaces pour traduire des questions complexes (formulées en langage naturel) en code SQL fonctionnel, intégrant des jointures, filtres, agrégations et autres concepts complexes.

Prenons un exemple simple réalisé dans Vertex AI Studio pour illustrer la puissance de ces LLM. À partir du prompt « J’ai un schéma de base de données qui contient des produits et des commandes. Écris une requête SQL qui affiche le nombre de commandes de chaussures », Gemini génère du code SQL en s’appuyant sur schéma hypothétique :

Voici une requête est bien construite… mais théorique. Dès qu’on sort de cet exemple trivial pour passer à une base de données réelle et à de vraies questions d’utilisateurs, le problème se complique. Pour y faire face, il faut enrichir la génération de code avec des méthodes qui :

1. spécifient le contexte métier,
2. interprètent correctement l’intention de l’utilisateur,
3. gèrent les différences entre les différents dialectes SQL.

Voyons comment résoudre chacun de ces défis.

Problème n°1 : spécifier le contexte métier

Tout comme les data analysts et les data engineers, les LLM ont besoin de beaucoup de connaissances — ou de contexte — pour générer du code SQL précis. Ce contexte peut être explicite (à quoi ressemble le schéma ? quelles sont les colonnes pertinentes ? à quoi ressemblent les données ?) ou plus implicite (quelle est la signification exacte d’une donnée ? que représente-t-elle dans un cas d’usage métier précis ?).

L’entraînement spécialisé du modèle, ou fine-tuning, n’est généralement pas une solution viable à grande échelle. Néanmoins, entraîner un modèle sur la structure de chaque base de données ou jeu de données, et suivre en permanence les évolutions de schéma ou du contenu de la base, se révèlerait à la fois trop complexe et trop coûteux. Sans compter que la connaissance métier et la sémantique sont rarement bien documentées et qu’elles sont généralement difficiles à transformer en données d’entraînement exploitables par un modèle.

Par exemple, même le meilleur DBA serait incapable d’écrire une requête correcte pour suivre les ventes de chaussures s’il ne savait pas que, dans la table pcat_extension, la valeur cat_id2 = 'Footwear' correspond à une chaussure. Il en va de même pour les LLM !

Problème n°2 : comprendre l’intention de l’utilisateur

Le langage naturel est moins précis que le langage SQL. Un data-engineer ou un data-analyst confronté à une question ambiguë saura détecter qu’il lui manque des informations et posera les bonnes questions pour clarifier le problème. Un LLM, en revanche, a tendance à vouloir fournir une réponse coûte que coûte, et face à une question ambiguë, il peut être sujet aux hallucinations.

Exemple : prenons une question comme « Quelles sont les chaussures les plus vendues ? » L’ambiguïté de la question saute aux yeux : que signifie exactement « les plus vendues » dans le contexte de l’entreprise ou de l’application ? Est-ce qu’on parle des chaussures qui ont généré le plus de commandes ? De la marque qui a rapporté le plus de chiffre d’affaires ? Faut-il inclure les commandes retournées dans le calcul ? Et combien de modèles doit-on afficher dans le rapport ?

De plus, selon l’utilisateur, les attentes peuvent varier. Pour un data-analyst ou un développeur qui pose une question vague, une requête SQL approximative mais globalement pertinente peut constituer un bon point de départ, car ils sauront la corriger ou l’affiner. En revanche, pour un utilisateur moins technique qui ne connaît pas SQL, il est essentiel de fournir une requête précise et correcte dès le départ car contrairement aux acteurs expérimentés précédents, il n’a pas les compétences pour la vérifier et la modifier. En matière de « text-to-SQL », la clé est de pouvoir poser des questions de suivi pour lever les ambiguïtés, expliquer le raisonnement qui a mené à une réponse et guider l’utilisateur vers ce qu’il cherche réellement.

Problème n°3 : les limites de la génération par LLM

De base, les LLM excellent dans des tâches comme la rédaction créative, le résumé ou l’extraction d’informations à partir de documents. Mais certains modèles ont plus de mal à suivre des instructions précises et à restituer les détails avec exactitude, en particulier lorsqu’il s’agit de fonctionnalités SQL peu usitées. Pour produire du SQL correct, le LLM doit s’en tenir strictement à des spécifications qui peuvent rapidement devenir complexes.

Exemple : prenons les différences entre les dialectes SQL, souvent plus subtiles que celles qui existent entre des langages de programmation comme Python et Java. Typiquement, en BigQuery SQL, la fonction correcte pour extraire un mois à partir d’une colonne de type timestamp est : EXTRACT(MONTH FROM timestamp_column. Mais en MySQL, on utilise : MONTH(timestamp_column).

Les techniques Text-to-SQL

Chez Google Cloud, nous faisons évoluer en permanence nos agents « text-to-SQL » afin d’en améliorer la qualité. Pour répondre aux problèmes évoqués plus haut, nous mettons en œuvre un ensemble de techniques.

Déchiffrons ensemble certaines de ces techniques :

Modèles « SQL-aware »
Nos solutions text-to-SQL reposent sur les puissants modèles de la famille de LLM Gemini 2.5. Celle-ci a déjà largement fait ses preuves en matière de génération de code et de SQL de haute qualité. Selon la tache de génération de code SQL, nous combinons différentes versions de modèles. Dans certains cas, nous appliquons même un fine-tuning personnalisé au modèle, afin d’obtenir un SQL fiable pour un dialecte donné par exemple.

Résolution des ambiguïtés grâce aux LLM
La levée d’ambiguïtés consiste à amener le système à répondre par une question demandant une clarification lorsqu’il est confronté à une requête trop vague. Par exemple, à la question « Quelle est la chaussure la plus vendue ? », l’agent text-to-SQL va réagir par une relance du type : « Voulez-vous voir les chaussures classées par nombre de commandes ou par chiffre d’affaires ? ».
Dans la pratique, nous orchestrons généralement les appels au LLM de façon à d’abord vérifier si une question peut réellement recevoir une réponse avec le schéma et les données disponibles. Si ce n’est pas le cas, le modèle génère alors les questions complémentaires nécessaires pour clarifier l’intention de l’utilisateur.

Recherche et in-context learning (apprentissage contextuel)
Comme mentionné plus haut, fournir aux modèles le contexte nécessaire pour générer du SQL est essentiel. Nous utilisons pour cela différentes techniques d’indexation et de recherche : d’abord pour identifier les jeux de données, tables et colonnes pertinents (généralement via une recherche vectorielle avec appariement sémantique en plusieurs étapes), puis pour charger du contexte supplémentaire utile. Selon le produit, cela peut inclure des éléments comme des annotations de schéma fournies par l’utilisateur, des exemples de requêtes SQL similaires, l’application de règles métier spécifiques, ou encore des échantillons de requêtes récentes exécutées par l’utilisateur sur les mêmes jeux de données. Toutes ces informations sont ensuite organisées dans des prompts soumis au modèle. Grâce à ses fenêtres de contexte étendues, Gemini peut prendre en charge des schémas volumineux ainsi qu’un grand nombre d’informations contextuelles, ce qui lui permet d’aller beaucoup plus loin dans le traitement du contexte.

Validation et reprompting
Même avec un modèle de haute qualité, la génération de code SQL par un LLM conserve une part de non-déterminisme et donc d’imprévisibilité. Pour y remédier, nous avons constaté que des approches non basées sur l’IA — comme l’analyse syntaxique de la requête ou l’exécution à blanc (dry run) du SQL généré — complètent efficacement les workflows de génération de code SQL pilotés par modèles. Ces techniques fournissent un signal clair et déterministe indiquant si le LLM a omis un élément crucial. Ce signal est ensuite renvoyé au modèle pour une seconde passe. Lorsqu’on lui fournit un exemple d’erreur accompagné de quelques indications, le modèle est généralement capable de corriger ce qu’il avait mal généré.

Contrôle de cohérence automatique
Le principe de contrôle automatique de cohérence repose sur l’idée de ne pas se contenter d’une seule réponse du modèle. Concrètement, le système génère plusieurs requêtes SQL pour une même question utilisateur, en variant les techniques de prompting et/ou les versions de modèles utilisées. Il compare ensuite les différentes réponses afin d’identifier celle qui semble la plus fiable et la plus pertinente. Lorsque plusieurs modèles, ou versions d’un même modèle, convergent vers le même résultat, les chances que la réponse soit correcte et qu’elle corresponde à ce que recherche l’utilisateur augmentent nettement.

Evaluer et mesurer les améliorations

L’amélioration de la génération de code SQL pilotée par l’IA repose sur une évaluation robuste. Les benchmarks text-to-SQL développés par la communauté académique — comme le très répandu BIRD-bench — fournissent une base de référence précieuse pour évaluer la performance des modèles et du processus complet de génération de code SQL.

Cependant, ces benchmarks montrent leurs limites dès qu’il s’agit de représenter la diversité des schémas et des workloads rencontrés en conditions réelles. Pour dépasser ces limites, nous avons développé notre propre suite de benchmarks dits synthétiques : des scénarios de tests construits avec des jeux de données fictifs, conçus pour simuler la complexité et la variété du monde réel. Ils enrichissent et complètent la base de référence fournie par les benchmarks académiques.

Couverture : nous nous assurons que nos benchmarks couvrent un large éventail de moteurs et de produits SQL, aussi bien les dialectes que les fonctionnalités propres à chaque moteur. Ils incluent non seulement les requêtes classiques, mais aussi le DDL, le DML et d’autres tâches d’administration de la base. Les benchmarks intègrent également des questions représentatives des usages courants, jusqu’aux requêtes et schémas plus complexes que l’on rencontre dans des environnements réels.

Métriques : nous combinons des métriques observées en conditions réelles (usages) et des métriques mesurées en laboratoire (benchmarks). Nous faisons appel à la fois à l’évaluation humaine et à l’évaluation automatisée — en particulier via les techniques de type LLM-as-a-judge, qui réduisent les coûts tout en permettant d’évaluer les performances sur des tâches ambiguës ou mal définies.

Évaluations continues : nos équipes d’ingénierie et de recherche utilisent ces évaluations pour tester rapidement de nouveaux modèles, de nouvelles techniques de prompting et d’autres améliorations. Elles nous fournissent des signaux rapides indiquant si une approche est prometteuse et mérite d’être poursuivie.

Ensemble, ces différentes techniques sont à l’origine de progrès remarquables réalisés dans le domaine du Text-to-SQL. Progrès que nous constatons aussi bien dans nos laboratoires que dans les environnements de nos clients. Si vous vous préparez à intégrer du Text-to-SQL dans vos propres systèmes, ne manquez pas nos prochains articles qui approfondiront à la fois le sujet et l’utilisation de nos propres solutions. En attendant, vous pouvez d’ores et déjà tester les capacités de Gemini Text-to-SQL dans BigQuery Studio, CloudSQL, AlloyDB et Spanner Studio, ainsi que dans AlloyDB AI. Vous allez voir, c’est bluffant…