Comment créer un moteur Text2SQL de niveau production

L'interaction avec les bases de données nécessite souvent un niveau d'expertise technique qui peut mettre les données hors de portée de nombreuses personnes. Prenons l'exemple d'un responsable financier qui a besoin de comprendre les chiffres et les tendances financières de l'entreprise. Traditionnellement, ce responsable doit s'appuyer sur des analystes SQL pour extraire les données nécessaires de la base de données. Cette dépendance peut entraîner des retards et des problèmes de communication, en particulier si le responsable doit affiner ses requêtes plusieurs fois pour obtenir les informations souhaitées.

Mais text2SQL, une fonctionnalité qui convertit le langage naturel en instructions de langage de requête structuré, a changé la donne. Avec text2SQL, le responsable financier peut interagir directement avec la base de données en utilisant le langage naturel. Par exemple, un utilisateur peut saisir une question commerciale telle que « Quelle était la valeur moyenne des commandes de chaque client le mois dernier ? »

Le moteur d'IA Text-to-SQL traitera la question et générera la requête SQL correspondante :

Select customer_id, AVG(order_value) AS average_order_value FROM orders WHERE order_date >= DATE_SUB(CURRDATE(), INTERVAL 1 MONTH) GROUP BY customer_id;

Exécutez-le ensuite sur la base de données et affichez les résultats à l’utilisateur.

Dans cet article, nous expliquerons le rôle des LLM dans text2SQL, discuterons des défis inhérents à cette capacité et explorerons SherloQ, un moteur text2SQL hautement précis et robuste développé par l'équipe Skypoint .

Le rôle des LLM dans text2SQL

La capacité de conversion de texte en SQL s'est considérablement améliorée grâce aux grands modèles de langage (LLM). Ces modèles utilisent de grandes quantités de données et de puissantes architectures de réseaux neuronaux pour comprendre et générer du texte de type humain. En s'entraînant sur divers ensembles de données, les LLM peuvent généraliser à diverses tâches, y compris la traduction du langage naturel en requêtes SQL.

Par exemple, l'article « Les modèles linguistiques sont des apprenants à faible coût » montre comment les LLM peuvent effectuer des tâches avec un minimum d'exemples, soulignant leur capacité à s'adapter à de nouvelles tâches avec des données limitées. Cette approche réduit considérablement le besoin de données volumineuses spécifiques aux tâches, ce qui facilite le déploiement des LLM dans diverses applications.

Le projet « Spider : un ensemble de données à grande échelle étiqueté par l'homme pour l'analyse sémantique complexe et inter-domaines et la tâche de conversion de texte en SQL » fournit un ensemble de données complet pour la formation et l'évaluation de modèles sur des requêtes SQL complexes dans différents domaines. Cet ensemble de données a joué un rôle essentiel dans l'avancement de l'état de l'art de text2SQL en fournissant une référence robuste pour les performances des modèles.

De plus, « PALM : Scaling Language Modeling with Pathways » explore comment les techniques de formation avancées, telles que la mise à l'échelle des tailles de modèles et l'optimisation des parcours de formation, peuvent améliorer les performances des modèles dans diverses applications, y compris text2SQL.

Bien que ces LLM soient très efficaces dans des environnements contrôlés, ils sont souvent confrontés à des défis dans les environnements de production. Il s'agit notamment de gérer des invites ambiguës, de gérer des schémas de base de données complexes et de garantir des performances en temps réel. De plus, l'intégration de ces modèles dans des systèmes existants nécessite des efforts considérables et une maintenance continue pour s'adapter à l'évolution des données et des exigences des utilisateurs. Voici trois LLM qui fonctionnent bien pour cette tâche :

Codeur SQL

L'objectif principal de SQLcoder est de convertir les entrées en langage naturel en requêtes SQL. Contrairement aux autres modèles à usage général, SQLCoder a été affiné sur des données spécifiques à SQL, il est donc particulièrement efficace pour comprendre et générer des requêtes SQL. SQLCoder démontre une performance notable sur l'ensemble de données Spider, une référence complexe et inter-domaines pour les systèmes text2SQL.

