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 pizza peut présenter les commandes de nourriture, les informations sur le client et la confirmation comme sujets distincts. 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. À un moment donné, une seule page est 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 Démarrer du diagramme représente la page d'accueil du flux de commande de nourriture. 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 pour plusieurs tours de conversation, jusqu'à ce qu'il ait collecté tous les paramètres du formulaire requis, également appelés paramè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 ne comportant qu'une exigence requise 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. Portée 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.

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.

Interactions avec les utilisateurs via l'API

L'utilisation de l'API pour CX est semblable à l'utilisation de l'API pour ES, sauf que certains chemins d'accès et méthodes de ressources ont été modifiés pour prendre en charge de nouveaux types, méthodes et champs.

Votre système doit gérer les éléments suivants :

  • Dialogflow CX n'est pas encore compatible avec les intégrations. Votre système doit donc fournir une interface utilisateur pour interagir directement avec les utilisateurs finaux.
  • Vous devez appeler l'API Dialogflow à chaque tour de conversation pour envoyer des 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.

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 système d'interface utilisateur reçoit l'entrée et la transmet à 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 au système d'interface utilisateur.
  7. Votre système d'interface utilisateur reçoit la réponse de détection d'intent et transmet la réponse texte ou audio à l'utilisateur final.
  8. L'utilisateur final voit ou entend la réponse.