Oracle Digital Assistant prend en charge deux types d'intention : 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, mènent à une conversation utilisateur-bot définie dans le flux de dialogue.

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

Pour rendre le développement et la maintenance de la brique plus efficaces, vous devez élaborer une convention de dénomination pour vos intentions qui vous permette de comprendre immédiatement ce qu'est une intention particulière et d'utiliser l'option de filtre lors de la recherche d'intentions.

Par exemple, une partie du nom doit être délimitée entre les intentions de réponse et les intentions standard (et peut-être également 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 en fonction d'une requête vers 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 classées, vous pouvez également l'utiliser dans la dénomination de l'intention. Supposons que vous ayez l'intention de créer des prescriptions et d'annuler des prescriptions. A l'aide des deux cas d'emploi suivants, la convention de dénomination peut être :

• 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'existe pas de règle stricte quant à l'utilisation de la notation par points, des traits de soulignement ou de vos propres méthodes. Toutefois, conservez les noms suffisamment courts pour qu'ils ne soient pas tronqués dans le panneau de l'éditeur d'intention d'Oracle Digital Assistant.

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

Chaque intention comporte 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 de définition trop étroite de la portée des intentions consiste à définir une intention distincte pour chaque produit que vous souhaitez gérer par une brique. Prenons l'exemple de l'extension d'une police d'assurance existante. 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, imaginons qu'Oracle ait créé un assistant numérique pour que nos clients puissent demander un support 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 tenir des bouteilles, des morceaux de papier, des jouets, des oreillers et des sacs. 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 une fois l'intention résolue. 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 récente note de frais"

• "Annuler ma récente note de frais"

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

Par conséquent, un traitement plus approfondi serait nécessaire pour déterminer si une note de frais doit être créée, mise à jour, supprimée ou recherchée. Pour éviter le code complexe dans votre flux de dialogue et réduire la surface d'erreur, vous ne devez pas concevoir des intentions trop larges.

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

Et il y a plus de fonctionnalités fournies par les entité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'il me demande une date d'achat ? Dans ce cas, l'entité, si elle est utilisée avec le composant Réponse commune ou Résoudre des 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 en tant qu'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'utilisation le prend en charge.

En outre, lorsque vous utilisez le composant Réponse commune ou Entités de résolution avec des entités personnalisées, les invites affichées pour les utilisateurs peuvent être définies dans l'entité de sorte que les utilisateurs obtiennent des invites alternatives lorsqu'ils sont invités à nouveau à saisir 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 alternées pour afficher 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éshomonymie.

Comme pour les intentions, nous recommandons de suivre 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 un élément personnel ne dépend que de vous. Au-delà de cela, nous vous suggérons d'essayer de garder les noms assez courts.

Chaque entité dispose d'un champ Description dans lequel vous devez décrire brièvement à quoi sert 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 réserver certaines variations pour tester le modèle que vous avez créé. Un fractionnement de données 80/20 est courant 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 l'apprentissage automatique est à une fraction de 70/15/15. Une scission 70/15/15 signifie que 70 % de vos variations seront utilisées pour entraîner une intention, 15 % pour tester l'intention lors du développement et les 15 % restants pour les tester avant de passer à la production. Une bonne analogie pour la formation d'intention est un examen scolaire. Le 70% est ce qu'un enseignant vous enseigne sur un sujet. Les 15% premiers sont ensuite 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 modèle 70/15/15 soit convaincant, nous vous recommandons 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 à des fins de test à partir de variations de test croisé dans le contexte de l'assistant numérique (test de voisins). Ainsi, si vous suivez les recommandations de ce guide, vous collecterez suffisamment de données pour les tester afin de vous assurer que vos modèles fonctionnent (même s'il ne s'agit pas d'un split 70/15/15). Et vous pourrez exécuter ces tests à plusieurs reprises pour avoir une idée des améliorations ou de la régression au fil du temps.

Il n'y a pas de déchets, des diamants quand il s'agit 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 d'outils de génération pour créer des variations. Il y a de fortes chances que vous obteniez de nombreuses variations avec peu de variation.

• Envisagez 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 ne disposent pas du contexte à partir duquel le modèle de machine peut apprendre.

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

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

• Faites varier 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 entre les intentions (par exemple, évitez 300 pour une intention et 15 pour une autre).

• Cherchez des phrases complètes sémantiquement et syntaxiquement.

• Utilisez des orthographes corrects. Ce n'est que par exception que vous ajouteriez des fautes d'orthographe et des fautes de frappe très probables dans les variations. Le modèle est généralement capable de gérer seul les fautes d'orthographe et les fautes de frappe.

• Ajoutez des variations spécifiques à chaque pays (p. ex. poubelle ou poubelle, couche ou couche).

• 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, moi, nous sommes, nous sommes, je voudrais, je voudrais, nous, vous, votre, nous).

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

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

• 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 trop de termes techniques 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 conversation. La création de variations dont seuls les mots-clés sont répertoriés n'a pas de contexte ou est tout 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, envisagez d'externaliser les variations plutôt que de simplement les synthétiser. Les synthétiser devrait être votre dernier recours.

Pour les variations provenant d'une foule, envoyez un courriel aux personnes que vous connaissez et qui représentent ou savent représenter l'audience prévue de votre bot. En outre, vous pouvez utiliser la fonctionnalité de fabrication de données d'Oracle Digital Assistant afin de configurer un processus automatisé pour la collecte (navigation) de suggestions de variations, que vous voudrez probablement organiser afin qu'elles soient conformes aux règles que nous avons décrites pour ce qui fait une bonne variation.

Notez que vous pouvez constater que les personnes que vous demandez des exemples de phrases 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 à traiter les phrases.

Gardez également à l'esprit que la conservation des variations d'échantillon implique également la création de plusieurs variations d'échantillons individuels que vous avez collectés via le crowdsourcing.

La qualité des variations est plus importante que la quantité. Quelques variations correctes sont meilleures que de nombreuses recommandations utterances.Our mal conçues. Elles consistent à commencer par 20 à 30 variations correctes par intention en développement, puis à augmenter ce nombre à 80-100 pour tester sérieusement vos intentions. Au fil du temps et au fur et à mesure que le bot est testé avec des utilisateurs réels, vous collectez des variations supplémentaires que vous organisez et utilisez 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, à des milliers). Toutefois, 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 le libellé de niveau supérieur (intention) et les finalistes. Dans l'IA conversationnelle, l'étiquette de niveau supérieur est résolue comme l'intention de démarrer une conversation.

Ainsi, en fonction de l'entraînement du modèle et du message de l'utilisateur, imaginez un cas où le modèle a 80 % de confiance que l'intention A est une bonne correspondance, 60 % de 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 faire si l'étiquette de notation la plus élevée n'a que 30% de confiance que c'est ce que l'utilisateur veut ? Risquez-vous que le modèle suive cette intention ou préférez-vous le lire 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 à prendre en compte pour la mise 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 :

• en dessous de laquelle une intention est considérée comme ne correspondant pas du tout à l'énoncé ; et,

• au-dessus de laquelle 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.

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

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 qu'un utilisateur veut, même s'il peut l'exprimer de différentes manières. Par exemple, dans un cas de bot de pizza, les utilisateurs devraient être en mesure de commander une pizza avec des phrases aussi diverses que "Je veux commander une pizza" et "J'ai faim".