SQLCoder génère la requête SQL correcte pour les nouveaux schémas non observés lors de la formation avec une précision de 64,6 % . Il surpasse GPT-3.5-turbo et text-davinci-003, qui sont des modèles plus de 10 fois plus grands. Cela met en évidence la capacité de SQLCoder à gérer des requêtes SQL diverses et complexes, ce qui est essentiel pour les environnements de production.

GPT 3,5/GPT 4

GPT-3.5 et GPT-4 (Generative Pre-trained Transformer) sont parmi les modèles de langage à usage général les plus avancés et les plus efficaces. Les deux modèles excellent dans l'apprentissage en quelques étapes, s'adaptant rapidement à de nouvelles tâches avec un minimum d'exemples, ce qui est idéal pour créer des requêtes SQL à partir d'entrées limitées.

Par exemple, lorsqu'il est évalué sur l'ensemble de données Spider, GPT-3.5-turbo présente un pourcentage de requêtes SQL correctement générées sur de nouveaux schémas non observés lors de la formation de 60,6 %, tandis que GPT-4 atteint 74,3 %.

Ces modèles présentent des performances robustes, notamment en termes de compréhension du contexte et de génération de requêtes SQL précises à partir d'entrées complexes en langage naturel. Cependant, leur conception à usage général nécessite parfois des ajustements supplémentaires pour obtenir des résultats optimaux dans des applications spécialisées comme la génération SQL.

PaLM SQL

PaLM (Pathways Language Model) SQL est un autre modèle puissant développé par Google. Les capacités et l'architecture avancées de PaLM SQL le rendent très efficace pour traduire le langage naturel en requêtes SQL et gérer des schémas de bases de données complexes et divers avec une plus grande précision.

Malgré les avancées des LLM, s'appuyer sur un seul LLM pour text2SQL en production peut s'avérer problématique. Un modèle unique ne sera pas en mesure de gérer efficacement la grande variété de requêtes, de schémas de base de données et les exigences de latence en temps réel d'un environnement de données d'entreprise.

Les environnements de production exigent robustesse, adaptabilité et capacité à gérer les messages ambigus des utilisateurs professionnels du monde réel. Par conséquent, un moteur text2SQL doit présenter trois propriétés pour être considéré comme de qualité production :

La capacité de comprendre diverses formulations de requêtes - Des invites utilisateur syntaxiquement différentes peuvent être réduites à la même requête SQL ; un bon moteur text2SQL doit être capable de comprendre la motivation derrière une invite utilisateur, en gardant à l'esprit le contexte du modèle de données, et doit formuler la requête SQL en conséquence.

La capacité de travailler avec des schémas de base de données et des modèles de données ambigus - Les modèles de données de production ont tendance à être chaotiques avec plusieurs équipes différentes au sein d'une organisation qui y contribuent et les données changeant de propriétaire plusieurs fois tout au long de leur cycle de vie.

Un bon moteur text2SQL doit avoir la capacité de lever l'ambiguïté du modèle de données pour l'utilisateur et de garantir que le bruit et l'ambiguïté ne conduisent pas à des hallucinations, une caractéristique des LLM actuels qui dissuadent de nombreux utilisateurs de production.

Il faut veiller à ce que le fonctionnement du moteur n'ajoute pas de latences importantes à l'exécution de la requête. Les réponses qu'un utilisateur attend en temps réel doivent être renvoyées en temps réel. Cela signifie que le moteur doit formuler des requêtes optimales au cours des trois premiers essais au maximum.

Présentation de SherloQ

SherloQ est le moteur text2SQL de Skypoint qui traduit les requêtes du langage naturel vers le langage SQL. Bien que l'exploitation d'un LLM interne personnalisé pour la génération de requêtes constitue une partie importante de son architecture, l'efficacité de SherloQ provient d'une combinaison de composants avancés conçus pour améliorer les capacités d'interrogation des données. SherloQ bénéficie d'une grande précision dans la traduction des requêtes, d'une gestion robuste des erreurs et d'une intégration transparente avec les systèmes de bases de données de production, ce qui le rend adapté aux environnements de données à grande échelle.

