Pourquoi le Text-to-SQL échoue en entreprise
La plupart des démos de Text-to-SQL sont trop simplistes.
Elles utilisent des schémas simples et des noms de tables évidents. Elles partent du principe qu'une ou deux tables se lient parfaitement. Cela fonctionne pour une démo. Cela échoue dans une véritable entreprise.
Dans les bases de données d'entreprise, la difficulté ne réside pas dans la clause SELECT. La difficulté réside dans le chemin de jointure.
Un modèle peut écrire une requête valide pour le chiffre d'affaires par client. Le SQL s'exécute. Le tableau de bord affiche des chiffres. Mais la réponse est fausse.
Pourquoi cela arrive-t-il ?
- La table client n'est pas la liste maîtresse officielle.
- Le champ du chiffre d'affaires n'est pas la version approuvée par la finance.
- Les enregistrements sont dupliqués entre les régions.
- La jointure crée des erreurs de fanout.
- Les calendriers fiscaux diffèrent des années civiles.
Une requête syntaxiquement valide n'est pas une requête fiable.
Les systèmes de production réels sont désordonnés. Vous faites face à des clés étrangères manquantes, des tables legacy et des relations de un à plusieurs qui gonflent les chiffres. Même les humains doivent vérifier les anciens rapports ou consulter la finance avant de faire confiance à une jointure.
Un modèle d'IA ne voit que des noms et des colonnes. Il devine. Parfois, la supposition est dangereuse.
Considérez le fanout. Si vous joignez les commandes aux lignes de commande, puis aux expéditions, une commande peut être comptabilisée plusieurs fois. Le SQL est correct. Le résultat est faux.
Les métadonnées aident, mais elles ne suffisent pas. Les noms de colonnes ne vous indiquent pas si une relation est sûre pour le reporting financier. Les clés étrangères n'expliquent pas les exceptions historiques.
Le Text-to-SQL a besoin d'une intelligence relationnelle.
Un système fiable doit connaître :
- Les chemins de jointure approuvés pour des questions métier spécifiques.
- La cardinalité des relations.
- Les risques de fanout connus.
- Quels chemins sont obsolètes.
Au lieu de simplement écrire du code, le système devrait raisonner sur la sécurité. Il devrait choisir le chemin de confiance ou demander de l'aide lorsque les chemins ne sont pas clairs.
La lacune des systèmes actuels est le saut entre le mappage des noms et la génération de SQL. Vous devez ajouter une couche de contexte relationnel.
Le Text-to-SQL n'est pas seulement un problème de langage. C'est un problème de contexte.
Tant que les modèles ne comprendront pas quelles jointures sont sûres, ils fonctionneront dans les démos mais échoueront en production.
Source: https://dev.to/arisyndata/why-text-to-sql-breaks-when-the-join-path-is-not-obvious-3bk0
Communauté d'apprentissage optionnelle: https://t.me/GyaanSetuAi