Après une première partie présentant les principes généraux de Dialogflow et ceux de la construction d’un dataset performant, nous allons appliquer l’ensemble sur la construction d’un agent conversationnel !

Nous nous concentrerons sur la création du dataset, et les pièges à éviter; l’article en revanche fera l’impasse sur les fonctionnalités d’intégration de Dialogflow comme l’utilisation de context, de webhooks ou encore la fonctionnalité “nocode” Dialogflow CX permettant de construire et d’intégrer un agent complet sans une ligne de code (enfin presque). Mais pas de panique (le mot est très bien choisi), nous verrons ça à un autre moment !

[Mais qu’est ce donc que cette image d’article? Il s’agit de Spin City (avec Bender de Futurama), une série de la fin des 90’s sur la mairie de New-York, très amusante, avec un maire absolument hilarant. Mais quel est le lien entre Spin City et Dialogflow? La réponse dans 6 lignes]

LEOBOT !

Nous allons créer un dataset permettant de créer un agent spécialisé dans l’aide aux administrés d’une petite ville qui s’appelera Leobot.

Pourquoi ce nom de Leobot ? Tout simplement car Coddity est implanté dans la petite ville de Saint Léonard de Noblat dans le Limousin ! (Saint Léo, c’est très pittoresque, les gens sont sympas et la campagne autour est magnifique - et il y a la fibre)

Architecture

Leobot sera un agent DF simple, c’est-à-dire qu’il ne servira qu’à réaliser des détections d’intentions et d’extraction d’entités.

Imaginez que vous êtes maire d’une petite ville et que vous lancez un chatbot pour aider vos administrés dans leur démarches avec la municipalité ou leur fournir des informations pratiques. Nous allons nous limiter à quelques fonctionnalités : la réservation de rendez-vous et la fourniture d’informations sur les démarches liées à la carte nationale d’identité (CNI). Votre bot sera déployé sur votre site internet ainsi que sur votre application mobile.

Leobot sera l’agent Dialogflow que vous allez utiliser ; le canal utilisateur de cet agent sera votre site web ou votre application mobile ; enfin, toute la logique métier, conversationnelle ainsi que le système de réservation seront réalisés par le backend du site et le systeme d’information de la mairie.

Pour simplifier les cas d’utilisations, nous considèrerons qu’il existe un système d’authentification de l’utilisateur et que celui-ci est authentifié au démarrage d’une conversation.

Evidemment, cette architecture évoluerait beaucoup si nous faisions appel aux intégrations fortes que propose Dialogflow, ce qui fera l’objet d’un prochain article.

Identification et Segmentation des intentions

Quel est le périmètre “métier” que nous souhaitons pour notre bot ? Les possibilités offertes par le bot peuvent se résumer aux 4 User Stories suivantes, avec leurs intentions correspondantes (à créer) :

• connaître les horaires d’ouverture de la mairie INFO-MAIRIE-HORAIRES
• réserver un rendez-vous en mairie auprès d’un service municipal RDV-RESERVATION
• gérer un rendez-vous déjà pris RDV-GESTION
• obtenir des informations sur les pièces d’identité (carte d’indentité ou passeport) INFO-PI

Simple non ? Et bah non, pas si simple que ça, car ce qui marche pour les trains, marche aussi pour les intentions NLU, c’est-à-dire qu’une intention peut en cacher une autre.

Regardons dans le détail quelles sont les intentions cachées derrière ces 4 stories

• INFO-MAIRIE-HORAIRES : pas d’intentions cachées : l’utilisateur veut savoir quelles sont les horaires d’ouverture de la mairie et de ses services
• RDV-RESERVATION : des utilisateurs vont vouloir connaître les créneaux disponibles, d’autres réserver un créneau, et avant même ça : avoir des informations sur comment réserver
• RDV-GESTION : des utilisateurs vont vouloir décaler un rendez-vous, d’autres en annuler un, et comme pour RDV-RESERVATION avoir des informations sur le comment gérer son rendez-vous
• INFO-PI : des utilisateurs vont demander des informations sur une obtention, d’autres sur un renouvellement, d’autres sur une perte

Vous pourriez objecter qu’une annulation de rendez-vous reste une modification de rendez-vous particulière mais gardez en tête que des êtres humains vont interagir avec notre agent, et que plus les intentions de notre dataset seront précises, meilleure sera la détection. Et si vous avez des craintes sur le nombre maximum d’intentions adressables par un agent Dialogflow, il est de 2000 - oui c’est beaucoup - donc keep calm \o/