Dans les sections suivantes, nous approfondissons les détails de l’architecture interne de SherloQ et partageons certains des résultats que nous avons obtenus en l’utilisant dans des paramètres de production.

Composants architecturaux de SherloQ

L'architecture de SherloQ contient plusieurs éléments mobiles qui contribuent chacun à améliorer la précision, la fiabilité et la latence du système. Voici un aperçu de l'architecture :

Saisie utilisateur - La saisie utilisateur est une requête en langage naturel.

Agent d'état Exécuteur - Notre implémentation d'une interface LangChain qui suit l'état tout au long du processus d'exécution. Il exploite Redis et DataStax Astra DB pour suivre l'état du raisonnement et de la mémoire pendant l'exécution. L'exécuteur gère le flux des opérations en coordonnant les différents modules.

Il garantit que les entrées utilisateur sont correctement analysées, traitées et transmises aux composants suivants, en maintenant un flux depuis l'entrée jusqu'à la génération de requêtes SQL.

Outil d'état - Une classe étendue de l'outil de base Langchain qui possède une variable d'état et transmet cet état à l'outil correspondant. En conservant une variable d'état, l'outil d'état garde une trace des données nécessaires qui doivent être transmises aux outils respectifs. Cela garantit la cohérence du flux de données, évitant toute perte d'informations lors de la transition entre les agents.

Les outils d'état de SherloQ :

• L' outil de génération de requêtes utilise les requêtes à quelques clichés récupérées, le contexte du modèle de données et le schéma de base de données pour générer la requête SQL initiale. Il améliore la précision et la pertinence des requêtes SQL générées en utilisant des informations de schéma analysées et en s'appuyant sur des exemples contextuels.

• L'outil de nouvelle tentative analyse toute erreur générée lors de l'exécution de la requête et régénère une requête qui corrige l'erreur.

• L'outil DB permet de récupérer le schéma de la base de données et les métadonnées correspondantes (annotations, commentaires, etc.) qui seraient utiles pour la génération de requêtes. Les informations de schéma récupérées sont mises en cache à l'aide d'un mécanisme de mise en cache basé sur le temps pour optimiser les performances et réduire les requêtes de base de données. Il exécute également la requête sur la base de données et renvoie les résultats ou une trace de pile d'erreurs.

Entrées de données et techniques pour améliorer les performances de SherloQ

Pour améliorer les performances de SherloQ, nous utilisons plusieurs techniques et fournissons au modèle des données d'entrée importantes. Celles-ci comprennent une décomposition structurée, des exemples de quelques prises de vue, la récupération du contexte du modèle de données, la réflexion et un mécanisme de nouvelle tentative. Chaque partie est essentielle pour améliorer la capacité du modèle à produire des requêtes SQL précises et pertinentes à partir d'entrées en langage naturel.

Décomposition structurée

Dans la décomposition structurée, l'invite utilisateur est décomposée en ses parties fondamentales. Se concentrer sur les composants essentiels de la requête et les identifier aide le modèle à produire un SQL précis. Par exemple :

Entrée : Quelle est la quantité actuelle disponible pour tous les articles fournis par XYZ Corp ?

Résultat : [« quantité actuelle disponible », « tous les articles », « fourni par XYZ Corp »]

Quelques exemples

Le modèle reçoit des questions de référence sous la forme de quelques exemples SQL, qui l'aident à générer des requêtes SQL basées sur des modèles similaires. Ces exemples améliorent la capacité du modèle à générer avec précision de nouvelles requêtes SQL pour diverses invites en l'aidant à reconnaître la structure et le format des requêtes prévues. Voici quelques exemples :

Exemple 1

Entrée : Afficher les articles avec une quantité inférieure à 20 unités disponibles.

Sortie : SELECT * FROM stock WHERE Quantité_Disponible < 20 ;

Exemple 2

Entrée : répertoriez les vendeurs dont les articles coûtent plus de 100 $.

Sortie : SELECT * FROM fournisseurs WHERE Vendor_ID IN (SELECT Vendor_ID FROM éléments WHERE Unit_Price > 100) ;

