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

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

Vous devriez également voir conception d'agent vocal spécialement conçu pour la conception d'agents vocaux, et bonnes pratiques sur l'utilisation du service Dialogflow.

Conseils d'ordre général

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, itérer dans les conversations pour vous assurer de couvrir tous les itinéraires possibles qu'un utilisateur final peut emprunter.

Pendant l'évolution de l'agent, envisagez d'utiliser la fonctionnalité des scénarios de test pour le développement piloté par les tests.

Agents prédéfinis

Dialogflow propose des modèles d'agent pour vous aider à démarrer. Agents prédéfinis couvrent des 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 traitements spécifiques à votre établissement, et vous allez rapidement créer un agent fonctionnel.

Intégrations et connexion de vos services

Il existe plusieurs façons d'intégrer les agents Dialogflow. Cette section présente les bonnes pratiques à suivre pour choisir comment effectuer l'intégration.

Intégrations

Dialogflow intégrations fournir 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. car les intégrations le gèrent pour vous. Ces intégrations peuvent fournir un agent textuel que vous pouvez intégrer à votre site Web, de se connecter à d'autres plates-formes de messagerie, ou fournir une interface de téléphonie.

API Dialogflow

Si aucune des intégrations prêtes à l'emploi ne vous convient, ou si vous souhaitez personnaliser l'interface de votre système, vous pouvez utiliser directement l'API Dialogflow. 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 complètement défini avec des données statiques, vous devez utiliser webhooks pour connecter votre service et fournir un agent capable de gérer les scénarios dynamiques. Cela s'applique que vous utilisiez des intégrations ou l'API Dialogflow.

Ressources de l'agent

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

Flux et pages

Flux et pages pour structurer votre agent. Vous pouvez considérer les pages comme des nœuds dans une machine à états, et des flux sous forme de groupes de pages associées. Vous contrôlez les transitions entre les nœuds gestionnaires d'état qui sont appelés lorsqu'un intent est mis en correspondance, une condition est remplie ou un événement est appelé.

Un agent simple peut fonctionner avec un seul flux, mais les agents complexes sont presque toujours mieux conçus avec plusieurs flux. Chaque flux doit représenter un sujet général pour votre agent, où chaque page associée au flux aide à gérer le sujet. De plus, chaque flux peut avoir ses propres paramètres, Il peut s'agir détenu par un sous-ensemble de membres de l'équipe, ce qui permet de diviser le travail lors de la conception de grands agents.

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

Si la conception de votre agent comporte trop de flux par agent, combiner des sujets connexes dans un seul flux. Par exemple : vous pouvez combiner les thèmes suivants dans une formule "Obtenir le solde" flux:

• Obtenir le solde courant
• Obtenir le solde de votre épargne
• Obtenir le solde de votre prêt immobilier
• Obtenir le solde du crédit

Si la conception de votre agent comporte trop de pages par flux, de combiner des pages connexes et d'utiliser de nombreuses itinéraires par page.

Si vous rencontrez toujours des difficultés avec le flux et les limites de pages, cela peut être dû au fait que vous avez trop de logique métier intégrée à l'agent lui-même. Envisagez de transférer cette logique vers des webhooks.

Voici la liste des niveaux de précision du contrôle des conversations pour les ressources d'agent. par ordre de précision croissant:

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

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

La principale façon dont votre système reçoit les données structurées de l'utilisateur final consiste à utiliser paramètres. Vous pouvez utiliser des paramètres intents (paramètres d'intent) ou pages (paramètres du formulaire).

La fonction principale de certaines pages consiste à collecter des informations spécifiques auprès de l'utilisateur final. Par exemple : une page peut être conçue pour recueillir les coordonnées de l'utilisateur final. Dans ce cas, vous devez toujours utiliser les paramètres du formulaire pour collecter ces informations.

