Dial: A Knowledge-Grounded Dialect-Specific NL2SQL System

Le papier présente Dial, un système NL2SQL ancré dans des connaissances qui améliore la génération de requêtes pour des dialectes SQL hétérogènes grâce à une planification logique adaptée, une base de connaissances hiérarchique et une boucle de débogage exécutée, surpassant ainsi les méthodes existantes sur un nouveau benchmark multi-dialectes.

L'essentiel

Imaginez que vous êtes un chef cuisinier très talentueux (c'est l'Intelligence Artificielle) capable de créer de délicieux plats à partir de n'importe quelle recette écrite en langage naturel. Cependant, il y a un problème : vos clients ne mangent pas tous dans le même restaurant, et chaque restaurant a ses propres règles de cuisine, ses propres ustensiles et même ses propres interdits.

• Le Restaurant A (MySQL) accepte que vous jetiez tous les ingrédients dans une grande marmite.
• Le Restaurant B (Oracle) exige que vous utilisiez des casseroles spécifiques et interdit d'utiliser certains ingrédients si vous n'avez pas de permission spéciale.
• Le Restaurant C (PostgreSQL) veut que vous épluchiez les légumes avant de les couper, sinon il refuse de vous servir.

Jusqu'à présent, les systèmes qui traduisent le langage humain en requêtes de bases de données (ce qu'on appelle NL2SQL) agissaient comme un chef qui connaissait parfaitement le menu du Restaurant A, mais qui essayait de cuisiner pour le Restaurant B en utilisant les mêmes règles. Résultat ? Le plat était soit rejeté par le chef de cuisine (erreur de syntaxe), soit il était comestible mais avait un goût terrible (résultat incorrect).

Voici comment Dial, le système présenté dans cet article, résout ce problème de manière ingénieuse.

1. Le Plan de Cuisine Universel (NL-LQP)

Au lieu de demander au chef de cuisiner directement, Dial lui fait d'abord rédiger un plan de cuisine logique en langage humain, sans se soucier des règles du restaurant.

• L'analogie : Au lieu de dire "Coupez 3 oignons avec le couteau suisse", le chef écrit : "Préparer la base de légumes".
• Pourquoi c'est génial : Cela sépare l'intention du client ("Je veux voir les 10 employés les mieux payés") de la technique spécifique ("LIMIT 10" pour MySQL vs "FETCH FIRST 10 ROWS" pour Oracle). Le chef sait quoi faire, mais pas encore comment le faire dans ce restaurant précis.

2. Le Grand Livre de Recettes Adapté (HINT-KB)

C'est le cœur du système. Dial ne se fie pas à la mémoire du chef (qui peut se tromper ou halluciner). Il utilise une bibliothèque de connaissances ultra-organisée, construite à partir des manuels officiels de chaque restaurant.

Ce livre est divisé en trois sections :

• La section "Outils" : Elle dit : "Si tu veux couper des oignons dans le Restaurant Oracle, utilise le couteau X, pas le couteau Y."
• La section "Règles cachées" : Elle explique les pièges invisibles. Par exemple : "Attention, dans le Restaurant Oracle, si tu demandes une liste, tu ne peux pas trier par un nom qui n'est pas dans ta liste finale."
• La section "Exemples" : Elle montre des plats réussis et des échecs cuisants pour que le chef apprenne par l'exemple.

3. Le Contrôleur de Qualité et le Mécanicien (Debugging Itératif)

Même avec un bon plan et un bon livre, le chef peut faire une erreur de détail. Dial ne se contente pas de servir le plat. Il lance un processus de vérification en boucle :

1. Essai : Le chef prépare le plat selon le plan et le livre de recettes.
2. Test : Le plat est envoyé en cuisine. Si le chef de cuisine du restaurant crie "Erreur !", Dial ne demande pas simplement au chef de réessayer au hasard.
3. Diagnostic : Dial regarde l'erreur, consulte le "Grand Livre" pour trouver la règle exacte qui a été violée, et dit au chef : "Tu as utilisé 3 arguments pour la fonction CONCAT, mais Oracle n'en accepte que 2. Corrige ça."
4. Apprentissage : Une fois le plat réussi, Dial note cette correction dans le livre pour que le chef ne refasse jamais la même erreur.

