Entraînement de votre modèle pour la compréhension du langage naturel

Oracle Digital Assistant prend en charge deux types d'intentions : les intentions standard et les intentions de réponse. Les deux types d'intention utilisent le même modèle de traitement du langage naturel, qui doit être défini sur Entraîneur Tm pour les tests de pré-production et en production.

La différence entre les deux types d'intention est que les intentions de réponse sont associées à un message prédéfini qui s'affiche chaque fois que l'intention est résolue à partir d'un message utilisateur, tandis que les intentions standard, lorsqu'elles sont résolues, conduisent à une conversation utilisateur-bot définie dans le flux de dialogue.

Vous utilisez des intentions de réponse pour que le bot réponde à la question fréquemment posée qui génère toujours une seule réponse. Des intentions régulières sont utilisées pour démarrer une interaction utilisateur-bot plus longue qui mène à la réalisation d'une tâche transactionnelle, à l'interrogation d'un système back-end ou à la fourniture d'une réponse à une question fréquemment posée qui doit prendre en compte une dépendance externe telle que l'heure, la date ou l'emplacement lors de la fourniture d'une réponse.

Pour améliorer l'efficacité du développement et du maintien de la brique, vous devez définir une convention d'appellation pour vos intentions qui vous permet de comprendre immédiatement ce que représente une intention particulière et d'utiliser l'option de filtre lors de la recherche d'intentions.

Par exemple, une partie du nom doit délimiter entre les intentions de réponse et les intentions standard (et peut-être aussi les intentions standard dont vous avez besoin pour pouvoir renvoyer une réponse directe, mais avec un traitement plus complexe, par exemple avec une pièce jointe ou basé sur une requête à un service distant). Dans cet esprit, vous pouvez commencer par un schéma similaire à ce qui suit :

• Intentions standard : reg.<name_of_intent>

• Intentions de réponse : ans.<name_of_intent>

• Intentions standard qui sont des réponses : reg.ans.<name_of_intent>

Si votre brique gère des tâches associées pouvant être catégorisées, elle peut également être utilisée dans la dénomination des intentions. Supposons que vous ayez l'intention de créer des commandes et d'annuler des commandes. Dans ces deux cas d'emploi, la convention de dénomination peut être la suivante :

• Intentions standard : create.reg.<name_of_intent>, cancel.reg.<name_of_intent>

• Intentions de réponse : create.ans.<name_of_intent>, cancel.ans.<name_of_intent>

• Intentions standard qui sont des réponses : create.reg.ans.<name_of_intent>, cancel.reg.ans.<name_of_intent>

Il n'y a pas de règle stricte quant à savoir si vous utilisez la notation par points, les traits de soulignement ou autre. Toutefois, gardez les noms suffisamment courts pour ne pas être tronqués dans le panneau de l'éditeur d'intention d'Oracle Digital Assistant.

Chaque intention possède également un champ Nom de conversation. Le nom de la conversation est utilisé dans les boîtes de dialogue de désambiguïsation créées automatiquement par l'assistant numérique ou la brique, si un message utilisateur est résolu en plusieurs intentions.

Chaque intention dispose d'un champ Description dans lequel vous devez décrire brièvement à quoi sert une intention afin que les autres personnes qui maintiennent la brique puissent la comprendre sans deviner.

Un exemple d'intentions de définition de portée trop étroite consiste à définir une intention distincte pour chaque produit que vous souhaitez gérer par une brique. Prenons l'extension d'une police d'assurance existante comme exemple. Si vous avez défini des intentions par police, le message "Je veux ajouter ma femme à mon assurance maladie" n'est pas très différent de "Je veux ajouter ma femme à mon assurance auto" car la distinction entre les deux est un seul mot. Autre exemple négatif, imaginez si, chez Oracle, nous avons créé un assistant numérique pour que nos clients demandent une assistance produit. Pour chacun de nos produits, nous avons créé une brique distincte avec les mêmes intentions et variations d'entraînement.

En tant que jeune enfant, vous n'avez probablement pas développé de compétences distinctes pour la tenue de bouteilles, de morceaux de papier, de jouets, d'oreillers et de sacs. Au contraire, vous avez simplement appris à tenir les choses. Le même principe s'applique à la création d'intentions pour un bot.

La portée d'une intention est trop large si vous ne pouvez toujours pas voir ce que l'utilisateur veut après la résolution de l'intention. Par exemple, supposons que vous ayez créé une intention nommée "handleExpenses" et que vous l'ayez entraînée avec les variations suivantes et un bon nombre de leurs variations.

