Création d'une périphérie de l'information avec accès conversationnel aux données

Republié par Platon

Suiveurs: 0

IA conversationnelle pour l'analyse de données

Figure 1 : Représentation du flux Text2SQL

Alors que notre monde devient de plus en plus global et dynamique, les entreprises dépendent de plus en plus des données pour prendre des décisions éclairées, objectives et opportunes. Cependant, à l'heure actuelle, libérer tout le potentiel des données organisationnelles est souvent le privilège d'une poignée de data scientists et d'analystes. La plupart des employés ne maîtrisent pas la boîte à outils conventionnelle de la science des données (SQL, Python, R, etc.). Pour accéder aux données souhaitées, ils passent par une couche supplémentaire où les analystes ou les équipes BI « traduisent » la prose des questions métiers dans le langage des données. Le potentiel de friction et d'inefficacité sur ce parcours est élevé - par exemple, les données peuvent être livrées avec des retards ou même lorsque la question est déjà devenue obsolète. Des informations peuvent se perdre en cours de route lorsque les exigences ne sont pas correctement traduites en requêtes analytiques. En outre, générer des informations de haute qualité nécessite une approche itérative qui est découragée à chaque étape supplémentaire dans la boucle. D'un autre côté, ces interactions ad hoc créent des perturbations pour les talents coûteux en données et les détournent d'un travail de données plus stratégique, comme décrit dans ces "confessions" d'un data scientist :