Nous sélectionnons de manière dynamique les exemples de plans les plus similaires à l'aide de la recherche de similarité sémantique d' Astra DB , notre base de données vectorielle. La base de données vectorielle nous permet de trouver les exemples les plus proches en termes de structure et de contenu de la nouvelle requête d'entrée, garantissant ainsi que le modèle peut exploiter les modèles les plus pertinents pour générer des requêtes SQL précises.

Dans notre environnement de production, nous utilisons en moyenne deux exemples de type « Feed Shot » par requête. D'après notre expérience, le simple ajout d'exemples de type « Feed Shot » supplémentaires pour améliorer la précision n'est pas une pratique évolutive.

Contexte du modèle de données

Le contexte du modèle de données contient des détails spécifiques au domaine qui peuvent être utiles pour créer une requête SQL. Par exemple, dans le contexte des données financières d'un réseau hospitalier, il peut s'agir de codes de mesures financières et de leurs descriptions. Ce contexte est utilisé par le modèle pour s'assurer que les requêtes SQL créées correspondent à la structure de données du domaine. L'inclusion du contexte du modèle de données est facultative et n'est requise que lorsque la table est complexe et nécessite des connaissances du domaine pour former une requête SQL.

Par exemple:

Codes métriques : « MGMTFEE » -> Description : « Frais perçus pour la gestion des propriétés – Frais de gestion »

Schéma de base de données SQL

Le schéma de base de données SQL est la représentation structurée des données disponibles. Le schéma est enrichi par l'annotation de la table et de ses colonnes. Il comprend les noms et descriptions des tables, ainsi que les colonnes, leurs descriptions et les types de données.

La fourniture du schéma aide le modèle à comprendre la structure de la base de données et la signification associée à chaque table et colonne, garantissant que les requêtes SQL générées sont syntaxiquement correctes et utilisent les éléments de base de données corrects.

Réflexion

La réflexion fait référence à la capacité du modèle à évaluer ses propres réponses passées, son comportement ou le contenu généré. Elle permet au modèle d'affiner ses réponses en identifiant et en corrigeant les erreurs ou les faiblesses. Le processus comprend la prise en compte des requêtes précédemment vues par le moteur Sherloq ainsi que des commentaires pendant la phase de génération des requêtes.

Ces scénarios aident le modèle à reproduire les succès ou à éviter les échecs de questions similaires qu'il a rencontrées dans le passé. Cette étape exploite également Astra DB pour trouver les requêtes les plus similaires sémantiquement à la requête actuelle.

Mécanisme de nouvelle tentative

SherloQ intègre un mécanisme de nouvelle tentative utilisant les erreurs reçues de la base de données. Lorsqu'une requête SQL générée génère une erreur, le moteur utilise un agent avec un modèle prédéfini pour corriger la requête :

“””

Votre tâche consiste à corriger une requête SQL incorrecte générée à partir d'une question pour la rendre compatible avec ANSI SQL. Suivez ces instructions : analysez soigneusement la question, le schéma de base de données et le message d'erreur reçu pour garantir des réponses précises. Utilisez des alias de table pour éviter toute confusion.

Par exemple, SELECT t1.col1, t2.col1 FROM table1 AS t1 JOIN table2 AS t2 ON t1.id = t2.id .

Lors du calcul des rations, convertissez toujours le numérateur en nombre à virgule flottante. Utilisez le format ci-dessous :

Tâche:

Générer une requête SQL pour répondre à la question [QUESTION] {user_input} [/QUESTION] La requête à corriger est : {sql_query} Le message d'erreur reçu lors de la dernière exécution est : {error_message}

Réponse:

Sur la base des entrées ci-dessus, voici la requête SQL corrigée : {response_sql} « » »

Comparaison des résultats : avant et après la mise en œuvre de SherloQ

Grâce à l'utilisation de LLM avancés et d'un système bien conçu, SherloQ produit des requêtes SQL plus précises et plus pertinentes par rapport au contexte. Ici, nous comparons les résultats des invites utilisateur avant et après SherloQ en utilisant les mesures de latence et de précision.

Comparaison à l'aide d'une question de production

Nous examinons ici l'un de nos clients de production, un exploitant de résidences pour personnes âgées bien connu. L'un de leurs cas d'utilisation est celui de leur équipe financière qui utilise la plateforme de Skypoint pour comprendre et raisonner sur les indicateurs financiers consolidés de leurs différentes résidences pour personnes âgées.

