Il y a un an, notre cher département des ressources humaines a demandé : créer un chatbot qui aiderait à intégrer les nouveaux employés dans l'entreprise.
Précisons que nous ne développons pas de produits propres, mais nous offrons à nos clients une gamme complète de services de développement. Ce récit concerne notre projet interne, pour lequel le client n'est pas une entreprise externe, mais notre propre département RH. La principale tâche, dans un contexte de disponibilité limitée de personnes, de ressources et de temps, est de mener le projet à bien dans les délais et de lancer le produit.
Pour commencer, décrivons les tâches qui devaient être résolues.
Les développeurs sont en majorité des introvertis et n'aiment pas discuter. Il est beaucoup plus simple d'écrire sa question dans un chat électronique. Avec le bot, il n'est pas nécessaire de réfléchir à qui demander, à qui téléphoner, où aller et où trouver des informations, ni à leur actualité.
Le deuxième problème concerne l'information : elle est abondante, provient de diverses sources, n'est pas toujours disponible et nécessite des mises à jour constantes.
L'entreprise compte près de 500 employés, répartis dans différents bureaux, fuseaux horaires et villes de Russie, ainsi qu'à l'étranger. Il y a généralement beaucoup de questions, donc une autre tâche consiste à réduire la charge du personnel RH liée aux questions les plus fréquemment posées par les employés.
Il était également nécessaire d'automatiser les processus : l'arrivée des nouveaux employés dans l'entreprise, l'envoi de messages aux managers et aux mentors des nouveaux arrivants, et l'envoi de rappels automatiques concernant les cours et les tests que le nouveau doit suivre pour une intégration réussie.
Des exigences commerciales ont été formulées sous forme de spécifications techniques.
Le bot doit fonctionner sur Skype (historiquement, l'entreprise l'utilise), donc un service sur Azure a été choisi.
Pour les restrictions d'accès, nous avons commencé à utiliser un mécanisme d'autorisation via Skype.
Pour la reconnaissance de texte, nous avons utilisé la bibliothèque ParlAI.
Un portail web administratif est également nécessaire pour la configuration, l'apprentissage, le débogage, la gestion des envois et d'autres tâches.
Au cours du projet, nous avons rencontré une série de problèmes et de complexités.
Par exemple, il y avait des problèmes techniques avec le compte Azure. Microsoft ne voulait absolument pas activer notre abonnement en raison de certaines complexités techniques au sein de leur service. Pendant presque deux mois, nous n'avons pu rien faire à ce sujet, et au final, le support de Microsoft a haussé les épaules et nous a renvoyés vers des partenaires qui ont réussi à tout configurer correctement et à nous fournir un compte.
La phase la plus complexe a été le démarrage du projet, où il fallait choisir ce que nous allions utiliser, quelle serait l'architecture, comment et où stocker les données et comment les composants et les modules du système interagiraient entre eux.
Dans notre cas, les problèmes ordinaires liés au démarrage de tout projet étaient encore compliqués par le recrutement. La spécificité de notre entreprise est telle que, contrairement aux projets commerciaux, des développeurs qui n'ont pas suffisamment de connaissances dans les domaines nécessaires travaillent souvent sur des projets internes – ils se retrouvent là par hasard, en attendant le prochain grand projet commercial. Il est logique que la motivation dans une telle situation soit également assez difficile. La productivité peut chuter, des périodes d'inactivité se produisent souvent dans l'équipe, et il faut au final convaincre (motiver) ou changer la personne. Lors du changement de développeur, il est nécessaire de former, de transmettre des connaissances et encore une fois de repartir de zéro. Chaque nouveau développeur voyait l'architecture à sa façon et critiquait les décisions prises par les précédents et le code des autres. La réécriture commençait depuis le début.
Cela a duré environ six mois. Nous n'avons fait que stagner, refactoriser le code et n'avons rien écrit de nouveau.
De plus, dans les projets internes, il n'y a généralement presque pas de documentation, et il était difficile de comprendre ce qu'il fallait faire à chaque instant et quelles étaient les priorités. Il était nécessaire de créer une équipe permanente, d'organiser les processus, de planifier et d'évaluer au moins pour trois mois. Mais comment faire cela lorsque le projet n'est pas commercial, ce qui signifie qu'il faut investir le minimum d'heures-homme tout en obtenant un résultat pas moins bon que pour un client externe?
Nous avons défini un pool de ressources qui ont participé au développement du projet, qui le connaissent et qui souhaitent y travailler. Nous avons élaboré un planning d'occupation des personnes sur les projets. Nous avons effectué une évaluation et une validation des travaux, et nous avons intégré ces travaux dans les « créneaux » entre les projets principaux. Après 4 mois, nous avons obtenu un prototype fonctionnel de l'application.
Maintenant, parlons plus en détail des fonctionnalités du bot, de l'architecture et des solutions techniques.
L'une des principales exigences des ressources humaines était de reconnaître le texte écrit par l'utilisateur pour répondre correctement à la question. Il peut écrire - je veux partir en congé, je souhaite un congé ou j'aimerais partir en congé, et il comprendra et répondra en conséquence. Ou si un employé a un fauteuil cassé et veut écrire - « le fauteuil est cassé » ou « j'ai un fauteuil fendu » ou « le dossier du fauteuil s'est détaché », avec un bon apprentissage, le bot reconnaîtra de telles demandes. La qualité de la reconnaissance du texte dépend bien sûr de l'apprentissage du bot, dont nous parlerons plus tard.
La prochaine exigence et partie de la fonctionnalité est le système de dialogues du bot. Un système a été développé, permettant au bot de mener un dialogue et de comprendre le contexte de la question actuelle. Il peut, en réponse à votre question, poser des questions complémentaires et continuer la conversation, si nous avons appris au bot à le faire. Skype prend en charge des éléments de menu simples pour indiquer aux utilisateurs les options de poursuite des dialogues. De plus, si nous avons eu un dialogue mais que nous décidons soudain de poser une question hors sujet, le bot le comprendra également.
Le bot permet d'envoyer divers artefacts à l'utilisateur, en fonction de ses données personnelles. Par exemple, selon sa localisation. Supposons que si une personne souhaite trouver des toilettes, une carte du bureau lui sera montrée, la guidant vers les toilettes. Et la carte sera choisie en fonction du bureau dans lequel se trouve l'employé.
L'une des tâches les plus importantes est la protection des informations personnelles des utilisateurs. Nous ne pouvons pas permettre à tout le monde d'accéder aux données confidentielles traitées par notre bot. La nécessité d'une authentification pour un tel bot fait partie intégrante de son fonctionnement. Le bot demande à l'utilisateur de s'authentifier avant qu'il ne puisse engager un dialogue avec lui. Cela se produit lors de la première interaction d'un employé avec le bot. L'authentification redirige l'utilisateur vers la page appropriée, où il obtient un token qu'il insère ensuite dans le message Skype. Si l'authentification réussit, il peut commencer à communiquer avec le bot.
L'authentification se fait via Skype - le service d'autorisation du portail, le réseau d'entreprise et LDAP. Ainsi, l'authentification dépend des données actuelles sur l'utilisateur dans le réseau d'entreprise.
Dans le processus de développement du bot, nous avons compris qu'il était nécessaire d'avoir un système intégré dans la fonctionnalité du portail, qui pourrait aider les RH à déboguer rapidement le bot. Nous avons ajouté une telle page au portail, où les RH peuvent voir les erreurs signalées par les utilisateurs lors de l'utilisation du bot et les résoudre par un réapprentissage ou les laisser aux développeurs.
La possibilité d'entraîner le bot directement sur le portail n'était pas prévue dès le départ. Au cours du développement, nous avons réalisé que l'entraînement du bot est la tâche la plus courante que les employés des ressources humaines effectueront en travaillant avec lui, et envoyer des fichiers de texte aux développeurs pour un apprentissage supplémentaire du bot est totalement inacceptable. Cela prend trop de temps et engendre trop d'erreurs et de problèmes.
Nous avons écrit une interface utilisateur sur le portail pour un apprentissage convivial du bot. Elle permet aux RH de voir l'apprentissage actuel du bot, de l'améliorer et d'apporter des corrections à l'apprentissage en cours. L'apprentissage est présenté sous forme de structure arborescente, où les nœuds, c'est-à-dire les branches, sont des prolongements du dialogue avec le bot. Il est possible de créer des questions-réponses simples ou des dialogues plus complexes, tout dépend des RH et de leurs besoins.
Quelques mots sur l'architecture de la solution.
L'architecture de la solution est modulaire. Elle comprend des services responsables de différentes tâches, à savoir :
• Le service de bot Skype sur Azure reçoit et traite les demandes des utilisateurs. C'est un service assez simple qui reçoit en premier la demande et effectue son traitement initial.
• Le portail Administrateur — un service fournissant une interface web pour configurer le portail et le bot lui-même. Le bot se connecte toujours d'abord au portail, et c'est le portail qui décide ensuite quoi faire avec la demande.
• Service d'authentification — fournit des mécanismes d'authentification pour le bot et le portail Administrateur. L'authentification se fait via le protocole Oauth2. En cas d'authentification réussie, le service valide l'authentification dans le réseau d'entreprise selon les données valides de l'utilisateur, permettant ainsi au système de contrôler les erreurs liées à la désynchronisation des données.
• Module AI de reconnaissance de texte, écrit en Python et utilisant le framework ParlAI pour la reconnaissance de texte. C'est un réseau de neurones, du moins dans son implémentation actuelle. Nous utilisons l'algorithme tfDiff pour comprendre les questions. Le module fournit une API pour communiquer avec lui et l'entraîner.
En conclusion, je voudrais dire que c'est notre première expérience dans la création d'un chatbot, et nous avons essayé de rendre le système aussi simple que possible, tout en étant fonctionnel, avec un minimum d'effort de travail. Je pense que nous avons créé un produit assez intéressant. Avec son propre système d'apprentissage, de journalisation des erreurs, et d'envoi de notifications, il peut également être intégré à tout autre messager.
Source : habr.com