Quand j'étais chez Square et que l'équipe était plus petite, nous avions une redoutable rotation "analytics on call". Il y avait une rotation stricte sur une base hebdomadaire, et si c'était votre tour, vous saviez que vous feriez très peu de "vrai" travail cette semaine-là et que vous passeriez la plupart de votre temps à répondre aux questions ad hoc des différentes équipes de produits et d'exploitation du société (SQL monkeying, nous l'avons appelé). Il y avait une concurrence acharnée pour les rôles de manager dans l'équipe d'analyse et je pense que cela était entièrement dû au fait que les managers étaient exemptés de cette rotation - aucun prix de statut ne pouvait rivaliser avec la carotte de ne pas faire de travail sur appel.[1]

En effet, ne serait-il pas cool de parler directement à vos données au lieu d'avoir à passer par plusieurs cycles d'interaction avec votre personnel de données ? Cette vision est embrassée par les interfaces conversationnelles qui permettent aux humains d'interagir avec les données en utilisant le langage, notre canal de communication le plus intuitif et universel. Après avoir analysé une question, un algorithme l'encode sous une forme logique structurée dans le langage de requête de votre choix, tel que SQL. Ainsi, les utilisateurs non techniques peuvent chatter avec leurs données et mettre rapidement la main sur des informations précises, pertinentes et opportunes, sans faire le détour via une équipe BI. Dans cet article, nous aborderons les différents aspects de l'implémentation de Text2SQL et nous nous concentrerons sur les approches modernes avec l'utilisation de Large Language Models (LLMs), qui réalisent les meilleures performances à ce jour (cf. [2] ; pour une étude sur les approches alternatives au-delà des LLM, les lecteurs sont renvoyés à [3]). L'article est structuré selon le « modèle mental » suivant des principaux éléments à prendre en compte lors de la planification et de la construction d'une fonctionnalité d'IA :

IA conversationnelle pour l'analyse de données — Figure 2 : Modèle mental d'une fonctionnalité d'IA

Commençons par la fin à l'esprit et récapitulons la valeur - pourquoi vous construiriez une fonctionnalité Text2SQL dans votre produit de données ou d'analyse. Les trois principaux avantages sont :

Utilisateurs professionnels peut accéder aux données organisationnelles de manière directe et rapide.
Cela soulage data scientists et analystes du fardeau des demandes ad hoc des utilisateurs professionnels et leur permet de se concentrer sur les défis de données avancés.
Ceci permet à l' la performance des entreprises pour exploiter ses données de manière plus fluide et stratégique, les transformant enfin en une base solide pour la prise de décision.

Maintenant, quels sont les scénarios de produit dans lesquels vous pourriez envisager Text2SQL ? Les trois paramètres principaux sont :

Vous offrez un données évolutives/produit BI et souhaitent permettre à davantage d'utilisateurs d'accéder à leurs données de manière non technique, augmentant ainsi à la fois l'utilisation et la base d'utilisateurs. Par exemple, ServiceNow a requêtes de données intégrées dans une offre conversationnelle plus largeet une Atlan a récemment exploration de données en langage naturel annoncée.
Vous cherchez à construire quelque chose dans l'espace des données/IA pour démocratiser l'accès aux données dans les entreprises, auquel cas vous pourriez potentiellement envisager un MVP avec Text2SQL au cœur. Des fournisseurs comme AI2SQL ainsi que Text2sql.ai font déjà leur entrée dans cet espace.
Vous travaillez sur un système de BI personnalisé et veulent maximiser et démocratiser son utilisation dans l'entreprise individuelle.

Comme nous le verrons dans les sections suivantes, Text2SQL nécessite une configuration initiale non triviale. Pour estimer le retour sur investissement, tenez compte de la nature des décisions à appuyer ainsi que des données disponibles. Text2SQL peut être une victoire absolue dans les environnements dynamiques où les données évoluent rapidement et sont activement et fréquemment utilisées dans la prise de décision, comme l'investissement, le marketing, la fabrication et l'industrie de l'énergie. Dans ces environnements, les outils traditionnels de gestion des connaissances sont trop statiques, et des moyens plus fluides d'accéder aux données et aux informations aident les entreprises à générer un avantage concurrentiel. En termes de données, Text2SQL fournit la plus grande valeur avec une base de données qui est :

Grand et en pleine croissance, afin que Text2SQL puisse déployer sa valeur au fil du temps à mesure que de plus en plus de données sont exploitées.
Hébergement de haute qualité, afin que l'algorithme Text2SQL n'ait pas à gérer un bruit excessif (incohérences, valeurs vides, etc.) dans les données. En général, les données générées automatiquement par les applications sont de meilleure qualité et plus cohérentes que les données créées et gérées par des humains.
Sémantiquement mature par opposition au brut, afin que les humains puissent interroger les données en fonction des concepts centraux, des relations et des métriques qui existent dans leur modèle mental. Notez que la maturité sémantique peut être atteinte par une étape de transformation supplémentaire qui conforme les données brutes dans une structure conceptuelle (cf. section "Enrichir l'invite avec des informations de base de données").

Dans ce qui suit, nous approfondirons les données, l'algorithme, l'expérience utilisateur, ainsi que les exigences non fonctionnelles pertinentes d'une fonctionnalité Text2SQL. L'article est écrit pour les chefs de produit, les concepteurs UX et les scientifiques et ingénieurs des données qui sont au début de leur parcours Text2SQL. Pour ces personnes, il fournit non seulement un guide pour démarrer, mais également un socle commun de connaissances pour les discussions autour des interfaces entre le produit, la technologie et l'entreprise, y compris les compromis associés. Si vous êtes déjà plus avancé dans votre mise en œuvre, les références à la fin fournissent une gamme de plongées approfondies à explorer.

Si ce contenu éducatif approfondi vous est utile, vous pouvez abonnez-vous à notre liste de diffusion de recherche sur l'IA d'être alerté lorsque nous publierons du nouveau matériel.

1. Les données

Toute entreprise d'apprentissage automatique commence par des données, nous commencerons donc par clarifier la structure des données d'entrée et cibles qui sont utilisées pendant la formation et la prédiction. Tout au long de l'article, nous utiliserons le flux Text2SQL de la figure 1 comme représentation courante et mettrons en évidence les composants et les relations actuellement considérés en jaune.

1.1 Format et structure des données

Typiquement, une paire entrée-sortie Text2SQL brute se compose d'une question en langage naturel et de la requête SQL correspondante, par exemple :

Question« Indiquez le nom et le nombre d'abonnés pour chaque utilisateur. »

Requête SQL:

sélectionnez le nom, les abonnés de user_profiles

Dans l'espace de données de formation, le mappage entre les questions et les requêtes SQL est plusieurs à plusieurs :

Une requête SQL peut être mappée à de nombreuses questions différentes en langage naturel ; par exemple, la sémantique de requête ci-dessus peut être exprimée par : "montrez-moi les noms et le nombre d'abonnés par utilisateur","combien y a-t-il d'abonnés pour chaque utilisateur ?" etc.
La syntaxe SQL est très polyvalente et presque toutes les questions peuvent être représentées en SQL de plusieurs manières. L'exemple le plus simple est l'ordre différent des clauses WHERE. D'un point de vue plus avancé, tous ceux qui ont fait de l'optimisation de requêtes SQL sauront que de nombreuses routes mènent au même résultat et que des requêtes sémantiquement équivalentes peuvent avoir une syntaxe complètement différente.

La collecte manuelle des données d'entraînement pour Text2SQL est particulièrement fastidieuse. Cela nécessite non seulement une maîtrise SQL de la part de l'annotateur, mais également plus de temps par exemple que des tâches linguistiques plus générales telles que l'analyse des sentiments et la classification de texte. Pour garantir une quantité suffisante d'exemples de formation, l'augmentation des données peut être utilisée - par exemple, les LLM peuvent être utilisés pour générer des paraphrases pour la même question. [3] fournit une étude plus complète des techniques d'augmentation de données Text2SQL.

1.2 Enrichir l'invite avec les informations de la base de données

Text2SQL est un algorithme à l'interface entre les données non structurées et structurées. Pour des performances optimales, les deux types de données doivent être présents lors de la formation et de la prédiction. Plus précisément, l'algorithme doit connaître la base de données interrogée et être capable de formuler la requête de telle manière qu'elle puisse être exécutée sur la base de données. Ces connaissances peuvent englober :

Colonnes et tables de la base de données
Relations entre tables (clés étrangères)
Contenu de la base de données

Il existe deux options pour intégrer les connaissances de la base de données : d'une part, les données d'entraînement peuvent être limitées à des exemples écrits pour la base de données spécifique, auquel cas le schéma est appris directement à partir de la requête SQL et de son mappage à la question. Ce paramètre de base de données unique permet d'optimiser l'algorithme pour une base de données individuelle et/ou une entreprise. Cependant, cela anéantit toute ambition d'évolutivité, car le modèle doit être affiné pour chaque client ou base de données. Alternativement, dans un environnement multi-base de données, le schéma de base de données peut être fourni dans le cadre de l'entrée, permettant à l'algorithme de « généraliser » à de nouveaux schémas de base de données invisibles. Bien que vous deviez absolument opter pour cette approche si vous souhaitez utiliser Text2SQL sur de nombreuses bases de données différentes, gardez à l'esprit qu'elle nécessite un effort d'ingénierie considérable et rapide. Pour toute base de données d'entreprise raisonnable, inclure les informations complètes dans l'invite sera extrêmement inefficace et très probablement impossible en raison des limites de longueur de l'invite. Ainsi, la fonction responsable de la formulation des invites doit être suffisamment intelligente pour sélectionner un sous-ensemble d'informations de base de données qui est le plus "utile" pour une question donnée, et pour le faire pour des bases de données potentiellement invisibles.

Enfin, la structure de la base de données joue un rôle crucial. Dans les scénarios où vous avez suffisamment de contrôle sur la base de données, vous pouvez faciliter la vie de votre modèle en lui permettant d'apprendre à partir d'une structure intuitive. En règle générale, plus votre base de données reflète la façon dont les utilisateurs professionnels parlent de l'entreprise, plus votre modèle peut en tirer des enseignements efficaces et rapides. Ainsi, envisagez d'appliquer des transformations supplémentaires aux données, telles que l'assemblage de données normalisées ou autrement dispersées dans de larges tables ou un coffre-fort de données, en nommant les tables et les colonnes de manière explicite et sans ambiguïté, etc. Toutes les connaissances métier que vous pouvez encoder à l'avance réduiront la charge de l'apprentissage probabiliste sur votre modèle et vous aider à obtenir de meilleurs résultats.

2. Algorithme

Text2SQL est un type de analyse sémantique — la mise en correspondance de textes avec des représentations logiques. Ainsi, l'algorithme doit non seulement "apprendre" le langage naturel, mais aussi la représentation cible - dans notre cas, SQL. Plus précisément, il doit acquérir les connaissances suivantes :

Syntaxe et sémantique SQL
Structure de la base de données
Compréhension du langage naturel (NLU)
Mapping entre le langage naturel et les requêtes SQL (syntaxiques, lexicales et sémantiques)

2.1 Résolution de la variabilité linguistique dans l'entrée

En entrée, le principal défi de Text2SQL réside dans la flexibilité du langage : comme décrit dans la section Format et structure des données, une même question peut être paraphrasée de bien des manières différentes. De plus, dans le contexte conversationnel réel, nous devons faire face à un certain nombre de problèmes tels que les fautes d'orthographe et de grammaire, les entrées incomplètes et ambiguës, les entrées multilingues, etc.

Les LLM tels que les modèles GPT, T5 et CodeX se rapprochent de plus en plus de la résolution de ce défi. En apprenant à partir d'énormes quantités de textes divers, ils apprennent à gérer un grand nombre de modèles et d'irrégularités linguistiques. Au final, ils deviennent capables de généraliser sur des questions sémantiquement similaires malgré des formes de surface différentes. Les LLM peuvent être appliqués prêts à l'emploi (zero-shot) ou après un réglage fin. Le premier, bien que pratique, conduit à une précision moindre. Ce dernier nécessite plus de compétences et de travail, mais peut augmenter considérablement la précision.

En termes de précision, comme prévu, les modèles les plus performants sont les derniers modèles de la famille GPT dont les modèles CodeX. En avril 2023, GPT-4 a conduit à une augmentation spectaculaire de la précision de plus de 5 % par rapport à l'état de l'art précédent et a atteint une précision de 85.3 % (sur la métrique "exécution avec valeurs").[4] Dans le camp open source, les premières tentatives de résolution du puzzle Text2SQL se sont concentrées sur des modèles d'encodage automatique tels que BERT, qui excellent dans les tâches NLU. [5, 6, 7] Cependant, au milieu du battage médiatique autour de l'IA générative, les approches récentes se concentrent sur des modèles autorégressifs comme le modèle T5. T5 est pré-formé en utilisant l'apprentissage multi-tâches et s'adapte ainsi facilement aux nouvelles tâches linguistiques, incl. différentes variantes d'analyse sémantique. Cependant, les modèles autorégressifs ont un défaut intrinsèque en ce qui concerne les tâches d'analyse sémantique : ils ont un espace de sortie sans contrainte et aucun garde-corps sémantique qui limiterait leur sortie, ce qui signifie qu'ils peuvent devenir incroyablement créatifs dans leur comportement. Bien que ce soit un truc incroyable pour générer du contenu de forme libre, c'est une nuisance pour des tâches comme Text2SQL où nous attendons une sortie cible contrainte et bien structurée.

2.2 Validation et amélioration des requêtes

Pour contraindre la sortie LLM, nous pouvons introduire des mécanismes supplémentaires pour valider et améliorer la requête. Cela peut être mis en œuvre comme une étape de validation supplémentaire, comme proposé dans le système PICARD.[8] PICARD utilise un analyseur SQL qui peut vérifier si une requête SQL partielle peut conduire à une requête SQL valide après son achèvement. A chaque étape de génération par le LLM, les jetons qui invalideraient la requête sont rejetés, et les jetons valides les plus probables sont conservés. Étant déterministe, cette approche garantit une validité SQL à 100 % tant que l'analyseur respecte les règles SQL correctes. Il découple également la validation des requêtes de la génération, permettant ainsi de maintenir les deux composants indépendamment l'un de l'autre et de mettre à jour et modifier le LLM.

Une autre approche consiste à intégrer les connaissances structurelles et SQL directement dans le LLM. Par exemple, Graphix [9] utilise des couches sensibles aux graphes pour injecter des connaissances SQL structurées dans le modèle T5. En raison de la nature probabiliste de cette approche, elle oriente le système vers les requêtes correctes, mais ne garantit pas le succès.

Enfin, le LLM peut être utilisé comme un agent multi-étapes qui peut vérifier et améliorer de manière autonome la requête.[10] En utilisant plusieurs étapes dans une invite de chaîne de pensée, l'agent peut être chargé de réfléchir à l'exactitude de ses propres requêtes et d'améliorer les défauts. Si la requête validée ne peut toujours pas être exécutée, la trace de l'exception SQL peut être transmise à l'agent en tant que retour d'information supplémentaire pour l'amélioration.

Au-delà de ces méthodes automatisées qui se produisent dans le backend, il est également possible d'impliquer l'utilisateur lors du processus de vérification des requêtes. Nous décrirons cela plus en détail dans la section sur l'expérience utilisateur.

2.3 Évaluation

Pour évaluer notre algorithme Text2SQL, nous devons générer un ensemble de données de test (validation), exécuter notre algorithme dessus et appliquer des métriques d'évaluation pertinentes sur le résultat. Un ensemble de données naïf divisé en données de formation, de développement et de validation serait basé sur des paires question-requête et conduirait à des résultats sous-optimaux. Des requêtes de validation peuvent être révélées au modèle pendant la formation et conduire à une vision trop optimiste de ses compétences de généralisation. UN fractionnement basé sur une requête, où l'ensemble de données est divisé de manière à ce qu'aucune requête n'apparaisse à la fois pendant la formation et pendant la validation, fournit des résultats plus véridiques.

En termes de métriques d'évaluation, ce qui nous intéresse dans Text2SQL n'est pas de générer des requêtes totalement identiques au gold standard. Ce "Correspondance exacte de la chaîne" La méthode est trop stricte et générera de nombreux faux négatifs, car différentes requêtes SQL peuvent conduire au même jeu de données renvoyé. Au lieu de cela, nous voulons atteindre des niveaux élevés précision sémantique et évaluez si les requêtes prédites et "gold standard" renverraient toujours les mêmes ensembles de données. Il existe trois mesures d'évaluation qui se rapprochent de cet objectif :

Précision de correspondance exacte: les requêtes SQL générées et cibles sont divisées en leurs constituants, et les ensembles résultants sont comparés pour l'identité.[11] L'inconvénient ici est qu'il ne tient compte que des variations d'ordre dans la requête SQL, mais pas des différences syntaxiques plus prononcées entre des requêtes sémantiquement équivalentes.
Précision d'exécution: les ensembles de données résultant des requêtes SQL générées et cibles sont comparés pour l'identité. Avec un peu de chance, les requêtes avec une sémantique différente peuvent toujours réussir ce test sur une instance de base de données spécifique. Par exemple, en supposant une base de données où tous les utilisateurs sont âgés de plus de 30 ans, les deux requêtes suivantes renverraient des résultats identiques malgré une sémantique différente :
sélectionnez * de l'utilisateur
sélectionnez * de l'utilisateur dont l'âge est > 30
Précision de la suite de tests: la précision de la suite de tests est une version plus avancée et moins permissive de la précision d'exécution. Pour chaque requête, un ensemble ("suite de tests") de bases de données est généré qui sont très différenciées en ce qui concerne les variables, les conditions et les valeurs de la requête. Ensuite, la précision d'exécution est testée sur chacune de ces bases de données. Tout en nécessitant des efforts supplémentaires pour concevoir la génération de la suite de tests, cette métrique réduit également considérablement le risque de faux positifs lors de l'évaluation..

3. Expérience utilisateur

L'état de l'art actuel de Text2SQL ne permet pas une intégration totalement transparente dans les systèmes de production — au lieu de cela, il est nécessaire de gérer activement les attentes et le comportement de l'utilisateur, qui doit toujours être conscient qu'il interagit avec un système d'IA.

3.1 Gestion des pannes

Text2SQL peut échouer dans deux modes, qui doivent être interceptés de différentes manières :

Erreurs SQL: la requête générée n'est pas valide — soit le SQL est invalide, soit il ne peut pas être exécuté sur la base de données spécifique en raison de défauts lexicaux ou sémantiques. Dans ce cas, aucun résultat ne peut être retourné à l'utilisateur.
Erreurs sémantiques: la requête générée est valide mais elle ne reflète pas la sémantique de la question, conduisant ainsi à un ensemble de données retourné incorrect.

Le second mode est particulièrement délicat car le risque de « pannes silencieuses », c'est-à-dire d'erreurs non détectées par l'utilisateur, est élevé. L'utilisateur prototype n'aura ni le temps ni les compétences techniques pour vérifier l'exactitude de la requête et/ou des données résultantes. Lorsque les données sont utilisées pour la prise de décision dans le monde réel, ce type d'échec peut avoir des conséquences dévastatrices. Pour éviter cela, il est essentiel d'éduquer les utilisateurs et d'établir garde-corps au niveau de l'entreprise qui limitent l'impact potentiel, telles que des vérifications de données supplémentaires pour les décisions ayant un impact plus important. D'autre part, nous pouvons également utiliser l'interface utilisateur pour gérer l'interaction homme-machine et aider l'utilisateur à détecter et à améliorer les demandes problématiques.

3.2 Interaction homme-machine

Les utilisateurs peuvent s'impliquer dans votre système d'IA avec différents degrés d'intensité. Plus d'interaction par demande peut conduire à de meilleurs résultats, mais cela ralentit également la fluidité de l'expérience utilisateur. Outre l'impact négatif potentiel des requêtes et des résultats erronés, tenez également compte de la motivation de vos utilisateurs à fournir des commentaires dans les deux sens afin d'obtenir des résultats plus précis et d'aider également à améliorer le produit à long terme.

Le moyen le plus simple et le moins engageant est de travailler avec des scores de confiance. Alors que le calcul naïf de la confiance comme moyenne des probabilités des jetons générés est trop simpliste, des méthodes plus avancées comme le feedback verbalisé peuvent être utilisées. [13] La confiance peut être affichée dans l'interface et mise en évidence avec une alerte explicite au cas où elle serait dangereusement basse. De cette façon, la responsabilité d'un suivi approprié dans le "monde réel" - qu'il s'agisse d'un rejet, d'une acceptation ou d'une vérification supplémentaire des données - repose sur les épaules de votre utilisateur. Bien qu'il s'agisse d'une valeur sûre pour vous en tant que fournisseur, le transfert de ce travail à l'utilisateur peut également réduire la valeur de votre produit.

Une deuxième possibilité consiste à engager l'utilisateur dans un dialogue de clarification en cas de requêtes peu fiables, ambiguës ou autrement suspectes. Par exemple, votre système peut suggérer des corrections orthographiques ou grammaticales à l'entrée et demander de désambiguïser des mots ou des structures grammaticales spécifiques. Cela peut également permettre à l'utilisateur de demander de manière proactive des corrections dans la requête :[14]

UTILISATEUR: Montrez-moi les tâches de John dans ce sprint.

ASSISTANT: Souhaitez-vous voir les tâches créées par John ou celles sur lesquelles il travaille ?

UTILISATEUR: tâches créées par John

ASSISTANT: Ok, voici les ID de tâche :

UTILISATEUR: Merci, j'aimerais aussi voir plus d'informations sur les tâches. Veuillez également trier par urgence.

ASSISTANT: Bien sûr, voici les tâches avec de brèves descriptions, les cessionnaires et les délais, triés par date limite.

Enfin, pour faciliter la compréhension des requêtes par l'utilisateur, votre système peut également fournir une reformulation textuelle explicite de la requête et demander à l'utilisateur de la confirmer ou de la corriger.[15]

4. Exigences non fonctionnelles

Dans cette section, nous discutons des exigences non fonctionnelles spécifiques pour Text2SQL ainsi que des compromis entre elles. Nous nous concentrerons sur les six exigences qui semblent les plus importantes pour la tâche : précision, évolutivité, rapidité, explicabilité, confidentialité et adaptabilité dans le temps.

Précision 4.1

Pour Text2SQL, les exigences de précision sont élevées. Premièrement, Text2SQL est généralement appliqué dans un cadre de conversation où les prédictions sont faites une par une. Ainsi, la "loi des grands nombres" qui aide généralement à compenser l'erreur dans les prédictions par lots, n'aide pas. Deuxièmement, la validité syntaxique et lexicale est une condition « dure » : le modèle doit générer une requête SQL bien formée, potentiellement avec une syntaxe et une sémantique complexes, sinon la requête ne peut pas être exécutée sur la base de données. Et si cela se passe bien et que la requête peut être exécutée, elle peut encore contenir des erreurs sémantiques et conduire à un mauvais jeu de données retourné (cf. section 3.1 Gestion des échecs).

Evolutivité 4.2

Les principales considérations d'évolutivité sont de savoir si vous souhaitez appliquer Text2SQL sur une ou plusieurs bases de données - et dans ce dernier cas, si l'ensemble de bases de données est connu et fermé. Si oui, vous aurez plus de facilité puisque vous pourrez inclure les informations sur ces bases de données lors de la formation. Cependant, dans un scénario de produit évolutif - qu'il s'agisse d'une application Text2SQL autonome ou d'une intégration dans un produit de données existant - votre algorithme doit faire face à tout nouveau schéma de base de données à la volée. Ce scénario ne vous donne pas non plus la possibilité de transformer la structure de la base de données pour la rendre plus intuitive pour l'apprentissage (lien !). Tout cela conduit à un lourd compromis avec la précision, ce qui pourrait également expliquer pourquoi les fournisseurs actuels de Text2SQL qui proposent une interrogation ad hoc de nouvelles bases de données n'ont pas encore atteint une pénétration significative du marché.

Vitesse 4.3

Étant donné que les requêtes Text2SQL seront généralement traitées en ligne dans une conversation, l'aspect vitesse est important pour la satisfaction de l'utilisateur. Du côté positif, les utilisateurs sont souvent conscients du fait que les demandes de données peuvent prendre un certain temps et font preuve de la patience requise. Cependant, cette bonne volonté peut être sapée par le paramètre de chat, où les utilisateurs s'attendent inconsciemment à une vitesse de conversation de type humain. Les méthodes d'optimisation par force brute, telles que la réduction de la taille du modèle, peuvent avoir un impact inacceptable sur la précision. Par conséquent, envisagez une optimisation par inférence pour répondre à cette attente.

4.4 Explicabilité et transparence

Dans le cas idéal, l'utilisateur peut suivre la façon dont la requête a été générée à partir du texte, voir le mappage entre des mots ou des expressions spécifiques dans la question et la requête SQL, etc. Cela permet de vérifier la requête et de faire des ajustements lors de l'interaction avec le système . En outre, le système pourrait également fournir une reformulation textuelle explicite de la requête et demander à l'utilisateur de la confirmer ou de la corriger.

4.5 Privacy

La fonction Text2SQL peut être isolée de l'exécution de la requête, de sorte que les informations de base de données renvoyées peuvent rester invisibles. Cependant, la question cruciale est de savoir combien d'informations sur la base de données sont incluses dans l'invite. Les trois options (par niveau de confidentialité décroissant) sont :

Aucune information
Schéma de base de données
Contenu de la base de données

La confidentialité est un compromis avec la précision - moins vous êtes contraint d'inclure des informations utiles dans l'invite, meilleurs sont les résultats.

4.6 Adaptabilité dans le temps

Pour utiliser Text2SQL de manière durable, vous devez vous adapter à la dérive des données, c'est-à-dire à l'évolution de la distribution des données auxquelles le modèle est appliqué. Par exemple, supposons que les données utilisées pour l'ajustement initial reflètent le comportement d'interrogation simple des utilisateurs lorsqu'ils commencent à utiliser le système BI. Au fil du temps, les besoins en informations des utilisateurs deviennent plus sophistiqués et nécessitent des requêtes plus complexes, qui submergent votre modèle naïf. Par ailleurs, les objectifs ou la stratégie d'un changement d'entreprise peuvent également dériver et orienter les besoins d'information vers d'autres zones de la base de données. Enfin, un défi spécifique à Text2SQL est la dérive de la base de données. Au fur et à mesure que la base de données de l'entreprise est étendue, de nouvelles colonnes et tables invisibles font leur chemin dans l'invite. Bien que les algorithmes Text2SQL conçus pour une application multi-base de données puissent bien gérer ce problème, cela peut avoir un impact significatif sur la précision d'un modèle à base de données unique. Tous ces problèmes sont mieux résolus avec un ensemble de données de réglage fin qui reflète le comportement actuel et réel des utilisateurs. Ainsi, il est crucial de consigner les questions et les résultats des utilisateurs, ainsi que tout retour d'information associé pouvant être recueilli à partir de l'utilisation. De plus, des algorithmes de clustering sémantique, utilisant par exemple des intégrations ou la modélisation de sujets, peuvent être appliqués pour détecter les changements sous-jacents à long terme dans le comportement des utilisateurs et les utiliser comme source d'informations supplémentaire pour perfectionner votre ensemble de données de réglage fin.

Conclusion

Résumons les points clés de l'article :

Text2SQL permet de mettre en place un accès intuitif et démocratique aux données dans une entreprise, maximisant ainsi la valeur des données disponibles.
Les données Text2SQL sont constituées de questions en entrée et de requêtes SQL en sortie. Le mappage entre les questions et les requêtes SQL est plusieurs à plusieurs.
Il est important de fournir des informations sur la base de données dans le cadre de l'invite. De plus, la structure de la base de données peut être optimisée pour faciliter son apprentissage et sa compréhension par l'algorithme.
En entrée, le principal défi est la variabilité linguistique des questions en langage naturel, qui peuvent être abordées à l'aide de LLM pré-formés sur une grande variété de styles de texte différents.
La sortie de Text2SQL doit être une requête SQL valide. Cette contrainte peut être intégrée en « injectant » des connaissances SQL dans l'algorithme ; alternativement, en utilisant une approche itérative, la requête peut être vérifiée et améliorée en plusieurs étapes.
En raison de l'impact potentiellement élevé des « pannes silencieuses » qui renvoient des données erronées pour la prise de décision, la gestion des pannes est une préoccupation majeure dans l'interface utilisateur.
De manière « augmentée », les utilisateurs peuvent être activement impliqués dans la validation itérative et l'amélioration des requêtes SQL. Bien que cela rende l'application moins fluide, cela réduit également les taux d'échec, permet aux utilisateurs d'explorer les données de manière plus flexible et crée des signaux précieux pour un apprentissage ultérieur.
Les principales exigences non fonctionnelles à prendre en compte sont la précision, l'évolutivité, la rapidité, l'explicabilité, la confidentialité et l'adaptabilité dans le temps. Les principaux compromis consistent entre la précision d'une part, et l'évolutivité, la vitesse et la confidentialité d'autre part.