- Les fonctionnalités de text-to-SQL basées sur Gemini sont utilisées dans l’ensemble de Google Cloud pour améliorer la productivité des développeurs comme des utilisateurs non techniques
- En conditions réelles, il est difficile de générer un SQL précis en raison du manque de contexte métier, de la difficulté à interpréter l’intention de l’utilisateur et des différences entre dialectes SQL
- Pour y remédier, Google introduit notamment des techniques de recherche intelligente de données, d’apprentissage en contexte et de structuration sémantique
- Les limites propres au modèle sont compensées par la génération multiple suivie d’une sélection optimale (self-consistency), la re-sollicitation après validation et l’apprentissage par dialecte SQL
- L’évaluation et la mesure des améliorations s’appuient sur des benchmarks internes et sur l’approche LLM-as-a-judge, afin d’accroître la pertinence en environnement réel
Techniques for improving text-to-SQL
Du texte vers SQL : état des lieux chez Google Cloud
- Les organisations utilisent SQL pour obtenir rapidement et précisément des insights sur leurs données
- Gemini propose une fonctionnalité de text-to-SQL qui génère directement du SQL à partir du langage naturel
- Cette fonctionnalité est utile non seulement pour les développeurs, mais aussi pour les utilisateurs non techniques
- Elle est actuellement disponible dans BigQuery Studio, Cloud SQL Studio, AlloyDB Studio, Vertex AI, etc.
Principaux défis de la technologie text-to-SQL
1. Difficulté à fournir le contexte métier
- Pour écrire un SQL précis, il faut fournir au LLM un contexte suffisant, comme la structure de la base de données, la signification des colonnes et le contenu réel des données
- Le contexte comprend à la fois des informations explicites (schéma, informations sur les colonnes, etc.) et implicites (comme la signification métier de certaines données)
- Une approche consistant à réentraîner en continu le LLM (fine-tuning) pour suivre l’évolution des structures de base de données, des jeux de données ou des schémas est, en pratique, très coûteuse
- Les connaissances métier ou les informations sémantiques sont souvent mal structurées, et leur transformation en données d’entraînement reste difficile
- Exemple : si un DBA ne connaît pas la signification de
cat_id2 = 'Footwear' dans la table pcat_extension, il ne pourra pas non plus écrire une requête SQL pour consulter les ventes de chaussures — un LLM court le même risque de générer une requête inexacte lorsqu’il manque de contexte
2. Problème d’interprétation de l’intention de l’utilisateur
- Les requêtes en langage naturel manquent souvent de clarté, comparées au SQL
- Un analyste de données ou un ingénieur peut poser des questions complémentaires lorsqu’une demande est ambiguë, mais un LLM tend à répondre directement à la question fournie, ce qui crée un risque de hallucination
- Dans une question comme « Quelles sont les chaussures les plus vendues ? », les critères de « plus vendues » (nombre de commandes, chiffre d’affaires, etc.) ou le nombre de résultats restent ambigus
- Un utilisateur technique peut partir d’un SQL approximatif, mais pour un non-spécialiste, il est plus important d’obtenir un SQL correct et exécutable
- Pour fonctionner efficacement, le LLM doit pouvoir prendre en charge les questions de suivi, les explications de raisonnement et le guidage utilisateur afin de clarifier l’intention réelle
3. Limites de génération des LLM
- Les LLM excellent dans des tâches comme le résumé de documents ou l’extraction d’informations, mais restent plus faibles sur la syntaxe SQL exacte ou sur des fonctionnalités SQL peu courantes
- La syntaxe diffère selon les dialectes SQL, et même de petites variations exigent une très grande précision
- Exemple : dans BigQuery, on utilise
EXTRACT(MONTH FROM timestamp_column), tandis qu’en MySQL il faut écrire MONTH(timestamp_column)
- Générer du SQL en respectant de façon constante des spécifications complexes reste une tâche difficile pour les LLM
Techniques d’amélioration du text-to-SQL chez Google Cloud
Problème : schéma et contexte métier
- Recherche et classement fondés sur la sémantique
- Apprentissage en contexte
- Échantillonnage et liaison des données
- Construction d’une couche sémantique
- Analyse des usages et de l’historique
Problème : interprétation de l’intention utilisateur
- Clarification via LLM
- Identification des entités, vérification des informations pertinentes puis génération de questions de suivi appropriées
Problème : dépasser les limites des LLM
- Self-consistency avec génération de plusieurs requêtes puis sélection de la meilleure
- Validation et re-prompting
- Apprentissage en contexte avec des exemples incluant les dialectes SQL
- Fine-tuning du modèle
Exemples concrets d’application technique
Modèles SQL-aware
- Gemini utilise plusieurs versions fine-tunées pour produire du SQL de haute qualité
- Pour garantir la précision selon les dialectes SQL, Google combine différentes versions de modèles et effectue des ajustements sur mesure
Clarification des questions utilisateur (Disambiguation)
- Lorsque la question est ambiguë, le système génère une question de clarification
- Exemple : « Les chaussures les plus vendues ? » → « Par nombre de commandes ou par chiffre d’affaires ? »
Recherche sémantique et construction du contexte
- Une recherche vectorielle fondée sur une correspondance sémantique en plusieurs étapes permet d’identifier les tables et colonnes pertinentes
- Le prompt est construit en incluant l’historique des requêtes utilisateur, des exemples de règles métier, etc.
- La prise en charge de longues fenêtres de contexte permet de traiter des schémas de grande taille
Validation et régénération
- Le parsing et le dry-run des requêtes générées par le LLM permettent de détecter explicitement les erreurs
- Lorsqu’une erreur est détectée, un nouveau prompt est envoyé pour guider la correction
Self-consistency
- Au lieu d’une seule requête, le système génère plusieurs requêtes selon différentes approches
- Lorsque plusieurs modèles recommandent la même requête, la précision augmente
Évaluation et mesure des performances
- Les benchmarks existants (comme BIRD-bench) sont utiles, mais présentent des limites pour refléter les schémas réels
- Google a construit son propre ensemble de benchmarks synthétiques
Stratégie d’évaluation
- Couverture des dialectes SQL et des fonctions propres aux moteurs : inclut non seulement les requêtes, mais aussi DDL, DML et les tâches d’administration
- Indicateurs d’évaluation : réactions des utilisateurs, métriques offline, LLM-as-a-judge
- Évaluation continue : permet de vérifier rapidement l’efficacité de nouveaux modèles et de nouvelles techniques de prompt
Conclusion
1 commentaires
Commentaires sur Hacker News
Je m’interroge sur l’objectif ultime du passage du texte au SQL : s’agit-il de créer un assistant pour les analystes de données, ou de permettre d’obtenir des insights business sans passer par un analyste ? Si c’est la seconde option, alors même avec un système très avancé, il reste impossible pour un non-spécialiste de juger si le SQL est correct et suffisant. Des questions comme « Pourquoi les transactions e-commerce d’hier n’ont-elles atteint que 80 % ? », « Pourquoi le coût d’acquisition client augmente-t-il ? » ou « Pourquoi la campagne de New York fonctionne-t-elle moins bien que celle de San Francisco ? » sortent du cadre du text2sql.
En pratique, on est sans doute plus proche du second objectif, mais les résultats ne sont pas à la hauteur des attentes. En entreprise, on veut souvent modifier les rapports au dernier moment, mais faute d’analystes, on n’obtient pas l’information souhaitée à temps. On essaie de résoudre cela avec une « vitesse infinie », alors qu’en réalité le problème vient du fait qu’on ne réfléchit pas assez aux métriques. Les données sont complexes, la connaissance métier est stockée de manière implicite à l’extérieur, et l’infrastructure data est insuffisante, ce qui rallonge les analyses. Les bons responsables analytics profitent de la vague IA pour investir dans l’infrastructure de base.
À mon avis, les questions ci-dessus ne sont de toute façon pas des problèmes qu’on peut résoudre en SQL. Le SQL répond surtout à la question du « quoi » (
what), pas à celle du « pourquoi » (why). L’objectif du text2sql est de faire gagner du temps aux analystes sur le « quoi », afin qu’ils puissent se concentrer sur le « pourquoi ».C’est vrai, mais à mon avis le texte en langage naturel peut devenir l’entrée universelle des systèmes à base de LLM. Le text2sql peut servir de socle de recherche d’information pour construire des réponses à des questions plus complexes. À court terme, c’est une aide au travail ; à long terme, l’objectif est de poser les bases de l’automatisation, de la comparaison des résultats et de l’intégration dans des workflows plus larges. L’essentiel est de construire la base permettant de répondre à ce type de questions. Il reste encore beaucoup à faire.
Tout algorithme peut être conçu et testé si un humain est capable d’effectuer la tâche. Si vous avez 10 analystes, ils auront tous un niveau différent de compréhension de la base de données, du métier et des compétences générales. L’automatisation fournit au moins un standard garantissant un niveau minimal de compétence et de connaissance. Même un nouvel analyste peut produire de meilleurs résultats immédiatement. Développer le système en collaboration avec des experts, le tester, et amener l’IA à interpréter les arbitrages, les bugs et les résultats attendus en comparaison des résultats effectifs est un objectif utile. Il est difficile d’automatiser l’intuition ou le « goût », mais avec une automatisation bien conçue par des experts métier et un sens raisonnable de ce qu’est un bon résultat, on peut aller très loin. Ce n’est pas parfait, mais c’est mon objectif.
Retour d’expérience avec le modèle OpenAI 4o : on lui fournit dans le prompt des consignes métier, la terminologie du secteur, ainsi que la description des tables et des clés étrangères. Il peut alors générer même des requêtes de jointure complexes et renvoyer les résultats. L’objectif était de fournir des résultats à des utilisateurs ne connaissant pas le SQL, mais on affiche aussi le SQL lui-même à titre de référence.
L’IA n’a pas besoin de générer un SQL parfait. Dans mon cas, même si la sortie peut être validée par du code, je ne la copie pas telle quelle à cause du risque de nuances sémantiques. En revanche, si l’IA me propose une approche, je m’en inspire pour écrire moi-même le SQL depuis zéro.
Retour d’expérience avec le dernier Gemini de Google AI Studio : c’est franchement impressionnant et révolutionnaire. Les résultats de Claude et ChatGPT en code donnent l’impression de venir d’un autre siècle. Il y a à peine un mois, je trouvais Claude extraordinaire, mais maintenant je ne vois pas comment je pourrais continuer à coder sans Google Gemini. Gemini AI Studio représente un bond gigantesque pour la programmation.
Je suis surpris que plus de gens n’aient pas encore pris conscience de ce changement. Claude gère bien les petites tâches, mais dès qu’on passe à des problèmes complexes, Gemini est nettement supérieur. Sa gestion du contexte est particulièrement impressionnante. Je ne l’utilise pas seulement comme agent de code : j’utilise aussi Gemini pour faire une bêta-lecture d’un manuscrit de 85 000 mots, et je reçois un rapport de retours de niveau expert presque en temps réel.
Cette semaine, j’ai eu l’impression qu’ils avaient désactivé le mode raisonnement sur Gemini Pro gratuit. Si on l’empêche de s’arrêter juste avant d’écrire le code ou de trop généraliser, c’est assez utile. En revanche, Gemini a tendance à surécrire le code. Ma façon principale de l’utiliser consiste à m’en servir pour explorer des choix de conception sans me bloquer sur l’implémentation. Par exemple, dans le cas de la création d’un service d’abonnement avec Stripe, j’ai pu recevoir des données existantes contextualisées selon ma stack technique et mon cas d’usage, et changer d’orientation de conception avant même d’écrire une seule ligne de code.
La réponse, c’est « utiliser une semantic layer ». C’est le moyen le plus efficace de transmettre le bon contexte, et le meilleur point d’intervention pour un humain. Si une personne définit clairement tous les indicateurs clés, le LLM peut ensuite les exploiter à tout moment. Par exemple, si MAU est défini, le LLM générera les requêtes à partir de cette définition. Si on écrit les requêtes en JSON plutôt qu’en SQL, le LLM produit des résultats bien plus cohérents. Nous utilisons cube, qui est la meilleure semantic layer open source. Il existe aussi des options closed source chez Naver. Mon ancienne entreprise avait aussi publié un article de blog sur le sujet, mais la société propriétaire a depuis arrêté de l’héberger.
En usage réel, créer du SQL avec l’IA est risqué. Quelqu’un qui ne connaît pas le SQL peut écrire une mauvaise requête et avoir un impact sérieux sur le serveur. Dans notre équipe, la base de données est grande selon les standards de la plupart des développeurs, mais elle n’est pas réellement énorme. Même quand on demande parfois à une IA d’améliorer une requête déjà optimisée, elle ne nous a jamais donné mieux. Parfois, elle raconte n’importe quoi ou fait des suggestions inutiles en pratique. On a l’impression d’un perroquet stupide qui répète quelque chose qu’il a entendu auparavant.
Je pense qu’une fonction de conversion texte-vers-expression-régulière de l’IA serait vraiment pratique.
Parmi tous les outils IA que j’ai essayés, le plus décevant est Gemini intégré à BigQuery. Pourtant, les noms de colonnes sont clairs et bien documentés, mais il n’arrive absolument pas à approcher la résolution du problème.
Le langage dans lequel j’ai écrit le plus de requêtes jusqu’à présent, c’est le SQL. Même quand je demande à une IA d’écrire une requête, il me faut bien plus de temps pour retoucher le résultat que si je l’avais écrite moi-même. À côté de ça, il y a une fonctionnalité que j’aimerais vraiment avoir pour écrire du SQL beaucoup plus vite : dans le DSL de notre entreprise, il existe un opérateur qui fait automatiquement les jointures à partir des clés étrangères, et c’est extrêmement pratique. La partie la plus pénible quand on écrit du SQL, c’est de devoir taper manuellement 10, 20 jointures ou plus. À côté de ça, le reste n’est pas très difficile.
D’après mon expérience, presque tout se règle avec des contraintes claires et des clés étrangères bien définies. Il faut des contraintes explicites sur chaque table pour que l’IA puisse comprendre correctement toute la structure des relations. Le SQL a une spécification très précise, mais justement, si les contraintes et les clés étrangères ne sont pas bien définies, l’IA ne peut pas produire une réponse exacte.
C’est devenu assez simple avec tous les foundation models, tant que le schéma des tables est bien commenté. Il suffit alors de demander la génération de requêtes.
Si on construit un scaffolding autour du modèle avec la bibliothèque smolagents, cela devient assez pratique. Le text2sql semble simple en démo, mais il existe aussi des articles expliquant qu’il est très difficile d’appliquer cela à des cas réels complexes.
Étape 1 : le schéma contient des milliers de tables et presque aucun commentaire. Étape 2...
Je pense vraiment que c’est le cas. Il n’y a plus tellement de magie à ce stade. Le DDL de création des tables est en soi une description exacte des tables, donc il n’y a en réalité presque rien d’autre à ajouter. Tant qu’on décrit précisément la requête souhaitée, la plupart des LLM peuvent facilement la générer.
Dans le billet « Show HN: We open sourced our entire text-to-SQL product » (2024), les ressources mentionnées comme awesome-Text2SQL et Awesome-code-llm > Benchmarks > Text to SQL sont d’excellentes références.