Pourquoi est-ce une révolution ?

Imaginez un traducteur qui ne se contente pas de traduire mot à mot, mais qui comprend la culture de chaque pays.

• Les anciens systèmes (comme les traducteurs automatiques basiques) prenaient une phrase en français et la traduisaient en anglais en utilisant des règles fixes. Si le français avait une expression idiomatique, la traduction était souvent absurde.
• Dial, lui, comprend d'abord l'idée, puis cherche la meilleure façon de l'exprimer dans la langue cible, en vérifiant à chaque étape que cela a du sens pour le locuteur natif.

Les Résultats

En testant ce système sur six grands "restaurants" (bases de données comme Oracle, MySQL, PostgreSQL, etc.), les chercheurs ont constaté que :

• Le système réussit beaucoup plus souvent à faire fonctionner les requêtes (moins d'erreurs de syntaxe).
• Il utilise les fonctions spécifiques de chaque base de données (comme un vrai expert local) plutôt que des solutions génériques et lourdes.
• Il s'améliore tout seul en apprenant de ses erreurs passées.

En résumé : Dial est comme un chef étoilé qui, au lieu d'improviser, consulte un guide de cuisine local précis, vérifie chaque plat avant de le servir, et apprend de chaque erreur pour devenir le meilleur cuisinier possible, quel que soit le restaurant où il travaille.

Résumé technique

Voici un résumé technique détaillé de l'article "Dial: A Knowledge-Grounded Dialect-Specific NL2SQL System" en français.

1. Problématique

Les entreprises déploient souvent des systèmes de bases de données hétérogènes (Oracle, PostgreSQL, MySQL, SQL Server, etc.), chacun possédant son propre dialecte SQL avec des règles de syntaxe, des fonctions intégrées et des contraintes d'exécution distinctes.

Le problème central identifié est que la plupart des méthodes existantes de NL2SQL (Natural Language vers SQL) supposent un dialecte unique (souvent SQLite ou MySQL) et échouent à générer des requêtes qui sont à la fois sémantiquement correctes et exécutables sur les moteurs cibles. Les approches actuelles souffrent de trois limitations majeures :

• Couplage fort : Les méthodes basées sur l'incitation (prompting) lient trop étroitement le raisonnement d'intention à la syntaxe du dialecte, entraînant des hallucinations (ex: utiliser LIMIT sur Oracle qui ne le supporte pas).
• Dégradation des opérateurs : Les traducteurs basés sur des règles ou des représentations intermédiaires génériques remplacent souvent les opérateurs natifs performants par des constructions verbeuses ou incorrectes.
• Interférence croisée : Le fine-tuning multi-dialectes sur un seul modèle provoque une interférence négative entre les dialectes, réduisant la capacité du modèle à respecter les contraintes spécifiques à chaque moteur.

2. Méthodologie : Le Framework Dial

Pour surmonter ces défis, les auteurs proposent Dial, un cadre ancré sur la connaissance (knowledge-grounded) qui découple la modélisation de l'intention logique de la réalisation syntaxique spécifique au dialecte. L'architecture repose sur trois piliers principaux :

A. Planification de Requêtes Logiques Consciente du Dialecte (Dialect-Aware Logical Query Planning)

Cette étape transforme la question naturelle en un Plan de Requêtes Logiques en Langage Naturel (NL-LQP).

• Décomposition : La requête utilisateur est décomposée en une chaîne linéaire d'opérateurs logiques standardisés (ex: Data Sourcing, Filtering, Scalar Calculation, Aggregation).
• Spécification : Un module identifie les opérateurs sensibles au dialecte et les associe à des catégories fonctionnelles standardisées. Cela permet de séparer la logique métier (ce qu'il faut faire) de la syntaxe SQL (comment le faire selon le dialecte).

B. Base de Connaissance Hiérarchique Intentionnelle (HINT-KB)

Dial utilise une base de connaissances structurée, HINT-KB, construite automatiquement à partir de la documentation officielle des fournisseurs. Elle est divisée en deux dépôts :

1. Dépôt de Fonctions Déclaratives (Declarative Function Repository) : Mappe les intentions abstraites (ex: "calculer la différence de dates") vers des implémentations spécifiques au dialecte (ex: TIMESTAMPDIFF pour MySQL, AGE pour PostgreSQL) avec des signatures et contraintes explicites.
2. Dépôt de Contraintes Procédurales (Procedural Constraint Repository) : Encode les règles implicites de compilation (ex: règles de citation des mots-clés réservés, contraintes ORDER BY sous DISTINCT). Ces règles sont indexées par des signatures d'erreurs de diagnostic.

C. Débogage et Vérification Itératifs Pilotés par l'Exécution

Le système génère la requête SQL et entre dans une boucle de correction fermée :

• Récupération de règles : Si une erreur d'exécution survient, le message d'erreur est utilisé pour récupérer une règle de transformation spécifique dans HINT-KB.
• Vérification Sémantique : Une fois la requête exécutable, elle est audité par rapport au NL-LQP original pour s'assurer qu'aucune dérive sémantique (changement de logique métier) ne s'est produite lors de la correction syntaxique.
• Consolidation : Les corrections validées sont réintégrées dans HINT-KB, permettant au système d'apprendre continuellement.

3. Contributions Clés

1. Framework Dial : Une architecture qui découple l'intention logique de la réalisation dialectale, permettant une exécution native sans réentraînement du modèle.
2. HINT-KB : Une architecture de connaissances hiérarchique ancrée sur les primitives ANSI SQL, séparant la syntaxe fonctionnelle des contraintes de compilation implicites.
3. NL-LQP : Une abstraction d'opérateurs logiques strictement linéarisée et agnostique au dialecte, normalisant les intentions utilisateur.
4. Pipeline de Spécification Divergente : Un mécanisme pour isoler les opérateurs sensibles et les mapper vers une taxonomie fonctionnelle standardisée.
5. DS-NL2SQL : Un nouveau benchmark de référence couvrant six systèmes de bases de données majeurs avec 2 218 cas de test spécifiques aux dialectes.

4. Résultats Expérimentaux

Les expériences ont été menées sur le benchmark DS-NL2SQL couvrant six dialectes (SQLite, PostgreSQL, MySQL, SQL Server, DuckDB, Oracle).

• Précision de Traduction : Dial améliore la précision de traduction globale de 10,25 % par rapport aux meilleures méthodes de référence (baselines).
• Couverture des Fonctionnalités : L'adoption des fonctionnalités spécifiques aux dialectes (DFC) augmente de 15,77 %.
• Exécutabilité : Dial atteint un taux d'exécutabilité global de 97,33 %, surpassant significativement les approches de fine-tuning (qui souffrent de surapprentissage sur un dialecte) et les traducteurs basés sur des règles (qui échouent sur les contraintes implicites).
• Robustesse : Contrairement aux autres méthodes qui chutent drastiquement sur des dialectes complexes comme Oracle (ex: EXESQL tombe à 5,50 % d'exécutabilité), Dial maintient des performances élevées (>99 %) grâce à son mécanisme de récupération de connaissances externes.

5. Signification et Impact

L'article Dial représente une avancée significative pour l'adoption de l'IA dans les environnements d'entreprise réels, où l'hétérogénéité des bases de données est la norme.

• Dépassement des limites actuelles : Il résout le problème de la "dérive sémantique" lors de la correction d'erreurs syntaxiques, un problème majeur des approches purement basées sur les LLM.
• Évolutivité : La construction automatisée de HINT-KB permet d'ajouter facilement de nouveaux dialectes ou de mettre à jour les règles sans réentraîner le modèle de fondation.
• Fiabilité : En séparant la logique de la syntaxe, Dial garantit que les requêtes générées respectent non seulement les règles de compilation du moteur cible, mais aussi l'intention exacte de l'utilisateur, rendant le système prêt pour des déploiements critiques.

En résumé, Dial propose une approche hybride robuste combinant la puissance des LLM pour la compréhension sémantique et la rigueur des bases de connaissances structurées pour la conformité dialectale, comblant ainsi le fossé entre la recherche NL2SQL et les besoins pratiques des entreprises.