[Les lecteurs qui réfléchissent vite pourront se dire que, partant par là, on peut encore trouver de nouvelles intentions ! C’est vrai mais patience, elles arrivent dans la suite de l’article]

Ok, donc notre agent de base sera constitué de 9 intentions :

• INFO-MAIRIE-HORAIRES : connaître les horaires d’ouverture
• RDV-CREATION : réserver un rendez-vous
• RDV-MODIFICATION-DECALAGE : décaler un rendez-vous déjà pris
• RDV-MODIFICATION-ANNULATION : annuler un rendez-vous déjà pris
• INFO-PI-CREATION : connaître les démarches de création d’une PI
• INFO-PI-PERTE-VOL : connaître les démarches de déclaration de perte ou vol d’une PI

Gestion des entités

Nous allons identifier les entités nécessaires pour chacune des intentions et identifier celles qui devront être custom, c’est à dire créées dans Dialogflow par nos soins. La première est celle à laquelle nous serons toujours confrontés quand il s’agit de gestion de rendez-vous : la date. Dialogflow a une entité @sys.date qui va récupérer tous les formats de date possibles employés par les utilisateurs. Enfin, presque tous, car nos utilisateurs peuvent être très créatifs !

Maintenant, 2 entités customs vont être pertinentes :

• entité service pour récupérer le service demandé par l’utilisateur lors de la prise de rendez-vous
• entité PI pour récupérer le type de pièce d’identité : passeport ou carte nationale d’identité

Ces 3 entités vont nous permettre de fournir à notre système d’information les données nécessaires aux 4 User Stories ci-dessus.

Création sous Dialogflow

Maintenant, passons à la pratique et à la création du dataset sous Dialogflow. (Cet article n’a pas vocation à être un tutoriel sur la création d’un agent sous DF, si vous souahitez plus de détails et une méthodologie de A à Z d’implémentation, contactez-nous !)

Création et paramétrage du projet

La première étape est la création du projet et de l’agent via la console Dialogflow. Chaque agent Dialogflow est en réalité une ressource que vous allez créer sur Google Cloud, et chaque agent aura un Google Project ID de référence. Pour démarrer, vous devez commencer par choisir la localisation de votre projet parmi celles proposées par Dialogflow. Attention ici, car ce choix ne sera pas modifiable par la suite et conditionnera l’hébergement des données utilisées, ce choix sera donc fait en fonction de politique de gestion des données personnelles. Pour un hébergement sous la législation européenne, vous vous pouvez déployer sur la zone EU-W1 dont les datacenters se situent physiquement en Belgique.

Si vous êtes curieux, et que vous créez un projet en zone US, vous pourrez remarquer que Dialogflow offrira plus de fonctionnalités que pour un agent basé en Europe, en particulier une base de connaissances pour déployer par exemple un bot FAQ foire-aux-questions (Knowledge) et des outils nocode d’intégration à des plateformes conversationnelles comme skype, slack, ou encore messenger.

Selectionnez maintenant “Create new agent” dans le menu en haut à gauche, en choisissant son nom, l’ID du project Google Cloud si existant (un projet sera automatiquement créé sinon), ainsi que la langue.

Ensuite allez dans le paramétrage de l’agent et sur l’onglet ML Settings pour activer le correcteur orthographique (qui fera un redressement orthographique sur les phrases écrites par les utilisateurs) ainsi que le seuil de détection auquel Dialogflow fournira une réponse et non un “fallback”, c’est-à-dire le taux de confiance pour lequel l’agent considera sa détection.

Vous êtes maintenant prêts à créer vos intentions et entités.

Création des entités Custom

Avant de créer les intentions de notre agent, nous allons commencer par les entités dites “custom” c’est-à-dire des entités propres à notre projet. Pas de difficultés particulières, il suffit de cliquer sur “Entities” dans la barre d’outils de gauche.

Dialogflow nous permet d’activer 4 options:

• les synonymes : permettre à dialogflow d’identifier une valeur d’entité selon un corpus de mots (synonymes) que nous allons utiliser pour l’entité service par exemple
• regex : typiquement l’application de règle regex. Si vous n’etes pas informaticien, les regex sont des règles permettant de récupérer des informations qui suivent un certain modèle : un numéro de téléphone, un numéro de commande, de facture, de réservation, une référence, etc
• l’expansion automatique
• fuzzy matching : qui va permettre d’identifier une entité même si l’utilisateur ne l’orthographie pas correctement. Option très utile sur les entités très spécifiques mais qui peut devenir problématique si votre entité est un mot assez courant

“service”