Invite utilisateur : « Déterminer la tendance trimestrielle des dépenses d'entretien ménager pour l'établissement CM tout au long de 2022. »

Avant SherloQ

• Requête générée

  • SÉLECTIONNEZ SOMME(Numérateur_Montant_Total) / SOMME(Dénominateur_Montant_Total) AS Dépenses_d'entretien ménager FROM skypoint_metric_fact_denormalized_vw OÙ Nom_installation = 'CM' ET Année = 2022 ET Nom_métrique = 'Dépenses d'entretien ménager' GROUP BY Numéro_de_quartier';

    
    

• Problèmes identifiés

  • La requête regroupe par Quarter_Number mais ne le sélectionne pas, ce qui peut entraîner des résultats incomplets.

  • Utilisation de Metric_Name au lieu d'un identifiant plus spécifique comme Metric_Code.

  • La division potentielle par zéro n'est pas gérée dans SUM(Total_Amount_Denominator).

    
    

• Latence moyenne : 29 secondes

  La configuration antérieure à SherloQ utilisait une combinaison de GPT-3.5 avec une ingénierie rapide et plus de 5 requêtes à quelques coups par invite utilisateur.

Avec SherloQ

• Requête générée

  • SÉLECTIONNEZ Année, Numéro_Trimestre, SOMME(Numérateur_Montant_Total) / COALESCE(SOMME(NULLIF(Dénominateur_Montant_Total, 0)), 1) AS Dépenses_d'entretien ménager DE skypoint_metric_fact_denormalized_vwOÙ Code_métrique = 'EXPOTHHOU' ET Nom_installation = 'CM' ET Année = 2022 GROUP BY Numéro_Trimestre, Année ORDER BY Numéro_Trimestre ASC ;

    
    

• Des améliorations ont été constatées
• La requête inclut Quarter_Number, fournissant la répartition trimestrielle nécessaire.
• Le champ Metric_Code est utilisé, fournissant un identifiant plus précis pour la métrique.
• La fonction COALESCE(SUM(NULLIF(Total_Amount_Denominator,0)),1) gère les erreurs potentielles de division par zéro.
• Les résultats sont classés par numéro de trimestre pour refléter la tendance trimestrielle.
• Latence moyenne : 10 secondes

Sur la base de références sur les charges de travail de production, vous trouverez ci-dessous les résultats que nous rapportons sur la précision et la fiabilité avant et avec SherloQ :

• Avant SherloQ

  • Précision : 65%

  • Fiabilité : 60%

    
    

• Avec SherloQ

  • Précision : 92%

  • Fiabilité : 90%

    
    

Les résultats ci-dessus sont issus d'une suite d'analyse comparative interne qui exécute chaque invite 100 fois avec des identifiants distincts pour annuler les effets de la mise en cache (dans nos systèmes internes ainsi que dans les modèles). La suite mesure la précision en comparant la réponse renvoyée à une réponse de référence et la fiabilité en mesurant la fréquence à laquelle elle renverrait des réponses similaires.

La comparaison illustre clairement les avantages de SherloQ pour transformer les requêtes en langage naturel en requêtes SQL précises. Les performances globales ont été améliorées de 30 % après SherloQ. Les requêtes générées auparavant souffraient de problèmes tels que des résultats incomplets et un manque de gestion des erreurs, ce qui affectait à la fois la précision et la fiabilité.

Avec SherloQ, les requêtes générées sont plus précises, efficaces et robustes, avec des améliorations notables en termes de latence, de précision et de fiabilité. Cette amélioration démontre la capacité de SherloQ à fournir une récupération de données fiable, ce qui en fait un outil précieux pour les organisations cherchant à optimiser leurs processus d'interrogation de données.

Pour explorer d'autres parties de la plateforme Skypoint ou pour réserver une démonstration de SkyPoint AI, visitez le site Web de Skypoint .

Par Alok Raj, ingénieur principal en IA, Skypoint, et Sayandip Sarkar, responsable de l'ingénierie, Skypoint