• "Je veux créer une nouvelle note de frais"

• "Je veux vérifier ma note de frais récente"

• "Annuler ma note de frais récente"

• "Mon récent rapport nécessite des corrections"

Dans ce cas, un traitement supplémentaire est nécessaire pour déterminer si une note de frais doit être créée, mise à jour, supprimée ou recherchée. Pour éviter tout code complexe dans votre flux de dialogue et réduire la surface d'erreur, vous ne devez pas concevoir d'intentions de portée trop large.

Rappelez-vous toujours que le machine learning est votre ami et que votre conception de modèle devrait vous faire un ami tout aussi bon de l'IA conversationnelle dans Oracle Digital Assistant.

De plus, les entités offrent plus de fonctionnalités qui valent la peine de passer du temps à identifier les informations qui peuvent être collectées avec elles.

Par exemple, que se passe-t-il si un utilisateur saisit le message "J'ai acheté cet article le 12 juin 2021 et le 2 juillet 2021" lorsqu'une date d'achat lui est demandée ? Dans ce cas, l'entité, si elle est utilisée avec le composant Réponse commune ou Résoudre les entités, génère automatiquement une boîte de dialogue de désambiguïté pour que l'utilisateur puisse sélectionner une seule valeur comme entrée de données. Comme dans une conversation humaine où une personne demanderait à une autre de désambiguïter une déclaration ou un ordre, les entités feront de même pour vous. Et bien sûr, les entités peuvent également être configurées pour accepter plusieurs valeurs si le cas d'emploi le prend en charge.

En outre, lorsque vous utilisez le composant Réponse commune ou Résoudre les entités avec des entités personnalisées, les invites affichées aux utilisateurs peuvent être définies dans l'entité de sorte que les utilisateurs obtiennent des invites alternatives lorsqu'ils sont de nouveau invités à entrer des données précédemment en échec. Lorsque le message d'invite change entre les appels, cela rend votre bot moins robotique et plus conversationnel. En outre, vous pouvez utiliser des invites alternatives pour révéler progressivement plus d'informations afin d'aider les utilisateurs à fournir une entrée correcte.

En règle générale, il est recommandé d'utiliser des entités pour effectuer la validation des entrées utilisateur et afficher les messages d'erreur de validation, ainsi que pour afficher les invites et les boîtes de dialogue de désambiguïsation.

Comme pour les intentions, nous recommandons d'appliquer une convention de dénomination lors de la création de noms d'entité. Pour commencer, si vous incluez le type d'entité dans le nom de l'entité, cela facilite la compréhension en un coup d'œil et permet de filtrer facilement une liste d'entités. Par exemple, vous pouvez utiliser le schéma suivant :

• Entité de liste de valeurs : list.<name_of_entity>

• Entité d'expression régulière : reg.<name_of_entity>

• Entité dérivée : der.<name_of_entity> ou der.DATE.<name_of_entity>

• Entité de conteneur composite : cbe.<name_of_entity>

• Entité d'apprentissage automatique : ml.<name_of_entity>

Que vous utilisiez la notation par points comme dans les exemples ci-dessus, les traits de soulignement ou les éléments qui vous sont propres appartiennent à vous. Au-delà de cela, nous suggérons que vous essayez de garder les noms assez courts.

Chaque entité possède un champ Description dans lequel vous devez décrire brièvement l'objectif d'une entité. Le champ est limité dans le nombre de caractères que vous pouvez entrer, alors assurez-vous d'être concis.

Lors de la création de variations pour vos intentions, vous utiliserez la plupart des variations comme données d'entraînement pour les intentions, mais vous devez également mettre de côté certaines variations pour tester le modèle que vous avez créé. Une répartition des données 80/20 est courante dans l'IA conversationnelle pour le rapport entre les variations à créer pour l'entraînement et les variations à créer pour le test.

Un autre ratio que vous pouvez trouver lors de la lecture sur le machine learning est un fractionnement de 70/15/15. Un fractionnement de 70/15/15 signifie que 70 % de vos variations seraient utilisées pour entraîner une intention, 15 % pour tester l'intention pendant le développement et les 15 % restants pour être utilisés pour les tests avant de passer à la production avec. Une bonne analogie pour la formation intentionnelle est un examen scolaire. Le 70% est ce qu'un enseignant vous enseigne sur un sujet. Les premiers 15% sont alors des tests que vous prenez pendant que vous étudiez. Ensuite, quand il s'agit d'écrire votre examen, vous obtenez un autre ensemble de 15% de tests que vous n'avez pas vu auparavant.

