Compétence B2B d'Alice: du prototype au premier rouble sauvé

Il n'y a pas si longtemps, à Saint-Pétersbourg, la deuxième conférence Conversations a eu lieu, consacrée à l'IA conversationnelle, au cours de laquelle j'ai eu la chance de parler en tant qu'orateur. Le sujet était de développer un prototype de compétence B2B pour une grande entreprise. Le rapport décrit comment ils ont réussi à «se faire des amis» avec les services Web relativement lents et l'infrastructure fermée de l'entreprise. Cela sera discuté sous la coupe.

Si soudain vous ne savez pas quelles sont les compétences d'Alice, regardez sous le spoiler: il décrit brièvement ce qui est quoi.

Idée

Comment tout a commencé? Le 13 mars 2018, ils ont annoncé les tests bêta de la plateforme Yandex.Dialogs (compétences d'Alice). À cette époque, beaucoup étaient déjà intéressés par l'assistant virtuel, ce qui signifie que c'était une excellente occasion de travailler avec un public assez large. L'idée d'un bot de discussion tourne dans ma tête depuis longtemps, j'ai donc décidé qu'il serait intéressant de faire des compétences dans son temps libre en fonction de cela. Et s'il peut également apporter des avantages au travail - ce sera généralement excellent.

Notre entreprise offre une gamme complète de services dans le domaine du tourisme d'affaires, ce qui signifie que vous pouvez faire une compétence qui aide l'utilisateur à partir en voyage d'affaires.
J'ai ensuite fait partie de l'équipe pour le développement d'une application mobile, avec laquelle vous pouvez trouver des options de vol et des hôtels pour les voyages d'affaires, et organiser celles qui conviennent. L'un des indicateurs clés, pour lesquels nous avons eu du mal à augmenter, était le nombre de téléchargements. L'idée est venue que si la compétence conduira les utilisateurs à l'application, elle nous aidera à augmenter ces indicateurs. Cela était nécessaire pour vérifier l'utilisation de ce projet.

Pour qu'une compétence soit utile à n'importe qui, elle doit résoudre une tâche spécifique de l'utilisateur. Dans ce cas, recherchez des options pour un voyage d'affaires. Autrement dit, la compétence doit recueillir des informations sur où aller et afficher les résultats dans une application mobile. Ainsi, l'utilisateur recevra les options souhaitées en utilisant une interaction vocale intéressante et continuera à travailler dans notre application, ce qui signifie que les développeurs recevront l'augmentation souhaitée des performances.

Il s'avère que la compétence devrait fonctionner quelque chose comme ceci: saluer l'utilisateur; le trouver par son nom; poser des questions de clarification et, ainsi, obtenir les paramètres de voyage nécessaires: villes (d'où et où) et dates. Affichez ensuite les paramètres reconnus. Si tout est correct, lancez la recherche et donnez un lien vers l'application.

Ressources et limites

Pour mener à bien sa tâche, la compétence doit interagir avec nos API internes et son service Web doit être publié quelque part. D'une part, il pouvait être mis en œuvre, mais, comme déjà mentionné, le développement se faisait en temps libre, donc je ne voulais pas dépendre de ressources d'entreprise spécialement allouées. Il fallait donc profiter de ce qui est disponible par défaut.

Par exemple, un serveur de test. Les développeurs ont suffisamment de droits pour y déployer une application Web, mais elle ne sera disponible que sur le réseau interne de l'entreprise, car le serveur ne dépasse pas. Dans le même temps, il a accès à Internet, ce qui signifie qu'il peut être utilisé.

Le service Web de compétences doit être accessible de l'extérieur (pour qu'Alice ait où envoyer les demandes), il doit donc être placé sur un hébergement externe.

Pour que la compétence remplisse sa tâche, vous avez besoin d'un service Web d'entreprise qui peut rechercher des profils et des villes et est accessible de l'extérieur. L'API d'application mobile convient à cela, bien qu'elle ait ses propres nuances. Ils consistent en ce que vous pouvez vous connecter à l'API pour le compte d'un seul utilisateur spécifique, ce qui signifie que la gamme de profils disponibles pour la recherche sera limitée. Et la chose la plus désagréable - les résultats d'une recherche lancée via l'API ne parviendront qu'à cet utilisateur. Néanmoins, il possède les fonctionnalités nécessaires, ce qui signifie que vous pouvez travailler avec.

Ainsi, la compétence sur l'hébergement externe interagira avec l'API. C'est bien sûr assez rapide, mais parfois, selon les résultats du test, la réponse n'arrive pas à arriver dans les 1500 ms requises (c'est l'exigence de la plateforme Yandex.Dialogs). Et afin d'envoyer toujours les résultats au bon utilisateur, vous devez exécuter un service de recherche en son nom, qui n'est disponible que sur le réseau interne. L'API, malheureusement, n'y aidera pas, ce qui signifie que vous devez en quelque sorte transférer la demande de la compétence directement à l'infrastructure interne.
Nous résoudrons ces problèmes dès qu'ils seront disponibles.

Les étapes Problèmes et solutions

Pour commencer, afin de mettre généralement en œuvre le scénario décrit, la compétence doit stocker l'état quelque part: stade, nom d'utilisateur, ville et date. Il n'y a pas beaucoup d'informations, vous ne devez donc pas déployer une base de données entière pour cela, d'autant plus qu'il y a trop de bruit avec elle. Vous pouvez stocker l'état dans le cache.

Le choix s'est porté sur Redis . Il s'est bien montré dans les tests de réponse, et nous l'utilisons également étroitement au travail, ce qui signifie qu'en cas de succès, ce projet peut être facilement transféré à l'entreprise (et au spoiler - nous l'avons déplacé). En tant que clé, vous pouvez utiliser l'identifiant utilisateur dans la compétence (indiqué dans la demande) et stocker les données d'état au format JSON dans la valeur. Une copie gratuite de Redis peut être déployée sur Heroku , et depuis un certain temps maintenant, elle est prise en charge dans Yandex.Cloud .