Pour cette entité et pour cette démo, nous allons nous concentrer sur 6 services d’une mairie, en utilisant l’option de la définition de synonyme : secretariat, voirie, urbanisme, periscolaire, etat-civil, technique.

L’agent identifiera directement l’entité qui pourra ainsi être utilisée par le système d’information pour traiter la demande du client correctement, c’est à dire vérifier les créneaux disponibles dans le bon agenda et les créer.

“PI”

Pas de difficultés ici, nous crééons juste 2 valeurs d’entité passeport et CNI.

Création des intentions

Maintenant, nous allons créer les intentions, commencer à les alimenter avec des phrases d’entraînement et tagger des entités sur ces phrases.

Nous n’utilisons dans cet article que la capacité de Dialogflow à détecter des intentions et en extraire des entités, nous n’utiliserons donc pas les champs context, events, responses et fulfillment. Ceux-ci seront vus dans un prochain article afin d’exploiter au mieux la puissance de Dialogflow en tant que plateforme conversationnelle permettant de créer un agent nocode.

Creation des phrases d’entraînement

Nous en sommes à l’initialisation de notre agent, pour laquelle nous avons 2 cas de figure : vous disposez de données pouvant servir à créer les phrases d’entraînement ou non.

Quelles peuvent être ces données ? > Toutes phrases écrites par les futurs utilisateurs de votre chatbot. Par exemple, si vous possédez un service de support client par chat, et que vous souhaitez déployer un chatbot en complément de ces équipes humaines, vous pouvez utiliser les conversations entre vos conseillers et vos clients pour créer des phrases d’entraînement des intentions. Un travail important d’annotations est cependant nécessaire pour identifier correctement l’intention du client.

Pourquoi est-ce important ? Si vous avez suivi le premier article, la réponse est évidente ! Il s’agit de phrases telles que vos utilisateurs les prononcent, et donc, qui seront celles utilisées sur votre chatbot. La détection d’intention en sera grandement facilitée puisque votre agent sera entraîné avec des données de production.

Pour Leobot, nous n’avons évidemment pas de données. Il faut donc laisser notre imagination nous fournir une cinquantaine de phrases par intention pour démarrer. Nous pouvons aussi utiliser des algorithmes de génération automatique de texte.

C’est parti !

Comment créer des phrases d’entraînement ? Alors attention, c’est assez compliqué, il s’agit de saisir une phrase dans “Add user expression”, et… c’est tout. Attention cependant, Dialogflow tague automatiquement des entités, et parfois l’identification automatique fait des erreurs. Pour l’un de nos projets, des références d’articles étaient identifiées en référence de vol commerciaux :grimace:.

On ne va pas détailler ici les phrases d’entraînement, vous les trouverez en fin d’article sur le lien vers le dataset, néanmoins voici le type de phrases qui vont composer le dataset. Vous remarquerez que les phrases comportent des fautes de frappe ou d’orthographe : ceci est bel et bien voulu, cela permet d’être au plus proche de la manière dont les utilisateurs interagissent avec le bot (parfois avec des fautes donc).

INFO-MAIRIE-HORAIRES

Quelles sont les horaries d'ouverture ?
Quand la mairie est ouverte?
Horaires

RDV-CREATION

je veux prendre rendez vous avec le maire
je veux un rendez vous car j'ai un probleme
je veux un  rdv pour ma carte d'identité

RDV-MODIFICATION-DECALAGE

j'ai rendez vous la semaine prochaine pour mon passeport mais je veux décaler'
rdv avec la voirie le 5 mars, possible de décaler?
Mon fils est malade, je ne pourrais pas venir à mon rendez vous du 10 avril, je veux reporter

RDV-MODIFICATION-ANNULATION

je veux annuler le rendez vous avec la voirie
je déménage, plus besoin de voir le maire
j'annule le rendez vous du 8 juin

INFO-PI-CREATION

je veux faire une carte d'indentité
comment faire un passeport ?
les passeports c'est à la mairie?

INFO-PI-PERTE-VOL

j'ai perdu ma carte d'indentité
perte du passeport ?
mon fils a perdu son passeport comment faire ?
On m'a volé ma carte d'indentité

Identification des entités

A chaque phrase que vous saisissez vous allez pouvoir identifier des entités, qu’elles soient custom ou identifiées automatiquement par Dialogflow. Pour cet agent, nous pouvons facilement identifier les entités qui vont être à la fois naturellement prononcées par l’utilisateur et utiles pour apporter la bonne réponse au client. Ainsi, un utilisateur qui veut des informations sur l’horaire d’ouverture du service de la voirie pourrait le dire explicitement dans sa phrase et le backend de notre chatbot lui fournir la bonne réponse.

