Documentation Oracle Cloud Infrastructure

Bonnes et mauvaises pratiques en matière de conception conversationnelle

La création d'un ensemble riche d'intentions pour une brique efficace requiert beaucoup d'attention. Voici quelques-unes des meilleures pratiques à connaître.

Conception et entraînement des intentions

A FAIRE Ne pas
Prévoir d'ajouter des variations jusqu'à obtenir les résultats escomptés. D'une manière générale, plus vous ajoutez de variations d'entraînement de qualité, mieux les modèles fonctionnent. Le nombre de variations requis dépend du modèle, des données d'entraînement et du niveau de précision réaliste de votre modèle. Ne pas entraîner excessivement les intentions individuelles. N'ajoutez pas de données d'entraînement excessives à certaines intentions pour les rendre "parfaitement efficaces". Si la résolution d'intention ne se comporte pas comme prévu, évaluez la structure de vos intentions pour repérer des chevauchements entre celles-ci. La résolution d'intention ne sera jamais précise à 100 %.
Utiliser des données réelles. Il est essentiel d'utiliser un langage réel que votre brique est susceptible de rencontrer. Les variations que vous inventez offrent des résultats limités et ne prépareront pas votre brique à des interactions réelles. Ne pas utiliser uniquement des mots-clés dans les données d'entraînement. Bien qu'il soit possible d'utiliser des mots uniques ou des expressions courtes pour l'entraînement, les données de ce dernier doivent avoir la même structure que les saisies utilisateur. Moins les variations contiennent de mots, moins leur classification sera efficace.
Utiliser des phrases entières pour entraîner les intentions. Bien que vous puissiez utiliser des variations d'entraînement abrégées, assurez-vous de correspondre autant que possible au style conversationnel de vos utilisateurs. Ne pas biaiser les intentions par inadvertance. Faites attention aux mots qui n'ajoutent pas de sens spécifique (par exemple, "please" et "thanks") ou aux valeurs d'entité au sein des variations, car ils peuvent biaiser par inadvertance la résolution d'intention s'ils sont abondamment utilisés dans une intention mais pas dans une autre.
Utiliser un nombre similaire de variations par intention. Certaines intentions (par exemple, "hello" et "goodbye") peuvent comporter un nombre moins important de variations dans leurs ensembles d'entraînement. Cependant, assurez-vous que vos intentions principales comportent un nombre similaire de variations afin d'éviter que votre modèle ne soit biaisé. Ne pas s'appuyer uniquement sur la résolution d'intention. Utilisez des entités pour lever l'ambiguïté des intentions courantes. En cas de chevauchement linguistique entre des intentions, envisagez d'utiliser des entités pour lever l'ambiguïté des intentions de l'utilisateur (et du parcours conversationnel unique correspondant).
Gérer les échanges de banalités. Les utilisateurs adresseront des demandes non pertinentes pour l'objectif de la brique, par exemple des plaisanteries et des informations sur la météo. Ils peuvent également effectuer d'autres actions comme demander si la brique est une personne. Assurez-vous que vous disposez d'une stratégie pour les échanges de banalités et testez de manière agressive la réponse de la brique à toutes les étapes de votre flux conversationnel. Ne pas trop utiliser unresolvedIntent. Créez des intentions hors de portée pour les éléments que vous êtes certain de ne pas connaître (que vous pourrez autoriser ou non votre brique à traiter ultérieurement).
Imaginer plusieurs intentions pour un même cas d'emploi. Les clients peuvent exprimer un même besoin de plusieurs façons. Ils peuvent par exemple exprimer la solution qu'ils désirent ou le symptôme de leur problème. Utilisez plusieurs intentions qui se résolvent toutes en une même "réponse". Ne pas négliger les interactions abusives. Tout comme pour les échanges de banalités, vous devez avoir un plan pour les utilisations abusives. Ce plan peut nécessiter d'inclure des mesures visant à garantir que les saisies utilisateur abusives ne sont pas reflétées par la brique, ainsi qu'à fournir une escalade immédiate.

Expérience utilisateur conversationnelle

