Bonnes pratiques générales de conception d'agents

Ce guide présente les bonnes pratiques générales pour concevoir tous les types d'agents.

Consultez également le guide de conception d'un agent vocal, qui est spécifiquement dédié à la conception d'agents vocaux, ainsi que le guide des bonnes pratiques pour l'utilisation du service Dialogflow CX.

Conseils généraux

Créer des agents de manière itérative

Si vous souhaitez concevoir un agent complexe ou de grande taille, commencez par créer une boîte de dialogue qui ne traite que les requêtes de niveau supérieur. Une fois la structure de base établie, perfectionnez le fil de la conversation pour vous assurer que toutes les voies qu'un utilisateur final pourrait emprunter sont envisagées.

À mesure que votre agent évolue, pensez à utiliser la fonctionnalité Scénarios de test pour le développement piloté par les tests.

Agents prédéfinis

Dialogflow CX propose des modèles d'agents pour vous aider à démarrer. Les agents prédéfinis couvrent les cas d'utilisation courants tels que les services financiers, les télécommunications et les voyages. Ces agents sont fournis avec des intents et des entités couvrant les requêtes utilisateur les plus répandues. Ajoutez des itinéraires et des options de traitement spécifiques à votre entreprise, et vous disposerez rapidement d'un agent opérationnel.

Intégrations et connexion de vos services

Il existe plusieurs façons de s'intégrer aux agents Dialogflow CX. Cette section présente les bonnes pratiques pour choisir la méthode d'intégration.

Intégrations

Les intégrations Dialogflow CX fournissent une interface utilisateur prête à l'emploi pour votre agent. Si vous utilisez une intégration, vous n'avez pas besoin d'appeler directement l'API Dialogflow CX, car les intégrations s'en chargent pour vous. Ces intégrations peuvent fournir un agent textuel que vous pouvez intégrer à votre site Web, vous connecter à d'autres plates-formes de messagerie ou fournir une interface de téléphonie.

API Dialogflow CX

Si aucune des intégrations prêtes à l'emploi ne convient ou si vous souhaitez personnaliser l'interface de votre système, vous pouvez utiliser directement l'API Dialogflow CX. Avec cette approche, vous devrez implémenter l'interface utilisateur de votre agent ou utiliser une interface utilisateur existante.

Webhooks

À moins que votre agent ne puisse être entièrement défini avec des données statiques, vous devez utiliser des webhooks pour connecter votre service et fournir un agent capable de gérer des scénarios dynamiques. Cela s'applique que vous utilisiez des intégrations ou l'API Dialogflow CX.

Ressources pour les agents

Les ressources d'agent Dialogflow CX peuvent être utilisées de nombreuses façons pour obtenir le résultat souhaité. Cette section fournit des conseils pour choisir les ressources appropriées pour les scénarios appropriés.

Flux et pages

Les flux et les pages structurent votre agent. Vous pouvez considérer les pages comme des nœuds dans une machine à états et les flux comme des groupes de pages associées. Vous contrôlez les transitions entre les nœuds à l'aide de gestionnaires d'état, qui sont appelés lorsqu'une intention est identifiée, qu'une condition est remplie ou qu'un événement est appelé.

Un agent simple peut fonctionner correctement avec un seul flux, mais les agents complexes sont presque toujours mieux conçus avec plusieurs flux. Chaque flux doit représenter un thème de haut niveau pour votre agent, où chaque page associée au flux permet de traiter le thème. De plus, chaque flux peut avoir ses propres paramètres et peut appartenir à un sous-ensemble de membres de l'équipe, ce qui permet de répartir le travail lors de la conception d'agents volumineux.

Lorsque vous concevez un agent volumineux et complexe, vous devez tenir compte des limites concernant le nombre de flux par agent et le nombre de pages par flux. Ces limites permettent de maintenir les performances de votre agent.

Si la conception de votre agent comporte trop de flux par agent, combinez les thèmes associés dans un seul flux. Par exemple, vous pouvez combiner les thèmes suivants dans un seul flux "Obtenir le solde" :

• Obtenir le solde du compte courant
• Obtenir le solde des économies
• Obtenir le solde de votre prêt hypothécaire
• Obtenir le solde de crédit

