Principes de base de Dialogflow CX

Ce document décrit les principes de base de l'utilisation de Dialogflow CX. Il en présente les concepts les plus importants.

Agents

Un agent Dialogflow CX est un agent virtuel qui gère les conversations avec vos utilisateurs finaux. Il s'agit d'un module de compréhension du langage naturel qui saisit les nuances du langage humain. Dialogflow traduit les contenus texte ou audio produits par l'utilisateur final au cours d'une conversation en données structurées assimilables par vos applications et vos services. Vous pouvez créer un agent Dialogflow conçu pour gérer les types de conversations requis pour votre système.

Un agent Dialogflow est comparable à un agent humain de centre d'appels. L'un comme l'autre doivent apprendre à gérer les scénarios de conversation attendus, sans qu'il soit nécessaire de leur dispenser un entraînement/une formation trop explicite.

Flux

Les boîtes de dialogue complexes impliquent souvent plusieurs sujets de conversation. Par exemple, un agent de livraison de pizzas peut avoir pour sujet distinct commande de repas, informations sur le client et confirmation. Chaque sujet nécessite plusieurs tours de conversation pour qu'un agent puisse acquérir les informations pertinentes de l'utilisateur final.

Les flux permettent de définir ces thèmes et les chemins de conversation associés. Chaque agent dispose d'un flux appelé flux de démarrage par défaut. Ce flux unique peut être tout ce dont vous avez besoin pour un agent simple. Des agents plus complexes peuvent nécessiter des flux supplémentaires, et différents membres de l'équipe de développement peuvent être chargés de créer et de gérer ces flux. Par exemple, les flux d'un agent de livraison de pizza peuvent se présenter comme suit :

Exemple de diagramme multi-flux.

Les flux Dialogflow CX ont la même fonction que les sous-agents des méga-agents Dialogflow ES. Les flux permettent un meilleur contrôle de la conversation et n'entraînent pas de coût supplémentaire.

Pages

Une conversation (session) Dialogflow CX peut être décrite et visualisée en tant que machine à états. Les états d'une session CX sont représentés par des pages.

Pour chaque flux, vous définissez de nombreuses pages dans lesquelles vos pages combinées peuvent gérer une conversation complète sur les sujets pour lesquels le flux est conçu. À tout moment, une seule page correspond à la page actuelle, la page actuelle est considérée comme active et le flux associé à cette page. est considéré comme actif. Chaque flux dispose d'une page d'accueil spéciale. Lorsqu'un flux devient initialement actif, la page d'accueil devient la page actuelle. À chaque tour de conversation, la page actuelle reste la même ou passe à une autre page.

Vous configurez chaque page pour collecter auprès de l'utilisateur final des informations pertinentes pour l'état conversationnel représenté par la page. Par exemple, vous pouvez créer les pages (en bleu) dans le diagramme ci-dessous pour un flux de commande de nourriture d'un agent de livraison de pizza. Le nœud Start (Début) du diagramme représente la page d'accueil du flux Food Order (Commande de repas). Une fois le flux terminé, il passe au flux Confirmation.

Exemple de diagramme multi-flux.

Types d'entités

Les types d'entité permettent de contrôler la manière dont les données des entrées de l'utilisateur final sont extraites. Les types d'entités CX sont très semblables aux types d'entités ES.

Dialogflow fournit des entités système prédéfinies correspondant à de nombreux types de données courants. Par exemple, il existe des entités système pour la mise en correspondance des dates, des heures, des couleurs, des adresses e-mail, etc. Vous pouvez également créer vos propres entités personnalisées pour la mise en correspondance de données personnalisées. Par exemple, vous pouvez définir une entité légume pouvant être mise en correspondance avec les types de légumes proposés dans une épicerie.

Paramètres

Les paramètres sont utilisés pour capturer et mentionner des valeurs ayant été fournies par l'utilisateur final au cours d'une session. Chaque paramètre possède un nom et un type d'entité. Contrairement aux entrées utilisateur brutes, les paramètres sont des données structurées pouvant être utilisées pour exécuter une logique ou générer des réponses.

Les paramètres CX ressemblent aux paramètres ES, mais l'utilitaire et le champ d'application ont été étendus, et la syntaxe des paramètres de référence a changé.

Forms

Pour chaque page, vous pouvez définir un formulaire, qui est une liste de paramètres devant être collectés par l'utilisateur final pour la page. L'agent interagit avec l'utilisateur final pendant plusieurs tours de conversation, jusqu'à ce qu'il ait collecté toutes les données requisesparamètres de formulaire , également appelésParamètres de page ... Pour chaque paramètre du formulaire, vous fournissez également des invites que l'agent utilise pour demander ces informations à l'utilisateur final. Ce processus est appelé le remplissage du formulaire.

Par exemple, vous pouvez créer un formulaire qui recueille le nom et le numéro de téléphone de l'utilisateur final pour une page Collect Customer Info.

Le remplissage de formulaire CX ressemble au remplissage de cases ES.

Intents