A FAIRE Ne pas
Donner des indications des réponses les plus probables (notamment l'aide et la sortie). Par exemple, "Hey, I'm Bob the Bot. Posez-moi une question sur X, Y ou Z. Si vous rencontrez des problèmes, tapez simplement "help". Ne pas repousser la conception conversationnelle à une étape ultérieure du projet. Pour toutes les briques, à l'exception des plus simples, vous devez accorder la même priorité et la même urgence à la conception conversationnelle qu'aux autres tâches de développement. Vous devez la commencer rapidement et la traiter en parallèle des autres tâches.
Envisager de donner une personnalité au bot. Vous devez réfléchir à la personnalité et à la tonalité de votre bot. Toutefois, vous devez veiller à ne pas trop vous rapprocher des interactions humaines (l'humour et la compassion ne sont pas toujours bien perçues venant d'un bot) et à ne jamais essayer de faire croire à vos utilisateurs qu'ils interagissent avec une personne. Ne pas dire que la brique est toujours en phase d'apprentissage. Bien que cette pratique découle de bonnes intentions, elle signale à l'utilisateur (consciemment ou non) que la brique n'est pas à la hauteur de la tâche.
Guider les utilisateurs en leur expliquant ce qui est attendu d'eux. La brique doit essayer de guider l'utilisateur vers une réponse appropriée et ne pas laisser de questions ouvertes. Les questions ouvertes augmentent la probabilité que l'utilisateur dévie du parcours idéal. Ne pas utiliser de réponses de politesse ou non pertinentes. Reportez-vous à Guider les utilisateurs en leur expliquant ce qui est attendu d'eux.
Diviser les réponses longues en bulles de discussion individuelles et/ou utiliser des sauts de ligne. Les blocs de texte volumineux sans séparation visuelle sont difficiles à lire et peuvent entraîner des confusions. Ne pas dire "I'm sorry, I don’t understand. Voulez-vous reformuler votre question ?" Cette approche laxiste de la gestion des erreurs est plus souvent incorrecte que l'inverse. Peu importe le nombre de fois où un utilisateur reformule une question hors de portée, la brique ne pourra jamais répondre une phrase intelligente.
-- Ne pas abuser des expressions de confirmation. Les expressions de confirmation sont utiles. Veillez toutefois à ne pas en abuser. Envisagez de mettre en place des flux de dialogue capables de prendre en compte les niveaux de confiance avant de demander une confirmation aux utilisateurs.

Stratégies de test

A FAIRE Ne pas
Développer les variations de manière cyclique. Le développement d'un corpus d'entraînement riche nécessite plusieurs itérations et cycles de test, ainsi qu'une surveillance et des réglages en continu. Adoptez une approche cyclique "créer, tester, surveiller, mettre à jour". Ne pas négliger la nécessité d'un plan de mesure des performances et d'amélioration. Sans plan destiné à mesurer les performances de votre brique et à l'améliorer, vous ne pourrez pas savoir si elle fonctionne réellement.
Tester les variations à l'aide de la règle 80/20. Testez toujours la fiabilité de vos intentions les unes par rapport aux autres en effectuant plusieurs tests 80/20, où 80 % des variations nouvellement collectées sont utilisées pour entraîner le modèle et où 20 % sont ajoutées à vos données de test. Ne pas tester uniquement le parcours idéal. Réussir à faire fonctionner ce parcours représente 20 % du travail. Les 80 % restants consistent à tester et à ajuster la réponse de la brique aux actions et aux saisies utilisateur incorrectes.
Tester l'échec de la brique. Essayez activement de faire dysfonctionner votre brique pour observer ce qui se produit. Ne vous fiez pas uniquement aux tests positifs. Ne pas négliger le traitement des messages dans le désordre. Les utilisateurs feront défiler l'historique de la conversation et cliqueront sur des boutons précédents. Le test de ces résultats doit faire partie des 80 % de travail indiqués dans Ne pas tester uniquement le parcours idéal.
-- Ne pas oublier d'effectuer un nouveau test lors de la mise à jour des intentions. Si vous ajoutez d'autres données d'entraînement (par exemple, au fur et à mesure que votre bot collecte des utilisations réelles) et/ou que vous ajoutez de nouvelles intentions pour de nouveaux cas d'emploi, n'oubliez pas de tester à nouveau votre modèle.

Remarques concernant les projets

A FAIRE Ne pas
Sélectionner des cas d'emploi améliorés par l'interface utilisateur conversationnelle. L'activation de l'interface utilisateur conversationnelle (via des briques et des assistants numériques) représente une certaine charge de travail. Assurez-vous que le cas d'emploi est réellement amélioré par l'ajout de l'interface utilisateur conversationnelle. Ne pas oublier d'intégrer un parcours d'escalade. Même si vous n'avez pas l'intention d'autoriser l'escalade vers une personne physique, vous devez disposer d'une stratégie pour les interactions où la brique ne peut pas apporter d'aide.
S'attendre à ce que le premier jour soit le pire. Même les briques et les assistants numériques les mieux testés doivent faire l'objet de réglages lors du premier jour. Ne pas congédier l'équipe du projet immédiatement après le lancement. Lorsque vous planifiez votre projet de brique, veillez à conserver les créateurs de la brique (concepteur de conversations, responsable de projet, responsable technique et autres) suffisamment longtemps dans le projet à des fins de réglage adéquat et de transfert des connaissances.