Nous partons sur le mapping intentions / entités suivant:

• INFO-MAIRIE-HORAIRES : entités service et PI vont permettre de fournir les horaires du bon service en connaissant directement le service demandé ou en le déduisant de l’entité PI
• RDV-CREATION : entités service, PI et date
• RDV-MODIFICATION-DECALAGE : entités service, PI et date
• RDV-MODIFICATION-ANNULATION : entités service, PI et date
• INFO-PI-CREATION : entité PI
• INFO-PI-PERTE : entité PI
• INFO-PI-VOL : entité PI

Pour identifier les entités, rien de plus simple il suffit de surligner le mot ou l’expression voulu(e) et Dialogflow s’occupe du reste.

Votre dataset est pret, votre agent peut maintenant s’entraîner avec, et vous pouvez déployer votre agent en production !

Bonjour ?

Il manque une série d’intentions à créer pour avoir un agent conversationnel utilisable immédiatement, il s’agit de ce que l’on appelle des small talk, c’est-à-dire toutes les petites phrases non couvertes par la spécialisation du bot : dire bonjour, remercier, demander de l’aide, et (malheureusement) insulter - c’est d’ailleurs un point assez surprenant, le nombre d’insultes que peut recevoir un chatbot. Dialogflow propose d’intégrer automatiquement certain small-talk mais uniquement pour certaines zones de projet Google et certaines langues.

Il faudra donc créer les intentions simples suivantes (liste non exhaustive):

• SMALL-BONJOUR
• SMALL-AUREVOIR
• SMALL-MERCI
• SMALL-INSULTE
• SMALL-AIDE

Les construire sera un bon un exercice de manipulation de la console Dialogflow pour vous !

Dans la vie de Leobot

Notre Leobot va vivre sa vie et rencontrer ses utilisateurs. Mais votre travail n’est pas terminé !

La lecture des conversations va vous permettre de grandement améliorer son comportement.

Enrichissement du dataset

Vous devrez ajouter au dataset d’entraînement des phrases émanant des conversations réelles afin d’améliorer la pertinence de l’agent. Veillez toutefois à maintenir un équilibre sur le nombre des phrases d’entraînement entre les différentes intentions.

Comportement utilisateur

Premier élément, la lecture des conversations va vous donner des informations sur le style littéraire des utilisateurs (leur syntaxe, le respect de l’ortographe). Vous devrez en tenir compte dans l’enrichissement du dataset.

Deuxième élément, vous allez voir apparaitre des tournures de phrase que vous n’avez pas anticipées. Par exemple, dans le cas de notre Leobot, un utilisateur ne va pas demander précisement un rendez-vous avec le service d’état civil mais peut être décrire son besoin en d’autres termes :

je veux un rendez vous pour mon pacs
besoin d'un rendez vous pour récupérer un certificat de naissance

Ces tournures devront être intégrées dans les phrases d’entrainement mais aussi faire évoluer votre structure d’entités.

Emergence d’intentions

Naturellement vos utilisateurs prononceront des phrases que votre agent ne saura pas identifier (fallback), ou les identifiera par une intention proche du sens de la phrase client, mais le bot sera bien incapable de fournir une réponse correcte à l’utilisateur, déclenchant une certaine frustration.

Exemples sur notre Leobot.

Ou garer ma voiture à la mairie? sera certainement identifié en fallback par notre agent ; à vous de voir si la récurrence de ce type de phrase est importante, ce qui nécessiterait une nouvelle intention du type “mairie-parking-info”.

Je n'arrive pas à prendre rendez vous avec la voirie sera certainement identifié par l’intention rdv-creation, la phrase est en effet proche sémantiquement des phrases d’entrainement de cette intention. 2 solutions s’offrent alors à vous :

• ajouter des phrases dans ce sens sur rdv-creation (je n'arrive pas à ..., impossible de ... ) mais vous ne serez pas capable d’apporter une réponse à la problématique de l’utilisateur car vous ne l’identifierez pas correctement
• créer une intention rdv-creation-probleme qui reprendra ce besoin utilisateur avec les phrases d’entraînement correspondantes

That’s all !

Notre première version de Leobot est prête ! Si vous souhaitez le tester, l’agent est disponible sur github, il ne vous restera plus qu’à créer un agent sur votre compte Dialogflow et le charger dans la rubrique Export and Import.

A venir : u article sur la misure de performance et l’amélioration du moteur de NLU

THE END