text to sql bedrock workshop
Module 4: Security for Text-to-SQL
Les entrepôts de données d'entreprise représentent bon nombre des investissements technologiques les plus importants pour les entreprises de tous les secteurs au cours des 20 dernières années. Même si l’IA générative s’est montrée très prometteuse dans la création de contenus nouveaux et la compréhension de vastes corpus d’informations dans un format non structuré, comment améliorera-t-elle la consommation des données que les organisations ont tant investi pour les rendre utiles ? Ces sources de données sont parmi les plus fiables d’une organisation et guident dans de nombreux cas les décisions aux plus hauts niveaux de direction.
Depuis sa création dans les années 70, le langage SQL (Structure Query Language) est le langage le plus répandu pour interagir avec les bases de données, mais il faut encore une compréhension approfondie de la théorie des ensembles, des types de données et des relations entre clés étrangères afin de donner un sens aux données. . L'IA générative offre un moyen de combler ce manque de connaissances et de compétences en traduisant les questions en langage naturel en une requête SQL valide.
Les systèmes et les personnes susceptibles de bénéficier de ce modèle d'accès aux bases de données incluent les personnes non techniques cherchant à intégrer des sources de données relationnelles dans leur processus, comme les agents du service client et les associés des centres d'appels. En outre, les cas d'utilisation techniques incluent les pipelines Extract-Transform-Load, les architectures RAG (Retrieval Augmented Generation) existantes qui intègrent des bases de données relationnelles et les organisations qui ont affaire à une plate-forme de données trop volumineuse pour pouvoir raisonnablement naviguer de manière isolée.
Les composants les plus difficiles à créer pour créer une requête SQL précise à partir d’un langage naturel sont les mêmes que ceux avec lesquels nous aurions pu avoir du mal en tant que nouveaux arrivants dans ce langage. Des concepts tels que l'identification des relations de clé étrangère, la décomposition de la question en requêtes plus petites et imbriquées et la jointure correcte des tables comptent parmi les composants les plus difficiles de la génération de requêtes SQL. Selon les chercheurs, plus de 50 % des tests de génération SQL échouent uniquement sur les liaisons et les jointures de schéma.
En plus de ces composants essentiels de la requête, chaque moteur de base de données possède sa propre syntaxe qui peut justifier la maîtrise afin d'écrire une requête valide. En outre, dans de nombreuses organisations, il existe de nombreux attributs de données qui se chevauchent (une valeur est agrégée dans une table et non dans une autre, par exemple) ainsi que des noms de colonnes abrégés qui nécessitent des connaissances tribales pour être utilisés correctement.
Alors, à quel point sommes-nous près de résoudre ce problème ? La communauté s'est regroupée autour de deux classements principaux qui classent les approches les plus réussies avec un ensemble de données étiquetées : Spider et BIRD. Les deux classements donnent la priorité à la mesure la plus importante pour mesurer la précision de toute approche donnée pour résoudre ce problème, appelée Précision d'exécution (EX). Cette métrique compare simplement la requête SQL générée à la requête SQL étiquetée pour déterminer s'il s'agit d'une correspondance ou non. De plus, SPIDER mesure l'Exact Set Match Accuracy (EM) – l'ensemble de résultats renvoyé a-t-il réellement répondu à la question, quelle que soit la manière dont la requête a été écrite – et BIRD propose le Valid Efficiency Score (VES), une mesure de la performance de la requête SQL générée. Vous pouvez en savoir plus sur chaque ensemble de données de référence sur leurs pages respectives.
Les ensembles de données Spider et BIRD se sont révélés être des ensembles de données robustes et faisant autorité pour comparer les techniques Text-to-SQL et même pour affiner les modèles. Tout au long de ce module, nous ferons référence à ces ensembles de données et à leurs classements correspondants pour démontrer les approches les plus robustes de Text-to-SQL.
Selon le classement BIRD, l'état de l'art pour le problème Text-to-SQL se situe à 60 % de précision d'exécution. Bien que ce soit encore bien en deçà de la performance humaine, notez qu'en un an, nous sommes passés du modèle de base T5 performant à 7 % d'EM à un an plus tard, celui-ci a dépassé 60 %. Nous sommes ravis de voir comment cela s'améliorera encore au cours de l'année à venir, à mesure que les recherches sur ces modèles et techniques se poursuivront.
Il est important de noter que ces techniques sont optimisées pour une seule chose : générer la requête SQL correcte. Ces classements n'évaluent pas certains aspects critiques de ces techniques, notamment la vitesse. Beaucoup de ces techniques démontrent une vitesse de chaîne d’invites de bout en bout bien supérieure à quelques secondes, ce que de nombreux cas d’utilisation de business intelligence sans tir ne peuvent tolérer. De plus, beaucoup d’entre eux font également plusieurs inférences à un LLM pour compléter le raisonnement nécessaire, ce qui peut augmenter considérablement le coût par requête.
Cet atelier est conçu pour être une progression des techniques Text-to-SQL, en commençant par une ingénierie d'invite robuste. Tout le code est sous la forme de Jupyter Notebooks, hébergés dans SageMaker Studio. Lorsque vous êtes prêt à commencer, accédez à la configuration pour commencer le déploiement des ressources nécessaires à cet atelier.
Vous trouverez ci-dessous un aperçu du contenu de l'atelier :