Si la conception de votre agent comporte trop de pages par flux, combinez les pages associées et utilisez de nombreuses routes par page.

Si vous rencontrez toujours des difficultés avec les limites de flux et de pages, c'est peut-être parce que vous avez intégré trop de logique métier à l'agent lui-même. Envisagez de déplacer cette logique vers les Webhooks.

Vous trouverez ci-dessous la précision du contrôle des conversations pour les ressources de l'agent, classée par ordre croissant :

1. Agents (un agent gère toutes les conversations)
2. Flux (un flux gère un ou plusieurs thèmes de conversation associés)
3. Pages (une page gère un ou plusieurs tours de conversation associés)
4. Routes (une route gère un intent utilisateur ou une vérification de condition)

Paramètres d'intent et paramètres de formulaire

La principale façon dont votre système obtient des données structurées de l'utilisateur final est avec les paramètres. Vous pouvez utiliser des paramètres pour les intents (paramètres d'intent) ou les pages (paramètres de formulaire).

L'objectif principal de certaines pages est de collecter des informations spécifiques auprès de l'utilisateur final. Par exemple, une page peut être conçue pour collecter les coordonnées de l'utilisateur final. Dans ce cas, vous devez toujours utiliser des paramètres de formulaire pour collecter ces informations.

Dans certains cas, vous pouvez souhaiter capturer des informations sur l'utilisateur final lors du passage d'une page à une autre. Par exemple, si l'utilisateur final demande un produit particulier au début de la conversation, vous devez capturer le produit souhaité tout en passant à la page de commande appropriée. Dans ce cas, utilisez les paramètres d'intent dans les routes d'intent.

Il existe également des situations dans lesquelles il est idéal d'utiliser à la fois des paramètres d'intent et des paramètres de formulaire. Par exemple, si l'utilisateur final demande un t-shirt de petite taille au début de la conversation, vous devez capturer le paramètre de taille souhaité (petite) lors de la transition vers la page de commande de t-shirt. La page de commande de t-shirts peut vous demander des informations supplémentaires, comme la couleur souhaitée. La page de commande de t-shirts doit comporter des paramètres de formulaire pour la taille et la couleur. Dans cet exemple, le paramètre de taille a déjà été fourni et est propagé. L'agent ne demandera donc que la couleur. Toutefois, d'autres conversations peuvent suivre un chemin différent, où l'utilisateur final n'a pas indiqué la taille souhaitée lorsque la page de commande de la chemise est devenue active. En définissant ce paramètre de deux manières, votre agent est plus flexible dans la façon dont il extrait les informations.

Remarque : Lorsque vous définissez des paramètres avec le même ID ou nom à afficher dans différentes intentions ou différents formulaires, assurez-vous que le type d'entité et les autres paramètres sont identiques pour toutes les définitions. Si le type d'entité ou d'autres paramètres diffèrent, utilisez un ID ou un nom à afficher unique pour chaque définition.

Routes et groupes de routes

Si vous souhaitez passer à une autre page, mettre en file d'attente un message de réponse ou appeler un webhook lorsqu'un intent est mis en correspondance ou qu'une condition est remplie, utilisez des routes.

Si vous utilisez le même ensemble de routes sur plusieurs pages, utilisez des groupes de routes. Cela vous évitera de dupliquer inutilement des éléments dans la conception de votre agent.

Réutilisation des intents

Si vous définissez plusieurs intents avec des expressions d'entraînement similaires, envisagez de réutiliser les intents sur plusieurs pages. Idéalement, vous devez définir des intents à usage général qui sont utilisés sur de nombreuses pages et des intents spécifiques qui ne sont utilisés que sur une seule page. Cela vous évitera de dupliquer inutilement des éléments dans la conception de votre agent.

Par exemple, les intents de confirmation sont généralement mieux définis comme des intents réutilisables. Un intent confirmation.yes peut comporter des phrases d'entraînement telles que :

• oui
• ouais
• Oui.
• OK
• oui, je veux
• tout à fait
• absolument
• oui s'il te plaît

Un intent confirmation.no peut comporter des phrases d'entraînement telles que :

• non
• nah
• non
• pas moyen
• pas pour moi
• absolument pas
• non, merci

Ces intentions de confirmation réutilisables peuvent être utilisées dans de nombreux scénarios pour votre agent.