Dans certains cas, vous pouvez collecter des informations sur l'utilisateur final tout en passant d'une page à une autre. Par exemple : si l'utilisateur final demande un produit particulier au début de la conversation, vous voulez capturer le produit souhaité tout en passant à la page de commande appropriée. Dans ce cas, d'utiliser des paramètres d'intent routes d'intent.

Il y a aussi des situations dans lesquelles l'idéal est d'utiliser à la fois les paramètres d'intent et de formulaire. Par exemple : si l'utilisateur final demande une chemise en taille S au début de la conversation, vous voulez capturer le paramètre de taille souhaité (petite taille) ; lors de la transition vers la page de commande des chemises. La page de commande des chemises peut demander des informations supplémentaires, comme la couleur souhaitée. La page d'ordre des chemises doit comporter des paramètres de formulaire pour la taille et la couleur. Dans cet exemple, le paramètre "size" est déjà fourni et propagées, l'agent ne demande donc que la couleur. Toutefois, d’autres conversations peuvent suivre un chemin différent, lorsque l'utilisateur final n'a pas fourni la taille souhaitée lorsque la page de commande des chemises devient active. En définissant ce paramètre des 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 ayant le même ID ou le même nom à afficher dans différentes des intents ou des 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 sont différents, utilisez un ID de paramètre unique ou un nom à afficher pour chaque définition.

Routes et groupes de routes

Si vous souhaitez passer à une autre page, mettre un message de réponse en file d'attente, ou appeler un webhook L'intent est mis en correspondance ou condition [état] est satisfaite, utiliser routes.

Si vous utilisez le même ensemble d'itinéraires sur plusieurs pages, utiliser groupes de routes. Cela permet d'éviter les doublons inutiles dans la conception de l'agent.

Réutilisation de l'intent

S'il vous arrive de définir plusieurs intents avec des phrases d'entraînement similaires, envisagez de réutiliser les intents sur plusieurs pages. Dans l’idéal, vous devez définir des intents généraux utilisés dans de nombreuses pages et d'intents spécifiques qui ne sont utilisés que sur une seule page. Cela permet d'éviter les doublons inutiles dans la conception de l'agent.

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

• oui
• ouais
• ouais
• OK
• oui, je veux
• et ok !
• absolument
• oui s'il te plaît

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

• non
• nah
• non
• pas du tout
• pas pour moi
• absolument pas
• non, merci

Ces intents de confirmation réutilisables peut être utilisé 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 : lors de la confirmation d'une commande, vous pouvez avoir un intent order.confirmation.yes spécialisé avec des phrases d'entraînement telles que:

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

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 commande est active, les routes d'intent pour ces quatre intents doivent entrer dans le champ d'application. Cela garantit que toute confirmation générique ou spécifique de l'utilisateur final seront traités de manière appropriée.

Intent négatif par défaut

Vous devez renseigner le champ intent négatif par défaut avec des phrases que vos utilisateurs finaux pourraient dire : mais ne doit correspondre à aucun intent de votre agent.

Fulfillment

Il existe de nombreuses options d'utilisation traitement pour répondre à l'utilisateur final. Pendant un tour de conversation, l'agent peut ajouter plusieurs messages à la file d'attente de réponses, et la file d'attente concaténée est envoyée à l'utilisateur final à la fin de la conversation. Cette section décrit chacune des options permettant de créer des messages individuels.

• Traitement des entrées de page: Ce fulfillment est appelé lorsque la page devient initialement active. Elle est utile lorsque vous souhaitez afficher un message décrivant l'objectif de la page, et il ne doit être dit qu'une seule fois lorsque la page est active. Exemple :
  • Que souhaitez-vous savoir à propos de votre compte courant ?
  • Quel type de produit souhaitez-vous acheter ?
  • Je dois recueillir des informations sur la chemise que vous souhaitez commander.
