Briques de boîte de dialogue SQL

Les boîtes de dialogue SQL sont des briques qui peuvent traduire les variations en langage naturel d'un utilisateur en requêtes SQL, envoyer les requêtes à une source de données back-end et afficher la réponse. Cette version de SQL Dialogs prend en charge l'intégration avec les services de base de données Oracle, tels qu'Oracle Enterprise Database Service.

Remarque

Cette version ne prend pas en charge les briques de dialogue SQL multilingues ou les briques dont la langue principale n'est pas l'anglais. Lorsque vous créez une brique (ou une version ou un clone d'une brique), vous utilisez le champ langue principale de la boîte de dialogue Créer pour indiquer la langue principale. Une brique est multilingue si le groupe de ressources, les exemples de variation, l'apprentissage automatique et les listes de valeurs, par exemple, ont plusieurs langues ou si le flux de dialogue contient du code permettant de détecter la langue de la saisie utilisateur et de la traduire en arrière-plan.

Lors de l'écriture de briques fournissant des informations de base de données aux utilisateurs finaux, les développeurs doivent généralement définir les cas d'emploi, écrire des composants personnalisés pour extraire les données, créer des intentions pour les cas d'emploi, mettre en correspondance des variations utilisateur avec des intentions et écrire le flux de dialogue pour gérer chaque intention. Avec les briques de dialogue SQL, vous n'avez pas besoin d'effectuer ces étapes. Au lieu de cela, vous mettez en correspondance les modèles mentaux des utilisateurs avec la source de données physique, et la brique utilise la carte pour générer dynamiquement du code SQL à partir de variations de langage naturel.

Par exemple, les utilisateurs peuvent savoir que les employés appartiennent à des services situés à différents endroits et qu'ils ont des matricules, des intitulés de poste, des dates d'embauche et parfois des commissions. Compte tenu de leur modèle mental, ils peuvent récupérer les données en demandant la compétence "Quel est le travail de James Smith ?", "Quand James Smith a-t-il été embauché ?", "Combien d'employés sont à New York ?", et "Qui a la commission la plus élevée ?

Vous créez une brique SQL Dialog différemment des briques standard. Pour permettre à la brique de comprendre les variations de langage naturel et d'y répondre, vous créez un modèle logique à partir du modèle physique et vous l'enseignez à l'aide de termes de langage naturel pour décrire le modèle physique.

Fonctionnement des boîtes de dialogue SQL

Pour implémenter une brique de dialogue SQL, vous créez une brique de dialogue visuelle et importez des informations sur le modèle physique (schéma de base de données) à partir du service de données. Oracle Digital Assistant utilise ces informations pour créer une entité de requête pour chaque table importée (modèle logique). Les entités de requête contiennent des attributs qui modélisent les colonnes de table.

Si une table du modèle physique possède une clé étrangère, l'entité de requête possède un attribut qui est lié à l'entité de requête associée. Par exemple, si une table Emp possède une clé étrangère vers la table Dept, l'entité de requête Emp possède un attribut dept, qui est lié à l'entité Dept.

Dès que vous créez les entités de requête et identifiez leurs clés primaires, vous pouvez entraîner la brique et elle est prête à être utilisée de manière rudimentaire. Autrement dit, vous pouvez utiliser des variations de forme libre, mais pour l'instant, la requête doit utiliser les noms principaux d'entité et d'attribut exacts, qui sont initialement dérivés des noms du modèle physique (noms canoniques). Cela changera au fur et à mesure que vous améliorerez le modèle logique pour refléter plus étroitement le langage naturel.

Pour permettre aux utilisateurs finaux d'utiliser le langage naturel pour interroger les données, vous mettez en correspondance la terminologie de l'utilisateur final avec le modèle physique en modifiant les noms principaux et en ajoutant des synonymes pour les entités de requête et leurs attributs. Par exemple, vous pouvez remplacer le nom principal de la table Emp par "employee" et ajouter le synonyme "staff member". L'ajout de noms principaux et de synonymes est deux des façons dont vous entraînez l'analyseur de langage naturel pour résoudre les variations en langage de requête de représentation de signification Oracle (OMRQL). Les requêtes OMRQL sont semblables à des requêtes SQL mais sont basées sur les noms canoniques des modèles d'objet (entités de requête). Par exemple, si vous remplacez le nom principal de empno par "numéro d'employé", "Quel est le numéro d'employé de Joe Smith" renvoie SELECT empno FROM emp WHERE ename = "Joe Smith".

Pour améliorer encore la résolution du processeur de langage naturel, vous pouvez également associer les attributs à des listes de valeurs, qui sont automatiquement alimentées à partir du service de données lors de leur création.

Par exemple, supposons que vous importiez les tables Emp et Dept à partir d'un service de données, ce qui génère des entités de requête Emp et Dept. Immédiatement après avoir importé les tables et entraîné la brique, vous pouvez interroger les entités de requête à l'aide de variations comme suit :

Show all Emp in dept 10

Une fois que vous avez remplacé les noms principaux des entités et des attributs par des termes en langage naturel, tels que Employees pour l'entité et department pour l'attribut, vous pouvez utiliser des variations comme celle-ci :

Show all the employees in department 10

Vous pouvez ajouter des synonymes pour modéliser toutes les façons dont les gens font généralement référence à l'entité ou à l'attribut. Par exemple, vous pouvez ajouter les synonymes district et territory pour department afin que le traitement du langage naturel reconnaisse cette variation :

Show all employees in district 10

Avec des variations plus complexes, vous pouvez apprendre à la brique à résoudre les requêtes sur OMRQL en ajoutant des données d'entraînement personnalisées qui associent les variations à des instructions OMRQL spécifiques.

Si votre brique a des intentions pour gérer des cas d'utilisation non SQL ou si elle est incluse dans un DA, vous voulez ajouter des variations de routage à l'ensemble de données des entités de requête afin d'aider la brique à différencier les variations liées à SQL des variations non liées à SQL.

Lorsque la brique génère un résultat de requête, elle permet à l'utilisateur de donner un pouce vers le haut ou un pouce vers le bas pour indiquer si le résultat est correct. La page Analyses affiche le nombre de pouces vers le haut (requêtes correctes) et le nombre de pouces vers le bas (requêtes incorrectes) afin que vous puissiez voir l'efficacité de la brique.

Requêtes prises en charge

Le modèle de traitement du langage naturel des boîtes de dialogue SQL prend en charge les requêtes qui se traduisent par les clauses SQL de base : SELECT, FROM, WHERE, GROUP BY, HAVING, ORDER BY et LIMIT.

Une requête peut impliquer jusqu'à 3 entités différentes. Cela signifie qu'il peut avoir jusqu'à 2 jointures. Les requêtes impliquant 3 jointures peuvent être résolues pour corriger les résultats en fonction du cas d'emploi. Pour 4 jointures ou plus, vous devrez ajouter des données d'entraînement personnalisées pour vous assurer que la brique donne les résultats corrects.

Les dialogues SQL ne prennent pas en charge les requêtes plus complexes impliquant des sous-requêtes et des opérateurs SET (INTERSECT, UNION, EXCEPT et NONE). Il ne prend pas en charge les requêtes non anglaises, les requêtes qui demandent une réponse oui ou non, les requêtes avec des pronoms et les requêtes de suivi. Pour en savoir plus sur ces limitations de requête et sur d'autres boîtes de dialogue SQL, reportez-vous à Dépannage des requêtes SQL.

Pour certaines des requêtes qui ne sont pas prises en charge, vous pouvez résoudre le problème à l'aide de vues de base de données ou en créant des attributs virtuels, comme décrit dans Ajout d'un attribut personnalisé.

Le tableau ci-dessous décrit les types de requête pris en charge par les boîtes de dialogue SQL. Il utilise les valeurs de base de données suivantes :

Table d'employé

employee_id	nom	rôle	salaire	department_id
1	Alex Smith	VP	500 000	1
2	Samyra Kent	Vendeur	60 000	1
3	Laticia Fan	Vendeur	80 000	1

Table des services

department_id	nom	emplacement
1	Ventes	Dallas

Voici les types de requête pris en charge par les boîtes de dialogue SQL :

catégorie	Description	Exemples
Affichage	Vous pouvez demander une entité, des attributs et des agrégations d'attributs. Les agrégations prises en charge sont moyenne, somme, min, max, count(attribute), count(column), count(distinct attribute) Si la requête ne nomme aucun attribut, la brique affiche ceux répertoriés pour Attributs par défaut dans l'onglet Présentation de l'entité.	montrez-moi tous les employés nom, salaire et nom du service des employés Quels sont les emplois uniques qu'un employé peut avoir ? combien d'employés renvoyer le salaire le plus élevé de tous les employés
Filtres	Vous pouvez filtrer les lignes du tableau par conditions sur des attributs spécifiques Les attributs de texte peuvent être égaux à une valeur, contenir une valeur ou commencer ou finir par une valeur. Vous pouvez utiliser différents comparateurs pour filtrer les colonnes numériques et de date/heure (=, <, <=, >, >=). Vous utilisez AND et OR pour combiner plusieurs conditions.	afficher le nom des employés dont l'intitulé de poste est Employé retourner le salaire de tous les commis employés dont le nom commence par Jo voir les employés qui ont rejoint le groupe en 2020 et qui gagnent plus de 7000
Filtres avec dates	Lorsque vous effectuez un filtrage par attribut de date ou de date/heure, tenez compte des points suivants : Pour les attributs date/heure, les valeurs doivent contenir des dates et des heures (10 décembre 2020 à 3 heures). Les valeurs peuvent être absolues (10 décembre 2020) ou relatives (aujourd'hui). Le filtre peut être un intervalle tel que "l'année dernière" ou "du 5 janvier au 5 juillet" et peut avoir des dates ou des dates avec des heures. Utilisez le paramètre Préférence temporelle de l'attribut dans l'onglet Informations générales pour définir si les valeurs ambiguës, telles que "Mercredi", doivent être définies par défaut sur la date la plus proche, passée ou future. Les valeurs de durée qui doivent être contraintes en dates, telles que "2 jours", sont prises en charge.	Exemple absolu : qui étaient les employés embauchés le 10 décembre 2020 Exemple d'intervalle relatif : qui étaient les employés embauchés l'année dernière Exemple de date relative : qui étaient les employés embauchés aujourd'hui Exemple date + heure : colis livrés hier à 6 h Exemple de date + intervalle de temps : colis livrés entre le 5 janvier 7 h et le 5 février 10 h Exemple de date ambiguë : qui étaient les employés embauchés mercredi Exemple de durée : employés embauchés depuis 1 mois
Tri et limitation du nombre de lignes	Vous pouvez demander explicitement à la brique de trier les lignes résultantes en fonction d'un attribut particulier. Vous pouvez également demander un certain nombre de valeurs les plus élevées ou les plus faibles d'un attribut ou d'une entité.	afficher les employés triés par nom de service employés classés par nom de Z à A renvoyer le nom et le salaire de tous les employés par ordre décroissant de salaire Quels sont les 10 salaires les plus élevés de tous les employés quel employé a le salaire le plus bas afficher les 5 meilleurs employés
Grouper par	Vous pouvez demander différents agrégats après le regroupement par attribut ou par entité.	le salaire moyen de chaque emploi Quel est le salaire le plus élevé par service ? afficher le nom, le lieu et le nombre d'employés par service
Grouper par et filtrer	Vous pouvez filtrer les attributs ou les entités en fonction d'agrégations.	afficher tous les emplois avec un salaire moyen supérieur à 3000 départements dont le salaire minimum est de 4000 Quels départements comptent au moins 20 salariés ?
Grouper par et commander avec une limite facultative	Vous pouvez trier les attributs ou les entités en fonction des agrégations, et éventuellement demander à voir un certain nombre de lignes supérieures ou inférieures.	afficher tous les emplois triés par salaire le plus élevé payé aux employés de cet emploi Quel service a le salaire moyen le plus bas ? afficher le nom des services dont le nombre d'employés est le plus élevé (3)

Tutoriel : Introduction aux boîtes de dialogue SQL

Vous pouvez jeter un oeil pratique aux dialogues SQL en parcourant ce tutoriel :

Introduction aux boîtes de dialogue SQL.

Workflow des boîtes de dialogue SQL

La façon dont vous créez une brique Boîte de dialogue SQL diffère des briques standard. Voici les principales étapes à suivre pour créer une brique Boîte de dialogue SQL et l'entraîner afin que les utilisateurs puissent utiliser le langage naturel pour interroger les services de données.

Les participants aux étapes suivantes sont le développeur de briques, l'administrateur de service, l'expert en bases de données et l'entraîneur en IA.

Le développeur de compétences collecte les exigences de brique (personnes utilisateur, cas d'utilisation et tâches) et le corpus d'entraînement (exemples de variation utilisateur), puis crée la brique. Le développeur aide également à définir le mode d'affichage des résultats. Cette personne est parfois appelée le concepteur de conversations.
L'administrateur de service ajoute une connexion au service de données.
L'expert en base de données analyse les exigences en matière de brique et le corpus d'entraînement afin d'identifier les tables et les attributs qui fournissent les réponses. L'expert crée ensuite le modèle logique de base en important les informations du modèle physique dans la brique. L'expert aide également le développeur de briques et l'entraîneur en IA à effectuer des tâches telles que l'ajout d'attributs basés sur l'expression SQL, l'association d'attributs à des listes de valeurs chargées à partir de tables, l'association d'attributs à des expressions régulières et l'exécution d'un entraînement personnalisé.
L'entraîneur d'IA ajoute des noms principaux et des synonymes pour enseigner à l'analyseur de langage naturel comment comprendre les variations de langage naturel. Pour les variations que la brique ne peut pas traduire dans OMRQL, l'entraîneur d'IA ajoute un entraînement personnalisé pour apprendre à l'analyseur de langage naturel à comprendre ces variations. Le formateur surveille et teste en permanence la brique pour améliorer la précision de la traduction du langage naturel dans les requêtes de base de données.

Pour illustrer le flux de travail, nous utiliserons un exemple de service de données de comptabilité fournisseurs avec les tableaux suivants. Pour des raisons de concision, nous montrons simplement les colonnes mentionnées dans ce sujet.

Table	colonnes
factures	invoice_num invoice_date pmt_status_flag invoice_amount fournisseur
payment_schedules	invoice_num due_date amount_remaining
fournisseurs	vendor_num vendor_name

Définir les exigences : le développeur de briques rassemble les cas d'utilisation et les tâches que la brique Boîte de dialogue SQL doit prendre en charge. Par exemple, un service de comptabilité fournisseurs peut avoir le cas d'emploi suivant :
- Cas d'utilisation : Payer toutes les factures dont les soldes impayés sont dus dans les 30 jours afin d'éviter les pénalités.
  - Tâche : recherchez toutes les factures non approuvées arrivant à échéance dans les 30 jours afin de pouvoir les approuver à temps.
  - Tâche : recherchez toutes les factures approuvées en attente dues dans un délai de 30 jours afin de pouvoir les planifier le paiement à temps.
Dans le cadre de cette phase d'exigences, le développeur de briques compile une liste représentative des différentes façons dont les gens demandent ces informations. Cette liste sert d'ensemble d'exemples de variation que l'entraîneur AI utilise pour le corps d'entraînement.
Configurer la brique : l'administrateur de service, le développeur de briques et l'expert en base de données travaillent ensemble pour configurer la brique de base.
1. Intégrer au service : l'administrateur de service crée une connexion d'Oracle Digital Assistant au service de données. Reportez-vous à Connexion au service de données.
2. Créer la brique Boîte de dialogue SQL : le développeur de briques crée la brique Boîte de dialogue SQL, en veillant à ce que le mode de boîte de dialogue soit défini sur Visuel dans la boîte de dialogue Créer une brique. Reportez-vous à Création de la brique de boîte de dialogue SQL.
3. Importer le schéma : l'expert en base de données identifie les tables et les champs nécessaires à la prise en charge des cas d'emploi, puis, à partir de la page Entités de la brique, les importe à partir du service de données, comme décrit dans Création d'entités de requête pour modéliser le service de données. Cela crée un modèle logique de base qui contient une entité de requête pour chaque table importée.
  
  Dans notre exemple, l'expert en base de données importe les tables invoices, payment_schedules et vendors.
  
  A ce stade, la brique est prête à être utilisée avec des fonctionnalités limitées. Pour le modèle logique de base, les noms d'entité et d'attribut sont dérivés des noms de table et de champ du modèle physique. Par exemple, si le nom de la table est payment_schedules, le nom principal est payment schedules. L'entraîneur AI peut tester les requêtes à partir de la page Entités ou utiliser le testeur de conversation (Aperçu) pour tester la fonctionnalité SQL.
  
  Dans notre exemple de service de données, ils peuvent utiliser des variations de test telles que "Afficher les factures avec l'indicateur de statut de paiement N", "Afficher le numéro de facture 17445" ou "Afficher les échéanciers de paiement avec une date d'échéance antérieure à 2022-08-30".
Entraînement : ajoutez des données d'entraînement via des noms principaux, des synonymes, des listes de valeurs, des expressions régulières et des requêtes en langage naturel mises en correspondance avec OMRQL.
1. Ajouter une terminologie en langage naturel : pour aider à associer des expressions en langage naturel à la structure de données sous-jacente, l'entraîneur d'IA enseigne à la brique les différentes façons dont les utilisateurs finals font référence aux entités et aux attributs. C'est-à-dire les noms que les gens utiliseront dans leurs déclarations en langage naturel. L'entraîneur commence par analyser les expressions que le développeur de brique a collectées pour identifier les variations que la brique doit gérer (corps d'entraînement). En outre, ils peuvent consulter un thésaurus pour les synonymes et une source de foule pour un phrasé similaire. Ensuite, l'entraîneur AI enregistre les termes équivalents en modifiant les noms principaux et en ajoutant des synonymes. Reportez-vous à Fourniture de données de formation via des noms et des synonymes.
  
  Dans notre exemple, l'une des variations collectées au cours de la phase des exigences est "Donnez-moi la liste des factures dont le solde est supérieur à zéro". L'attribut qui contient le solde est amount remaining, de sorte que l'entraîneur IA ajoute le synonyme outstanding balance à cet attribut.
2. Associer à des listes de valeurs : pour améliorer la précision, l'entraîneur d'IA peut, le cas échéant, créer des listes de valeurs contenant des exemples de valeurs à partir du service de données. La brique associe automatiquement les listes à leurs attributs respectifs, ce qui aide l'analyseur de langage naturel à comprendre les types de valeur que ces attributs peuvent contenir. Voir Fournir des données de formation via des listes de valeurs.
  
  Dans notre exemple, ils associent l'attribut vendor_name à une liste de valeurs extraite du service de données. Si la liste de valeurs inclut "Seven Corporation" et qu'un utilisateur demande "afficher l'indicateur de synthèse pour Seven Corporation", le NLP déduira que Seven Corporation est un nom de fournisseur.
3. Associer à des expressions régulières : lorsque les valeurs d'un attribut doivent correspondre à un modèle spécifique, l'entraîneur d'IA peut créer une entité d'expression régulière et l'associer à cet attribut. Reportez-vous à Fourniture de données d'entraînement via des expressions régulières.
  
  Par exemple, l'entraîneur AI peut associer un attribut ip_address à l'expression régulière (\\d{1,2}|(0|1)\\d{2}|2[0-4]\\d|25[0-5]).
4. Mettre en correspondance des requêtes complexes : dans les cas où la brique ne peut pas traduire une variation valide dans OMRQL, l'entraîneur d'IA ajoute cette variation aux données d'entraînement et la met en correspondance avec OMRQL, comme décrit dans Fournir des données d'entraînement via des variations. Par exemple, vous pouvez mapper "Afficher les factures impayées" sur SELECT * payment_schedules WHERE payment_status_flag = 'Y' .
5. Fournir des suggestions de saisie semi-automatique : pour aider les utilisateurs à savoir ce que le modèle logique est capable de répondre, ajoutez des exemples de variation comme décrit dans Fournir des suggestions de requête pour les utilisateurs de la boîte de dialogue SQL.
6. Fournir des données de routage : si votre brique Boîte de dialogue SQL a des intentions ou si elle se trouve dans un DA, vous devez ajouter des variations pour aider la brique à distinguer les requêtes de base de données. Reportez-vous à Routage des variations vers la conversation des boîtes de dialogue SQL.
7. Entraîner le modèle de traitement du langage naturel : pour intégrer des données d'entraînement au modèle de traitement du langage naturel, le développeur de compétences ou l'entraîneur d'IA clique sur l'icône Entraîner et clique sur Soumettre.
Configurer l'affichage des informations : l'expert en base de données et le développeur de compétences travaillent ensemble pour affiner l'affichage des résultats de chaque entité, comme décrit dans Configuration de la présentation des entités et des attributs. Par exemple, ils peuvent définir l'ordre de tri par défaut d'une entité, l'afficher sous forme de formulaire ou de table, définir les attributs minimum à inclure dans la sortie, ajouter des boutons et des liens aux résultats et ajouter des attributs qui affichent des données dérivées ou calculées.

Dans notre exemple, ils peuvent définir à la fois l'ordre de tri par défaut et les attributs minimum de l'entité de facture sur invoice_num, et définir les attributs par défaut sur invoice_num, invoice_date, pmt_status_flag et invoice_amount. Ils peuvent également ajouter un attribut age calculé à l'aide de la différence entre la date du jour et la date de la facture.
Configurer les règles de requête : l'expert en base de données et l'entraîneur d'IA travaillent ensemble pour définir les règles de requête, telles que le moment où utiliser la correspondance partielle et l'attribut à utiliser pour la mesure lorsque quelqu'un demande de comparer des lignes sans spécifier d'attribut à comparer. Reportez-vous à Définition de règles de requête.

Dans notre exemple, ils prévoient que les utilisateurs finaux demandent les 10 paiements les plus importants à effectuer. Ils configureront donc l'entité payment schedules de sorte qu'elle utilise due_date pour les comparaisons, et ils inverseront les comparaisons pour cet attribut de sorte que les dates antérieures soient supérieures aux dates ultérieures.
Test et réparation : l'entraîneur d'IA utilise le testeur de requête de la page Entités pour vérifier que les variations de test sont résolues en OMRQL souhaité et que la brique peut convertir OMRQL en SQL exécutable. Lorsque le testeur de requêtes ne peut pas convertir OMRQL en SQL, il demande des données d'entraînement. Dans de nombreux cas, vous pouvez résoudre ce problème en ajoutant la variation aux données d'entraînement et en l'associant à une instruction OMRQL. Reportez-vous à la section Test et réparation.
Surveiller et améliorer : une fois que la brique entre dans la phase de test bêta et au-delà, l'entraîneur d'IA, le développeur de compétences, le chef de projet et les parties prenantes peuvent surveiller en permanence les tests par lots et les données d'analyse pour voir les performances de la brique et identifier les domaines à améliorer. Reportez-vous à Surveillance et amélioration.

Se connecter au service de données

Pour pouvoir accéder à un service de données à partir d'une brique SQL Dialog, vous devez ajouter une intégration de service de données qui permet à Oracle Digital Assistant d'accéder au service de données. Vous n'avez besoin que d'une intégration par service de données.

Les intégrations ont été testées avec Oracle Database Cloud Service Enterprise Edition 12c et 19c Oracle Autonomous Transaction Processing et MySQL HeatWave Database Service avec MySQL version 8.

Remarque

Une fois le service créé, vous ne pouvez pas le modifier. Si le mot de passe change, vous devrez supprimer et recréer l'intégration du service de données.

Service de données Oracle

Pour vous connecter à une base de données Oracle, procédez comme suit :

Dans Digital Assistant, cliquez sur pour ouvrir le menu latéral, sur Paramètres, sur Services supplémentaires, puis sur l'onglet Données.
Cliquez sur + Ajouter un service.

Dans la boîte de dialogue Nouveau service de données, fournissez les informations de base suivantes :

Nom du champ	Description
Type de base de données	Sélectionnez Oracle.
Nom	Nom unique du service.
Description du service de données	Description facultative de l'intégration du service de données, telle qu'une description de la base de données ou de l'objectif.
Nom utilisateur :	Demandez à l'administrateur de base de données le nom utilisateur et le mot de passe permettant d'accéder aux tables dont les développeurs de briques ont besoin pour créer les entités composites de leur brique Boîte de dialogue SQL, comme décrit dans Création d'entités de requête pour modéliser le service de données.
Mot de passe	Mot de passe de l'utilisateur. Pour l'intégration à Oracle Digital Assistant, un mot de passe doit comporter au moins 14 caractères et au plus 30 caractères, et contenir au moins un caractère majuscule, un caractère minuscule et un chiffre. Il ne peut pas non plus commencer par un chiffre.

Cliquez sur Continuer pour configurer l'authentification de l'utilisateur final si votre service de données est configuré pour un accès basé sur les rôles. Voici une description des champs de cette page :

Nom du champ	Description
L'authentification de l'utilisateur final est requise	Sélectionnez cette option si votre service de données est configuré pour un accès basé sur les rôles.
Service d'authentification	Sélectionnez les services d'authentification que vous avez configurés dans Paramètres > Services d'authentification.
Identifiant de l'utilisateur final	Sélectionnez le type d'identifiant de l'utilisateur final.
Expression personnalisée	Si le type d'identificateur d'utilisateur final sélectionné est personnalisé, entrez une expression FreeMarker dans une variable de profil utilisateur qui représente l'identificateur d'utilisateur final. Pour plus d'informations et d'exemples, reportez-vous à Expressions pour les déclarations de profil OICD.

Cliquez sur Continuer pour ajouter les détails de connexion.
Sur la page Détails de connexion, sélectionnez De base ou Connexion au portefeuille cloud pour le type de connexion.
- Pour les bases de données à noeud unique et les bases de données compatibles RAC, vous devez sélectionner De base.
- Si vous êtes connecté à une base de données ATP, vous devez sélectionner Connexion de portefeuille cloud.

Si le type de connexion est De base, entrez les valeurs suivantes, que vous pouvez obtenir de l'administrateur de base de données :

Nom du champ	Description
Utiliser TLS	Déplacez ce commutateur en position ON si vous souhaitez utiliser TLS (Transport Layer Security) pour sécuriser la connexion. Remarque Si vous utilisez un certificat d'autorité de certification privée pour vous connecter à la base de données, cette option doit être activée.
Nom d'hôte	Entrez l'hôte du service de données. Enlevez le préfixe `https://`. Par exemple : `example.com`.
Port	Port qui autorise les connexions client à la base de données.
Identifiant du service	Effectuez l'une des opérations suivantes : Sélectionnez SID et entrez l'identificateur système Oracle de l'instance de base de données. Sélectionnez Nom de service et entrez le nom de service pour la base de données.
Adresse privée	Cette option apparaît uniquement si des adresses privées sont configurées dans votre instance Digital Assistant. Si vous êtes connecté à une adresse privée pour accéder au service, basculez l'adresse privée sur la position ON, puis sélectionnez-la dans la liste des adresses privées associées à l'instance. (L'utilisation d'une adresse privée vous permet d'accéder à un service qui n'est pas accessible directement à partir du réseau Internet public. Pour plus d'informations, reportez-vous à Adresse privée.)

Si le type de connexion est Connexion de portefeuille cloud, entrez les valeurs suivantes, que vous pouvez obtenir de l'administrateur de base de données :

Nom de champ	Description
Fichier de portefeuille	Recherchez et sélectionnez le fichier de portefeuille cloud contenant les informations d'identification client ou glissez-déplacez-le dans le champ.
Mot de passe du portefeuille	Entrez le mot de passe fourni lors du téléchargement du fichier de portefeuille. Pour l'intégration à Oracle Digital Assistant, un mot de passe de portefeuille doit comporter au moins 15 caractères et au plus 30 caractères, et doit contenir au moins un caractère majuscule, un caractère minuscule, un caractère spécial et un chiffre. Il ne peut pas non plus commencer par un chiffre.
Service	Sélectionnez le nom du service de base de données. Veillez à sélectionner un service avec une simultanéité d'accès aux services suffisamment élevée pour que les requêtes ne prennent pas plus de 30 secondes (à quel moment elles expirent). Les noms de service avec les suffixes `_tp` et `_tpurgent` sont généralement les choix les plus appropriés ici. Pour en savoir plus sur ces considérations, reportez-vous à Noms de service de base de données pour Autonomous Database et à Concurrence de service.
Adresse privée	Cette option apparaît uniquement si des adresses privées sont configurées dans votre instance Digital Assistant. Si vous êtes connecté à une adresse privée pour accéder au service, basculez l'adresse privée sur la position ON, puis sélectionnez-la dans la liste des adresses privées associées à l'instance. (L'utilisation d'une adresse privée vous permet d'accéder à un service qui n'est pas accessible directement à partir du réseau Internet public. Pour plus d'informations, reportez-vous à Adresse privée.)

Sur la page Propriétés avancées, si vous avez besoin d'un certificat d'autorité de certification privée pour vous connecter à la base de données, basculez l'option Utiliser la confiance privée sur la position ON et renseignez les autres champs requis.

Nom du champ	Description
Utiliser la confiance privée	Si vous utilisez un certificat CA privé pour vous connecter à la base de données, basculez-le sur la position ON. Ce commutateur n'est activé que si vous avez sélectionné Utiliser TLS sur la page Détails de connexion.
Ressource Certificates	Sélectionnez Self Managed.
Choisir un fichier PEM et Coller le texte PEM	Sélectionnez l'une de ces options pour fournir le certificat.

Cliquez sur Ajouter un service.

Vous pouvez désormais importer le schéma de base de données dans une brique afin de créer des entités de requête, ce qui permet aux utilisateurs d'interroger la base de données en langage naturel.

Expressions pour les déclarations de profil OICD

Si vous disposez d'une connexion à un service de données avec un accès basé sur les rôles et que vous avez sélectionné Personnalisé comme type d'identificateur utilisateur, vous devez fournir une expression FreeMarker à une variable de profil utilisateur qui représente l'identificateur utilisateur final, en tant que demande OpenID Connect (OIDC) standard ou personnalisée. Voici quelques exemples :

```
${userProfile.MyAuthService1.value.sub}
```

${userProfile.MyAuthService1.value["http://acme.com/custom_identifier"]}

Pour plus d'informations sur le fonctionnement des réclamations de profil dans OIDC et des exemples de réclamations, reportez-vous aux ressources suivantes :

MySQL Service de données

Dans Digital Assistant, cliquez sur pour ouvrir le menu latéral, sur Paramètres, sur Services supplémentaires, puis sur l'onglet Données.
Cliquez sur + Ajouter un service.

Dans la boîte de dialogue Nouveau service de données, fournissez les informations de base suivantes :

Nom du champ	Description
Type de base de données	Sélectionnez MySQL.
Nom	Nom unique du service.
Description du service de données	Description facultative de l'intégration du service de données, telle qu'une description de la base de données ou de l'objectif.
Type d'authentification	L'administrateur de base de données vous indiquera s'il faut sélectionner Par défaut, Kerberos ou O/S.
Nom utilisateur :	Demandez à l'administrateur de base de données le nom utilisateur et le mot de passe permettant d'accéder aux tables dont les développeurs de briques ont besoin pour créer les entités composites de leur brique Boîte de dialogue SQL, comme décrit dans Création d'entités de requête pour modéliser le service de données.
Mot de passe	Mot de passe de l'utilisateur. Pour l'intégration à Oracle Digital Assistant, un mot de passe doit comporter au moins 14 caractères et au plus 30 caractères, et contenir au moins un caractère majuscule, un caractère minuscule et un chiffre. Il ne peut pas non plus commencer par un chiffre.

Cliquez sur Continuer pour configurer les détails de connexion répertoriés dans le tableau suivant :

Nom du champ	Description
Utiliser TLS	Déplacez ce commutateur en position ON si vous souhaitez utiliser TLS (Transport Layer Security) pour sécuriser la connexion. Remarque Si vous utilisez un certificat d'autorité de certification privée pour vous connecter à la base de données, cette option doit être activée.
Nom d'hôte	Entrez l'hôte du service de données. Enlevez le préfixe `https://`. Par exemple : `example.com`.
Port	Port qui autorise les connexions client à la base de données.
Base de données	Nom de la base de données.
Adresse privée	Cette option apparaît uniquement si des adresses privées sont configurées dans votre instance Digital Assistant. Si vous êtes connecté à une adresse privée pour accéder au service, basculez l'adresse privée sur la position ON, puis sélectionnez-la dans la liste des adresses privées associées à l'instance. (L'utilisation d'une adresse privée vous permet d'accéder à un service qui n'est pas accessible directement à partir du réseau Internet public. Pour plus d'informations, reportez-vous à Adresse privée.)

Nom du champ	Description
Utiliser la confiance privée	Si vous utilisez un certificat CA privé pour vous connecter à la base de données, basculez-le sur la position ON. Ce commutateur n'est activé que si vous avez sélectionné Utiliser TLS sur la page Détails de connexion.
Ressource Certificates	Sélectionnez Self Managed.
Choisir un fichier PEM et Coller le texte PEM	Sélectionnez l'une de ces options pour fournir le certificat.

Cliquez sur Ajouter un service.

Vous pouvez désormais importer le schéma de base de données dans une brique afin de créer des entités de requête, ce qui permet aux utilisateurs d'interroger la base de données en langage naturel.

Création de la brique de boîte de dialogue SQL

Pour créer une brique Boîte de dialogue SQL, il vous suffit de créer une brique avec le mode Boîte de dialogue défini sur Visuel.

Créer des entités de requête pour modéliser le service de données

Pour activer les requêtes de service de données dans une brique Boîte de dialogue SQL, vous devez importer des informations sur le modèle physique d'un service de données (les tables ou les vues et leurs colonnes) afin de créer un modèle logique de base. Lors de l'import, la brique ajoute des entités de requête au modèle logique, où chaque entité de requête représente une table physique.

Remarque

Une brique ne peut pas avoir plus de 50 entités et attributs de requête. Par exemple, vous pouvez avoir 5 entités de requête combinées avec 45 attributs.

Lorsque vous entraînez votre brique, elle utilise les informations des entités de requête pour créer un modèle pour l'analyseur de langage naturel, ce qui lui permet de traduire les variations utilisateur en OMRQL. OMRQL est un langage de requête similaire à SQL, mais basé sur des modèles d'objet, qui, dans ce cas, sont les entités de requête.

Avant de commencer, procédez comme suit :

Une brique créée à l'aide du mode Visuel.
Intégration de service de données pour la connexion au service de données, comme décrit dans Connexion au service de données.

Pour créer des entités de requête pour les tables souhaitées dans votre service de données, procédez comme suit :

Sur la page Entités, cliquez sur Plus, puis sélectionnez Importer à partir du service de données.

La boîte de dialogue Importer des entités de requête apparaît.
Sélectionnez le service de données, puis les tables et les attributs à utiliser dans la brique.
Cliquez sur Importer.

La brique ajoute des entités de requête pour les tables sélectionnées. Il définit les noms principaux d'entité et d'attribut en fonction des noms canoniques. Par exemple, si le nom canonique est "invoice_num", le nom principal sera "numéro de facture".
Pour chaque entité de requête ajoutée, sélectionnez l'entité, cliquez sur l'onglet Configuration et vérifiez que la clé primaire est définie dans la section Mise en correspondance de back-end.

A ce stade, vous pouvez tester les requêtes à l'aide des noms principaux des entités et des attributs, tels que "show factures where invoice num is 12345". Mais vous devez d'abord cliquer sur , puis, une fois l'opération terminée, vous pouvez cliquer sur Tester les requêtes pour essayer les variations, ou sur Aperçu pour effectuer un test dans le testeur de conversation.

Etant donné que vous utilisez une brique de boîte de dialogue SQL minimale, vous pouvez vous entraîner avec l'entraîneur Ht ou l'entraîneur Tm. Cependant, après avoir ajouté des suggestions de saisie semi-automatique, des données de routage et des données d'entraînement personnalisées, l'entraîneur Tm produit des résultats plus précis.

L'étape suivante consiste à apprendre à la brique comment les utilisateurs finals se réfèrent aux entités et aux attributs. Reportez-vous à Formation de la brique à la conversion des variations de langage naturel en SQL.

Entraîner la brique à la conversion des variations de langage naturel en SQL

En tant qu'entraîneur d'IA, votre travail consiste à permettre à l'analyseur de langage naturel de traduire les variations de langage naturel telles que "nombre de factures dont la date d'échéance est antérieure au 15/12/22" dans une requête OMRQL pour extraire la réponse de la source de données sous-jacente (modèle physique). Pour ce faire, vous créez un modèle logique intuitif des données qui reflète étroitement le langage naturel.

Une fois le modèle logique créé par l'import à partir de la source de données, vous utilisez des noms principaux, des synonymes, des listes de valeurs et des variations pour aider l'analyseur de langage naturel de la brique à associer des expressions de langage naturel aux tables et colonnes du modèle physique.

Pour enseigner à la brique les différentes façons dont les personnes se réfèrent aux objets, vous ajoutez des noms principaux et des synonymes, comme décrit dans Fournir des données de formation via des noms et des synonymes. Par exemple, vous voudrez peut-être enseigner à la brique que les utilisateurs utilisent "numéro de facture" pour faire référence à la colonne invoice_num, et vous voudrez peut-être également ajouter "numéro de facture" et "numéro de référence" en tant que synonymes.
Pour aider la brique à identifier les valeurs d'attribut dans une variation, vous devez créer des exemples de liste de valeurs et les associer à des attributs, comme décrit dans Fournir des données d'entraînement via des listes de valeurs. Par exemple, vous pouvez créer une liste de valeurs contenant les statuts de paiement réels et l'associer à l'attribut payment status de la facture.
Pour aider la brique à identifier les valeurs d'attribut en fonction de modèles, vous devez créer des entités d'expression régulière et les associer à des attributs, comme décrit dans Fournir des données d'entraînement via des expressions régulières. Par exemple, vous pouvez créer une entité d'expression régulière avec l'expression (\\d{1, 2}|(0|1)\\d{2}|2[0-4]\\d|25[0-5]) et l'associer à l'attribut ip_address.
Lorsque la brique ne parvient pas à traduire correctement une variation en OMRQL, vous pouvez ajouter une mise en correspondance variation-OMRQL à l'ensemble de données d'entité de requête, comme décrit dans Fournir des données d'entraînement via des variations et Tester et réparer. Vous pouvez également ajouter des variations pour aider la brique à savoir quand acheminer une variation vers le flux qui la traite en tant qu'exécution SQL (c'est-à-dire qu'elle est convertie en OMRQL, puis envoie une requête SQL à la source de données).

Fournir des données de formation via des noms et des synonymes

Pour aider une brique Boîte de dialogue SQL à associer des expressions en langage naturel à la structure de données sous-jacente (modèle physique), commencez par prendre les variations identifiées que la brique doit gérer (corps d'entraînement) et analysez-les pour découvrir les différentes façons dont les utilisateurs finals font référence aux entités et aux attributs.

Par exemple, supposons que vous disposiez des variations suivantes dans votre corpus d'entraînement :

Afficher les factures dont les soldes non réglés sont supérieurs à zéro.
Quel est le montant dû pour la référence 12656 ?

Ici, vous voyez que les personnes utilisent "solde restant dû" et "montant dû" pour se référer à la colonne amount_remaining. Vous voyez également que la "référence" est une façon dont les gens se réfèrent à invoice_num.

Outre le corpus d'entraînement, vous pouvez également utiliser des variations crowdsourcées de vos utilisateurs cible pour obtenir plus d'expressions et les analyser également.

Après avoir compilé la liste des références des personnes aux entités et aux attributs, choisissez le terme à utiliser pour le nom principal de chaque entité et attribut. Il doit s'agir des noms les plus proches des utilisations les plus courantes. Lorsque vous choisissez le nom, tenez compte du fait que le modèle de traitement du langage naturel prêt à l'emploi ne comprendra probablement pas les relations propres au domaine. Par exemple, il ne comprendra pas automatiquement que le numéro de facture et la référence font référence à la même chose. Etant donné que le numéro de facture est couramment utilisé et qu'il est également le plus proche des autres termes couramment utilisés tels que numéro de facture et numéro de facture, vous devez en faire le nom principal.

Traitez les autres termes comme des synonymes. Dans l'exemple ci-dessus, vous devez ajouter référence, numéro de facture et numéro de facture à la liste des synonymes.

Notez que le nom principal est le nom par défaut des en-têtes et des libellés de colonne de résultat, mais vous pouvez le modifier dans l'onglet Présentation.

A l'aide de votre liste, vous créez les données d'entraînement sur la page Entités.

Pour définir le nom principal et les synonymes de l'entité, ouvrez l'onglet Configuration de l'entité et développez Langage naturel.
Pour définir le nom principal et les synonymes de l'attribut, ouvrez l'onglet Langue naturelle de l'attribut.

Remarque

Lors du traitement des variations, l'analyseur de langage naturel ne prend pas en compte les noms canoniques du modèle physique, c'est-à-dire qu'il ne regarde pas les noms de table et de colonne. Il utilise uniquement les mappings de langage naturel que vous définissez à l'aide de noms et de synonymes (modèle logique).

Fournir des données de formation via des listes de valeurs

Vous pouvez améliorer la précision de l'analyseur de langage naturel en associant des attributs à des listes de valeurs ou des entités dynamiques. Cela permet à l'analyseur d'identifier un attribut en fonction de ses valeurs connues. Utilisez Entité référencée dans l'onglet Informations générales de l'attribut pour associer l'attribut aux valeurs de l'entité de référence. Pour les entités de liste de valeurs, vous pouvez créer automatiquement l'entité, importer les valeurs du service de données et l'associer en tant qu'entité référencée en une seule étape.

Lorsque vous décidez d'utiliser une liste de valeurs ou une entité dynamique pour stocker les valeurs, déterminez si l'entité est ouverte ou fermée.

Une liste ouverte est une liste infinie ou dynamique (ou les deux). Pour les listes ouvertes, envisagez de créer et de tenir à jour une entité dynamique plutôt qu'une liste de valeurs. Si vous choisissez d'utiliser une liste de valeurs, vous devez la classer pour vous assurer qu'elle contient au moins les valeurs les plus couramment utilisées. Par exemple, pour une liste de fournisseurs qui croît probablement au fil du temps, vous voudrez que la liste inclue vos fournisseurs les plus fréquemment utilisés. En effet, les requêtes sur un fournisseur sans utiliser le mot "fournisseur", par exemple "afficher l'indicateur de synthèse pour Seven Corporation", ne correspondent pas si cette valeur ne figure pas dans la liste de valeurs. Vous augmentez ainsi la fréquence des résolutions correctes en incluant au moins les valeurs les plus fréquemment utilisées.
Une liste fermée est une liste finie statique. Elles sont idéales pour les entités de liste de valeurs.

Pour les listes de valeurs et les entités dynamiques, ajoutez des versions de synonymes au singulier et au pluriel (le cas échéant) pour chaque valeur d'entité afin d'indiquer la façon dont les utilisateurs finals se référeront à la valeur.

Les synonymes sont particulièrement importants lorsque la liste contient des valeurs que les utilisateurs finaux n'utilisent généralement pas. Prenons, par exemple, cette liste de statuts de paiement valides. Les utilisateurs seront beaucoup plus susceptibles d'utiliser des mots tels que payé, non payé et partiellement payé que d'utiliser Y, N et P. L'ajout de ces mots en tant que synonymes permet de s'assurer que le traitement du langage naturel reconnaît que les utilisateurs font référence à l'attribut de statut de paiement.

Valeurs du statut du paiement	synonymes
Y	payé
N	impayé, non payé
P	partiel, partiellement payé, non payé

Lorsqu'un terme décrit plusieurs valeurs d'entité, ajoutez-le en tant que synonyme. Par exemple, N et P indiquent que la facture est impayée. Si vous ajoutez "non payé" en tant que synonyme pour les deux statuts, "Afficher les factures non payées" extrait les factures dont la valeur payment_status est N ou P.

Pour les entités dynamiques, créez l'entité, puis utilisez Entité référencée dans l'onglet Informations générales de l'attribut pour associer l'attribut à la liste.

Pour les listes de valeurs, vous pouvez créer une liste de valeurs à partir du service de données et l'associer à une entité en procédant comme suit :

Sur la page Entités, modifiez l'attribut et accédez à l'onglet Informations générales.
Sélectionnez Entité dans la liste déroulante Type.
Cliquez sur Si l'entité souhaitée n'existe pas, vous pouvez générer une entité de liste de valeurs basée sur la mise en correspondance en arrière-plan en cliquant ici. La liste de valeurs est créée et alimentée à partir du service de données, et l'entité référencée pointe vers la nouvelle liste de valeurs.
(Facultatif) Pour augmenter les chances que les entrées utilisateur correspondent à une valeur de la liste, ouvrez l'entité de liste de valeurs et activez l'option Correspondance partielle. Sinon, il utilise une correspondance stricte, ce qui signifie que la saisie utilisateur doit correspondre exactement aux valeurs et aux synonymes. Par exemple, "voitures" ne correspondra pas à "voiture".

La mise en correspondance partielle utilise la création de mots pour identifier les attributs de la requête. Par exemple, "pound" correspond à "pounds", "hold" correspond à "on hold", "besed approval" correspond à "besoins approval", et "rent-lease" correspond à "rent Lease".

Notez que la correspondance partielle ne fonctionne pas pour "_" et " ?". En outre, le rapprochement partiel ne fonctionne pas. Par exemple, "Seven" ne correspond pas à "Seven Corporation". Si vous devez activer la mise en correspondance pour ces chaînes, ajoutez-les à la liste des synonymes.
Cliquez sur Appliquer pour enregistrer les modifications.

Remarque

Si une valeur de la table physique du service de données se termine par un point, un point d'interrogation ou des espaces, ces caractères ne sont pas inclus dans la liste de valeurs car ils ne sont pas autorisés pour les noms canoniques.

Fournir des données de formation via des expressions régulières

Si les valeurs d'un attribut doivent correspondre à un certain modèle, vous pouvez aider l'analyseur de langage naturel à identifier les valeurs de cet attribut en associant l'attribut à une entité d'expression régulière.

Cela peut être utile lorsque toutes les valeurs doivent suivre un modèle spécifique et que l'ensemble des valeurs valides est trop grand pour une liste de valeurs ou infini. Par exemple, pour un attribut ip_address, vous pouvez l'associer à une entité d'expression régulière nommée IpAddress, qui contient l'expression régulière (\\d{1,2}|(0|1)\\d{2}|2[0-4]\\d|25[0-5]).

Notez que, comme pour les listes de valeurs, si plusieurs attributs du modèle peuvent être associés à la même expression régulière, les utilisateurs devront fournir un contexte suffisant dans leur requête pour distinguer les deux (ou plusieurs) attributs.

Pour associer un attribut à une expression régulière :

Sur la page Entités, cliquez sur + Ajouter une entité, sélectionnez Expression régulière dans la liste déroulante Type, entrez l'expression régulière, puis cliquez sur Créer.

Veillez à créer l'expression régulière de manière à empêcher l'analyseur de langage naturel d'associer des valeurs non liées à l'attribut.
Sélectionnez l'entité avec l'attribut à associer à l'expression régulière, modifiez l'attribut et accédez à l'onglet Informations générales.
Sélectionnez Entité dans la liste déroulante Type.
Dans la liste déroulante Entité référencée, sélectionnez l'entité d'expression régulière.
Cliquez sur Appliquer pour enregistrer les modifications.

Fournir des données de formation via des variations

En tant qu'entraîneur d'IA, vous rencontrerez des variations de langues naturelles que la brique ne peut pas traduire dans OMRQL. Par exemple, le modèle peut ne pas être en mesure de gérer les synonymes propres au domaine qui ne semblent pas être étroitement liés au nom principal. Un autre exemple est lorsque le modèle n'est pas en mesure de faire la distinction entre deux entités similaires. Dans ce cas, vous pouvez utiliser les données d'entraînement pour apprendre à la brique à analyser correctement la variation dans OMRQL.

L'ajout aux données d'entraînement est souvent appelé formation personnalisée. Vous utilisez un entraînement personnalisé pour apprendre au modèle à associer des mots et des expressions à des attributs, des entités et des mots-clés OMRQL dans le contexte d'une variation complète en mettant en correspondance la variation avec OMRQL.

Pour chaque scénario que vous corrigez, commencez par 20 variations et ajoutez-en d'autres si nécessaire. Etant donné qu'un trop grand nombre d'exemples peut amener le modèle à surestimer les attributs et les opérateurs, vous devez vous concentrer sur un plus petit ensemble de variations diverses plutôt que sur un grand ensemble de variations similaires de moindre qualité. La limite est de 120 variations par brique.

Toutes les valeurs de l'instruction OMRQL doivent correspondre exactement à la valeur et au format de la base de données. Prenons, par exemple, la variation "qui est l'employé dont le nom est Jones". Si les valeurs de base de données de l'attribut name sont toutes en majuscules, la valeur name doit également être toutes en majuscules. Il s'agit de "SELECT * FROM Emp WHERE name = 'JONES'".

Lorsque la variation que vous mettez en correspondance utilise un synonyme pour la valeur de base de données réelle, ce synonyme doit être défini pour la valeur dans une liste de valeurs et OMRQL doit utiliser la valeur de base de données réelle. Par exemple, si la variation est "show the department which location is the big apple", "big apple" doit être défini dans la liste de valeurs dept_loc en tant que synonyme de la valeur "NEW YORK", et OMRQL doit être "SELECT * FROM Dept WHERE loc = 'NEW YORK'".

Vous pouvez ajouter des variations qui contiennent des dates absolues, telles que "factures dues le 5 janvier 2022", mais n'utilisez pas de variations avec des dates ou des dates relatives sans l'année. Par exemple, si la variation est "factures dues aujourd'hui", la date du jour est codée en dur dans OMRQL en tant que SELECT * FROM factures WHERE due_date = '2022-01-01'. En outre, si vous utilisez une date relative telle que "aujourd'hui", vous risquez d'obtenir une erreur indiquant que les dates relatives ne sont pas prises en charge.

Voici quelques bonnes pratiques pour les variations d'entraînement personnalisées :

Equilibrer le nombre de variations : certains des scénarios les plus complexes peuvent nécessiter plus de variations que les simples, mais essayez d'équilibrer le nombre de variations par scénario.
Equilibrer l'entraînement d'attributs et d'entités similaires : si vous disposez de deux attributs similaires et que vous devez fournir des données d'entraînement personnalisées pour l'un d'entre eux, vous devez également fournir la même quantité de données d'entraînement pour l'autre. Lorsque les données d'entraînement se concentrent uniquement sur l'un des attributs similaires, le modèle risque de surestimer cet attribut par rapport à son équivalent. Il en va de même pour les entités similaires. Par exemple, la devise du paiement et la devise de la facture sont des attributs similaires. Si la devise du paiement est surreprésentée dans les données d'entraînement, le modèle peut prévoir la devise du paiement même lorsque la variation demande la devise de la facture.

Lorsque vous devez enseigner au modèle comment faire la distinction entre deux attributs similaires ou étroitement liés, équilibrez la pondération de l'importance en fournissant la moitié des variations pour un attribut et la moitié des variations pour l'autre.

Variez les variations qui font référence à ces attributs similaires. Par exemple, voici des paires de variations contrastées pour aider le modèle à faire la distinction entre amount_remaining et amount_paid :
- indiquer le montant restantpour les factures approuvées
- afficher le montant payé pour les factures approuvées
- afficher le montant à payer total au fournisseur AAD
- calculer le montant total payé au fournisseur AAD
- quel est le montant dû sur les factures au fournisseur AAD
- répertorier le montant payé des factures au fournisseur AAD
Equilibrer l'entraînement des valeurs correspondant aux noms principaux ou aux synonymes : Supposons, par exemple, que votre modèle a un attribut manager et que "manager" est également une valeur pour l'attribut job de l'employé. Si vous voulez ajouter le nombre de responsables aux données d'entraînement, vous devez équilibrer ces données d'entraînement avec des variations qui utilisent l'attribut manager, telles que "Qui est le responsable de l'employé Adam Smith", ainsi qu'avec les variations qui utilisent le responsable job, telles que "Afficher tous les responsables". De cette façon, le modèle peut apprendre à différencier les deux usages. Si vous n'incluez pas d'exemples pour les deux types d'utilisation, la brique peut prédire une utilisation plutôt que l'autre.
Diversifier des expressions : les meilleures pratiques de formulation pour diverses données personnalisées sont similaires à celles des variations d'intention :
- Utilisez des phrases complètes.
- Utilisez des verbes différents. Par exemple : view, list, show, tell et see.
- Utilisez divers synonymes et paraphrases en plus du nom de l'entité ou de l'attribut.
- Utilisez des pronoms différents. Par exemple : montrez-moi, pouvons-nous voir, dites-nous, je veux.
- Variez la structure de la phrase. Par exemple, placez la valeur d'attribut près du début, du milieu et de la fin des phrases.
- Si vous disposez de variations avec une agrégation, telle que AVG, ajoutez également des variations avec d'autres opérateurs.
- Si possible, utilisez différentes clauses, telles que les clauses group by et where avec les conditions AND et OR.
Diversifier les valeurs : lorsque vous utilisez plusieurs valeurs dans les variations de votre scénario, le modèle est mieux en mesure de reconnaître différentes valeurs. Inclure des valeurs avec des longueurs de mot différentes. Incluez certaines valeurs avec des caractères spéciaux tels que "/" et "-". Incluez quelques valeurs avec des mots-clés spéciaux tels que "and".
Incluez un mélange de valeurs connues et inconnues. Pour les attributs de liste de valeurs, utilisez un ensemble représentatif de valeurs d'attribut (mais pas toutes) pour entraîner que les correspondances de liste de valeurs sont des signaux importants. En outre, pour les listes de valeurs qui ne sont pas fermées, incluez des valeurs qui ne figurent pas dans la liste de valeurs pour lui apprendre à associer également des phrases particulières à l'attribut.

Pour ajouter une variation mise en correspondance aux données d'entraînement, procédez comme suit :

Si le bouton Entraîner comporte un badge rouge, cliquez sur et entraînez-vous à l'aide de l'entraîneur Tm.
Sur la page Entités, accédez à l'onglet Ensemble de données et cliquez sur Entités de requête.
Cliquez sur l'onglet Données de formation.
Cliquez sur Ajouter une variation.

La boîte de dialogue Créer une variation s'affiche.
Saisissez la variation et cliquez sur Continuer.

La boîte de dialogue affiche la requête OMRQL pour la variation. Si elle ne peut pas traduire la variation dans la requête, celle-ci sera vide.

Si la brique n'a pas été entraînée, elle ne peut pas traduire la variation en requête OMRQL.
Vérifiez la requête et corrigez-la si elle est incorrecte.

Pour obtenir des mots-clés et des exemples OMRQL, reportez-vous à Référence OMRQL.
Cliquez sur Terminé pour ajouter la variation mise en correspondance aux données d'entraînement.

Fournir des suggestions de requête pour les utilisateurs de la boîte de dialogue SQL

Vous pouvez aider les utilisateurs à se familiariser avec les requêtes de base de données qu'ils peuvent effectuer en fournissant des suggestions de saisie semi-automatique. Ces suggestions fournissent des conseils sur les types de questions auxquels le modèle logique est capable de répondre. Les variations aident également la brique à effectuer le routage.

Pour créer des suggestions de saisie semi-automatique pour une brique Boîtes de dialogue SQL, procédez comme suit :

Si le bouton Entraîner comporte un badge rouge, cliquez sur et entraînez-vous à l'aide de l'entraîneur TM.
Sur la page Entités, accédez à l'onglet Ensemble de données et cliquez sur Entités de requête.
Cliquez sur l'onglet Suggestions de saisie semi-automatique.
Cliquez sur Ajouter une variation.

La boîte de dialogue Créer une variation s'affiche.
Saisissez la variation, cliquez en dehors de la zone de texte, puis cliquez sur Continuer.

La boîte de dialogue affiche la requête OMRQL pour la variation. S'il ne peut pas convertir la variation en requête, la requête sera vide.

Si la brique n'a pas été entraînée, elle ne peut pas traduire la variation en requête OMRQL.
Vérifiez la requête et corrigez-la si elle est incorrecte.

Pour obtenir des mots-clés et des exemples OMRQL, reportez-vous à Référence OMRQL.
Cliquez sur Terminé pour ajouter la variation mise en correspondance aux suggestions de saisie semi-automatique.

Acheminer les variations vers la conversation des boîtes de dialogue SQL

Si votre brique comporte des intentions ou qu'elle se trouve dans un DA, comme pour les intentions, elle a besoin de variations pour l'aider à acheminer les requêtes SQL vers la conversation des boîtes de dialogue SQL. Le mécanisme de routage utilise les suggestions de saisie semi-automatique, les données d'entraînement, les variations de routage générées et les variations de routage conçues à la main pour apprendre à reconnaître les requêtes SQL. Vous pouvez voir chaque type de variation dans les onglets distincts de la page Entités de requête - Ensemble de données.

Dans l'onglet Données de routage générées, vous pouvez générer rapidement 100 variations de routage basées sur le modèle logique, comme décrit dans Générer des données de routage de boîtes de dialogue SQL. Vous pouvez ensuite les vérifier, les modifier si nécessaire, puis les approuver ou les annuler. Ceux que vous approuvez sont ajoutés à l'onglet Données de routage combinées et marqués comme synthétiques ou, si vous les avez modifiés, affinés.

L'onglet Données de routage combinées répertorie tous les types d'ensemble de données. En outre, vous pouvez ajouter manuellement des données de routage artisanales, comme décrit dans la section Données de routage des boîtes de dialogue SQL artisanales.

Notez que le nombre total de variations d'écriture automatique, d'entraînement, générées et conçues à la main ne peut pas dépasser 10 000. Si vous dépassez cette limite, le message "Le nombre maximal d'exemples de corpus pour ce bot (10000) a été atteint" apparaît. Il existe également une limite de 120 variations d'entraînement.

Pour en savoir plus sur les suggestions de saisie semi-automatique et les données de formation, reportez-vous à Fourniture de suggestions de requête pour les utilisateurs de la boîte de dialogue SQL et à Fourniture de données de formation via des variations.

Conseil :

Chaque entité dispose d'un onglet de jeu de données dans lequel vous pouvez voir les variations qui utilisent des attributs de cette entité spécifique.

Générer les données de routage des boîtes de dialogue SQL

Si votre brique comporte des intentions ou se trouve dans un DA, comme pour les intentions, elle a besoin de variations pour l'aider à acheminer les requêtes SQL vers la conversation des boîtes de dialogue SQL. Outre les suggestions de saisie semi-automatique, les données d'entraînement et les données de routage artisanales, le mécanisme de routage utilise les variations de routage générées que vous créez à partir de l'onglet Données de routage générées de l'ensemble de données Entités de requête. Les variations générées représentent une large couverture de questions sur toutes les entités de requête du modèle logique.

Pour générer des données de routage :

Si le bouton Entraîner comporte un badge rouge, cliquez sur et entraînez-vous à l'aide de l'entraîneur TM.
Sur la page Entités, accédez à l'onglet Ensemble de données et cliquez sur Entités de requête.
Cliquez sur l'onglet Données de routage générées.
Cliquez sur Générer.

La boîte de dialogue Générer des données de gamme apparaît.
Dans le champ Sélectionner des entités, sélectionnez Tout. La première fois que vous générez les données de routage, vous devez générer des données pour toutes les entités. Après avoir généré l'ensemble initial, vous pouvez revenir en arrière et générer des entités spécifiques si nécessaire.
Cliquez sur Générer.

La brique génère 100 variations, qui reflètent les questions auxquelles le modèle logique peut répondre.

Description de l'image qe-generated-routing-data.png
Vérifiez les données générées et modifiez celles qui doivent être affinées.

Conseil :
La variation n'est pas modifiable si elle a été approuvée. Si vous voulez modifier une variation approuvée, annulez son approbation, modifiez-la, puis approuvez-la à nouveau.
Supprimez les entrées si nécessaire et approuvez le reste.

Les variations approuvées sont ajoutées aux données de routage combinées. Si vous avez modifié une variation, son sous-type de routage dans l'onglet Données de routage combinées est Défini. Sinon, il est synthétique.

Boîte de dialogue SQL Handcraft - Données d'acheminement

S'il existe des requêtes SQL valides que l'assistant numérique ou la brique n'achemine pas vers la conversation SQL, vous devez ajouter ces variations aux données de routage à partir de l'onglet Données de routage combinées de la page Entités de requête, ensemble de données.

Pour ajouter des données de routage artisanales :

Si le bouton Entraîner comporte un badge rouge, cliquez sur et entraînez-vous à l'aide de l'entraîneur TM.
Sur la page Entités, accédez à l'onglet Ensemble de données et cliquez sur Entités de requête.
Cliquez sur l'onglet Données de routage combinées.
Cliquez sur Ajouter une variation.

La boîte de dialogue Créer une variation apparaît.
Saisissez la variation, puis cliquez en dehors de la zone de texte.
Cliquez sur Continuer.
Consultez la requête OMRQL pour vérifier que ses résultats répondent à la requête. Si ce n'est pas le cas, corrigez la requête, puis cliquez sur Réinterpréter. Reportez-vous à Référence OMRQL pour connaître les mots-clés de requête OMRQL.
Cliquez sur Terminé.

La variation est ajoutée aux données avec le sous-type de routage défini sur Handcrafted.

Configurer la présentation des entités et des attributs

Voici ce que vous pouvez faire pour contrôler quand et comment les lignes d'entité et les attributs sont affichés dans les résultats :

En règle générale, l'expert en base de données et le concepteur de conversations travaillent ensemble sur cette tâche, car l'un possède une expertise en matière de schéma de base de données et l'autre est familiarisé avec les attentes des utilisateurs.

Vous pouvez tester vos modifications en cliquant sur Aperçu pour ouvrir le testeur de conversation et en saisissant une variation afin d'extraire les données appropriées.

Conseil :

La plupart des modifications que vous apportez nécessiteront un nouvel entraînement de l'analyseur de langage naturel. Lorsque vous testez vos modifications, si l'icône Entraîner comporte un badge rouge (

), vous devez d'abord cliquer sur Entraîner et terminer le processus de formation.

Configurer l'affichage du formulaire ou de la table

La brique peut afficher les résultats de l'entité sous forme de tableau, de formulaire ou de tableau (dans lequel vous pouvez développer une ligne pour afficher plus de détails en mode de formulaire). Utilisez les champs de conversion de présentation de l'onglet Présentation de l'entité pour configurer le moment où les résultats doivent être affichés dans chaque mode.

Par défaut, la brique affiche chaque ligne de la réponse sous forme de formulaire, sauf si le nombre de lignes dépasse un seuil que vous indiquez pour Utiliser la présentation de formulaire pour ce nombre de lignes ou moins. Voici des exemples de réponse en mode formulaire et en mode table :

La description de sql-results-form.png suit
Description de l'image sql-results-form.png

La description de sql-results-table.png suit
Description de l'image sql-results-table.png

Dans le cas où le nombre de colonnes dépasse un seuil, la brique affiche un formulaire de tableau. Avec un formulaire de tableau, seul le nombre de colonnes spécifié est affiché et l'utilisateur peut développer le formulaire pour voir les autres attributs. Utilisez Passer à la présentation de formulaire de tableau lorsque le nombre de colonnes dépasse ce nombre pour indiquer le seuil. Voici un exemple de présentation de formulaire de tableau pour le seuil de colonne de 2.

La description de sql-results-table-form.png suit
Description de l'image sql-results-table-form.png

Afficher une ou deux sections horizontales dans le formulaire

Par défaut, en mode formulaire, la brique affiche tous les attributs de résultat les uns en dessous des autres. Pour économiser de l'espace, vous pouvez définir le nombre de sections horizontales dans la présentation de formulaire sur 2 pour afficher deux colonnes d'attributs.

Définir le titre des résultats

Par défaut, la brique utilise le nom de l'entité de requête pour le titre des résultats, mais vous pouvez utiliser le nom d'affichage de l'onglet Présentation pour définir un autre titre.

Notez qu'une fois le nom d'affichage défini, vous ne pouvez pas effacer le champ.

Définir l'ordre de tri par défaut d'une entité

Vous pouvez indiquer un ordre de tri par défaut pour la brique à utiliser chaque fois que la variation de l'utilisateur n'en indique pas. Pour définir la valeur par défaut, accédez à l'onglet Général de l'entité, cliquez sur Ajouter un ordre d'attributs, sélectionnez un attribut et sélectionnez son ordre (croissant ou décroissant). Vous pouvez continuer à cliquer sur Ajouter un ordre d'attributs pour ajouter d'autres attributs à l'ordre de tri.

Définir les attributs à inclure lorsqu'ils ne sont pas spécifiés par la variation

Si la variation ne nomme aucun attribut, vous souhaitez probablement que les résultats incluent certains champs essentiels. Vous pouvez utiliser Attributs par défaut dans l'onglet Présentation de l'entité pour spécifier ces champs. Par exemple, pour une entité invoices, vous pouvez afficher invoice_num, invoice_date et invoice_amount lorsqu'aucun attribut n'est nommé.

Vous ne pouvez pas ajouter d'attributs de type entité de requête à la liste d'attributs par défaut.

Définir les attributs à toujours inclure dans les résultats

Lorsqu'une variation identifie des attributs spécifiques, vous pouvez souhaiter que le résultat inclue non seulement les attributs demandés, mais également un contexte. Par exemple, si quelqu'un saisit "Afficher les montants de facture", les données n'auront aucun sens si elles affichent uniquement les valeurs invoice_amount, et non un contexte d'identification tel que invoice_num. Utilisez Attributs minimum dans l'onglet Présentation de l'entité pour identifier les attributs minimum.

Vous ne pouvez pas ajouter des attributs de type entité de requête à la liste d'attributs minimum.

Configurer la taille de page de résultats

Utilisez le nombre maximal de lignes par page de l'onglet Présentation de l'entité pour définir le nombre de lignes à afficher simultanément.

L'utilisateur peut cliquer sur des boutons pour parcourir les résultats.

Ajouter des boutons et des liens aux résultats

Vous pouvez ajouter des boutons et des liens aux résultats d'une entité de requête au niveau global et au niveau de la ligne. Une action sur ligne apparaît sur chaque ligne et une action globale apparaît sous les résultats.

Par exemple, pour une entité d'employé, vous pouvez ajouter une action globale qui renvoie à la page de recherche d'employés de la société. Au niveau ligne, vous pouvez ajouter une action pour une requête de suivi commune, telle qu'une requête sur le service de l'employé.

Vous ajoutez des actions à partir de l'onglet Présentation de l'entité. Si vous avez plusieurs actions, vous pouvez indiquer l'ordre dans lequel elles apparaissent. Pour les types d'action QUERY, vous devez fournir une requête OMRQL. Pour les types d'action URL, vous devez définir l'URL.

Pour les actions de suivi au niveau ligne, vous pouvez utiliser ${row.attributeName} pour référencer les valeurs d'attribut de chaque ligne. Par exemple, select * from Emp WHERE dept.loc = "${row.loc}". Lors de l'exécution, le bouton de chaque ligne aura une valeur différente pour la requête. Cette syntaxe n'est disponible que pour les actions de niveau ligne.

Vous pouvez éventuellement restreindre l'affichage de l'action. Par exemple, vous pouvez avoir une action de ligne pour afficher les collaborateurs directs d'un salarié, qui ne doit s'afficher que si l'emploi du salarié est responsable. Pour ce faire, basculez Expression de visibilité sur Activé et fournissez une expression FreeMarker, telle que ${row.job = 'MANAGER'}.

Remarque

Les actions de ligne apparaissent sous forme de boutons ou de liens dans chaque ligne d'une présentation de formulaire ou de tableau. Toutefois, elles n'apparaissent pas dans les présentations de tableau.

Ajouter un attribut personnalisé

Vous pouvez ajouter vos propres attributs personnalisés pour afficher des informations supplémentaires, telles que des valeurs dérivées ou calculées.

Dans l'onglet Attributs de la page d'entité, cliquez sur + Ajouter un attribut et indiquez un nom et un type canoniques.
Dans l'onglet Langage naturel, indiquez un nom principal et, éventuellement, ajoutez des synonymes.
Dans l'onglet Mise en correspondance de back-end, sélectionnez Expression SQL et ajoutez l'expression.

Si l'expression référence une colonne, utilisez le nom de la colonne du modèle physique (schéma de base de données) et ajoutez le préfixe ${alias}. Par exemple, pour une entité invoices, vous pouvez ajouter un attribut amount_to_pay avec l'expression ${alias}invoice_amount + ${alias}discount_taken où :

invoice_amount et discount_taken sont des noms de colonne physique existants dans la table invoices.
La nouvelle colonne dérivée amount_to_pay est la somme des valeurs des colonnes physiques invoice_amount et discount_taken.

Vous pouvez utiliser ce tableau pour déterminer le type à utiliser pour l'attribut :

Type	Utilisation	Exemples
Nombre	Les valeurs sont uniquement numériques et ne sont pas limitées à une liste d'ensembles.	Matricule salarié numérique, montant de la facture
Date	La valeur est une date sans heure.	Date d'entrée en fonction
Date/Time	La valeur peut avoir à la fois une date et une heure.	Date et heure de départ
Entité	L'attribut est associé à une entité de liste de valeurs. Notez que si la liste de valeurs énumère toutes les valeurs valides (c'est-à-dire une liste fermée) et que les valeurs sont rarement utilisées dans les variations en langage naturel, vous devez ajouter des synonymes pour les valeurs de la liste.	statut (fermé), noms de fournisseur (ouvert)
Chaîne	A utiliser pour le texte qui peut contenir des chiffres et des caractères lorsqu'il n'est pas logique de l'associer à une liste de valeurs.	Numéro de facture alphanumérique, description du produit
Entité de requête	Utilisez cette option uniquement lorsque vous devez créer un lien vers une autre entité de requête.	Aucun exemple
Valeur booléenne	Ne pas utiliser.	Non applicable.

Configurer dynamiquement la présentation à l'aide de gestionnaires d'événements

Si vous souhaitez que la brique modifie de façon dynamique la façon dont elle présente les résultats de requête SQL, vous pouvez ajouter des gestionnaires d'événements de requête de données à un package de composants personnalisé, ajouter le package à la brique en tant que service de composant personnalisé, puis associer vos entités à leurs gestionnaires spécifiques à partir des onglets Présentation de l'entité. La brique déclenche l'événement de requête de données d'une entité lorsque cette entité de requête est la première entité nommée dans la clause FROM (entité racine).

Par exemple, vous pouvez ajouter dynamiquement un nombre de lignes au texte d'en-tête, ajouter une ligne au tableau pour afficher une somme ou déterminer quand afficher ou masquer un attribut.

Pour savoir comment créer des gestionnaires d'événements de requête de données, reportez-vous à Ecriture de gestionnaires d'événements de requête SQL.

Définir les règles de requête

Voici comment utiliser les paramètres d'une entité sur la page Entités pour contrôler la façon dont les utilisateurs finaux peuvent poser des questions sur les données et comment évaluer les résultats.

Vous pouvez tester vos modifications en cliquant sur Aperçu pour ouvrir le testeur de conversation et en saisissant une variation afin d'extraire les données appropriées.

Conseil :

Certaines des modifications que vous apportez nécessiteront un nouvel entraînement de l'analyseur de langage naturel. Lorsque vous testez vos modifications, si l'icône Entraîner comporte un badge rouge (

), vous devez d'abord cliquer sur Entraîner et terminer le processus de formation.

Identifier l'attribut à utiliser pour la mesure ou la comparaison : si la variation demande de comparer des éléments d'entité à un nombre ou demande de classer les entités à l'aide d'un superlatif tel que le plus élevé ou le moins élevé, quel attribut mesurable, le cas échéant, la brique doit-elle utiliser pour effectuer la comparaison ? Supposons, par exemple, que les utilisateurs interrogent le fournisseur le plus important, que vous souhaitiez que la brique utilise l'attribut rating pour les comparaisons. Pour spécifier l'attribut à utiliser pour la mesure ou la comparaison, accédez à l'onglet Général de l'entité et sélectionnez l'attribut dans la liste déroulante Mesurer par. Si le classement est opposé à l'ordre numérique, par exemple 5 étant supérieur à 1, vous devez également définir l'option Inverser la comparaison de l'attribut sur Vrai dans son onglet Informations générales.
Indiquer comment comparer des attributs mesurables : par défaut, les valeurs d'attribut mesurable sont comparées à l'aide d'un ordre numérique, où 1 est inférieur à 5. Cependant, il est parfois plus approprié d'inverser la comparaison lorsque 1 vaut mieux que 5. Par exemple, lorsque vous examinez les résultats de la course, les 5 meilleures périodes sont les valeurs les plus faibles des résultats. Pour inverser les comparaisons d'un attribut, définissez l'option Inverser la comparaison de l'attribut sur Vrai dans son onglet Informations générales. Notez que ce paramètre affecte également l'ordre de tri de l'attribut.
Autoriser la correspondance partielle pour les chaînes : si vous pensez que les utilisateurs laisseront souvent des caractères ou des valeurs de début ou de fin, tels que "responsable" au lieu de "responsable de service", envisagez d'activer la correspondance partielle. Lorsque la mise en correspondance partielle est activée, la clause WHERE SQL générée utilise upper (<column-name>) LIKE UPPER(%<string>%) au lieu de = <string>. Vous pouvez activer la mise en correspondance partielle dans l'onglet Informations générales de l'attribut. Notez que le comportement de correspondance partielle pour les attributs d'entité est différent du comportement de correspondance partielle pour les listes de valeurs.
Indiquer comment résoudre les dates et heures ambiguës : Pour les attributs de type date ou date/heure, vous pouvez indiquer si les valeurs ambiguës, telles que "Mercredi", doivent être résolues en fonction du passé, du futur ou de la date ou de l'heure la plus proche. Vous pouvez le définir à l'aide de la préférence temporelle de l'onglet Informations générales de l'attribut.

AVERTISSEMENT :
Gardez à l'esprit que la définition de la préférence temporelle sur la date ou l'heure la plus proche ne fonctionne que pour la saisie de dates et d'heures fixes, telles que "Mercredi". Si un utilisateur saisit une valeur de durée, telle que "deux jours", la requête ne sera pas résolue, car une valeur de durée est la même pour le passé et le futur. Sauf si vous êtes certain qu'un utilisateur n'entrera jamais de valeur de durée, vous ne devez définir la préférence temporelle que sur passée ou future.

Conseil :
Si un attribut peut parfois être défini par défaut sur le passé et parfois sur le futur en fonction du contexte, envisagez de créer des attributs personnalisés avec des préférences temporelles différentes. Par exemple, pour un attribut due_date, vous pouvez ajouter un attribut due avec une préférence future et un attribut overdue avec une préférence passée.

Activer les requêtes en langage naturel pour les colonnes dénormalisées

Si vous disposez d'un attribut dénormalisé avec un nom qui utilise un modèle pour identifier les attributs que la colonne représente, tels que PTD_LBR_CST, vous pouvez rendre l'attribut dénormalisé compréhensible pour le modèle de langage naturel en mettant en correspondance une entité normalisée avec elle via l'utilisation d'une correspondance de back-end d'extension de colonne.

Par exemple, supposons que vous disposez d'une entité de requête costToSales avec les attributs PTD_LBR_CST, QTD_LBR_CST, YTD_LBR_CST, PTD_SUB_CST, QTD_SUB_CST, YTD_SUB_CST.

Pour permettre à la brique d'associer des requêtes en langage naturel à ces attributs, vous créez une entité de requête de coût qui contient les attributs d'identification unique, tels que project_num, plus la période, le type et le coût. Les attributs de période et de type sont de type entité et référencent les listes de valeurs de période (Cumul période, Cumul trimestriel, Cumul annuel) et de type (LBR, Sous-traitance). Le mappage back-end de l'attribut de coût est une extension de colonne avec l'expression "${period}_${type}_CST". L'étape finale consiste à ajouter l'attribut de coût à l'entité costToSales, qui référence l'entité de requête de coût pour lier les deux entités.

Lorsque la requête est "Quels sont mes coûts de main-d'oeuvre de cumul annuel", le mapping de développement de colonne de back-end indique à la brique d'extraire la valeur de l'attribut YTD_LBR_CST, qui se trouve dans l'entité costToSales (en supposant que les noms et synonymes principaux nécessaires sont définis).

Test et réparation

Lorsque vous définissez et ajoutez des données d'entraînement à vos entités et attributs via des noms, des synonymes, des listes de valeurs et les données d'entraînement dans l'ensemble de données des entités de requête, vous devez tester dans quelle mesure les données d'entraînement aident l'analyseur de langage naturel à traduire les variations de l'utilisateur final en requêtes SQL.

Conseil :

Si l'icône Entraîner comporte un badge rouge (

), vous devez cliquer sur Entraîner et terminer le processus d'entraînement pour pouvoir tester les variations.

La page Entités comporte un lien Tester les requêtes, qui ouvre le testeur de requêtes pour tester vos variations de cas d'utilisation. Dans le testeur, vous pouvez entrer la variation de test et vérifier la requête OMRQL générée par la brique.

La description de sql-query-tester.png suit

Description de l'image sql-query-tester.png

Si le testeur convertit la variation en requête, examinez la requête OMRQL pour vérifier qu'elle produira les résultats souhaités. Si la requête OMRQL n'est pas correcte, vous devrez réparer la brique à l'aide du correctif approprié :

Ajoutez des synonymes pour une entité ou un attribut. Reportez-vous à Fourniture de données de formation via des noms et des synonymes.
Associez un attribut à une liste de valeurs ou ajoutez des éléments à une liste de valeurs. Voir Fournir des données de formation via des listes de valeurs.
Ajoutez la variation et OMRQL corrigé aux données d'entraînement dans l'ensemble de données des entités de requête pour apprendre au modèle à associer des mots et des expressions à des attributs, des entités et des mots-clés OMRQL dans le contexte d'une variation complète. Voir Fournir des données de formation via des variations.

Conseil :

Envisagez d'utiliser l'option Enregistrer en tant que scénario de test pour enregistrer certaines de vos requêtes valides dans le testeur de batch, que vous pouvez utiliser pour vous assurer que les modifications que vous apportez n'ont pas d'impact négatif sur d'autres zones. Reportez-vous à Surveillance avec test par lots d'entités de requête.

Notez que certaines variations peuvent ne pas se traduire correctement en raison de limitations de la fonctionnalité Boîtes de dialogue SQL. Dans certains cas, vous pouvez contourner ces limitations en ajoutant des données d'entraînement personnalisées. Reportez-vous à Dépannage des requêtes SQL.

Si le testeur de requêtes signale qu'il existe des données d'entraînement insuffisantes, vous pouvez cliquer sur Visualiser le fichier JSON pour obtenir des informations sur la façon dont il a analysé la variation. La valeur translatable indique si le modèle prend en charge la requête. confusionSpanText peut vous donner un indice sur la partie de la requête qui n'est pas prise en charge.

Description de l'image query-tester-json.png

Pour les variations qui ne peuvent pas être traduites, vérifiez d'abord si vous avez introduit une faute de frappe, si votre requête est trop vague ou si elle est en dehors de la portée du modèle. Ces problèmes ne peuvent pas être résolus par la formation. Sinon, vous pouvez être en mesure de résoudre des données d'entraînement insuffisantes en ajoutant un synonyme ou en ajoutant la variation aux données d'entraînement personnalisées dans l'ensemble de données des entités de requête. Voici quelques exemples de problèmes de données d'entraînement insuffisantes que vous pouvez résoudre en ajoutant des données d'entraînement personnalisées.

Confusion d'attributs : Par exemple, le statut fait-il référence au statut de paiement ou d'approbation ?
Confusion attribut-valeur : par exemple, "nombre de responsables" (fait référence à la valeur de l'attribut manager ou à la valeur de l'emploi de l'employé ?).
Valeurs de recherche qui sont également des mots-clés ou des opérateurs : par exemple, en distinguant le synonyme "total" de l'opérateur SUM.

Si OMRQL est valide, vous pouvez tester la façon dont la brique convertit OMRQL en SQL en cliquant sur Cliquez pour le tester dans le testeur de conversation. Le testeur de conversations s'affiche avec les résultats.

Dans le testeur de conversation, vous pouvez voir les instructions OMRQL et SQL dans l'onglet Boîtes de dialogue SQL. Lorsqu'elle ne peut pas traduire la requête, elle indique qu'elle n'est pas traduisible et indique le texte à l'origine de la confusion.

Voici la description de sql-sql-dialogs-tab.png :

Description de l'image sql-sql-dialogs-tab.png

Dépannage des requêtes SQL

Lorsqu'une requête ne résout pas comme prévu, cela peut être dû au fait que le modèle ne dispose pas de suffisamment d'informations ou que la variation est hors de portée. Cela peut également être dû aux limitations des dialogues SQL.

Pour les cas où le modèle ne dispose pas d'informations suffisantes, reportez-vous à Test et réparation pour savoir comment résoudre les problèmes. Certaines limitations des boîtes de dialogue SQL slso peuvent empêcher l'analyseur de langage naturel de traduire correctement la variation vers OMRQL. Cette section fournit des informations sur ces limitations et les moyens de les contourner, dans la mesure du possible.

Limites générales dans les boîtes de dialogue SQL

Le tableau ci-dessous décrit les limites générales des boîtes de dialogue SQL que vous devez connaître. Ces limitations n'ont pas de solutions de contournement.

catégorie	Limite	Exemples de requêtes non prises en charge
Nombre d'entités et d'attributs pris en charge	Le modèle logique peut avoir un total de 50 attributs plus des entités. Cette limite inclut tous les attributs et entités virtuels créés.
Requête non anglaise	Toute requête dans une langue autre que l'anglais.	nombre total d'empleadas
Utilisation des pronoms	Utiliser des pronoms tels que "I", "me" et "my" dans une variation.	Quel est mon salaire ? Qui suis-je le manager ? employés embauchés avant moi
Oui et pas de questions	Toute question pour laquelle la réponse est un oui ou un non. Les boîtes de dialogue SQL prennent uniquement en charge les requêtes pour lesquelles la réponse est un ensemble de résultats d'une requête de table de données.	John est-il commis ? Y a-t-il des analystes dans le département comptabilité ? avons-nous moins de 30 employés dans le service des ventes ?
Négation	Variations contenant des mots de négation tels que "non" et "non" ou requêtes pour des valeurs indiquant une négation ou des valeurs NULL.	Quels employés ne font pas partie du service comptable ? dont les employés perçoivent une commission (les requêtes de commission n'ont pas la valeur NULL) Quelles factures ne sont pas payées ? factures pour un fournisseur non fédéral (requêtes pour une valeur contenant une négation)
Opérateurs SQL complexes	Les dialogues SQL ne prennent pas en charge les requêtes plus complexes impliquant des sous-requêtes, des opérateurs SET (INTERSECT, UNION, EXCEPT et NONE), des requêtes nécessitant des opérateurs arithmétiques et des mots-clés EXISTS et NOT. Bien que, dans de rares cas, vous puissiez trouver une requête complexe résolue correctement, pour garantir la cohérence des résultats, vous devez envisager d'utiliser des vues de base de données ou de créer des attributs virtuels comme décrit dans Ajout d'un attribut personnalisé.	Afficher les employés dont les salaires sont supérieurs au salaire le plus élevé du service des ventes Quelle est la rémunération totale gagnée par chaque salarié ? Afficher les emplois qui emploient à la fois des hommes et des femmes sélectionner un emploi de l'employé où sexe = M INTERSECT sélectionner un emploi de l'employé où sexe = F
Opérateurs SQL implicites	Les boîtes de dialogue SQL ne prennent pas en charge les fonctions de clause SQL qui ne sont pas explicitement demandées. Par exemple : Implicite distinct : implique que les résultats renvoyés doivent être distincts. Agrégations implicites : implique une opération d'agrégation. Ordre implicite par : implique l'ordre des résultats. Envisagez de définir l'expression de commande par défaut dans l'onglet Général de l'entité.	Distinct : afficher les villes de tous les employés (renvoie plusieurs lignes avec des villes répétitives) afficher les noms des services pour lesquels tous les employés gagnent plus de 10000 (renvoie plusieurs lignes avec le même nom de service, une pour chaque employé qui gagne plus de 10 000) Agrégation : combien payons-nous à tous les employés du service de comptabilité (implique une demande pour le salaire total de tous les employés de la comptabilité) afficher le salaire par service (implique la somme) Commander par afficher tous les noms d'employé (l'utilisateur peut vouloir les trier par ordre alphabétique, mais l'ordre de tri n'est pas explicitement implicite) afficher les employés par ordre croissant (l'attribut de tri est implicite)
Support limité pour les questions de suivi	Les boîtes de dialogue SQL ne prennent pas en charge les questions de suivi prêtes à l'emploi. Autrement dit, les utilisateurs ne peuvent pas poser de nouvelle question de suivi pour mettre à jour la réponse. Conseil : Vous pouvez ajouter des actions rapides aux résultats sous la forme de liens ou de boutons qui effectuent des requêtes de suivi courantes. Reportez-vous à Ajouter des boutons et des liens aux résultats.	Voici des exemples de requêtes de suivi pour la variation d'origine "show all employees in Seattle" afficher uniquement les commis afficher maintenant les responsables Qui d'entre eux gagne plus de 3000 ? Dans ces cas, les utilisateurs doivent saisir la question complète, telle que "montrer tous les employés de Seattle qui travaillent en tant que commis".

Résoudre les problèmes de base liés aux requêtes

Catégorie	Description du problème	Exemples de requêtes non prises en charge	Solution de contournement
Sélectionner un attribut	Sélection de plus de 3 attributs	Afficher le nom, l'intitulé de poste, le salaire et la commission de tous les employés	Ajouter des données d'entraînement personnalisées. Les données d'entraînement peuvent inclure des exemples couvrant différentes entités et quelques ensembles différents de 4 (ou plus) attributs.
Sélectionner une entité	Demande de plus d'une entité	afficher tous les salariés et leurs services afficher le fournisseur et le site fournisseur pour toutes les factures	Utiliser des données d'entraînement personnalisées pour apprendre à l'entité à générer un attribut de la deuxième entité. Par exemple, pour "afficher le fournisseur de chaque facture", vous pouvez ajouter des données de formation qui mappent la requête avec OMRQL : `select invoiceid, vendor.vendor_name from invoices`
Où	Trois conditions ou plus dans la clause WHERE	montrer les employés qui ont été embauchés après 2000 et qui travaillent dans le service financier en tant qu'analyste	Ajouter des données d'entraînement avec des exemples contenant plusieurs conditions
Commander par	Tri par plusieurs attributs ou entités	afficher les employés triés par intitulé de poste et nom	Ajouter des données d'entraînement avec des exemples qui contiennent un ordre de 2 attributs ou plus
Grouper par	Regrouper par plusieurs attributs ou entités	afficher le salaire moyen par poste et par service	Ajouter des données d'entraînement avec des exemples contenant un regroupement par 2 attributs ou entités supplémentaires
Regrouper par + Avoir	Plusieurs conditions dans la clause have	afficher les emplois d'au moins 20 employés et un salaire moyen supérieur à 30000	Ajouter des données d'entraînement avec des exemples contenant plusieurs conditions dans la clause have
Auto-intégration	Si une entité a un lien vers elle-même, ce calcul peut ne pas être possible pour le modèle, même avec des données d'entraînement personnalisées.	Dans ce cas, les requêtes demandent des données salarié qui sont liées aux données salarié. afficher le nom et le salaire du manager de John Quels employés relèvent de Chris ?	Aucune solution n'est vérifiée.

Résolution des problèmes de date et d'heure

Catégorie	Description du problème	Exemples de requêtes non prises en charge	Solution de contournement
Valeurs de date et date/heure implicites	Lorsque vous filtrez par date ou date/heure, vous devez fournir explicitement le contexte de la clause WHERE. Par exemple, au lieu de dire "quelles factures sont en retard", vous devez dire quelque chose comme "quelles factures ont une date d'échéance antérieure à aujourd'hui".	Quel est le prochain événement ? Quelles factures sont en retard ?	Créez un attribut virtuel (par exemple, pour indiquer si un événement est à venir), puis utilisez un entraînement personnalisé pour enseigner au modèle le comportement attendu.
Référence passée ou future implicite	Pour les attributs de date et de date/heure, vous utilisez la préférence temporelle de l'attribut dans l'onglet Informations générales de l'attribut pour indiquer comment résoudre les dates ou dates/heures ambiguës. Les variations qui impliquent qu'une valeur ambiguë doit être résolue en tant que date ou heure passée ou future sont ignorées et la préférence temporelle est utilisée.	salariés qui seront embauchés mercredi Si la préférence temporelle par défaut est passée, elle sera résolue à une date passée, même si le contexte est implicitement futur.	Vous pouvez peut-être créer 2 attributs dérivés pour résoudre ce problème pour votre scénario.
Contexte "passé" avec les opérateurs `<` et `>`	Les boîtes de dialogue SQL ne prennent pas en charge l'utilisation des opérateurs `<` et `>` sur des dates ou des dates/heures passées contenant une durée.	employés embauchés il y a plus de 2 jours factures en retard de moins de 2 jours	Aucune solution de contournement fiable. Essayer d'enseigner quelque chose comme cela avec un entraînement personnalisé peut entraîner le début d'une prévision incorrecte du modèle dans d'autres cas.
Heure sans date	Les boîtes de dialogue SQL ne prennent pas en charge les requêtes qui ont des heures mais pas des dates.	commandes livrées à 3 heures	Aucune solution de contournement connue.
Dates récurrentes	Les boîtes de dialogue SQL ne prennent pas en charge les dates qui spécifient une valeur récurrente sur un intervalle spécifique.	Quelle réunion a lieu le premier lundi de chaque mois ?	Aucune solution de contournement connue

Résoudre les problèmes de sélection d'attributs

catégorie	Description du problème	Exemples de requêtes non prises en charge	Solution de contournement
Performances limitées pour les synonymes d'entité/d'attribut propres au domaine	Pour les synonymes techniques ou spécifiques à un domaine, rarement utilisés en tant que synonymes, le modèle peut avoir du mal à les mapper avec l'attribut approprié	Attribut : ip_address Synonyme : dispositifs	Ajouter des données d'entraînement personnalisées. Incluez des exemples utilisant les synonymes de l'attribut et un autre ensemble d'exemples portant le nom principal pour vous assurer que le modèle n'oublie pas les fonctionnalités existantes
Attribut d'identification pour les entités	Impliquer un attribut en se référant uniquement à l'entité	Afficher les factures contenant 1234 Implique le filtrage par numéro de facture	Ajouter des données d'entraînement personnalisées. Créez des données avec des exemples à l'aide de `=`, `LIKE`, `starts with` et `ends with` (par exemple, "afficher toutes les factures contenant 1234") Assurez-vous que les données de formation contiennent quelques exemples où le nom de l'entité est utilisé pour faire référence à l'entité elle-même (par exemple, "afficher toutes les factures")
Homonymie	Dans les cas ambigus avec de multiples possibilités, le modèle ne peut pas désambiguïter	Afficher le montant pour toutes les factures impossible de déterminer si "montant" fait référence à "montant de la facture" ou "montant brut"	Ajouter des données d'entraînement personnalisées. Incluez des exemples qui mettent en correspondance le nom ambigu avec l'attribut prévu. Incluez quelques exemples en utilisant les noms complets (sans ambiguïté) des options pour cette utilisation ambiguë particulière.
Référence d'attribut implicite pour les valeurs qui ne figurent pas dans l'entité de liste de valeurs	Si nous faisons référence à un attribut uniquement par valeur et que cette valeur n'est pas présente dans la liste de valeurs (valeur canonique/synonyme)	Afficher le salaire de tous les employés dans ODA Où "ODA" n'est pas une valeur dans la liste de valeurs pour les noms de service Afficher les départements situés aux États-Unis Où "USA" n'est pas synonyme de "Etats-Unis" dans la liste de valeurs d'emplacement	Vous pouvez ajouter des données d'entraînement personnalisées, mais elles ne seront pas fiables dans tous les cas. Par exemple, le modèle peut apprendre que les "factures émises par VALUE" doivent être mappées avec l'attribut de nom de fournisseur. Mais le modèle ne peut pas apprendre "factures pour VALEUR" ou "factures par valeur" car les mots pour, par, dans, etc. sont très généraux et peuvent être utilisés dans une grande variété de contextes.
Ordre des valeurs et nom de l'attribut	L'attribut odel est moins robuste lorsque la valeur est mentionnée avant le nom de l'attribut dans la variation. (C'est plus un problème lorsque les valeurs ne sont pas dans la liste de valeurs et pour les valeurs à plusieurs mots).	afficher les factures approuvées	Ajouter des données d'entraînement personnalisées. Créez des exemples avec la valeur avant l'attribut dans les conditions, ainsi que quelques exemples avec des attributs avant les valeurs.

Dépannage des problèmes de regroupement par groupe

catégorie	Description du problème	Exemples de requêtes non prises en charge	Solution
Regrouper par plus de 2 entités	Regroupement entre plusieurs entités avec des agrégations	afficher le nombre de versements pour chaque fournisseur où trois entités sont impliquées : fournisseurs, factures, versements montant total restant pour chaque fournisseur où le montant restant se trouve dans l'entité des versements	Vous pouvez essayer d'ajouter des données d'entraînement personnalisées. Cependant, essayer de résoudre ce problème est risqué et nécessiterait de nombreuses données d'entraînement personnalisées.
Regrouper par + Trier par + Min ou Max	Tri des entités en fonction des valeurs minimales ou maximales de l'attribut après regroupement par cette entité.	Afficher tous les services triés en fonction de leur salaire le plus élevé afficher tous les emplois par ordre du salaire minimum versé aux employés de cet emploi	Ajouter des données d'entraînement personnalisées.
Regrouper par + Trier par + Min/Max + Limite 1 ou Limite N	Grouper d'abord en fonction de l'attribut ou de l'entité, trier par le minimum ou le maximum d'un attribut numérique, puis sélectionner la première ligne	quel service a le salaire minimum le plus élevé	Ajouter des données d'entraînement personnalisées.
Les clauses Select et Having ont des agrégations différentes	Les clauses Select et Having ont des agrégations différentes	afficher le salaire moyen de chaque service comptant au moins 10 employés la clause SELECT doit avoir la valeur avg(invoices.amount) et la clause HAVING doit avoir la valeur count(invoice)	Ajouter des données d'entraînement personnalisées.
Les clauses Sélectionner et Trier par ont des agrégations différentes	Les clauses Sélectionner et Trier par ont des agrégations différentes	afficher le nom et la facture moyenne de chaque fournisseur, et trier les fournisseurs par ordre alphabétique du nom du fournisseur Ici, la clause SELECT doit avoir avg(invoices.amount) et la clause ORDER BY doit avoir vendor_name	Ajouter des données d'entraînement personnalisées.
Agrégations multiples dans la clause Select	Les boîtes de dialogue SQL prennent en charge les clauses Select avec une seule agrégation, une moyenne plus la somme et une valeur minimale plus la valeur maximale. Il ne prend pas en charge d'autres combinaisons telles que moyenne plus min, moyenne plus somme plus max, et compte plus somme.	afficher le salaire moyen et le salaire le moins élevé par service pour chaque emploi, afficher le nombre d'employés et le salaire moyen	Ajouter des données d'entraînement personnalisées.
Disposer de clauses + Where	Requête de regroupement avec des clauses Having et Where	Quels fournisseurs de type LEGAL ont plus de 6 factures ?	Ajouter des données d'entraînement personnalisées.

Résolution des problèmes d'entité

catégorie	Description du problème	Exemples de requêtes non prises en charge	Solution
Typos		Employés du service comptable Le compte de valeur a une faute de frappe Département d'emlpoyee nme John Doe L'attribut emlpoyee nme a une faute de frappe	Aucune solution. Les fautes de frappe dans les valeurs ne fonctionneront pas, même avec une formation personnalisée.
Entités autres que les listes de valeurs et les expressions régulières	Associer des attributs à tout type d'entité autre que la liste de valeurs (par exemple, des entités d'apprentissage automatique personnalisées)		Aucune solution.
Correspondance partielle	Pour la correspondance partielle, seule la dérivation est prise en charge.	Factures d'Amazon Là où il n'y a pas de contexte, et la liste de valeurs a "Amazon LLC"	Ajoutez des synonymes dans la liste de valeurs.
Correspondance partielle	La correspondance partielle ne fonctionnera pas pour les caractères `_` et `?`	Factures payées à l'aide de DBX TEF En l'absence de contexte et lorsque la liste de valeurs contient "DBX_EFT"	Ajoutez des synonymes dans la liste de valeurs.
Nombres sous forme non numérique	Les boîtes de dialogue SQL prennent en charge une liste limitée de nombres pouvant être représentés sous d'autres formes (0-10, 20 et 50). Tous les autres nombres, s'ils sont référencés dans un format autre que numérique, ne sont pas pris en charge	afficher les factures dont le montant dû est inférieur à trente Afficher les factures dont le montant dû est inférieur à 1 ko Afficher les factures dont le montant dû est inférieur à 1 mille Afficher les factures dont le montant dû est inférieur à 1 000	Aucune solution.

Résolution d'autres problèmes

catégorie	Description du problème	Exemples de requêtes non prises en charge	Solution
2 filtres numériques ou plus	Deux clauses Where avec des nombres (qu'il s'agisse du même attribut ou d'un attribut différent)	Employés dont le salaire est supérieur à 10000 et dont la commission est d'au moins 2000 Employés dont le salaire est inférieur à 2000 ou supérieur à 5000	Ajouter des données d'entraînement personnalisées.
Ordre des superlatifs	Demander les N entités supérieures ou inférieures. Remarque Le modèle est plus robuste avec le haut et le bas	Afficher le meilleur employé L'OMRQL idéal est "SELECT * FROM Emp ORDER BY * DESC LIMIT 1" Cependant, le modèle rencontre des problèmes avec `order by *`	Ajouter des données d'entraînement personnalisées.
Attributs où les agrégations sont précalculées	Si le schéma comporte des agrégations précalculées telles que `total_amount` qui stocke déjà la somme ou `total_servers` qui stocke le nombre total de serveurs, le modèle peut être confondu entre la nécessité d'utiliser la fonction SUM/COUNT ou l'attribut avec l'agrégation précalculée.	Afficher le montant total de la facture 1234 Où `total_amount` est un attribut dérivé, mais le modèle peut prévoir `SUM(amount)`	Ajouter des données d'entraînement personnalisées.
Sélection par défaut	Le modèle prédit parfois le nom ou l'ID de l'entité au lieu de sélectionner *. Il s'agit d'une erreur rare et l'impact n'est pas critique, car l'utilisateur voit l'attribut minimum au lieu des attributs par défaut de l'entité.	Affichez les factures qui sont approuvées. L'OMRQL idéal est "SELECT * à partir de factures où approval_status = 'approuvé'" Cependant, le modèle prédit "select invoice_num"	Ajouter des données d'entraînement personnalisées, s'il s'agit d'un problème

Surveiller et améliorer

Au fur et à mesure que vous construisez et testez votre brique, vous pouvez utiliser les analyses et les tests par lots pour surveiller la façon dont la brique atteint ses objectifs et exposer les domaines nécessitant une amélioration. Lorsque vous entrez dans la phase de test et que vous publiez la brique au public, vous devez continuer à effectuer des contrôles et des tests périodiques.

Surveillance à l'aide des informations clés

La page Informations de la brique fournit plusieurs mesures que vous pouvez utiliser pour mesurer les performances de votre brique Boîte de dialogue SQL et pour déterminer les améliorations à apporter.

En tant qu'analyste commercial, les mesures de requête de données suivantes peuvent vous intéresser dans l'onglet Présentation :

Performances : Tendance des conversations par statut (ligne) : affiche le nombre de conversations sur une période donnée et indique si le trafic est en hausse, en baisse ou latéral.
Le rapport entre les requêtes correctes et les requêtes incorrectes indique à quel point les utilisateurs de bot sont satisfaits de la précision de la traduction des variations en requêtes SQL.
Le ratio entre les conversations terminées et inachevées indique dans quelle mesure les problèmes techniques ont un impact sur l'expérience des utilisateurs.
Le ratio entre le nombre total de conversations et les requêtes non résolues (OOD/OOS) permet de mesurer la mesure dans laquelle la brique répond aux attentes des utilisateurs finaux.
La tendance des conversations par type et le ratio entre le nombre total de conversations et les conversations de requêtes de données indiquent la proportion de variations qui sont des requêtes SQL.
Les entités de requête de données indiquent les entités les plus interrogées.

En tant qu'entraîneur d'IA, vous pouvez examiner les messages utilisateur de l'onglet Conversations pour découvrir les points à améliorer. Par exemple, vous pouvez consulter les messages utilisateur suivants :

Les messages utilisateur Type : Intention, Résultat : Incomplet indiquent des problèmes de traduction de la variation en requête SQL. Vous pouvez souvent résoudre ces problèmes en ajoutant des synonymes ou, pour les requêtes plus complexes, en ajoutant des variations mises en correspondance à l'ensemble de données des entités de requête. Vous pouvez également voir ces messages en sélectionnant Erreurs gérées par le système dans la liste déroulante Erreurs.
Type : Intention, Intention : unresolvedIntent les messages utilisateur indiquent à la fois des variations hors portée et des variations que la brique ne reconnaît pas en tant que variation de requête de données. Pour les variations qui sont des requêtes de données valides mais que la brique ne reconnaît pas comme telles, vous pouvez souvent résoudre les problèmes en ajoutant des synonymes ou en mettant en correspondance les variations avec OMRQL dans l'ensemble de données de requête.
Type : Requête de données, Entités : affiche les messages utilisateur par entité de requête.
Type : Requête de données, Résultat : Incorrect : affiche les messages qui, selon les utilisateurs, ont renvoyé des résultats incorrects. Vous devez vérifier que les résultats sont incorrects et, le cas échéant, ajouter des synonymes, des listes de valeurs et des entrées de jeu de données de requête.

Surveillance avec test par lots d'entités de requête

En tant qu'entraîneur d'IA, il est recommandé de créer des tests par lots pour s'assurer que l'amélioration d'un domaine n'a pas d'impact négatif sur un autre. Vous pouvez également utiliser des tests par lots pour vous assurer que les modifications apportées au modèle logique n'ont pas d'effets négatifs sur l'entraînement personnalisé ou le routage vers les conversations SQL.

Tout comme pour le test par lots des variations d'intention, vous pouvez réserver environ 20 % des requêtes réelles que vous avez collectées pour les utiliser pour le test par lots des requêtes. Vous pouvez exécuter le test par lots régulièrement et après avoir apporté des modifications au modèle logique, à l'entraînement personnalisé ou aux données de routage.

Chaque cas de test doit appartenir à une suite de tests. Par conséquent, avant de créer un cas de test, vous pouvez créer une suite de tests qui reflète certains aspects des tests d'interrogation, tels que les tests d'échec, les tests dans le domaine ou les tests hors domaine. Nous fournissons une suite appelée Suite de tests par défaut. Vous pouvez affecter des cas de test à cette suite de tests si vous n'en avez pas encore créé d'autres.

Vous pouvez ajouter un cas de test à un test par lot de deux manières :

Après avoir testé une variation à partir du testeur de requêtes, vous pouvez sélectionner une suite de tests dans la liste déroulante Enregistrer en tant que cas de test pour l'enregistrer dans cette suite.
Vous pouvez cliquer sur + Cas de test dans l'onglet Suites de test du testeur de lots.

Pour accéder au testeur de batch, procédez comme suit :

Sur la page Entités, cliquez sur Tester les requêtes.

Le testeur de requêtes s'ouvre.
Cliquez sur Accéder aux cas de test.

Dans l'onglet Suites de tests, sélectionnez une suite de tests et exécutez tous les cas de test, ou sélectionnez et exécutez des cas spécifiques. Les résultats sont présentés sur la page Résultats du test. L'exécution des tests prend un certain temps. Vous savez que l'exécution est terminée lorsque En cours affiche 0.

Référence OMRQL

Voici les mots-clés que vous pouvez utiliser lorsque vous définissez des requêtes OMRQL pour les variations que vous ajoutez à l'ensemble de données des entités de requête. Notez que vous utilisez des noms canoniques et non des noms et synonymes principaux.

Composant	Mots-clés OMRQL	Exemple OMRQL	contraintes
Composants de base	SÉLECTIONNER * FROM	SELECT * FROM Emp	OMRQL ne peut pas nommer les attributs qui ne sont pas référencés dans la variation.
Filtrage	WHERE	Salaire de l'employé WHERE > 100000	Aucune action.
Liaison d'entités Pour plus d'informations sur ce fonctionnement, reportez-vous à la section Link Attributes.	. (point)	SELECT * FROM Employee WHERE Departments.location = 'NYC'	Aucune action.
Tri	TRIER PAR LIMIT ASC Décroiss.	SELECT name FROM Employee ORDER BY salary DESC LIMIT 10	OMRQL peut trier les données à l'aide de ORDER BY <ATTR> [LIMIT N] uniquement si la variation inclut l'ordre des mots ou ses synonymes de langage naturel, tels que triés, ordonnés, les plus élevés et les plus petits.
Tri sans attribut spécifique L'astérisque (``) est utilisé en conjonction avec ORDER BY lorsqu'un utilisateur demande à commander quelque chose sans spécifier quoi commander. Par exemple, "show the top 10 employees" (on ne sait pas par quel attribut nous devons commander). Le back-end remplace ensuite `` par un attribut par défaut prédéfini (`measure_by`).	TRIER PAR *	SELECT name FROM Employee ORDER BY * DESC LIMIT 10	ORDER BY * ne fonctionne de bout en bout que lorsque la valeur "measure_by" est définie pour l'entité dans l'interface utilisateur
Fonctions d'agrégation	COUNT DISTINCT AVG SUM MIN MAX	SELECT AVG(sal) de l'employé	OMRQL ne peut contenir DISTINCT que si la variation contient ce mot ou un synonyme de langage naturel tel que différent ou unique.
Regroupement	GROUPE PAR	SELECT location, AVG(Employees.salary) FROM Department GROUP BY location	La clause FROM doit contenir l'entité à laquelle appartient l'attribut group by
Regroupement par entité	GROUPER PAR *	SELECT , MAX(Employees.salary) FROM Department GROUP BY Remarque : groupe par entité dans la clause FROM (le back-end convertit Grouper par * en Grouper par la clé primaire de l'entité racine)
Regroupement et filtrage	AVOIR	SELECT location FROM Department GROUP BY location HAVING AVG(Employees.salary) < 4000
Opérateurs de comparaison	= != <> > >= < <= Egal à PAS COMME ENTRE IN NOT IN	SELECT * from Department WHERE name IN ('Ventes', 'HR')	Pour les opérateurs >, >=, < et <=, la variation doit contenir un synonyme de langage naturel équivalent, tel que supérieur à, au moins, inférieur à et au plus. Si la variation ne contient pas de synonyme d'opérateur, OMRQL doit contenir =. OMRQL ne peut contenir LIKE que si la variation contient ce mot ou un synonyme de langage naturel tel qu'inclut, contient ou sous-chaîne. OMRQL ne peut contenir ENTRE que si la variation contient ce mot ou un synonyme de langage naturel, par exemple dans la plage de
Opérateurs logiques	AND Ou NOT	SELECT name FROM Employee WHERE salary > 10000 AND role = 'VP'	Aucune action.

Lorsque la variation que vous mettez en correspondance utilise un synonyme pour la valeur de base de données réelle, ce synonyme doit être défini pour la valeur de la liste de valeurs et OMRQL doit utiliser la valeur de base de données réelle. Par exemple, si la variation est "show the department which location is the big apple", "big apple" doit être défini dans la liste de valeurs dept_loc en tant que synonyme de la valeur "NEW YORK", et OMRQL doit être "SELECT * FROM Dept WHERE loc = 'NEW YORK'".

Voici quelques exemples d'écriture d'OMRQL pour vos variations :

Variation	SQL	NQM	Commentaires
Montrez-moi tous les employés qui travaillent comme commis	SELECT * FROM Emp WHERE job = 'CLERK'	SELECT * FROM Emp WHERE job = 'CLERK'	OMRQL est identique à SQL.
Montrez-moi le nombre d'employés qui travaillent dans le service des ventes	SELECT COUNT(*) FROM Emp AS T1 JOIN Dept AS T2 ON T1.deptno = T2.deptno WHERE T2.dname = 'SALES'	SELECT COUNT() FROM Emp WHERE dept.dname* = 'SALES'	Au lieu d'une jointure, utilisez "link_attribute.attribute_name" pour faire référence à un attribut d'une autre entité.
Adams est membre de quel département ?	SELECT * FROM Dept AS T1 JOIN Emp AS T2 ON T1.deptno = T2.deptno WHERE T2.ename = 'Adams'	SELECT * FROM Dept WHERE emp.ename = 'ADAMS'	Au lieu d'une jointure, utilisez "link_attribute.attribute_name" pour faire référence à un attribut d'une autre entité.
Quel est le lieu du service et le rôle fonctionnel de l'employé Adams	SÉLECTIONNEZ T1. SITE, T2. TRAVAIL DU SERVICE T1 REJOINDRE L'EMPLOYÉ T2 SUR T1. NUMÉRO DE SERVICE = T2. NUMÉRO DE SERVICE OÙ T2. NOM = 'ADAMS'	SELECT loc, emp.job FROM Dept WHERE emp.ename = 'ADAMS'	Notez que l'écriture OMRQL est plus simple que l'écriture SQL.
Combien d'employés y a-t-il pour chaque poste ?	SELECT COUNT(*), job FROM Emp GROUP BY job	SELECT COUNT(*), job FROM Emp GROUP BY job	OMRQL est identique à SQL.
Quel employé a le salaire le plus élevé ?	SELECT * FROM Emp ORDER BY salary DESC LIMIT 1	SELECT * FROM Emp ORDER BY salary DESC LIMIT 1	OMRQL est identique à SQL.
Afficher le nom de l'employé et le nom du service en les classant par salaire dans l'ordre croissant	SELECT T1.ename, T2.dname FROM Emp AS T1 JOIN Dept AS T2 ON T1.deptno = T2.deptno ORDER BY T1.sal ASC	SELECT ename, dept.dname FROM Emp ORDER BY salary ASC	Notez que l'écriture OMRQL est plus simple que l'écriture SQL.
Nombre d'employés dans chaque lieu	SELECT COUNT(*), loc FROM Emp AS T1 JOIN Dept AS T2 ON T1.deptno = T2.deptno GROUP BY T2.loc	SELECT loc, COUNT(emp) from Dept GROUP BY loc	Avec GROUP BY, lorsque nous comptons une entité liée, nous utilisons une nouvelle syntaxe COUNT(LINK) au lieu de COUNT(*). OMRQL est ainsi plus lisible que SQL.
Afficher les lieux avec un salaire moyen d'au moins 40000	SELECT T2.name FROM Emp AS T1 JOIN Dept AS T2 ON T1.deptno = T2.deptno GROUP BY T2.name HAVING AVG(T1.sal) >= 40000	SELECT loc from Dept GROUP BY loc HAVING AVG(emp.sal) <= 40000	Exemple de clause GROUP BY avec HAVING.
Salaire moyen des employés de chaque service	SELECT AVG(T1.sal), T2.dno FROM Emp AS T1 JOIN Dept AS T2 ON T1.deptno = T2.deptno GROUP BY T2.dno	SELECT , AVG(sal) du service GROUP BY	L'objectif ici est de regrouper par un attribut unique dans l'entité "department". La clé primaire est le candidat le plus approprié, mais l'affichage de la clé primaire peut ne pas toujours être utile. Dans OMRL, nous regroupons par *. Le back-end sera regroupé par clé primaire et affichera également les attributs minimum de l'entité pour rendre le résultat plus convivial
Afficher le lieu et le salaire minimum des employés pour chaque service	SELECT T2.dno, T2.loc, MIN(T1.sal) FROM Emp AS T1 JOIN Dept AS T2 ON T1.deptno = T2.deptno GROUP BY T2.dno, T2.loc	SELECT , loc, MIN(sal) du service GROUP BY , loc	Ici, nous voulons toujours regrouper par entité de service, mais la variation demande également spécifiquement l'affichage de l'emplacement des services. Notez que les clauses SELECT et GROUP BY comportent un astérisque (*) et que les attributs d'affichage demandés.
Afficher le nom et le lieu du service ayant le salaire moyen le plus élevé	SELECT T2.name, T2.loc FROM Emp AS T1 JOIN Dept AS T2 ON T1.deptno = T2.deptno GROUP BY T2.name ORDER BY AVG(T1.sal) LIMIT 1	SELECT , nom, lieu du service GROUP BY , nom, lieu ORDER BY AVG(emp.sal) LIMIT 1	Autre exemple de regroupement par entité et d'affichage des attributs demandés, cette fois avec ORDER BY LIMIT 1
Afficher les 10 premiers employés	SELECT * from Emp ORDER BY évaluation LIMIT 10	SELECT * from Emp ORDER BY * LIMITE 10	En supposant que "meilleurs employés" impliquent un classement par leur notation, la notation sera définie en tant qu'attribut "measure_by" pour l'entité Emp.

Attributs de lien

A l'exception de la liaison d'entités, les composants OMRQL sont similaires à SQL. Au lieu d'une jointure SQL, vous utilisez une paire d'attributs de lien pour lier une entité à une autre. Les attributs de lien ont des noms principaux et des synonymes qui définissent la relation entre les entités. Par exemple, un lien d'attribut d'employé/service avec une relation 1-1 peut avoir un nom principal "service" et des synonymes "fonctionne dans", "appartient à" et "équipe". Un lien d'attribut de service/employé avec une relation de 1 à plusieurs peut avoir un nom principal "employees" et des synonymes "members" et "workers".

Outre les attributs de lien de clé primaire/clé étrangère standard, vous pouvez également disposer des types d'attribut de lien suivants :

Plusieurs attributs de lien d'une entité à une autre qui définissent plusieurs relations sémantiques.
Attribut de lien entre une entité et elle-même qui implique une auto-jointure.
Attribut de lien pour une table d'intersection en raison d'une jointure de plusieurs à plusieurs

Documentation Oracle Cloud Infrastructure