Bonnes pratiques générales pour la conception d'agents

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

Vous devez également consulter le guide de conception des agents vocaux spécifiquement pour la conception d'agents vocaux, ainsi que le guide des bonnes pratiques concernant l'utilisation du service Dialogflow.

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, itérez les chemins de conversation pour vous assurer que vous couvrez tous les chemins qu'un utilisateur final peut emprunter.

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

Agents prédéfinis

Dialogflow propose des modèles d'agents pour vous aider à démarrer. Les 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 un traitement propres à votre entreprise, et vous créerez rapidement un agent opérationnel.

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 la méthode d'intégration.

Intégrations

Les intégrations Dialogflow 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, car les intégrations s'en chargent pour vous. Ces intégrations peuvent fournir un agent texte 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

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. 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.

Ressources d'agent

Les ressources d'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 bons scénarios.

Flux et pages

Les flux et les pages fournissent une structure à 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'un intent est mis en correspondance, qu'une condition est remplie ou qu'un événement est appelé.

Un agent simple peut convenir à 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, et chaque page associée au flux facilite la gestion du sujet. De plus, chaque flux peut avoir certains de ses propres paramètres et appartenir à un sous-ensemble de membres de l'équipe, ce qui facilite la division du travail lors de la conception d'agents volumineux.

Lors de la conception d'un agent volumineux et complexe, vous devez prendre en compte les limites "flux par agent" et "pages par flux". Ces limites permettent d'assurer les performances de votre agent.

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

  • Consulter votre solde
  • Obtenir le solde d'épargne
  • Obtenir le solde de votre prêt immobilier
  • Obtenir le solde créditeur

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

Si vous rencontrez toujours des difficultés avec les limites de flux et de pages, il se peut que vous ayez trop de logique métier intégrée à l'agent lui-même. Envisagez de déplacer cette logique vers des webhooks.

Vous trouverez ci-dessous la 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'intent ou de la condition de l'utilisateur)

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

Le principal moyen pour votre système d'obtenir des données structurées de l'utilisateur final consiste à utiliser des 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 recueillir 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 de formulaire pour collecter ces informations.

Dans certains cas, vous pouvez capturer des informations sur l'utilisateur final lors de la transition d'une page à une autre. Par exemple, si l'utilisateur final demande un produit particulier au début de la conversation, vous souhaitez sélectionner le produit souhaité lors de la transition vers la page de commande appropriée. Dans ce cas, utilisez des paramètres d'intent dans le cadre de routes d'intent.

Dans certains cas, il est également idéal d'utiliser à la fois des paramètres d'intent et de formulaire. Par exemple, si l'utilisateur final demande une petite chemise au début de la conversation, vous souhaitez capturer le paramètre de taille souhaité (small) lors de la transition vers la page de commande des chemises. La page de commande de chemises peut demander des informations supplémentaires, comme la couleur souhaitée. La page de commande de chemises 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 demande donc que la couleur. Toutefois, d'autres conversations peuvent suivre un chemin différent, où l'utilisateur final n'a pas fourni la taille souhaitée lorsque la page de commande de chemises devient active. En définissant ce paramètre des deux manières, vous bénéficiez d'une plus grande flexibilité dans la manière dont l'agent extrait les informations.

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 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. Vous éviterez ainsi de dupliquer inutilement la conception de votre agent.

Réutilisation des intents

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

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

  • oui
  • oui
  • oui
  • OK
  • oui, oui
  • et comment !
  • absolument
  • oui s'il te plaît

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

  • 0
  • nah
  • non
  • impossible
  • pas pour moi
  • absolument pas
  • non, merci

Ces intents de confirmation réutilisables peuvent être utilisés 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 disposer d'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 votre page de confirmation de commande est active, les routes d'intent pour ces quatre intents doivent être incluses dans le champ d'application. Cela garantit 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 renseigner l'intent négatif par défaut avec des phrases que vos utilisateurs finaux sont susceptibles de prononcer, mais qui ne doivent correspondre à aucun intent de votre agent.

Fulfillment