Un intent permet de catégoriser l'intention exprimée par un utilisateur final durant un tour de conversation. Par rapport aux intents ES, les intents CX ont été simplifiés pour être plus réutilisables.

Un intent contient les données suivantes :

Terme Définition
Phrases d'entraînement Les expressions d'entraînement sont des exemples de phrases que les utilisateurs finaux sont susceptibles de saisir ou de prononcer, appelées entrées de l'utilisateur final. Lorsque l'entrée de l'utilisateur final ressemble à l'une de ces expressions, Dialogflow établit la mise en correspondance avec l'intent. Il n'est pas nécessaire de définir tous les exemples de phrases possibles, car les fonctionnalités de machine learning intégrées de Dialogflow se chargent d'étendre votre liste aux phrases semblables.
Paramètres Vous définissez vos expressions d'entraînement pour utiliser des paramètres afin d'extraire des valeurs de parties spécifiques de l'entrée de l'utilisateur final.

Webhook

Les webhooks sont des services qui hébergent votre logique métier. Au cours d'une session, les webhooks vous permettent d'utiliser les données extraites par le traitement du langage naturel de Dialogflow pour générer des réponses dynamiques, valider les données collectées ou déclencher des actions sur le backend.

Les webhooks CX ressemblent aux webhooks ES, sauf que les champs de demande et de réponse ont été modifiés pour prendre en charge les fonctionnalités CX.

Fulfillment

Pour le tour de conversation d'un agent, il doit répondre à l'utilisateur final en lui fournissant une réponse à une question, une requête d'informations ou une cessation de session. Votre agent peut également avoir besoin de contacter votre service pour générer des réponses dynamiques ou prendre des mesures pour un tour. Le fulfillment permet d'effectuer toutes ces opérations.

Un fulfillment peut contenir l'un des éléments suivants :

  • Messages de réponse statiques
  • Appels webhook pour les réponses dynamiques et/ou pour effectuer des actions
  • Préréglages de paramètres pour définir ou remplacer les valeurs de paramètres

Lors du tour d'un agent, il est possible (et parfois souhaitable) d'appeler plusieurs fulfillments, chacun pouvant générer un message de réponse. Dialogflow conserve ces réponses dans une file d'attente de réponses. Une fois le tour de l'agent terminé, Dialogflow envoie les réponses triées à l'utilisateur final.

Le fulfillment ES est limité à la connexion d'un service de webhook. Le champ d'application du fulfillment a été étendu pour CX. Il couvre désormais tous les types d'invites et de réponses.

Gestionnaires d'état

Les gestionnaires d'état, également appelés gestionnaires, permettent de contrôler la conversation en créant des réponses pour les utilisateurs finaux et/ou en remplaçant la page active. À chaque tour de conversation, les gestionnaires sont évaluées et peuvent affecter la session. Les gestionnaires ont trois types généraux de données :

Terme Définition
Exigences des gestionnaires Il s'agit des exigences qui doivent être satisfaites pour que le gestionnaire ait un effet sur la session. Un gestionnaire est appelé lorsqu'il répond à ses exigences et affecte la session d'une manière ou d'une autre.
Fulfillment du gestionnaire Si un gestionnaire est appelé, un fulfillment facultatif est utilisé pour créer des réponses pour les utilisateurs finaux. Ces réponses sont définies dans les données de l'agent statique ou extraites de manière dynamique à partir de votre service de webhook.
Cible de transition du gestionnaire Si un gestionnaire est appelé, une cible de transition facultative est utilisée pour modifier la page actuelle. La page suivante ne peut être qu'une page d'accueil de flux ou une page du flux actuellement actif.

Il existe deux types de gestionnaires d'état avec des exigences de gestionnaire différentes :

Terme Définition
Routes Les routes sont appelées lorsqu'une entrée de l'utilisateur final correspond à un intent et/ou une condition sur l'état de la session est rempli. Une route avec une exigence d'intent est également appelée route d'intent. Une route qui ne comporte qu'une exigence de condition est également appelée route de condition.
Gestionnaires d'événements Les gestionnaires d'événements sont appelés lorsqu'un événement est appelé. Certains événements intégrés sont déclenchés lorsque des entrées de l'utilisateur final inattendues sont reçues ou lorsqu'une erreur de webhook se produit. Vous pouvez également définir des événements personnalisés que vous appelez lorsqu'un événement se produit en dehors de la conversation.

Le traitement d'un gestionnaire d'état comprend trois étapes :

Terme Définition
1. Champ d'application Un gestionnaire doit figurer dans la portée pour avoir un effet sur la session. La portée est déterminée par l'application d'un gestionnaire à un paramètre de flux, de page ou de formulaire, et si le flux ou la page associés sont actifs ou si l'agent tente actuellement de remplir le paramètre de formulaire associé.
2. Évaluation Chaque gestionnaire dans la portée est évalué dans l'ordre. Si les exigences du gestionnaire sont remplies, il réussit l'évaluation.
3. Appel Si un gestionnaire est dans la portée et réussit l'évaluation, il est appelé. Un fulfillment associé est appelé, et toute cible de transition associée est appliquée à la session.