• Routes: Ce fulfillment est appelé lorsqu'une route d'intent ou une route de condition avec fulfillment est appelé. Ceci est utile lorsque vous souhaitez un message qui répond à l'utilisateur final concernant la correspondance d'intention, la condition "satisfaite" (qui peut être condition de remplissage du formulaire), ou la transition. Exemple :
  • Oui, votre forfait international inclut le Japon. (correspondance d'intent)
  • Voulez-vous vraiment acheter 300 chemises ? (condition de comparaison satisfaite)
  • OK, votre rendez-vous est à 7h demain matin. (remplissage du formulaire)
  • Parlons maintenant des oryctéropes du Nord. (transition)
• Gestionnaires d'événements: Ce fulfillment est appelé lorsqu'un événement est appelé. Elle est utile lorsque vous souhaitez recevoir un message qui répond à l'événement. Exemple :
  • Action que vous envisagez d'acheter vient d'augmenter de 10%. (événement personnalisé)
  • Pouvez-vous reformuler ? (événement sans correspondance)
• Invites initiales pour les formulaires: Ce fulfillment est appelé lorsque l'agent remplit le formulaire. Ces messages doivent poser une question spécifique à l'utilisateur final. Chaque paramètre de formulaire possède son propre traitement de requête initial. Exemple :
  • Quelle taille de chemise voulez-vous ?
  • Quelle couleur de chemise souhaitez-vous ?
• Redemander des gestionnaires pour les formulaires: Ce fulfillment est appelé lorsque l'agent effectue le remplissage du formulaire, et ne comprend pas la sélection de l'utilisateur final pour le paramètre actuel. Ce traitement n'est nécessaire que si vous souhaitez recevoir un nouveau message du message de requête initial. S'il n'existe aucun gestionnaire de reprompt, l'agent utilisera simplement l'invite initiale comme message de nouvelle invite. Exemple :
  • Je ne comprends pas. Pouvez-vous fournir une couleur valide pour la chemise ?

Dénomination

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

Nommer les intents

Si votre agent a de nombreuses intents vous devez envisager un schéma de nommage qui vous aide à 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

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 de vos agents.

Transitions gratuites

Lorsque vous définissez une route qui déclenche une transition, prenez en compte qu'il peut y avoir une route complémentaire ou inverse.

Exemple :

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

Traiter 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 façon optimale les entrées de l'utilisateur final.

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

Vous devez en avoir au moins 20 Phrases d'entraînement pour chaque intent. Sinon, le modèle NLU risque de ne pas disposer de suffisamment d'informations pour qu'elles correspondent à votre intention. Il s'agit d'un principe minimal. Idéalement, vous devriez définir plus, en particulier pour intents head des grands agents, où environ 50 est souhaitable.

Soyez conscient du biais d'intention

Lorsqu'un ou plusieurs intents comportent beaucoup plus d'expressions d'entraînement que d'autres intents, le modèle NLU privilégie les intents plus importants en raison 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, il s'agit d'un comportement souhaité, car vous pouvez définir des intents qui devraient être mises en correspondance plus souvent que d'autres, car elles correspondent aux entrées de l'utilisateur final est plus souvent observée dans le trafic en temps réel.

Dans d’autres cas, ce comportement peut être indésirable, car vous ne voulez pas de biais en faveur de ces intents plus larges. Dans ce cas, réduire le nombre de phrases d'entraînement pour ces grands intents doivent avoir le même ordre de grandeur que les autres intents. Exemple :

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

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

Pour tous les types d'entités utilisés dans un intent:

• Annotez chaque exemple de types d'entités.
• Pour chacun des types d'entités, fournir au moins cinq phrases 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 avoir au moins 30 phrases d'entraînement.

Les phrases d'entraînement doivent être naturelles

Les phrases d'entraînement doivent être conversationnelles et naturelles. elles doivent correspondre à ce que les gens disent réellement. Dans la mesure du possible, utiliser comme données d'entraînement les entrées de l'utilisateur final générées en production ; en portant une attention particulière à celles qui sont les plus courantes.

Diversité des phrases d'entraînement nécessaires

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

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

Définir des phrases d'entraînement dont la longueur, la formulation et la structure des phrases varient est important pour assurer un bon entraînement de votre agent. Il n'est pas nécessaire d'ajouter de la variété pour l'intérêt de la variété, mais il est nécessaire de fournir suffisamment de variété pour que le modèle NLU puisse détecter correctement à partir d'un large éventail d'entrées utilisateur. Si vous n'avez pas assez de variété, il existe un risque de surapprentissage. Autrement dit, le modèle risque d'être trop lié aux exemples spécifiques que vous fournissez et ne seront pas assez généralisables à d'autres exemples.

Diversité des majuscules

La sensibilité à la casse varie en fonction 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 pour les phrases d'entraînement dont la casse diffère uniquement. Cela s'applique généralement aux lorsque vous attendez des utilisateurs finaux qu'ils saisissent du texte entièrement en majuscules.

D'autres approches pourraient être proposées:

• Réduire le seuil de classification du ML
• Diminution des entrées de l'utilisateur final avant de les envoyer à Dialogflow.

NLU avancé

Contrairement au modèle NLU standard, le modèle NLU avancé est sensible à la casse. Mer recommandent d'effectuer des tests et d'ajouter les données d'entraînement pertinentes en majuscules des taux de correspondance d'intention.

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

Évitez les variations triviales dans les phrases d'entraînement, car elles fournissent des informations en double au modèle NLU. Par exemple : n'incluent pas de variantes qui se distinguent uniquement par:

• Majuscules: si vous utilisez le modèle NLU standard, évitez les doublons Expressions telles que "Commander un billet" et "commander un billet" sauf dans de rares cas cas d'utilisation. Cependant, le modèle NLU avancé est sensible à la casse et nécessite des phrases d'entraînement pour augmenter les correspondances d'intent. Consultez le dans la section sur la variété des majuscules.
• Mots de remplissage: Par exemple, "Ok, commande un billet" et "commander un billet".
• Ponctuation: Par exemple, "Peux-tu m'aider ?" et "Peux-tu m'aider ?"

Cohérence des annotations

La partie de la phrase d'entraînement sélectionnée pour une annotation doit inclure tous les éléments suivants : et pas plus de, le texte nécessaire pour la mise en correspondance d'une entité. Assurez-vous également que les parties similaires des phrases d'entraînement sont annotées pour l'ensemble de l'intent.

Par exemple : le tableau suivant montre les bonnes et les mauvaises manières pour annoter avec l'entité système @sys.date:

Bon	Mauvais
Départ le 7 septembre	Départ du 7 septembre
Départ le 4 juillet	Départ le 4 juillet

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

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 d'une phrase d'entraînement. Exemple :

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

Les modèles de machine learning de Dialogflow prennent en compte la signification sémantique lors de la mise en correspondance d'entités système. Signification sémantique de la partie 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 l'annotation des "sept premières années" dans l'exemple ci-dessus. La signification sémantique de "7 ans" ne correspond pas à une durée simple. Sélectionnez plutôt "7" pour l'annotation et utilisez l'entité système @sys.number.

Définir des intents pour gérer les réponses de remplissage de formulaire non conformes

Envisagez de définir des intents pour gérer les réponses de remplissage de formulaire non conformes. Par exemple : votre agent peut vous demander "Quelles sont vos dates de voyage ?", suivi de la réponse de l'utilisateur final "Je ne sais pas encore". Cette réponse ne répond pas à l'invite du paramètre de formulaire, mais si votre agent a une route d'intent dans le champ d'application qui peut correspondre à cette réponse, votre agent peut bien gérer la situation.

Éviter @sys.any

Évitez d'utiliser le type d'entité système @sys.any. Ne l’utilisez que si vous avez complètement épuisé toutes les voies, 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é, éviter d'annoter plusieurs parties d'une même phrase d'entraînement ; avec ce type d'entité, car cela crée une ambiguïté, et le comportement de l'agent n'est 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 lorsque vous demandez 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, et @sys.any est parfois recommandé comme solution de contournement.

Les annotations doivent inclure diverses valeurs d'entité

Lorsque vous définissez des phrases d'entraînement annotées, vous devez utiliser divers exemples de valeurs d'entité dans les phrases. Vous ne devez pas systématiquement utiliser le même exemple d'entité. pour les annotations. L'exemple suivant illustre les bonnes et les mauvaises annotations. Pour un type d'entité "product" :

Bon	Mauvais
Je veux acheter une chemise	Je veux acheter une chemise
Commandez un nouveau chapeau	Commander une nouvelle chemise
Ajouter une montre à mon panier	Ajouter une chemise à mon panier

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

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

Éviter les entités dont les correspondances sont agressives

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

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

Les types d'entités de mappage et de liste doivent avoir un champ d'application limité qui capture les valeurs distinctes d’un type d’information. Veillez à ce que vos entités soient ciblées, simples et concises.

Si les valeurs de vos entités sont complexes, c'est peut-être parce que les phrases d'entraînement de l'intent sont mieux adaptées à votre situation. Par exemple, considérez les entrées de l'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."

Ne créez pas de types d'entités pour les actions et les plans, comme suit:

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

À la place, vous devez utiliser des phrases d'entraînement et des correspondances d'intents pour capturer les actions et les entités afin de capturer les plans.

Utiliser des entités d'expression régulière pour capturer des identifiants autres que des mots

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

Éviter 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 phrases d'entraînement similaires, peut ne pas être fiable, car le modèle NLU ne peut pas déterminer avec une confiance suffisante, l'intention à mettre en correspondance.

Si deux phrases d'entraînement représentent la même intention, elles doivent appartenir au même intent. Par exemple : "modifier la date d'échéance actuelle de la facture" et "plus de temps pour payer" doivent toutes les deux appartenir au même intent, car ils demandent tous les deux un changement de date limite. Toutefois, "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 à différents intents, parce que l’utilisateur final veut une chose différente dans chaque cas.

Éviter les types d'entités similaires

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

Utiliser des événements sans correspondance en production pour améliorer vos intents

Lorsque vous exécutez l'agent en production, il est inévitable que certaines entrées de l'utilisateur final les événements sans correspondance. Vous pouvez utiliser ces opportunités pour améliorer votre agent de l'une des trois façons suivantes:

• Ajoutez l'entrée de l'utilisateur final en tant qu'expression d'entraînement à l'intent souhaité. Cependant, ce n'est pas toujours la meilleure option. Si vous répétez cette opération plusieurs fois pour l'intent, biais d'intention.
• Nettoyer les phrases d'entraînement de l'intent souhaité afin qu'elles reflètent toutes précisément l'intention. Dans certains cas, intents avec des phrases d'entraînement divergentes peut empêcher la mise en correspondance pour l'intent.
• Si des intents qui ne doivent pas être mis en correspondance pour l'entrée de l'utilisateur final contiennent des phrases d'entraînement correspondant à l'entrée utilisateur, supprimer ces phrases d'entraînement.

Éviter les caractères spéciaux

Caractères spéciaux dans les phrases d'entraînement ({, _, #, [, etc.) sont ignorés. Une exception à cette règle concerne les émoticônes, où elles fonctionnent comme prévu.

Éviter les mots de remplissage

Les mots de remplissage sont des mots que vous pouvez ignorer tout en étant capable de comprendre le texte. Exemple :

• s'il te plaît
• peux-tu s'il te plaît
• Hmmm
• pourquoi pas

Il est inutile, mais sans danger, d'utiliser des mots de remplissage dans les phrases d'entraînement, car elles sont ignorées par le modèle NLU. Cependant, vous ne devez pas définir de phrases d'entraînement qui ne varient qu'en fonction des mots de remplissage.

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

Tester les paramètres de ML

La Paramètres de ML permet d'ajuster le traitement des entrées de l'utilisateur final. Dans la plupart des cas, les paramètres par défaut fonctionnent bien. Toutefois, vous pouvez ajuster les paramètres pour améliorer les performances de votre agent.

Répondre à l'utilisateur final

Cette section fournit des consignes sur l'utilisation du fulfillment pour répondre à l'utilisateur final.

Accueillir l'utilisateur final

Un nouvel agent dispose d'une route d'intent créée automatiquement pour intent de bienvenue. Vous devez modifier cet itinéraire pour inclure un message de traitement 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.

Confirmer les informations sur l'utilisateur final

Il est souvent préférable de répéter les informations fournies par l'utilisateur final dans ses réponses. Cela indique à l'utilisateur final que l'agent comprend sa requête.

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

Dialogue	Description
Utilisateur final: J'ai des questions concernant mon compte courant. Agent: D'accord, que souhaitez-vous savoir sur votre compte courant ?	Les données saisies par l'utilisateur final ont généré une correspondance d'intent et une route a été suivie, incluant un message de fulfillment et une transition vers une page qui gère les questions liées au compte de vérification. Notez que l'agent confirme que l'utilisateur final souhaite en savoir plus sur son compte courant.

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

Dialogue	Description
Utilisateur final: Demain Agent: D'accord, ta coupe est programmée 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'une coupe de cheveux programmée.

Guider la conversation

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

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

Lors de la définition de ces questions, évitez de poser plusieurs questions telles que:

• Êtes-vous toujours là ? Sur quel service porte votre demande ?
• Voulez-vous toujours cette commande ? Voulez-vous ajouter quelque chose ?

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

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 à la capture des exceptions en programmation logicielle. Selon la situation, vous voudrez peut-être gérer les événements avec des gestionnaires d'événements spécifiques aux paramètres, les gestionnaires d'événements spécifiques aux pages, ou des gestionnaires d'événements spécifiques au flux.

Gérer les erreurs des webhooks

En cas de défaillance de votre service de webhook, il est important que votre agent puisse gérer l'échec. Pour ce faire, définissez des gestionnaires d'événements pour les attributs événements intégrés. Voici une approche recommandée pour gérer les erreurs de webhook:

• Ne fournissez pas de cible de transition à partir de gestionnaire d'état qui déclenche appel 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 webhook. Le fulfillment d'entrée pour cette page doit initialiser le compteur d'erreurs vers 0 à l'aide d'un préréglage du paramètre de traitement. 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 confirmer l'échec pour l'utilisateur final, Il doit incrémenter un paramètre de session de compteur d'erreurs à l'aide d'un préréglage du paramètre de traitement. Exemple :

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

  • Définissez une route de condition avec une condition selon laquelle le nombre d'erreurs est inférieur au maximum autorisé. (par exemple, $session.params.webhook-error-count <= 3). Cette route doit comporter un fulfillment qui notifie l'utilisateur final que l'agent doit réessayer. La cible de transition doit être définie sur PREVIOUS_PAGE, ou vers n'importe quelle page pouvant effectuer une nouvelle tentative d'appel du webhook.

  • Définir une route de condition comportant une condition selon laquelle le nombre d'erreurs est supérieure au maximum autorisé (par exemple, $session.params.webhook-error-count > 3). Cette route doit comporter un fulfillment qui notifie l'utilisateur final que l'agent ne fera plus de nouvelle tentative. La cible de transition doit être définie sur une page qui ne déclenchera pas de nouvelle tentative du webhook.

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

Outils

Cette section fournit des conseils sur l'utilisation d'outils permettant d'améliorer la conception des agents.

Utiliser l'outil de validation

Vous devez toujours utiliser la méthode outil de validation pour vérifier votre agent. Cet outil détecte certains des problèmes décrits dans ce guide.

Utiliser la fonctionnalité de scénarios de test

Vous devez toujours définir cas types pour votre agent. Ces scénarios de test permettent d'éviter les régressions pendant que votre agent évolue pour gérer d'autres scénarios.