Il existe de nombreuses options permettant d'utiliser le fulfillment pour répondre à l'utilisateur final. Au cours d'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 du tour de conversation. Cette section décrit chacune des options permettant de créer des messages individuels.

  • Traitement de l'entrée de page : ce traitement est appelé lorsque la page devient active. Cette approche est utile lorsque vous souhaitez obtenir un message décrivant l'objectif de la page. Il ne doit être prononcé 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 voulez commander.
  • Routes : ce traitement est appelé lorsqu'une route d'intent ou une route de condition avec fulfillment est appelée. Cela est utile lorsque vous souhaitez obtenir un message qui répond à l'utilisateur final à propos de la correspondance d'intent, de la condition de satisfaction (qui peut être une condition de remplissage du formulaire) ou de la transition. Exemple :
    • Oui, votre forfait international inclut le Japon. (correspondance d'intent)
    • Voulez-vous vraiment acheter 300 chemises ? (condition de comparaison remplie)
    • OK, votre rendez-vous est à 7h demain matin. (remplissage du formulaire)
    • Maintenant, parlons d' aardvarques. (transition)
  • Gestionnaires d'événements : ce traitement est appelé lorsqu'un événement est appelé. Elle 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 cette question ? (événement sans correspondance)
  • Invites initiales pour les formulaires : ce traitement 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 l'invite initiale. Exemple :
    • Quelle taille de chemise ?
    • Quelle couleur de chemise souhaitez-vous ?
  • Gestionnaires de nouvelles invites pour les formulaires : ce traitement est appelé lorsque l'agent remplit le formulaire et qu'il 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 qu'un message de nouvelle invite soit différent du message d'invite initial. S'il n'existe aucun gestionnaire de reinvites, l'agent utilise simplement l'invite initiale comme message de nouvelle invite. Exemple :
    • Je ne comprends pas. Pouvez-vous indiquer 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 comporte de nombreux intents, vous devez envisager un schéma de dénomination 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

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 vos transitions d'agents.

Transitions gratuites

Lorsque vous définissez une route qui déclenche une transition, tenez compte du fait qu'il peut exister 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 une autre route qui utilise !=.

Gérer les entrées de l'utilisateur final

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

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

Vous devez disposer d'au moins 20 phrases d'entraînement pour chaque intent. Sinon, le modèle de NLU risque de ne pas disposer de suffisamment d'informations pour correspondre de manière appropriée à votre intent. Il s'agit d'un conseil strict. Idéalement, vous devriez en définir davantage, en particulier pour les intents principaux des grands agents, auxquels environ 50 est souhaitable.

Tenir compte du biais d'intention

Lorsqu'un ou plusieurs intents ont beaucoup plus de phrases d'entraînement que d'autres intents, le modèle NLU favorise les intents plus importants en raison d'un déséquilibre des données. Ce biais d'intent 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 souhaité, car vous pouvez définir certains intents qui doivent être mis en correspondance plus souvent que d'autres, car ils correspondent aux entrées de l'utilisateur final plus fréquemment observées 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 importants. Si tel est le cas, réduisez le nombre de phrases d'entraînement pour ces intents plus larges afin qu'ils aient le même ordre de grandeur que les autres intents. Exemple :

Expressions 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 À la limite d'une infraction
20 2000 Oui

Utilisation d'entités et quantité d'expressions d'entraînement

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

  • 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 d'un intent, vous devez disposer d'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 utilisateurs disent réellement. Dans la mesure du possible, utilisez comme données d'entraînement les entrées utilisateur ayant eu lieu en production, en prêtant une attention particulière à celles qui sont les plus courantes.

Variété d'expression d'entraînement nécessaire

Incluez des variantes de questions, de commandes, de verbes et de synonymes pour les noms courants afin de 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 plus longues comme "Je viens de recevoir un courrier qui dit que je dois payer le solde de mon relevé". Il n'existe pas de proportion recommandée de phrases courtes à longues, mais vous devez la baser sur les entrées utilisateur réelles envoyées à votre agent en production.

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

Diversité des majuscules

Dans de rares cas, vous devrez peut-être ajouter des expressions d'entraînement dont seule la casse diffère. Cela s'applique généralement aux cas où vous prévoyez que les utilisateurs finaux fournissent des entrées de texte en majuscules.

Voici d'autres approches possibles:

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

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

  • Majuscules (sauf dans les cas rares) : par exemple, "Commander un ticket" et "Commander un ticket".
  • Mots de remplissage : par exemple, "d'accord, commande un billet" et "commander 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 doit inclure tout le texte nécessaire pour faire correspondre une entité. Assurez-vous également que des parties similaires des phrases d'entraînement sont annotées pour l'intégralité de l'intent.

Par exemple, le tableau suivant présente les bonnes et les mauvaises méthodes d'annotation avec l'entité système @sys.date:

Bon Mauvaises
Départ le 7 septembre 7 septembre : départ
Départ le 4 juillet Départ le 4 juillet

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

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

Expression d'entraînement annotée Signification sémantique du texte annoté
J'ai 7 ans L'âge d'une personne
Le contrat est valable sept 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. Le sens sémantique de la partie de la phrase d'entraînement doit correspondre au sens sémantique souhaité de l'entité système.

Par exemple, n'utilisez pas l'entité système @sys.duration pour annoter les sept premiers exemples "7 ans" ci-dessus. La signification sémantique de "7 ans" ne correspond pas à une durée simple. Vous devez sélectionner "7" pour l'annotation et utiliser 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 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 possède une route d'intent dans le champ d'application pouvant correspondre à cette réponse, il pourra bien gérer la situation.

Éviter @sys.any

Évitez d'utiliser le type d'entité système @sys.any. Elle ne doit être utilisée que si vous avez complètement épuisé toutes les possibilités, 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 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 lorsqu'il demande des paramètres de formulaire.

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és dans les phrases. Vous ne devez pas utiliser systématiquement le même exemple d'entité pour les annotations. L'exemple suivant montre les annotations correctes et non pertinentes pour un type d'entité produit:

Bon Mauvaises
Je veux acheter une chemise Je veux acheter une chemise
Commander un nouveau chapeau Commander une nouvelle chemise
Ajoute une montre à mon panier Ajouter 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 apportera de la variété pour les formes grammaticales, mais vous devez inclure tous les éléments possibles.

Éviter les entités avec des correspondances 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 ce qui se trouve dans chaque expression d'entraînement sera évalué comme une correspondance possible.

Les entités map et list doivent se concentrer sur des valeurs distinctes

Les types d'entités "map" et "list" doivent avoir un champ d'application limité qui capture les valeurs distinctes d'un même type d'information. Veillez à ce que vos entités soient ciblées, simples et concises.

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

  • "Comment 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 à la fois pour les actions et les plans, comme dans l'exemple suivant:

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

Utilisez plutôt des expressions d'entraînement et une correspondance d'intent pour capturer les actions, et les entités permettant de capturer les plans.

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

Lors de la capture d'entrées d'utilisateur final impliquant des identifiants autres que des mots, vous devez utiliser des entités d'expression régulière. Par exemple, pour capturer des 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 l'imbrication d'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 recueillir l'intention de l'utilisateur final. Si vous définissez des intents différents avec des phrases d'entraînement similaires, la mise en correspondance peut ne pas être fiable, car le modèle de NLU ne peut pas déterminer avec une confiance suffisante l'intent à 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 limite de facturation actuelle" et "plus de temps pour payer" doivent tous deux appartenir au même intent, car ils demandent tous deux une modification de la date d'échéance. Toutefois, les options "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 intents différents, car l'utilisateur final ne souhaite pas avoir la même chose 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é similaires, car cela peut entraîner une ambiguïté pour le modèle de NLU.

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

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 d'absence de correspondance. Vous pouvez profiter de ces opportunités pour améliorer votre agent de l'une des trois manières suivantes:

  • Ajoutez l'entrée de l'utilisateur final à l'intent souhaité en tant que phrase d'entraînement. Cependant, ce n'est pas toujours la meilleure option. Si vous exécutez cette opération plusieurs fois pour l'intent, cela peut entraîner un biais d'intention.
  • Nettoyez les phrases d'entraînement de l'intent souhaité afin qu'elles reflètent toutes l'intent. Dans certains cas, les intents dont les phrases d'entraînement sont divergentes peuvent empêcher la mise en correspondance de l'intent.
  • Si les intents qui ne doivent pas être mis en correspondance avec les entrées de l'utilisateur final comportent des phrases d'entraînement susceptibles de correspondre à celles de l'utilisateur final, supprimez-les.

Éviter les caractères spéciaux

Les caractères spéciaux des phrases d'entraînement ({, _, #, [, etc.) sont ignorés. Seule exception : les émoticônes, qui fonctionnent comme prévu.

Éviter les mots de remplissage

Les mots de remplissage sont des mots que vous pouvez ignorer et toujours être en mesure de comprendre le texte. Exemple :

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

Il est inutile mais inoffensif d'utiliser des mots de remplissage dans les phrases d'entraînement, car ils sont ignorés par le modèle de NLU. Cependant, vous ne devez pas définir des phrases 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 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 affiner les paramètres pour améliorer les performances de votre agent.

Répondre à l'utilisateur final

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

Accueillez l'utilisateur final

Un agent nouvellement créé dispose d'une route d'intent créée automatiquement pour l'intent d'accueil. Vous devez modifier cette route pour inclure un message de fulfillment accueillant l'utilisateur final. Ce message doit décrire l'agent et donner à l'utilisateur final une idée de ses capacités.

Accepter les informations sur 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 se poursuit en fonction de sa requête. Exemple :

Dialogue Description
Utilisateur final: J'ai des questions concernant mon compte courant.
Agent: D'accord, que souhaitez-vous savoir à propos de votre compte courant ?
Les entrées de 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 de vérification du compte. 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 coupe de cheveux est programmée pour 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 du formulaire sur la page active. L'agent a confirmé l'heure et la date d'une coupe de cheveux programmée.

Guidez la conversation

L'agent doit toujours guider la conversation avec l'utilisateur final. Pour ce faire, terminez chaque réponse par une question telle que:

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

Lorsque vous définissez ces questions, assurez-vous d'éviter de poser plusieurs questions telles que:

  • Vous êtes 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 peut ne pas gérer cette situation correctement.

Gérer les erreurs et les entrées inattendues de la part des utilisateurs finaux

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

Le cas échéant, vous devez créer des gestionnaires d'événements pour les événements intégrés. Le traitement de ces événements s'apparente à l'interception d'exceptions en programmation logicielle. En fonction de la situation, vous pouvez gérer les événements avec des gestionnaires d'événements spécifiques aux paramètres, à la page ou au flux.

Gérer les erreurs de webhook

En cas d'échec de votre service de webhook, il est important que votre agent puisse le gérer correctement. Pour ce faire, définissez des gestionnaires d'événements pour les événements intégrés spécifiques au webhook. 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'erreurs 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 traitement de l'entrée pour cette page doit initialiser le compteur d'erreurs sur 0 à l'aide d'un paramètre de traitement prédéfini. Exemple :

    Paramètres Value (Valeur)
    webhook-error-count 0
  • Créez une page d'erreur de webhook qui gère les événements associés:

    • Le traitement de l'entrée doit accuser réception de l'échec pour l'utilisateur final et incrémenter un paramètre de session de compteur d'erreurs à l'aide d'un paramètre de traitement prédéfini. Exemple :

      Paramètres Value (Valeur)
      webhook-error-count $sys.func.ADD($session.params.webhook-error-count, 1)
    • Définissez une route de condition dont la condition est que le nombre d'erreurs est inférieur au maximum autorisé. (par exemple, $session.params.webhook-error-count <= 3). Cette route doit comporter un traitement 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 toute page pouvant effectuer une autre tentative d'appel du webhook.

    • Définissez une route 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). Cette route doit comporter un traitement qui informe l'utilisateur final que l'agent ne réessayera plus. Cette route doit avoir une cible de transition 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 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 l'outil de validation pour vérifier votre agent. Cet outil détecte certains des problèmes décrits dans ce guide.

Utiliser les scénarios de test

Vous devez toujours définir des scénarios de test pour votre agent. Ces scénarios de test peuvent aider à éviter les régressions lorsque l'agent évolue afin de gérer d'autres scénarios.