Oracle Digital Assistant prend en charge deux types d'intentions : Intentions normales et Intentions de réponse. Les deux types d'intention utilisent le même modèle de TLN, qui doit être réglé à Trainer 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 ordinaires, lorsqu'elles sont résolues, mènent à une conversation utilisateur-agent définie dans le flux de dialogue.

Vous utilisez des intentions de réponse pour que le robot réponde aux questions fréquemment posées qui produisent toujours une seule réponse. Les intentions régulières sont utilisées pour démarrer une interaction utilisateur-agent plus longue qui mène à l'achèvement d'une tâche transactionnelle, à l'interrogation d'un système dorsal ou à la réponse à une question fréquemment posée qui doit tenir compte de 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 compétence plus efficaces, vous devez créer une convention d'attribution de nom pour vos intentions qui vous permet de comprendre immédiatement ce qu'une intention particulière signifie et d'utiliser l'option de filtre lors de la recherche d'intentions.

Par exemple, une partie du nom doit être définie entre les intentions de réponse et les intentions standard (et peut-être aussi les intentions standard dont vous avez besoin pour pouvoir retourner une réponse directe mais avec un traitement plus complexe, par exemple avec une pièce jointe ou basé sur une interrogation vers un service distant). Dans cet esprit, vous pouvez commencer avec 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 compétence gère des tâches connexes qui peuvent être catégorisées, cela peut également être utilisé dans l'attribution de nom aux intentions. Supposons que vous ayez l'intention de créer des commandes et d'annuler des commandes. À l'aide de ces deux cas d'utilisation, la convention d'attribution de nom 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 régulières 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 quelque chose de votre propre. Toutefois, gardez 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 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 compétence, si un message d'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 d'autres personnes qui maintiennent la compétence puissent la comprendre sans la deviner.

Un exemple d'intention de portée trop étroite consiste à définir une intention distincte pour chaque produit que vous souhaitez traiter par une compétence. 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 automobile" parce que la distinction entre les deux est un seul mot. Autre exemple négatif, imaginez si nous, chez Oracle, avons créé un assistant numérique pour nos clients afin qu'ils puissent demander le soutien des produits. Pour chacun de nos produits, nous avons créé une compétence distincte avec les mêmes intentions et les mêmes énoncés 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. Au contraire, vous avez simplement appris à tenir les choses. Le même principe s'applique à la création d'intentions pour un robot.

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 que vous avez nommée "handleExpenses" et que vous l'ayez entraînée avec les énoncés suivants et un bon nombre de leurs variations.

• "Je veux créer un nouveau rapport de frais"

• "Je veux vérifier mon rapport de frais récent"

• "Annuler mon dernier rapport de frais"

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

Par conséquent, un traitement supplémentaire serait nécessaire pour comprendre si un rapport de frais doit être créé, mis à jour, supprimé ou recherché. Pour éviter le code complexe dans votre flux de dialogue et réduire la surface d'erreur, vous ne devez pas concevoir des intentions dont la portée est trop large.

N'oubliez jamais que l'apprentissage automatique est votre ami et que votre conception de modèle devrait faire de vous un aussi bon ami 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 entre le message "J'ai acheté cet article le 12 juin 2021 et le 2 juillet 2021" lorsqu'on lui demande une date d'achat? Dans ce cas, l'entité, si elle est utilisée avec le groupe de pages Réponse commune ou Résoudre entités, générera automatiquement une boîte de dialogue de désambiguïsation permettant à l'utilisateur de sélectionner une seule valeur comme entrée de données. Comme dans la conversation humaine où une personne demanderait à une autre de désambiguïser une déclaration ou un ordre, les entités feront la même chose 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.

De plus, lorsque vous utilisez le groupe de pages 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 réinvités pour une entrée de données ayant échoué précédemment. Lorsque le message d'invite change entre les appels, il rend votre robot moins robotique et plus conversationnel. En outre, vous pouvez utiliser des invites alternatives 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ésambiguïsation.

Comme pour les intentions, nous recommandons de suivre une convention d'attribution de nom lors de la création des noms d'entité. Pour commencer, si vous incluez le type d'entité dans le nom de l'entité, il est plus facile à comprendre en un coup d'œil et fournit un moyen facile de filtrer 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 rationnelle : reg.<name_of_entity>

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

• Entité 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 quelque chose de votre choix dépend de vous. Au-delà, nous vous suggérons d'essayer de garder les noms assez courts.

Chaque entité a 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 d'énoncés pour vos intentions, vous utiliserez la plupart des énoncés comme données d'entraînement pour les intentions, mais vous devez également mettre de côté certains énoncés pour tester le modèle que vous avez créé. Un fractionnement des données 80/20 est courant dans l'IA conversationnelle pour le ratio entre les énoncés à créer pour l'entraînement et les énoncés à créer pour les tests.

