Six tables sur 260 : le piège du choix de tables en texte vers SQL

Contexte

Les systèmes de texte vers SQL donnent l'impression de convertir directement le langage naturel en requêtes, mais le déploiement réel révèle une étape que peu d'ingénieurs documentent. Avant qu'un modèle ne produise le moindre SQL, il faut décider quelles tables il a le droit de voir. Une vraie base de données peut contenir 260 tables, et une fenêtre de prompt ne peut pas tout contenir, encore moins sans diluer l'attention du modèle ni faire grimler la latence et le coût. Le système doit donc filtrer vers un petit ensemble de tables candidates avant la génération.

Cette étape est presque toujours traitée comme un problème de récupération. Le schéma de chaque table est encodé en embedding vectoriel, la question de l'utilisateur interpelle ces embeddings, les résultats sont classés par similarité, et les six premières tables sont retenues. Ce pipeline suffit en environnement de démonstration, où les schémas sont rangés, bien nommés et propres. Les questions mappent directement sur les noms de tables, le taux de hit naturel reste élevé, et l'industry aQuietement supposé que le problème était résolu.

Analyse approfondie

L'auteur a perçu l'écart entre cette confiance de démo et cette fragilité de production, et a délibérément construit un schéma fait pour casser le mécanisme, y faisant tourner sa propre bibliothèque. Le résultat fut un chiffre de rappel qu'il aurait voulu ne pas publier, et qui s'est révélé être la découverte la plus précieuse. Le cœur du problème est que la pertinence de la récupération n'est pas la même chose que la justesse de la requête. Le choix de tables style RAG repose sur la similarité sémantique entre le texte de la question et le schéma, alors que SQL exige en réalité une accessibilité logique entre la table et l'intention de la requête.

Une table peut ne rien partager de son nom ou de ses champs avec une question tout en étant essentielle à sa réponse. Prenons une table nommée audit_log, servant la question sur combien d'utilisateurs ont changé leur mot de passe ce mois-ci. La vraie réponse peut dépendre d'un enregistrement dans user_actions où un champ est codé en dur comme action_type=7, tandis que les mots mot de passe et changer n'apparaissent jamais dans le schéma. La récupération par similarité de texte l'écarte sans hésiter. Inversement, une table dont le nom entre en collision avec un mot-clé peut n'être que du bruit. La situation empire avec les clés étrangères : les réponses correctes exigent souvent de joindre plusieurs tables, or la récupération Top-K note chaque table indépendamment, sans rien connaître de ses voisines, incapable donc de détecter des dépendances structurelles comme le besoin de sélectionner la table B avec la table A.

Impact sur l'industrie

Cette découverte ébranle une hypothèse implicite derrière un grand nombre de produits texte vers SQL existants. Pour les sociétés qui construisent des outils BI et d'analyse de données, le choix de tables est la porte amont qui détermine l'exactitude finale. Si cette porte échoue, aucune génération de SQL aval ni correction d'erreur ne peut récupérer, et l'utilisateur ne voit qu'un système incapable de répondre à des questions qu'il sait répondables, sans comprendre pourquoi.

Les petites entreprises et les équipes de outils internes sont particulièrement exposées, leurs bases de données portant souvent un nommage chaotique, un lourd passé historique et une sémantique hautement implicite, exactement les conditions où un schéma délibérément cassé excelle. L'écart entre performance de démo et expérience réelle devient éblouissant. Pour la communauté des développeurs, l'analyse reporte l'attention de la question de savoir si un modèle est assez gros ou comment rédiger un prompt, vers la préoccupation d'engineering plus fondamentale et moins étudiée de la récupération et de l'organisation des schémas elles-mêmes.

Perspectives

Plusieurs directions méritent surveillance. La plus importante est de savoir si les relations de join, les contraintes et l'information sur la distribution des valeurs de champs peuvent être intégrées à la récupération plutôt que de reposer uniquement sur la similarité de texte, ce qui pourrait être la clé pour briser le plafond actuel. Une deuxième question est de savoir si émergeront des benchmarks d'évaluation dédiés, utilisant des schémas-pièges délibérément construits pour mesurer le vrai plancher du rappel plutôt que de ne rapporter que des chiffres de démo attrayants. Une troisième est de savoir si la récupération hybride et le reranking peuvent genuinement traiter les dépendances structurelles, par exemple en filtrant grossièrement d'abord puis en étendant les relations via une structure de graphe.

Pour les équipes qui construisent ou sélectionnent un système texte vers SQL, le geste le plus pragmatique est de cesser de traiter les métriques de schéma de démo comme des conclusions. À la place, faire tourner le rappel de tables sur des données correspondant à la vraie complexité de sa propre base et observer comment l'exactitude bout-en-bout se dégrade quand les tables nécessaires ne sont simplement pas sélectionnées. Ce nombre dit souvent plus que n'importe quel benchmark de modèle.