Une plateforme permettant de gérer des chatbots doit être robuste et flexible afin de traiter un nombre de messages important avec parfois des pics. Pour les chatbots QANTIS, nous avons opté pour une plateforme basée sur des microservices, c’est à dire que chaque partie de l’application a son propre rôle indépendant.
Dans cet article, nous allons donc détailler chaque étape du traitement du message afin de mettre en avant les différentes problématiques que peut rencontrer une plateforme permettant de gérer des centaines de chatbots.
Quels sont les différents types de messages sur un chatbot ?
Nous considérons qu’il y a quatre types de messages. Le premier qui vient naturellement quand on parle de chatbots, c’est le message utilisateur. Ce message est envoyé par un utilisateur du chatbot à partir d’une plateforme gérée par le chatbot QANTIS.
Suite à un message utilisateur, le chatbot doit répondre, le second type de message est donc le message du bot.
Cette réponse peut être envoyée par le chatbot mais pas seulement, un humain peut aussi prendre la main (escalade) sur le chatbot et répondre à l’utilisateur, ces messages sont appelés messages opérateur et sont le troisième type de message.
Un dernier type de message existe, les notifications. Ce message est différent des messages du chatbot car il n’est pas déclenché suite à un message utilisateur, celui-ci est programmé pour être envoyé plus tard. Cette notification peut servir à envoyer des informations à l’utilisateur dans le but de relancer une conversation.
Que fait-on lors de la réception d’un message ?
Afin de recevoir les messages, il a fallu mettre en place ce qu’on appelle un webhook, c’est un microservice qui est capable de réceptionner les messages venant d’une plateforme externe (site web, messenger, whatsapp, etc) sur une url renseignée au préalable dans la configuration. C’est donc un microservice qui est exposé aux différentes plateformes.
Pour que celui-ci soit toujours disponible, nous avons mis en place une stratégie de déploiement qui nous permet d’avoir toujours au moins un webhook fonctionnel. En cas de surcharge du microservice, nous sommes dans la capacité d’augmenter le nombre de webhook pour pouvoir absorber la charge, c’est ce qu’on appelle, la scalabilité.
Une fois un message reçu, sur un des endpoint du webhook, nous vérifions la qualité du message, en répondant à plusieurs questions :
- Est-ce qu’il a bien été envoyé par une plateforme et pas par une personne malveillante ?
- Est-ce qu’il est formaté correctement ?
- Est-ce que l’utilisateur n’a pas été bloqué par le bot ?
- Est-ce que ce n’est pas du spam ?
- Est-ce qu’un bot est associé à ce message ?
Si nous pouvons répondre “oui” à toutes ces questions, le message est placé dans une queue de messages afin d’être traité par la suite par un autre microservice. Ce système permet de séparer la réception du traitement afin d’augmenter notre résistance à une forte charge.
Qu’arrive-t-il aux messages du chatbot une fois reçus?
Lorsqu’un message dans la queue est prêt à être traité, un autre microservice appelé worker s’occupe de le récupérer. Ce microservice s’occupe de toute la partie traitement du message. Ce traitement pouvant être long, nous déployons plusieurs worker afin de pouvoir paralléliser le traitement de plusieurs messages. Ils seront donc traités en même temps et indépendamment. Là encore, dans le cas d’une forte charge ce microservice est scalable.
Le message récupéré par le worker passe donc par plusieurs étapes, la première étant l’analyse par notre brique d’analyse du langage naturel. Pour ce faire, nous avons développé un microservice en interne qui permet pour une phrase envoyée de nous retourner toutes les intentions et les entités trouvées à l’intérieur.
Ce microservice est indépendant. Comme les microservices précédemment énoncés, celui-ci est scalable, il n’est pas exposé sur internet mais dans le réseau privé de QANTIS, il est placé derrière un load balancer qui permet suite à la scalabilité du microservice de dispatcher correctement les différentes requêtes.
Nous distinguons deux requêtes qui sont faites à ce microservice :
- La première permet de prédire les intentions liées aux messages. La phrase envoyée au chatbot QANTIS est transformée en vecteur puis est transmise aux modèles de machine learning. L’avantage d’utiliser cet outil, est qu’il est indépendant du reste de notre infrastructure et nous permet de gagner en flexibilité et en robustesse.
- La seconde permet de prédire les entités. Il y a deux méthodes pour les définir, la première via le microservice Duckling qui fait de la reconnaissance d’expressions régulières sur des patterns connus (email, date, url…). Et la seconde méthode consiste à faire de l’analyse sur des entités spécifiques via différentes méthodes et modèles de machine learning.
Suite à cette analyse, le worker va essayer de trouver une correspondance avec une réponse, par rapport aux intentions détectées et en fonction de la configuration du bot stockée dans la base de données. Cette réponse sera ensuite envoyée à l’utilisateur, ce sera donc un message du bot.
Comment est envoyée la réponse du chatbot ?
Après avoir trouvé une correspondance à envoyer à l’utilisateur, le worker effectue une dernière étape qui est le formatage du message. Les messages envoyés par le bot pouvant être dynamiques, nous avons mis en place un outil nous permettant de rendre la partie dynamique encore plus intéressante. Et ce grâce à un microservice serverless. Ce microservice permet de faire des requêtes externes comme par exemple appeler une API afin de récupérer des informations pour les incorporer dans le message. Mais ce microservice permet aussi de faire des requêtes à l’intérieur de notre infrastructure, comme par exemple appeler un autre microservice interne que nous avons nommé Lambda API.
Une fois le travail du worker terminé et la réponse correctement formatée, nous envoyons ce message au sender. Ce microservice là encore indépendant, est aussi asynchrone, c’est à dire que lorsque l’on envoie un message, le programme peut traiter d’autre messages, il n’est pas bloqué par l’attente de la réponse comme dans le cas d’une requête synchrone. Cela permet en cas de charge de traiter un nombre important de messages sans issues de bots différents, sans pour autant pénaliser les bots.
Les messages de notification sont aussi envoyés par le sender, mais avant ça ils sont traités par un microservice de notifications qui récupère les messages à envoyer puis les prépare selon le bon format en fonction de la plateforme sur laquelle on va envoyer le message et ensuite ce microservice le transmet au sender.
Voilà, vous savez (presque) tout sur le fonctionnement de notre plateforme chatbot ! C’est grâce à cette infrastructure que nous sommes en mesure de déployer de nombreux chatbots qui fonctionnent en simultané tout en étant éditable en temps réel via notre outil QANTIS Bot Builder.
N’oubliez pas…
La mise en place d’un agent conversationnel nécessite :