Régionalisation et paramètres de localisation

Lorsque vous créez un agent, vous devez spécifier une région comme emplacement de l'agent. Les requêtes envoyées à votre agent sont gérées par les services Google dans cette région, et Dialogflow conserve données au repos physiquement dans la région ou l'emplacement géographique. Pour de meilleures performances, vous devez choisir une région proche de vos services et de vos utilisateurs finaux.

Une fois l'agent créé, son emplacement ne peut pas être modifié. Pour modifier l'emplacement d'un agent, vous devez l'exporter puis le restaurer dans un nouvel agent situé dans un autre emplacement.

Chaque emplacement est associé à des paramètres qui s'appliquent à l'ensemble de votre projet. Dans la plupart des cas, il n'est pas nécessaire de modifier ces paramètres de localisation, car les paramètres par défaut fonctionnent correctement. Si votre système nécessite des clés de chiffrement gérées par le client (souvent requises par les entités gouvernementales ou les secteurs réglementés), consultez la documentation sur les paramètres de localisation.

Console

Dialogflow fournit une interface utilisateur Web : la console Dialogflow CX (consulter la documentation, ouvrir la console). Cette console vous permet de créer, de compiler et de tester des agents CX. La console CX a un objectif semblable à la console ES, mais l'interface utilisateur de la console CX est beaucoup plus visuelle. Elle représente chaque flux sous forme de schéma de machine à états de conversation, ce qui facilite la conception et la compréhension des agents complexes.

La console Dialogflow CX est différente de la console Google Cloud Platform (GCP) (consulter la documentation, ouvrir la console). La console Dialogflow CX permet de gérer les agents Dialogflow CX, tandis que la console GCP permet de gérer les paramètres Dialogflow CX spécifiques à GCP (par exemple, la facturation) et d'autres ressources GCP.

Dans la plupart des cas, la console de Dialogflow CX permet de créer des agents, mais vous pouvez également passer par l'API CX de Dialogflow pour créer des agents pour des scénarios avancés.

Intégrations

Dialogflow CX fournit actuellement plusieurs intégrations intégrées à d'autres plates-formes de conversation. Ces intégrations fournissent une interface utilisateur à l'utilisateur final et appellent l'API Dialogflow pour vous. Il vous suffit de créer votre agent et éventuellement de mettre en œuvre un service de webhook. Chaque intégration gère les interactions d'une manière spécifique à la plate-forme. Pour plus d'informations, consultez la documentation d'intégration spécifique.

Interactions

Une interaction se produit à chaque tour de conversation. Lors d'une interaction, un utilisateur final envoie des entrées à Dialogflow, qui envoie ensuite une réponse. Lors de la mise en œuvre de votre système, vous disposez de deux options: utiliser l'API ou une intégration.

Lorsque vous utilisez l'API, votre système doit gérer les éléments suivants:

  • Créer un agent
  • fournir une interface utilisateur aux utilisateurs finaux ;
  • Appelez l'API Dialogflow à chaque tour de conversation pour envoyer les entrées de l'utilisateur final à l'API.
  • À moins que les réponses de l'agent ne soient purement statiques (non courant), vous devez héberger un service de webhook pour gérer le fulfillment compatible avec webhook.

Lorsque vous utilisez une intégration, votre système doit simplement gérer les éléments suivants:

  • Créer un agent
  • Vous pouvez éventuellement mettre en œuvre un service de webhook.

Le schéma suivant illustre les étapes qui se produisent pour un tour de conversation d'une session.

Schéma de flux de l'API.

  1. L'utilisateur final saisit ou prononce quelque chose, appelé entrée de l'utilisateur final.
  2. Votre interface utilisateur ou votre système d'intégration reçoit l'entrée et la transfère à l'API Dialogflow dans une requête de détection d'intent.
  3. L'API Dialogflow reçoit la requête de détection d'intent. Elle correspond à l'entrée d'un intent ou d'un paramètre de formulaire, définit les paramètres nécessaires et met à jour l'état de la session. Si elle doit appeler un fulfillment compatible avec le webhook, elle envoie une requête de webhook à votre service de webhook. Sinon, passez à l'étape 6.
  4. Votre service webhook reçoit la requête webhook. Votre service effectue les actions nécessaires, telles que l'appel d'API externes, le questionnement ou la mise à jour d'une base de données, etc.
  5. Votre service de webhook crée une réponse et renvoie une réponse de webhook à Dialogflow.
  6. Dialogflow crée une réponse de détection d'intent. Si un webhook a été appelé, il utilise la réponse fournie dans la réponse du webhook. Si aucun webhook n'a été appelé, il utilise la réponse statique définie dans l'agent. Dialogflow envoie une réponse de détection d'intent à votre interface utilisateur ou à votre système d'intégration.
  7. Votre interface utilisateur ou votre système d'intégration reçoit la réponse de détection d'intent et transmet la réponse textuelle ou audio à l'utilisateur final.
  8. L'utilisateur final voit ou entend la réponse.