Les récentes évolutions dans le domaine de la compréhension du langage naturel permettent désormais aux machines de comprendre et de répondre aux messages écrits et vocaux de manière instantanée et sans interruption.
Aujourd’hui, le nombre d’utilisateurs d’applications de messagerie comme WhatsApp, Slack ou encore Skype montent en flèche. L’application Facebook Messenger à elle seule compte plus de 1,2 milliard d’utilisateurs par mois. Avec la multiplication des applications de messages, les chatbots virtuels qui imitent les conversations humaines pour résoudre diverses tâches sont de plus en plus demandés. Par exemple, le chatbot WeChat chinois peut déjà fixer des rendez-vous médicaux, appeler un taxi, envoyer de l’argent à des amis ou bien s’enregistrer pour un vol.
Est-ce que les chatbots ont aujourd’hui les ressources suffisantes pour imiter les humains ou s’agit-il simplement d’une nouvelle façon d’interagir plus naturellement avec les machines? Je vais ici présenter Botpress, une solution permettant de créer des chatbots simplement.
Botpress est une solution open-source et on-premise écrite en TypeScript et ayant pour ambition d’être le WordPress des chatbots avec une plate-forme qui facilite la construction de bots à l’aide de modules de code créés par la communauté.
Il s’agit d’une plate-forme complète livrée avec tous les outils nécessaires pour construire, déployer et gérer des bots de production. Botpress utilise notamment son propre moteur de compréhension du langage naturel (Natural Langage Understanding ou NLU) embarquée avec la solution, ce qui signifie qu’il n’y a aucun besoin d’effectuer des appels à un service web assurant ici un grand contrôle sur les données pour les créateurs de chatbots.
A cela s’ajoute un éditeur de flux visuel intuitif qui rend la solution très simple à utiliser, permettant aux personnes ayant un profil non-techniques de maintenir et de faire évoluer le bot facilement avec des parcours utilisateurs complexes.
Simple à utiliser, Botpress est cependant parfois compliqué à configurer. En effet, la documentation, bien que couvrant de nombreux aspects, n’est parfois pas mis à jour avec les évolutions (du moins lors de mon utilisation en août 2019). Or le produit étant assez récent, celui-ci évolue régulièrement.
La présence d’un débogueur de chat permet d’améliorer rapidement son bot et d’assurer une bonne compréhension sur les résultats du moteur de NLP et un contrôle fin. De plus, si les développeurs souhaitent intégrer des actions personnalisées comme effectuer une recherche dans une base de données ou un appel à un API, il suffit d’ajouter du code dans des dossiers spécifiques, par la suite facilement réutilisable, afin que celui-ci soit lancé au moment souhaité avec une gestion des événements par Botpress.
Depuis la version 12, la gestion du langage a été amélioré avec la possibilité de changer entre plusieurs langues de façon transparent. Les langues par défaut étant l’arabe, le français, l’anglais, le japonais et le portugais
Voici donc une présentation des concepts associés à Botpress afin de comprendre son mode de fonctionnement.
Dialog Engine
Botpress utilise ce que les développeurs appellent le moteur de dialogue pour gérer les conversations. Le moteur de dialogue est responsable de chaque interaction avec un bot. Il gère l’entrée utilisateur et la réponse du bot.
Vue d’ensemble
Le moteur de dialogue utilise des flux (Flows) qui représentent la logique conversationnelle globale d’un bot. Un flux est alors composé de nœuds (Nodes) qui exécutent une série d’instructions. Les instructions font partie du cycle de vie d’un nœud et peuvent exécuter des Actions. Une Action est un essentiellement un fichier javascript de code, écrit par le développeur, par Botpress ou par d’autres.
La création de bot se fait simplement à l’aide de l’interface utilisateurs. Il suffit d’ajouter des nœuds et de le relier entre eux. Au sein de ceux-ci, on définit des messages ou des actions à exécuter. Cette interface et la logique associée au bot sont sauvegardées au sein de fichier json de type *.ui.json et *.flow.json qu’il est possible de modifier manuellement.
Flows
Les bots plus complexes sont généralement décomposés en plusieurs flux plus petits au lieu d’un seul grand flux (par exemple un flux pour le traitement d’une demande de réservation et un autre flux pour une recherche d’informations). La raison de décomposer le bot en plusieurs flux est de faciliter la maintenabilité et la réutilisabilité.
Cycle de vie d’un flow
Un flux démarre toujours au startNode de son fichier *.flow.json. Le nœud de départ (startNode) indique le nom du nœud sur lequel le flux va commencer. Une fois le nœud sélectionné, le moteur de dialogue met en file d’attente les instructions du nœud actif. Ensuite, il traitera les instructions de façon séquentielle.
Le moteur de dialogue est basé sur les événements et n’est pas bloqué par défaut, ce qui signifie qu’un flux exécutera tout ce qu’il peut exécuter jusqu’à ce qu’il doive attendre.
Une fois le premier nœud traité, le moteur de dialogue passe au nœud suivant dans le flux jusqu’à la toute fin. Les nœuds ont également leur propre cycle de vie. Ce sont les nœuds qui font le travail le plus important dans un flux, celui-ci ne faisant que les orchestrer.
Nodes
Les nœuds sont les unités primaires de la logique conversationnelle du bot. Une conversation active (appelé « session ») a toujours un et un seul nœud actif. Un nœud passe généralement à un autre nœud ou à un autre flux. Si ce n’est pas le cas, la conversation est terminée. Le message suivant de l’utilisateur fera alors partie d’une session entièrement nouvelle.
Un nœud est séparé en trois étapes différentes : onEnter (A), onReceive (B) et onNext (C).
Cycle de vie d’un noeud
onEnter
onEnter est une liste d’instructions qui seront exécutées lorsque le nœud est saisi. Si plusieurs actions sont définies, elles seront toutes exécutées séquentiellement.
onReceive
onReceive est une liste d’instructions qui sera exécutée lorsque le nœud reçoit un message tout en étant le nœud actif. Dès qu’une action est définie, le nœud attend automatiquement la saisie utilisateur (nœud orange).
Lorsque cette propriété n’est pas utilisée, le nœud n’est pas bloquant (noir), ce qui signifie qu’il passe directement de onEnter à onNext.
onNext
onNext (aussi appelé Transitions) n’est évalué qu’après l’exécution de onReceive ou onEnter et redirige vers une cible appelée une destination. Ça peut être :
- Un nœud différent
- Un flux différent
- Le flux précédent
- Lui-même (boucle de retour sur lui-même)
- La fin de la conversation
Cas particuliers : Si aucune condition n’est définie, le comportement par défaut est que la conversation se termine. S’il y a des conditions définies mais qu’aucune ne correspond, rien ne se passe, c’est-à-dire que le nœud courant reste actif, et il s’écoule quand une condition correspond. Par défaut, onNext ne sera réessayé qu’après la réinvocation de onReceive.
Actions
Les actions sont essentiellement des fonctions côté serveur qui sont exécutées par le bot dans le cadre d’un flux conversationnel. Les actions permettent de faire beaucoup de choses :
- Modifier l’état de la conversation
- Envoyer des messages personnalisés à la conversation
- Exécuter du code javascript arbitraire comme appeler une API ou stocker des données dans la base de données
Les Actions sont exécutées dans une machine virtuelle pour éviter un crash du serveur en cas d’erreur de script. Les scripts peuvent nécessiter n’importe quel module qui est chargé par Botpress par défaut (par exemple : lodash, axios, moment, nanoid, et autres).
Lorsqu’une action est invoquée par le gestionnaire de dialogue (DM), elle récupère les arguments suivants :
- user : Inclut tous les attributs d’un utilisateur.
- session : Inclut les variables conservées pendant toute la durée de la session.
- temp : Contient des variables qui ne durent que pendant la durée du flux.
- bot : Objet contenant des variables globales pour ce bot (identique pour tous les utilisateurs)
- event : L’événement original (le plus récent) reçu de l’utilisateur au cours de la conversation.
- args : Les arguments qui ont été passés à cette action depuis le Visual Flow Builder.
- process : machine virtuelle « bac à sable » contenant certaines des variables d’environnements (à commencer par EXPOSED_)
Pour ajouter une action il suffit de sélectionner « Execute code » dans un nœud et de choisir l’action souhaitée.
Hooks
Les « hooks » sont des actions exécutés lorsque des événements spécifiques se produisent. En effet, certains événements sont récurrents et il peut être utile de vouloir exécuter une action récurrente en fonction. Chaque fichier placé dans le dossier correspondant sera exécuté au moment de l’événement correspondant.
Ils sont définis globalement comme fichiers javascript dans le dossier data/global/hooks. Il est possible d’ajouter autant de fichiers que l’on veut, ils seront traités séquentiellement, par ordre alphabétique.
Attention, les hooks ne reçoivent pas automatiquement les mêmes arguments que les actions mais certains spécifiques à chaque évènement.
After Server Starts
Cet événement est appelé une fois que tous les modules et les bots sont chargés et que le bot est prêt à accepter les connexions entrantes.
After Bot Mount
Cet événement est appelé chaque fois qu’un bot est monté, que ce soit au démarrage du serveur ou lors de l’ajout de nouveaux bots lors de l’exécution.
After Bot Unmount
Cet événement est appelé chaque fois qu’un bot est démonté. C’est généralement pour faire le nettoyage quand un bot est supprimé.
Before Incoming Middleware
Ce hook est appelé lorsqu’un événement est reçu, avant tout middleware. Il est possible de modifier les propriétés des événements. Il est souvent utilisé pour définir des flags pour sauter certains traitements, par exemple pour empêcher le module QNA de faire un traitement lorsqu’il s’agit d’une réponse rapide.
After Incoming Middleware
Ce hook est appelé juste après que tous les middlewares entrants aient traité l’événement, mais avant que le moteur de dialogue ne commence à le traiter. Cela signifie que l’on a accès à toutes les données nécessaires (y compris l’intention de NLU) pour effectuer un traitement spécial et décider de ce qui se passe avec l’événement.
Before Outgoing Middleware
Ce hook est appelé avant que les réponses du bot ne soient envoyées à l’utilisateur.
Before Session Timeout
Ce hook est appelé juste avant un timeout utilisateur sur un nœud.
Before Suggestions Election
Ce hook est appelé après le classement du moteur de décision, mais avant l’élection de suggestion. Il permet de surcharger le classement du moteur de décision en modifiant directement le event.suggestions.
Sources
Botpress website, 2019