Dans certains cas, vous devez également envisager de créer des intents de confirmation spécialisés. Par exemple, lorsque vous confirmez une commande, vous pouvez utiliser un intent order.confirmation.yes spécialisé avec des phrases d'entraînement telles que :

• la commande me semble correcte.
• J'accepte cette commande

et un intent order.confirmation.no spécialisé avec des phrases d'entraînement telles que :

• Je ne veux pas de cette commande
• Je n'accepte pas cette commande

Lorsque la page de confirmation de votre commande est active, les routes d'intention pour ces quatre intentions doivent être incluses. Cela permet de s'assurer que toute confirmation générique ou spécifique de l'utilisateur final sera traitée de manière appropriée.

Intent négatif par défaut

Vous devez remplir l'intent négatif par défaut avec des expressions que vos utilisateurs finaux pourraient prononcer, mais qui ne doivent correspondre à aucun intent de votre agent.

Fulfillment

Il existe de nombreuses options pour utiliser le fulfillment afin de répondre à l'utilisateur final. Pendant un tour de conversation, l'agent peut ajouter plusieurs messages à la file d'attente de réponses. La file d'attente concaténée est envoyée à l'utilisateur final à la fin du tour de conversation. Cette section décrit chaque option permettant de créer les messages individuels.

• Fulfillment d'entrée de page : ce fulfillment est appelé lorsque la page devient active. Il est utile lorsque vous souhaitez qu'un message décrive l'objectif de la page. Il ne doit être prononcé qu'une seule fois lorsque la page est active. Exemple :
  • Que souhaitez-vous savoir sur votre compte courant ?
  • Quel type de produit souhaitez-vous acheter ?
  • J'ai besoin de collecter des informations sur le t-shirt que vous souhaitez commander.