Bien que le 70/15/15 soit convaincant, nous vous recommandons toujours d'utiliser un fractionnement 80/20 pour la formation des intentions Oracle Digital Assistant. Comme vous le verrez plus loin dans ce guide, vous obtiendrez des données supplémentaires à tester à partir de variations de test croisé dans le contexte de l'assistant numérique (tests voisins). Donc, si vous suivez les recommandations de ce guide, vous collecterez suffisamment de données pour les tests afin de vous assurer que vos modèles fonctionnent (même si cela ne finit pas par être un split 70/15/15). Et vous serez en mesure d'exécuter à plusieurs reprises ces tests pour avoir une idée des améliorations ou de la régression au fil du temps.

Il n'y a pas d'ordures, les diamants en matière d'IA conversationnelle. La qualité des données avec lesquelles vous entraînez votre modèle a un impact direct sur la compréhension du bot et sa capacité à extraire des informations.

L'objectif de la définition des variations est de créer un ensemble impartial et équilibré de données d'entraînement et de test qui n'encombrent pas le modèle d'intention. Pour ce faire, voici quelques règles à suivre qui, selon notre expérience, donnent de bons résultats

• N'utilisez pas les outils de génération pour créer des variations. Les chances sont que vous obtiendrez beaucoup de variations avec peu de variation.

• Considérez différentes approches pour déclencher une intention, telles que "Je veux réinitialiser mon mot de passe" ou "Je ne peux pas me connecter à mon courriel".

• N'utilisez pas de variations composées de mots uniques, car elles n'ont pas le contexte à partir duquel le modèle machine peut apprendre.

• Évitez les mots comme "s'il vous plaît", "merci", etc. qui ne contribuent pas beaucoup à la signification sémantique des variations.

• Utilisez un ensemble représentatif de valeurs d'entité, mais pas toutes.

• Changer le placement de l'entité. Vous pouvez placer l'entité au début, au milieu et à la fin de la variation.

• Maintenez l'équilibre entre le nombre de variations (par exemple, évitez 300 pour une intention et 15 pour une autre).

• Recherchez des phrases complètes sur le plan sémantique et syntaxique.

• Utilisez des orthographes correctes. Ce n'est que par exception que vous ajouteriez très probablement des fautes d'orthographe et des fautes de frappe dans les variations. Le modèle est généralement capable de traiter les fautes d'orthographe et les fautes de frappe par lui-même.

• Ajouter des variations spécifiques au pays (p. ex. poubelle vs poubelle, couches vs couches).

• Variez la structure de la phrase (par exemple "Je veux commander une pizza", "Je veux une pizza, puis-je commander").

• Changez le pronom personnel (par exemple, je, nous sommes, nous sommes, je le ferais, je le ferais, nous, vous, votre, nous).

• Utilisez des termes différents pour le verbe (par exemple, ordre, obtenir, demander, vouloir, aimer, vouloir).

• Utilisez des termes différents pour le nom (par exemple pizza, calzone, hawaïen).

• Créez des variations de longueurs variables (phrases courtes, moyennes et longues).

• Pensez à la pluralisation (par exemple, "Je veux commander des pizzas", "Puis-je commander des pizzas").

• Envisagez d'utiliser différentes formes verbales et gerunds ("La pêche est autorisée", "Je veux pêcher, puis-je le faire").

• Utilisez la ponctuation dans certains cas et omettez-la dans d'autres.

• Utilisez des termes représentatifs (par exemple, évitez les termes techniques trop nombreux si le logiciel est utilisé par les consommateurs).

Les variations ne doivent pas être définies de la même manière que vous écririez des arguments de ligne de commande ou des mots-clés de liste. Assurez-vous que toutes les variations que vous définissez ont la notion de "conversationnel". La création de variations dont seuls les mots-clés sont répertoriés manque de contexte ou est simplement trop courte pour que le modèle d'apprentissage automatique puisse en tirer des enseignements.

Idéalement, les bonnes variations sont organisées à partir de données réelles. Si vous n'avez pas de journaux de conversation existants pour commencer, considérez les variations de crowdsourcing plutôt que de simplement les synthétiser. La synthèse devrait être votre dernier recours.

Pour les variations provenant de sources multiples, envoyez des courriels aux personnes que vous connaissez qui représentent ou savent représenter le public visé de votre bot. En outre, vous pouvez utiliser la fonction de fabrication de données d'Oracle Digital Assistant pour configurer un processus automatisé de collecte (crowdsourcing) de suggestions de variations, que vous souhaiterez probablement organiser afin qu'elles soient conformes aux règles que nous avons définies pour ce qui fait une bonne variation.