Un autre rapport que vous pouvez trouver lors de la lecture sur l'apprentissage automatique est un fractionnement de 70/15/15. Un fractionnement de 70/15/15 signifie que 70 % de vos énoncés seront utilisés pour entraîner une intention, 15 % pour tester l'intention lors du développement et les 15 % restants pour les tests avant la mise en production. Une bonne analogie pour la formation à l'intention est un examen scolaire. Les 70% sont ce qu'un enseignant vous enseigne sur un sujet. Les 15% premiers sont alors des tests que vous prenez pendant que vous étudiez. Ensuite, lorsqu'il s'agit de rédiger votre examen, vous obtenez un autre ensemble de tests de 15% que vous n'avez jamais vu auparavant.

Bien que la version 70/15/15 soit convaincante, nous 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 pour les tests à partir d'énoncés de test croisé dans le contexte de l'assistant numérique (test de voisinage). Ainsi, si vous suivez les recommandations de ce guide, vous recueillerez suffisamment de données pour les tests afin de vous assurer que vos modèles fonctionnent (même s'il ne s'agit pas d'une division de 70/15/15). Et vous serez en mesure d'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 robot et sa capacité à extraire des informations.

L'objectif de la définition des énoncés est de créer un jeu impartial et équilibré de données d'entraînement et de test qui n'encombre 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 énoncés. Il est probable que vous obtiendrez de nombreux énoncés avec peu de variation.

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

• N'utilisez pas d'énoncés composés de mots uniques, car ils 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 énoncés.

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

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

• Gardez le nombre d'énoncés équilibré entre les intentions (par exemple, évitez 300 pour une intention et 15 pour une autre).

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

• Utilisez des orthographes correctes. Ce n'est que par exception que vous ajouterez des fautes d'orthographe et des fautes de frappe très probables dans les énoncés. Le modèle est généralement capable de faire face aux fautes d'orthographe et aux fautes de frappe par lui-même.

• Ajoutez des variations propres au pays (p. ex. poubelle vs poubelle, couche-culotte vs couche-culotte).

• 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, nous, vous, nous).

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

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

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

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

• Envisagez d'utiliser différentes formes de verbes 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 de trop de termes techniques si le logiciel est utilisé par les consommateurs).

Les énoncés ne doivent pas être définis de la même façon que vous écririez des arguments de ligne de commande ou des mots clés de liste. Assurez-vous que tous les énoncés que vous définissez ont la notion de "conversationnel" pour eux. La création d'énoncés qui ne contiennent que des mots clés n'ont pas de contexte ou sont tout simplement trop courts pour que le modèle d'apprentissage automatique puisse en tirer des leçons.

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

Pour les énoncés provenant d'une foule, envoyez un courriel aux personnes que vous connaissez qui représentent ou savent représenter le public visé par votre robot. En outre, vous pouvez utiliser la fonction de fabrication de données d'Oracle Digital Assistant pour configurer un processus automatisé de collecte (crowdsourcing) des suggestions d'énoncés, que vous souhaiterez probablement organiser afin qu'ils respectent les règles que nous avons définies pour ce qui constitue un bon énoncé.

Notez que vous pouvez trouver que les gens que vous demandez des exemples d'énoncés se sentent mis au défi de trouver des exemples exceptionnellement bons, ce qui peut conduire à des cas de niche irréalistes ou à une utilisation excessivement artistique du langage vous obligeant à organiser les phrases.

En outre, gardez à l'esprit que la conservation des exemples d'énoncés implique également la création de multiples variations d'échantillons individuels que vous avez collectés par le crowdsourcing.

La qualité des énoncés est plus importante que la quantité. Quelques bons énoncés sont meilleurs que beaucoup d'énoncés mal conçus. La recommandation utterances.Our consiste à commencer par 20 à 30 bons énoncés par intention en cours de développement et à éventuellement augmenter ce nombre à 80 à 100 pour tester sérieusement vos intentions. Au fil du temps et au fur et à mesure que le robot est testé avec des utilisateurs réels, vous collectez des énoncés 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 finir avec différents nombres d'énoncés définis par intention, allant de cent à plusieurs centaines (et, rarement, aux milliers). Cependant, comme mentionné précédemment, la différence dans les énoncés par intention ne doit pas être extrême.

Un modèle d'apprentissage automatique évalue un message utilisateur et retourne une note de confiance pour ce qu'il pense être l'étiquette de niveau supérieur (intention) et le résultat final. 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 se passe-t-il si l'étiquette de notation la plus élevée a seulement 30% de confiance que c'est ce que l'utilisateur veut? Voulez-vous risquer 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 à considérer pour la mise en correspondance avec un énoncé d'utilisateur, l'IA conversationnelle utilise un paramètre appelé seuil de confiance. Le modèle d'intention évalue un énoncé utilisateur par rapport à toutes les intentions et affecte des notes de confiance pour chaque intention. Le seuil de confiance est une valeur comprise dans l'intervalle de notes 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 compétence dans les paramètres de celle-ci et a la valeur par défaut 0.7.

Un paramètre de 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 bien supérieure à 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 nombreux énoncés viables peuvent ne pas correspondre), ce qui n'est pas ce que vous voulez. En d'autres termes, la "compréhension" à 100% (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 exprimer cela de différentes façons. Par exemple, dans un cas de robot pizza, les utilisateurs devraient pouvoir commander une pizza avec des phrases aussi diverses que "Je veux commander une pizza" et "J'ai faim".