Nous allons maintenant analyser plus en détail les étapes de la compétence. Au tout premier démarrage, l'utilisateur voit la phrase de bienvenue habituelle. Ensuite, il doit nommer son nom, selon lequel la compétence recherchera un profil.



S'il existe, alors son nom doit être écrit dans l'état, et puisque le cache est utilisé, le reste des informations nécessaires sur le profil peut y être inséré. Maintenant, lorsque le client revient à la compétence, il verra un message d'accueil personnel. Si la même personne se connecte à partir d'un autre appareil et nomme son nom, son profil sera également trouvé dans le cache, ce qui signifie que nous éviterons de chercher à nouveau via l'API, ce qui permet de gagner du temps lors du traitement de la demande.

Ensuite, les paramètres de déclenchement sont reçus. En tant qu'utilisateur de compétences vocales, je veux nommer les villes et les dates comme je le veux, par exemple, «Peter» et «dans une semaine». La compétence doit être capable de reconnaître de telles phrases afin de transférer le nom complet de la ville dans l'API et d'effectuer une recherche le jour souhaité. Maintenant, le service Web de compétences reçoit immédiatement ces informations directement dans la demande:



Mais une telle fonctionnalité est apparue vers octobre 2018, et la compétence a été développée un peu plus tôt, donc Dialogflow a été choisi pour comprendre le langage naturel. Il dispose d'un excellent système de balisage, et de temps en temps, vous pouvez venir le former, indiquant ce que l'utilisateur voulait dire dans une phrase donnée.

Ainsi, le client nomme la ville et la date à sa manière, la compétence passe ses mots à Dialogflow et envoie le nom de la ville reconnue à l'API, d'où il reçoit l'identifiant nécessaire. La chaîne est longue et, par conséquent, ne répondra probablement pas aux 1500 ms requises.

La solution évidente est de mettre en cache. Et comme clé, vous pouvez spécifier exactement ce que l'utilisateur a dit, et dans le magasin de valeur l'identifiant de la ville de notre système. Ensuite, dans le cache, il peut y avoir plusieurs entrées pour une ville, par exemple, pour les mots "Peter" et "St. Petersburg". Mais cela n'est pas critique si la valeur n'indique pas trop d'informations. Dans tous les cas, cette approche permettra de remplir le cache avec des villes populaires demandées par d'autres utilisateurs, ou de «l'échauffer» à l'avance. Cela vous permettra d'utiliser Dialogflow et l'API moins fréquemment à l'avenir, ce qui vous fera gagner du temps.

L'étape la plus intéressante est de lancer la recherche. Il y a tous les paramètres nécessaires, mais pour que les résultats parviennent à la bonne personne, vous devez en quelque sorte «tirer» le service de recherche interne. De plus, la recherche elle-même prend un certain temps et les opérations à long terme sont mieux effectuées non pas dans le même service Web, mais dans une application distincte.