Notez que vous pouvez constater que les personnes que vous demandez des exemples de variations se sentent mises au défi de trouver des exemples exceptionnellement bons, ce qui peut conduire à des cas de niche irréalistes ou à une utilisation trop artistique du langage vous obligeant à organiser les phrases.

Gardez également à l'esprit que la gestion des variations d'échantillons implique également la création de multiples variations d'échantillons individuels que vous avez récoltés via le crowdsourcing.

La qualité des variations est plus importante que la quantité. Quelques bonnes variations sont meilleures que de nombreuses recommandations utterances.Our mal conçues : commencer par 20 à 30 bonnes variations par intention en cours de développement et éventuellement augmenter ce nombre à 80-100 pour les tests sérieux de vos intentions. Au fil du temps, au fur et à mesure que le bot est testé avec des utilisateurs réels, vous allez collecter des variations supplémentaires que vous allez ensuite organiser et utiliser pour entraîner le modèle d'intention.

Selon l'importance et le cas d'utilisation d'une intention, vous pouvez vous retrouver avec différents nombres de variations définies par intention, allant de cent à plusieurs centaines (et, rarement, en milliers). Cependant, comme mentionné précédemment, la différence entre les variations par intention ne doit pas être extrême.

Un modèle d'apprentissage automatique évalue un message utilisateur et renvoie un score de confiance pour ce qu'il pense être l'étiquette de niveau supérieur (intention) et les finalistes. Dans l'IA conversationnelle, le libellé de niveau supérieur est résolu en tant qu'intention de démarrer une conversation.

Donc, en fonction de l'entraînement du modèle et du message utilisateur, imaginez un cas où le modèle a 80 % confiance que l'intention A est une bonne correspondance, 60 % confiance pour l'intention B et 45 % pour l'intention C. Dans ce cas, vous seriez probablement assez à l'aise que l'utilisateur souhaite l'intention A.

Mais que se passe-t-il si l'étiquette de notation la plus élevée n'a que 30 % confiance que c'est ce que l'utilisateur veut ? Risquez-vous que le modèle suive cette intention, ou préférez-vous la jouer en toute sécurité et supposer que le modèle ne peut pas prédire ce qu'un utilisateur voudrait et afficher un message à l'utilisateur pour reformuler une demande ?

Pour aider le modèle d'intention à prendre une décision sur les intentions à envisager de mettre en correspondance avec une variation utilisateur, l'IA conversationnelle utilise un paramètre appelé seuil de confiance. Le modèle d'intention évalue une variation utilisateur par rapport à toutes les intentions et affecte des scores de confiance pour chaque intention. Le seuil de confiance est une valeur comprise dans la plage des scores de confiance possibles qui marque la ligne :

• au-dessous duquel une intention est considérée comme ne correspondant pas du tout à l'énoncé ; et

• au-dessus duquel une intention est considérée comme une intention candidate pour démarrer une conversation.

Dans Oracle Digital Assistant, le seuil de confiance est défini pour une brique dans les paramètres de la brique et a la valeur par défaut 0.7.

La valeur 0.7 est une bonne valeur pour commencer et tester le modèle d'intention entraîné. Si les tests montrent que l'intention correcte pour les messages utilisateur est résolue bien au-dessus de 0,7, vous disposez d'un modèle bien entraîné.

Si vous obtenez de bons résultats avec un paramètre de 0.7, essayez 0.8. Plus la confiance est élevée, plus vous êtes susceptible de supprimer le bruit du modèle d'intention, ce qui signifie que le modèle ne répondra pas aux mots d'un message utilisateur qui ne sont pas pertinents pour la résolution du cas d'utilisation.

Cependant, plus le seuil de confiance est élevé, plus il est probable que la compréhension globale diminue (ce qui signifie que de nombreuses variations viables peuvent ne pas correspondre), ce qui n'est pas ce que vous voulez. En d'autres termes, 100% de "compréhension" (ou 1,0 comme niveau de confiance) pourrait ne pas être un objectif réaliste.

Rappelez-vous que l'IA conversationnelle consiste à comprendre ce que veut un utilisateur, même s'il peut l'exprimer de différentes manières. Par exemple, dans un cas de bot de pizza, les utilisateurs devraient pouvoir commander une pizza avec des phrases aussi diverses que "Je veux commander une pizza" et "J'ai faim".