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 simultanées 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 :
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.
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 L'agent collecte ces paramètres dans l'ordre défini sur la page. Pour chaque paramètre du formulaire requis, 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 |
|---|---|
| Nom à afficher | Nom affiché dans la console pour l'intent. |
| Étiquettes | Étiquettes qui aident à catégoriser les intents. Par exemple: intent principal. |
| 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. |
| Schémas DTMF | Reportez-vous à DTMF pour les intégrations de téléphonie. |
Webhook
Les webhooks sont des services qui hébergent votre logique métier ou appellent d'autres services. 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.Un webhook peut être un webhook standard ou un webhook flexible. Avec un webhook standard, les champs de requête et de réponse sont définis par Dialogflow. Avec un webhook flexible, vous définissez les champs de requête et de réponse.
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 |
|---|---|
| Conditions requises pour le gestionnaire | 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. |
| Traitement des gestionnaires | 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. 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 traitées par les services Google de cette région, et Dialogflow conserve les données au repos physiquement dans la région ou l'emplacement géographique. Pour des performances optimales, 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. Les paramètres par défaut fonctionnent correctement. Si votre système requiert des clés de chiffrement gérées par le client (souvent requises par des entités administratives ou des secteurs réglementés), lisez 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 natives pour 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 de manière spécifique à la plate-forme. Pour plus d'informations, consultez la documentation de l'intégration spécifique.
Interactions
À chaque tour de conversation, une interaction a lieu. Lors d'une interaction, un utilisateur final envoie une entrée à Dialogflow, qui envoie une réponse. Vous disposez de deux options lorsque vous mettez en œuvre votre système pour gérer les interactions : utiliser l'API ou utiliser 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
- Appeler l'API Dialogflow pour chaque tour de conversation afin d'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 ne doit gérer que les éléments suivants :
- Créer un agent
- Mettre en œuvre un service de webhook (facultatif)
Le schéma suivant illustre les étapes qui se produisent pour un tour de conversation d'une session.
- L'utilisateur final saisit ou prononce quelque chose, appelé entrée de l'utilisateur final.
- Votre système d'interface utilisateur ou d'intégration reçoit l'entrée et la transmet à l'API Dialogflow dans une requête de détection d'intent.
- 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.
- 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.
- Votre service de webhook crée une réponse et renvoie une réponse de webhook à Dialogflow.
- 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.
- Votre système d'interface utilisateur ou d'intégration reçoit la réponse de détection d'intent et transmet la réponse texte ou audio à l'utilisateur final.
- L'utilisateur final voit ou entend la réponse.