Il est temps d'utiliser le serveur disponible de l'entreprise. Sur celui-ci, vous pouvez déployer une application qui "récupérera" les informations de l'extérieur et effectuera des tâches à long terme, y compris le démarrage d'une recherche.

Une telle application pourrait bien être un service d'arrière-plan.

D'après le nom, il est clair qu'il s'agit d'une application sans interface utilisateur, qui devrait commencer son travail avec le démarrage du serveur et effectuer les actions prévues, ou des actions sur une commande spécifique (message). Nous organisons généralement un tel service sur le framework Topshelf , et il peut recevoir des commandes, par exemple, à partir d'une file d'attente de messages basée sur le protocole AMQP .

En bref, la file d'attente fonctionne comme ceci: il existe un courtier dans lequel les expéditeurs ajoutent des messages d'un certain type. Et il y a des lecteurs qui se connectent au courtier et obtiennent les informations nécessaires.
Une description plus détaillée peut être trouvée, par exemple, dans cet article .

Une bonne solution cloud a été trouvée sur Internet, fournissant une file d'attente de messages en tant que service - CloudAMQP . Il a un tarif gratuit, mais cela fonctionne de manière stable. Un autre argument pour son choix est que ce service fonctionne sur la base de RabbitMQ , que nous utilisons également fortement au travail.

Examinons donc le travail de la compétence dans son ensemble: le service Web de compétences interagit avec l'API d'application mobile et Dialogflow. Les résultats de leurs appels sont mis en cache dans Redis et l'état y est stocké. Après avoir confirmé les paramètres du voyage, la compétence envoie un message au courtier avec toutes les informations nécessaires. Le service d'arrière-plan du serveur de test s'y connecte et lorsqu'un message apparaît, démarre la recherche et les résultats sont envoyés à l'application mobile.


Lorsque le client le télécharge et l'installe, il les trouvera dans ses requêtes:



Ceci termine le travail de la compétence.

Résumé

Que s'est-il passé ensuite? Cette compétence a été montrée à plusieurs clients pour des commentaires, et voici ce que nous avons découvert: les utilisateurs eux-mêmes hésitent à passer à une application mobile, peu importe à quel point c'est cool. Il est plus facile pour certains d’appeler notre agent au téléphone et de lui demander de chercher ce dont il a besoin.

Comme le montre la pratique, dans ce cas particulier, les utilisateurs sont plus intéressés à interagir avec un assistant vocal. Dans ce cas, il remplace l'agent, ce qui lui permet de gagner un peu de temps et motive en même temps les clients à télécharger l'application afin de continuer à travailler avec des options.

Il s'avère que, grâce à la compétence, il est possible d'économiser certaines ressources et d'augmenter certains indicateurs clés, c'est-à-dire que l'hypothèse du bénéfice de la compétence pour notre entreprise a été confirmée.

Je voudrais souligner quelques conclusions. Évident: pour suivre 1500 ms, évitez de faire des demandes inutiles de services web, cache. Vous pouvez utiliser différentes clés de cache pour les mêmes informations. Cela est justifié si au moins une personne pénètre dans le cache généré par un autre utilisateur. Et surtout: il est préférable d'effectuer de longues opérations dans un service d'arrière-plan distinct: outre le fait qu'il assure la décentralisation des compétences, il aura moins de problèmes de multithreading et, si nécessaire, il peut être "déployé" à l'intérieur du réseau fermé de l'entreprise et "capter" des messages de l'extérieur.

Au lieu d'un épilogue

Les chatbots et les compétences sont souvent écrits en JavaScript et Python (à en juger par le nombre de référentiels sur GitHub pour «chatbot»). Cela est également dû à la publication facile sur le serveur. Ce projet a été écrit en C # sous le noyau .net. Dans le cas du framework .net classique, la publication présente certaines difficultés (il fonctionne principalement sous Windows, etc.), mais beaucoup de choses ont changé avec l'avènement du core .net. Pour chaque service ou cadre mentionné ci-dessus, il existe des bibliothèques qui prennent entièrement en charge cette technologie. Grâce à cela, la compétence peut potentiellement être exécutée sur des serveurs Linux, et plus encore sur tout hébergement prenant en charge Docker. Si tout à coup vous êtes dans une recherche créative, je vous recommande de faire attention à ce framework, il devient une bonne alternative pour développer des robots de chat.

PS
UPD 08/01/2019: à partir de maintenant, le délai d'attente pour les compétences est de 3 secondes .