• Routes : ce fulfillment est appelé lorsqu'une route d'intent ou une route de condition avec fulfillment est appelée. Cela est utile lorsque vous souhaitez qu'un message réponde à l'utilisateur final concernant la correspondance de l'intention, la condition remplie (qui peut être une condition d'achèvement du remplissage du formulaire) ou la transition. Par exemple :
  • Oui, votre forfait international inclut le Japon. (correspondance d'intent)
  • Voulez-vous vraiment acheter 300 chemises ? (condition de comparaison remplie)
  • D'accord, votre rendez-vous est prévu demain matin à 7h. (remplissage de formulaire)
  • Parlons maintenant des oryx. (transition)
• Gestionnaires d'événements : ce fulfillment est appelé lorsqu'un événement est invoqué. Cette option est utile lorsque vous souhaitez obtenir un message qui répond à l'événement. Exemple :
  • La valeur de l'action que vous envisagez d'acheter vient d'augmenter de 10 %. (événement personnalisé)
  • Pouvez-vous reformuler ? (événement sans correspondance)
• Invites initiales pour formulaires : ce fulfillment est appelé lorsque l'agent remplit un formulaire. Ces messages doivent poser une question spécifique à l'utilisateur final. Chaque paramètre de formulaire possède son propre fulfillment d'invite initiale. Exemple :
  • Quelle taille de t-shirt souhaitez-vous ?
  • Quelle couleur de chemise souhaitez-vous ?
• Gestionnaires de nouvelles invites pour les formulaires : ce traitement est appelé lorsque l'agent remplit un formulaire et ne comprend pas la sélection de l'utilisateur final pour le paramètre actuel. Cette réponse n'est nécessaire que si vous souhaitez que le message de relance soit différent du message de requête initial. Si aucun gestionnaire de nouvelles invites n'existe, l'agent utilise simplement l'invite initiale comme message de nouvelle invite. Exemple :
  • Je ne comprends pas. Veuillez indiquer une couleur valide pour la chemise.

Dénomination

Cette section fournit des conseils pour nommer les ressources de l'agent.

Nommer les intents

Si votre agent dispose de nombreux intents, vous devez envisager un schéma de nommage qui vous aidera à les organiser. Il est courant de segmenter les noms d'intents avec des signes de ponctuation, avec une spécificité croissante de gauche à droite. De plus, un nom d'intent doit refléter l'intention de l'utilisateur final pour un tour de conversation.

Il existe de nombreux schémas de nommage. En voici un exemple :

• phone-service.order.cancel
• phone-service.order.create
• phone-service.order.change
• tv-service.order.cancel
• tv-service.order.create
• tv-service.order.change
• account.balance.get
• account.balance.pay
• account.address.get
• account.address.update

Transitions

Les transitions définies dans les gestionnaires d'état permettent de contrôler la conversation en modifiant la page active. Cette section fournit des conseils pour organiser les transitions d'agent.

Transitions sans frais

Lorsque vous définissez un itinéraire qui déclenche une transition, tenez compte du fait qu'il peut exister un itinéraire complémentaire ou inverse.

Exemple :

• Si vous avez une route d'intent pour confirmation.yes, envisagez de définir une autre route pour confirmation.no.
• Si vous définissez un itinéraire conditionnel avec un opérateur booléen =, envisagez de définir un autre itinéraire qui utilise !=.

Gérer les entrées utilisateur

Cette section fournit des consignes concernant les intents et les phrases d'entraînement, afin que votre agent puisse gérer et traiter de manière optimale les entrées des utilisateurs finaux.

Définir au moins 20 expressions d'entraînement

Vous devez disposer d'au moins 20 expressions d'entraînement pour chaque intent. Sinon, le modèle NLU risque de ne pas disposer de suffisamment d'informations pour faire correspondre correctement votre intention. Il s'agit d'une recommandation minimale. Dans l'idéal, vous devriez en définir davantage, en particulier pour les intents principaux des grands agents, où environ 50 est souhaitable.

Prenez conscience du biais d'intention

Lorsque un ou plusieurs intents comportent beaucoup plus d'expressions d'entraînement que les autres, le modèle NLU est biaisé en faveur des intents les plus importants en raison des données déséquilibrées. Ce biais d'intention peut se produire lorsque la quantité d'expressions d'entraînement diffère d'un ordre de grandeur ou plus.

Dans certains cas, ce comportement est souhaitable, car vous pouvez définir des intents qui doivent être mis en correspondance plus souvent que d'autres, car ils correspondent à des entrées d'utilisateur final plus fréquemment observées dans le trafic réel.

Dans d'autres cas, ce comportement peut être indésirable, car vous ne souhaitez pas de biais en faveur de ces intentions plus larges. Si c'est le cas, réduisez le nombre de phrases d'entraînement pour ces intents plus importants afin qu'ils soient du même ordre de grandeur que les autres intents. Exemple :

Phrases d'entraînement de l'intention A	Phrases d'entraînement de l'intention B	Biais pour l'intention B
20	50	Non
20	200	Passable
20	2000	Oui

Utilisation des entités et quantité de phrases d'entraînement

Pour tous les types d'entités utilisés dans une intention :

• Annotez chaque exemple des types d'entités.
• Pour chacun des types d'entités, fournissez au moins cinq expressions d'entraînement contenant des exemples annotés.
• Fournissez au moins trois fois plus d'expressions d'entraînement que de types d'entités. Par exemple, si vous utilisez 10 types d'entités différents pour les annotations dans un intent, vous devez disposer d'au moins 30 expressions d'entraînement.

Les expressions d'entraînement doivent être naturelles

Les expressions d'entraînement doivent être conversationnelles et naturelles. Elles doivent correspondre à ce que les utilisateurs disent réellement. Dans la mesure du possible, utilisez comme données d'entraînement les entrées des utilisateurs finaux qui se sont produites en production, en accordant une attention particulière à celles qui sont les plus courantes.

Variété nécessaire des expressions d'entraînement

Incluez des variantes de questions, de commandes, de verbes et de synonymes pour les noms communs afin de vous assurer que les expressions couvrent un large éventail de requêtes possibles.

Il est préférable d'inclure des expressions courtes comme "payer ma facture", ainsi que des expressions et des phrases plus longues comme "Je viens de recevoir un courrier m'indiquant que je dois payer le solde de mon relevé". Il n'existe pas de proportion recommandée entre les phrases courtes et longues, mais vous devez vous baser sur les entrées réelles des utilisateurs finaux envoyées à votre agent en production.

Il est important de définir des expressions d'entraînement dont la longueur, la formulation et la structure des phrases varient pour assurer un bon entraînement de votre agent. Il n'est pas nécessaire d'ajouter de la variété pour le plaisir, mais il est nécessaire d'en fournir suffisamment pour que le modèle NLU puisse détecter l'intention de l'utilisateur final à partir d'un large éventail d'entrées. Si la variété n'est pas suffisante, il existe un risque de surapprentissage. En d'autres termes, le modèle risque d'être trop étroitement lié aux exemples spécifiques que vous fournissez et de ne pas se généraliser suffisamment à d'autres exemples.

Variété de la mise en majuscules

La sensibilité à la casse varie en fonction du modèle NLU utilisé par votre agent.

NLU standard

Le modèle NLU standard n'est pas sensible à la casse. Dans de rares cas, vous devrez peut-être ajouter des expressions d'entraînement qui ne diffèrent que par la casse. Cela s'applique généralement aux situations où vous vous attendez à ce que les utilisateurs finaux fournissent des entrées de texte en majuscules.

Voici quelques exemples d'approches alternatives :

• Diminution du seuil de classification du ML
• Mettre en minuscules les entrées des utilisateurs finaux avant de les envoyer à Dialogflow CX.

NLU avancée

Contrairement au modèle de NLU standard, le modèle de NLU avancé est sensible à la casse. Nous vous recommandons de tester et d'ajouter les données d'entraînement pertinentes en majuscules pour augmenter les taux de correspondance de l'intention.

Variété inutile des expressions d'entraînement

Évitez les variations triviales dans les expressions d'entraînement, car elles fournissent des informations en double au modèle NLU. Par exemple, n'incluez pas les variantes qui ne diffèrent que par :

• Majuscules : si vous utilisez le modèle NLU standard, évitez les expressions en double (par exemple, "Commander un billet" et "commander un billet"), sauf dans de rares cas. Toutefois, le modèle NLU avancé est sensible à la casse et nécessite davantage de expressions d'entraînement pour augmenter les correspondances d'intention. Pour en savoir plus, consultez la section Variété de capitalisation.
• Mots de remplissage : par exemple, "d'accord, commande un billet" et "commande un billet".
• Ponctuation : Par exemple, "pouvez-vous m'aider ?" et "pouvez-vous m'aider ?!"

Cohérence des annotations

La partie de la phrase d'entraînement sélectionnée pour une annotation ne doit inclure que le texte nécessaire pour faire correspondre une entité. Assurez-vous également que les parties semblables des expressions d'entraînement sont annotées pour l'ensemble de l'intention.

Par exemple, le tableau suivant montre les bonnes et les mauvaises façons d'annoter avec l'entité système @sys.date :

Bon	Mauvais
Départ le 7 septembre	7e départ en septembre
Départ le 4 juillet	Disparition le 4 juillet

Utiliser des annotations sémantiquement pertinentes pour les entités système

La signification sémantique d'une partie de phrase d'entraînement sélectionnée pour une annotation peut être affectée par le reste du texte de la phrase d'entraînement. Exemple :

Phrase d'entraînement annotée	Signification sémantique du texte annoté
J'ai sept ans.	Âge d'une personne
Le contrat est valable pendant sept ans.	Durée

Les modèles de machine learning de Dialogflow CX tiennent compte de la signification sémantique lorsqu'ils font correspondre des entités système. La signification sémantique de la partie de la phrase d'entraînement doit correspondre à la signification sémantique prévue de l'entité système.

Par exemple, n'utilisez pas l'entité système @sys.duration pour annoter le premier exemple "7 ans" ci-dessus. La signification sémantique de "7 ans" ne correspond pas à une simple durée. À la place, vous devez sélectionner "7" pour l'annotation et utiliser l'entité système @sys.number.

Définir des intentions pour gérer les réponses non conformes aux formulaires

Envisagez de définir des intentions pour gérer les réponses non conformes aux formulaires. Par exemple, votre agent peut demander "Quelles sont vos dates de voyage ?", puis l'utilisateur final répond "Je ne sais pas encore". Cette réponse ne satisfait pas l'invite du paramètre de formulaire, mais si votre agent dispose d'une route d'intention dans le champ d'application qui peut correspondre à cette réponse, il peut gérer la situation correctement.

Éviter @sys.any

Évitez d'utiliser le type d'entité système @sys.any. Vous ne devez l'utiliser que si vous avez épuisé toutes les pistes, y compris la création d'entités personnalisées. Ce type d'entité est très large et peut entraîner un comportement indésirable.

Si vous utilisez ce type d'entité, évitez d'annoter plusieurs parties d'une même expression d'entraînement avec ce type d'entité, car cela crée une ambiguïté et le comportement de l'agent ne sera pas défini.

Il est moins dangereux d'utiliser @sys.any avec des paramètres de formulaire, car l'agent attend des informations spécifiques lorsqu'il demande des paramètres de formulaire.

Remarque Certaines entités système ne sont pas disponibles lorsque vous régionalisez le déploiement de votre agent. @sys.any est parfois recommandé comme solution de contournement.

Les annotations doivent inclure différentes valeurs d'entité.

Lorsque vous définissez des expressions d'entraînement annotées, vous devez utiliser différents exemples de valeurs d'entités dans les expressions. Vous ne devez pas utiliser systématiquement le même exemple d'entité pour les annotations. L'exemple suivant montre des annotations correctes et incorrectes pour un type d'entité produit :

Bon	Mauvais
Je veux acheter une chemise	Je veux acheter une chemise
Commander un nouveau chapeau	Commander un nouveau t-shirt
Ajoute une montre à mon panier	Ajoute une chemise à mon panier.

Les entités personnalisées doivent inclure de la variété

Les entités personnalisées doivent couvrir un large éventail d'exemples. Le modèle NLU fournira des formes grammaticales variées, mais vous devez inclure tous les éléments possibles.

Éviter les entités qui correspondent de manière agressive

Ne définissez pas d'entités pouvant correspondre à pratiquement n'importe quoi. Cela dégrade les performances et la qualité du ML. Chaque terme ou presque de chaque expression d'entraînement sera évalué comme une correspondance possible.

Les entités de carte et de liste doivent se concentrer sur des valeurs distinctes.

Les types d'entités de carte et de liste doivent avoir une portée limitée qui capture les différentes valeurs possibles d'un type d'information. Veillez à ce que vos entités soient ciblées, simples et concises.

Si les valeurs de votre entité sont complexes, cela peut être dû au fait que des expressions d'entraînement de l'intent sont mieux adaptées à votre situation. Prenons l'exemple d'une saisie d'utilisateur final comme :

• "Comment puis-je passer un appel international avec le forfait A ?"
• "Utiliser l'itinérance des données à l'international avec le forfait B".

Évitez de créer des types d'entité à la fois pour les actions et pour les forfaits, comme suit :

Type d'entité "Actions"	Type d'entité "Plans"
"Comment passer un appel à l'étranger ?"	"Forfait A"
"Utiliser l'itinérance des données à l'étranger"	"Forfait B"

Utilisez plutôt des expressions d'entraînement et des correspondances d'intent pour capturer les actions, et des entités pour capturer les forfaits.

Utiliser des entités d'expression régulière pour capturer des identifiants non verbaux

Lorsque vous capturez des entrées d'utilisateur final qui impliquent des identifiants non verbaux, vous devez utiliser des entités d'expression régulière. Par exemple, pour capturer des ID de produit tels que "AA-256" ou "AC-436", utilisez une entité d'expression régulière telle que "[A-Z]{2}-\d{3}".

Évitez d'imbriquer des entités composites.

N'utilisez pas plus d'un niveau d'imbrication dans les entités composites. Chaque niveau d'imbrication dégrade considérablement la qualité.

Éviter les intents similaires

Chaque intent doit capturer l'intention de l'utilisateur final. Si vous définissez différents intents avec des expressions d'entraînement semblables, la correspondance peut ne pas être fiable, car le modèle NLU ne peut pas déterminer avec suffisamment de certitude l'intent auquel faire correspondre l'expression.

Si deux expressions d'entraînement représentent la même intention, elles doivent appartenir au même intent. Par exemple, les expressions "changer la date limite de paiement de la facture actuelle" et "plus de temps pour payer" doivent appartenir à la même intention, car elles demandent toutes les deux un changement de date limite de paiement. Toutefois, les expressions "Puis-je passer un appel international avec le forfait A ?" et "Puis-je utiliser l'itinérance des données à l'international avec le forfait A ?" peuvent appartenir à des intentions différentes, car l'utilisateur final souhaite une chose différente dans chaque cas.

Éviter les types d'entités similaires

Évitez de définir plusieurs types d'entités comportant des entrées d'entités similaires, car cela peut entraîner une ambiguïté pour le modèle NLU.

Utiliser les événements sans correspondance en production pour améliorer vos intentions

Lorsque vous exécutez votre agent en production, il est inévitable que certaines entrées de l'utilisateur final entraînent des événements sans correspondance. Vous pouvez utiliser ces opportunités pour améliorer votre agent de trois manières :

• Ajoutez l'entrée de l'utilisateur final en tant qu'expression d'entraînement à l'intent souhaité. Toutefois, ce n'est pas toujours la meilleure option. Si vous le faites plusieurs fois pour l'intention, cela peut entraîner un biais d'intention.
• Nettoyez les expressions d'entraînement pour l'intent souhaité afin qu'elles reflètent toutes précisément l'intention. Dans certains cas, les intents dont les expressions d'entraînement sont divergentes peuvent empêcher la mise en correspondance de l'intent.
• Si des intents qui ne doivent pas correspondre à l'entrée de l'utilisateur final comportent des expressions d'entraînement qui pourraient correspondre à l'entrée de l'utilisateur final, supprimez ces expressions d'entraînement.

Évitez les caractères spéciaux

Les caractères spéciaux dans les expressions d'entraînement ({, _, #, [, etc.) sont ignorés. Les émoticônes constituent toutefois une exception et fonctionnent comme prévu.

Éviter les mots de remplissage

Les mots de remplissage sont des mots que vous pouvez ignorer et quand même comprendre le texte. Exemple :

• s'il te plaît
• peux-tu s'il te plaît
• hmmm
• que dirais-tu de

Il est inutile, mais inoffensif, d'utiliser des mots de remplissage dans les expressions d'entraînement, car ils sont ignorés par le modèle NLU. Toutefois, vous ne devez pas définir d'expressions d'entraînement qui ne varient que par des mots de remplissage.

Ne définissez jamais d'entités composées de mots de remplissage.

Tester les paramètres de ML

Les paramètres de ML peuvent être utilisés pour ajuster la façon dont les entrées de l'utilisateur final sont traitées. Dans la plupart des cas, les paramètres par défaut fonctionnent bien. Toutefois, vous pouvez affiner les paramètres pour améliorer les performances de votre agent.

Répondre à l'utilisateur final

Cette section fournit des consignes pour utiliser le fulfillment afin de répondre à l'utilisateur final.

Accueillir l'utilisateur final

Lorsqu'un agent est créé, une route d'intent est automatiquement créée pour l'intent de bienvenue. Vous devez modifier cette route pour inclure un message d'exécution qui accueille l'utilisateur final. Ce message doit décrire l'agent et donner à l'utilisateur final une idée de ce dont il est capable.

Tenez compte des informations fournies par l'utilisateur final.

Il est souvent préférable de répéter les informations fournies par l'utilisateur final dans les réponses. Cela permet à l'utilisateur final de savoir que l'agent comprend sa demande.

Lorsqu'un intent est mis en correspondance et qu'une transition se produit, informez l'utilisateur final que la conversation progresse en fonction de sa demande. Exemple :

Dialogue	Description
Utilisateur final : J'ai des questions sur mon compte courant. Agent : D'accord, que voulez-vous savoir sur votre compte courant ?	La saisie de l'utilisateur final a entraîné une correspondance d'intention et un itinéraire a été suivi, incluant un message d'exécution et une transition vers une page traitant les questions sur les comptes chèques. Notez que l'agent confirme que l'utilisateur final souhaite obtenir des informations sur son compte courant.

Une fois le formulaire rempli, répétez les données fournies par l'utilisateur final. Exemple :

Dialogue	Description
Utilisateur final : Demain Agent : D'accord, votre rendez-vous pour une coupe de cheveux est prévu demain à 19h. Puis-je faire autre chose pour vous ?	L'utilisateur final a fourni le paramètre de formulaire de date, qui était le dernier paramètre de formulaire sur la page active. L'agent a confirmé l'heure et la date d'un rendez-vous pour une coupe de cheveux.

Guider la conversation

L'agent doit toujours guider la conversation avec l'utilisateur final. Pour ce faire, il vous suffit de terminer chaque réponse par une question, par exemple :

• Puis-je faire autre chose pour vous ?
• Que voulez-vous savoir sur les beagles ?
• Souhaitez-vous annuler ou envoyer cette commande ?
• Comment puis-je vous aider aujourd'hui ?
• Voyagez-vous seul ou avec quelqu'un ?

Lorsque vous définissez ces questions, veillez à ne pas en poser plusieurs à la fois, par exemple :

• Vous êtes toujours là ? Quel service vous intéresse ?
• Voulez-vous toujours cette commande ? Voulez-vous ajouter quelque chose ?

L'utilisateur final peut ne répondre qu'à une seule des questions, et votre agent peut ne pas gérer correctement cette situation.

Gérer les erreurs et les entrées inattendues de l'utilisateur final

Cette section fournit des conseils sur la gestion des erreurs et des entrées inattendues de l'utilisateur final.

Créer des gestionnaires d'événements pour les événements intégrés

Vous devez créer des gestionnaires d'événements pour les événements intégrés, le cas échéant. La gestion de ces événements est semblable à l'interception d'exceptions dans la programmation logicielle. Selon la situation, vous pouvez gérer les événements avec des gestionnaires d'événements spécifiques aux paramètres, aux pages ou aux flux.

Gérer les erreurs de webhook

Lorsque votre service de webhook échoue, il est important que votre agent puisse gérer l'échec de manière fluide. Pour ce faire, définissez des gestionnaires d'événements pour les événements intégrés spécifiques aux webhooks. Voici une approche recommandée pour gérer les erreurs de webhook :

• Ne fournissez pas de cible de transition à partir du gestionnaire d'état qui déclenche l'appel de webhook. Sinon, le gestionnaire d'événements d'erreur de webhook ne sera pas appelé. Définissez plutôt la cible de transition dans la réponse du webhook à partir du service de webhook.

• Choisissez une page sur laquelle un compteur d'erreurs peut être initialisé à zéro. Cette page doit être active avant celle qui déclenche un appel de webhook. Le fulfillment d'entrée de cette page doit initialiser le compteur d'erreurs à 0 à l'aide d'un préréglage des paramètres de fulfillment. Exemple :

  Paramètre	Valeur
  webhook-error-count	0

• Créez une page d'erreur de webhook qui gère les événements d'erreur de webhook :

  • Le fulfillment d'entrée doit reconnaître l'échec pour l'utilisateur final et incrémenter un paramètre de session de compteur d'erreurs à l'aide d'un préréglage de paramètre de fulfillment. Exemple :

    Paramètre	Valeur
    webhook-error-count	$sys.func.ADD($session.params.webhook-error-count, 1)

  • Définissez une route conditionnelle dont la condition est que le nombre d'erreurs est inférieur au nombre maximal autorisé. (par exemple, $session.params.webhook-error-count <= 3). Cette route doit comporter un fulfillment qui informe l'utilisateur final que l'agent va réessayer. Cette route doit avoir une cible de transition définie sur PREVIOUS_PAGE ou sur n'importe quelle page pouvant effectuer une autre tentative d'appel du webhook.

  • Définissez un itinéraire de condition dont la condition est que le nombre d'erreurs est supérieur au maximum autorisé (par exemple, $session.params.webhook-error-count > 3). Cet itinéraire doit comporter un fulfillment qui informe l'utilisateur final que l'agent ne tentera plus de résoudre le problème. La cible de transition de cette route doit être définie sur une page qui ne déclenchera pas de nouvelles tentatives de webhook.

• Le gestionnaire d'événements de webhook doit avoir une cible de transition qui redirige vers la page d'erreur du webhook.

Outils

Cette section fournit des conseils sur l'utilisation d'outils pour améliorer la conception de l'agent.

Utiliser l'outil de validation

Vous devez toujours utiliser l'outil de validation pour vérifier votre agent. Cet outil permet de détecter certains des problèmes décrits dans ce guide.

Utiliser la fonctionnalité de cas de test

Vous devez toujours définir des cas de test pour votre agent. Ces scénarios de test peuvent vous aider à éviter les régressions à mesure que votre agent évolue pour gérer davantage de scénarios.