Hai un ano, o noso querido departamento de RRHH pediunos que escribisemos un chat bot que axudase á adaptación dos recén chegados á empresa.
Imos facer unha reserva de que non desenvolvemos os nosos propios produtos, pero ofrecemos aos clientes unha gama completa de servizos de desenvolvemento. A historia versará sobre o noso proxecto interno, para o que o cliente non é unha empresa allea, senón o noso propio RRHH. E a principal tarefa, dada a limitada dispoñibilidade de persoas, recursos e tempo, é completar o proxecto a tempo e lanzar o produto.
En primeiro lugar, imos describir os problemas que había que resolver.
Os desenvolvedores son na súa maioría persoas introvertidas e non lles gusta falar; é moito máis fácil escribir a túa pregunta nun chat de correo electrónico. Cun bot, non tes que pensar a quen preguntar, a quen chamar, a onde ir e, en xeral, onde buscar información e se é relevante.
O segundo problema é a información: hai moita, está en diferentes fontes, non sempre está dispoñible e precisa de adición e actualización constante.
A empresa ten case 500 empregados, están situados en diferentes oficinas, fusos horarios, cidades de Rusia e mesmo no estranxeiro, normalmente hai moitas preguntas, polo que outra tarefa é reducir a carga do persoal de RRHH asociada ás preguntas máis frecuentes. polos empregados.
Tamén foi necesario automatizar os procesos de: incorporación de recén chegados á empresa, envío de mensaxes a xestores e mentores de recén chegados, envío de recordatorios automáticos sobre cursos e probas que un recén chegado debe superar para unha adaptación exitosa.
Os requisitos técnicos formáronse en función dos requisitos empresariais.
O bot debe funcionar en base a Skype (históricamente úsano na empresa), polo que se escolleu o servizo en Azura.
Para restrinxir o acceso a ela, comezamos a utilizar o mecanismo de autorización a través de Skype.
Utilizouse a biblioteca ParlAI para o recoñecemento de textos
Tamén é necesario un portal web administrativo para a configuración, formación, depuración, configuración de correos e outras tarefas.
Mentres traballabamos no proxecto, atopamos unha serie de problemas e dificultades.
Por exemplo, houbo problemas técnicos cunha conta de Azure. Microsoft non quixo activar a nosa subscrición debido a algunhas dificultades técnicas no seu servizo. Durante case dous meses non puidemos facer nada ao respecto; o soporte de Microsoft finalmente botou as mans e enviounos a socios, que configuraron todo con éxito e déronnos unha conta.
A etapa máis difícil foi o inicio do proxecto, cando hai que elixir o que imos usar, cal será a arquitectura, como e onde almacenar os datos e como interactuarán os compoñentes e módulos do sistema entre si.
No noso caso, os problemas esencialmente ordinarios de iniciar calquera proxecto complicáronse aínda máis pola dotación de persoal. As características específicas do noso negocio son tales que, a diferenza dos comerciais, os proxectos internos adoitan ser traballados por desenvolvedores que non teñen coñecemento suficiente nas áreas requiridas; simplemente, por vontade do destino, acabaron no banco esperando o seguinte. gran proxecto comercial xenial. É lóxico que as cousas tamén fosen moi difíciles coa motivación nunha situación así. A produtividade baixa, o equipo adoita estar inactivo e, como resultado, hai que persuadir (motivar) ou cambiar a persoa. Ao cambiar de programador, cómpre realizar formación, transferir coñecementos e, esencialmente, comezar de novo o proxecto. Cada novo desenvolvedor viu a arquitectura ao seu xeito e reprochou aos anteriores polas decisións que tomaban e polo código alleo. A reescritura comezou desde cero.
Isto durou uns seis meses. Só estabamos marcando o tempo, refactorizando o código e non escribindo nada novo.
Ademais, nos proxectos internos, por regra xeral, case non hai documentación, e era difícil entender o que hai que facer en cada momento e cales son as prioridades actuais. Foi necesario crear un equipo permanente, establecer procesos e realizar planificación e avaliación durante polo menos tres meses. Pero como facelo cando o proxecto non é comercial, o que significa que cómpre investir un mínimo de horas de traballo e, ao mesmo tempo, obter o resultado non peor que para un cliente externo?
Identificamos un conxunto de recursos que participaron no desenvolvemento do proxecto, coñecen e queren traballar nel. Elaboramos un calendario para a inserción laboral de persoas en proxectos. Avaliamos e coordinamos o traballo, e encaixamos estes traballos nos "buratos" entre os principais proxectos. Despois de 4 meses recibimos un prototipo funcional da aplicación.
Agora imos falar con máis detalle sobre a funcionalidade, a arquitectura e as solucións técnicas do bot.
Un dos principais requisitos de RRHH era recoñecer o texto escrito polo usuario para responder correctamente á pregunta. Podes escribirlle: quero ir de vacacións, quero ir de vacacións ou quero ir de vacacións, e el entenderá e responderá en consecuencia. Ou de súpeto a cadeira dun empregado rompe e quere escribir "a cadeira está rota" ou "A miña cadeira está rachada" ou "O respaldo da cadeira caeu"; coa formación adecuada, o bot recoñecerá tales solicitudes. A calidade do recoñecemento de texto en si depende do adestramento do bot, do que falaremos máis adiante.
O seguinte requisito e parte da funcionalidade é o sistema de diálogo do bot. Desenvolveuse un sistema no que o bot pode dialogar e comprender o contexto do problema actual. En resposta á túa pregunta, pode facer preguntas aclaratorias e continuar a conversa se adestramos o bot para facelo. Skype admite opcións de menú simples para informar aos usuarios sobre as opcións para continuar as conversas. Ademais, se estivésemos dialogando, pero de súpeto decidimos facer unha pregunta fóra do tema, o bot tamén o entenderá.
O bot permite enviar varios artefactos ao usuario en función dos seus datos persoais. Por exemplo, na súa localización. Supoñamos que se unha persoa quere atopar un inodoro, amosaríalle un mapa da oficina que o conduciu ao baño. E a tarxeta seleccionarase en función da oficina da empresa na que se atope o empregado.
Unha das tarefas máis importantes é protexer a información persoal dos usuarios. Non podemos permitir que todas as persoas teñan acceso aos datos confidenciais que opera o noso bot. A necesidade de autorización para tal bot é parte integrante dela. O bot pídelle ao usuario que se autentique antes de que poida dialogar con el. Isto ocorre a primeira vez que un empregado contacta co bot. A propia autorización redirixe o usuario á páxina correspondente, onde o usuario recibe un token, que logo insire nunha mensaxe de Skype. Se a autorización ten éxito, pode comezar a comunicarse co bot.
A autorización realízase a través de Skype: servizo de autorización de portal, rede corporativa e LDAP. Así, a autorización depende dos datos actuais do usuario na rede corporativa.
No proceso de desenvolvemento do bot, decatámonos de que necesitabamos algún tipo de sistema integrado na funcionalidade do portal que puidese axudar a RH a depurar rapidamente o bot. Engadimos unha páxina do portal onde RH pode ver os erros rexistrados polos usuarios ao traballar co bot e resolvelos mediante a reciclaxe ou deixalos para os desenvolvedores.
A capacidade de adestrar un bot directamente no portal non se incluíu desde o principio. Durante o proceso de desenvolvemento, decatámonos de que adestrar o bot é a tarefa máis común que realizarán os empregados do departamento de RRHH cando traballen con el, e é completamente inaceptable enviar ficheiros de texto aos desenvolvedores para adestramento adicional do bot. Isto consume demasiado tempo e crea demasiados erros e problemas.
Escribimos unha IU no portal para o adestramento amigable do bot. Permite que RH vexa o adestramento actual do bot, adestralo e faga axustes no adestramento actual. O adestramento está representado por unha estrutura en árbore na que os nós, é dicir, as ramas, son unha continuación do diálogo co bot. Podes crear preguntas e respostas sinxelas, ou podes crear diálogos de peso, todo depende de RRHH e das súas necesidades.
Algunhas palabras sobre a arquitectura da solución.
A arquitectura da solución é modular. Inclúe servizos responsables de diversas tarefas, a saber:
• Servizo de bot de Skype en Azure: recibe e procesa as solicitudes dos usuarios. Este é un servizo bastante sinxelo que é o primeiro en recibir unha solicitude e realizar o seu tratamento inicial.
• Portal de administración: un servizo que proporciona unha interface web para configurar o portal e para o propio bot. O bot sempre contacta primeiro co portal e o portal decide que facer a continuación coa solicitude.
• Servizo de autorización: ofrece mecanismos de autenticación para o bot e para o portal de administración. A autorización realízase mediante o protocolo Oauth2. Con autorización positiva, o servizo realiza a autorización na rede corporativa segundo os datos válidos do usuario, para que o sistema poida controlar os erros asociados a datos fóra de sincronía.
• Módulo de recoñecemento de textos AI, escrito en Python e que utiliza o framework ParlAI para o propio recoñecemento de textos. Esta é unha rede neuronal, polo menos na súa implementación actual. Usamos o algoritmo tfDiff para entender as preguntas. O módulo proporciona unha API para comunicarse con el e aprender.
En conclusión, quero dicir que esta é a nosa primeira experiencia na creación dun bot de chat, e intentamos facer o sistema o máis sinxelo posible, pero ao mesmo tempo funcional, cun mínimo custo laboral. Creo que temos un produto moi interesante. Co seu propio sistema de adestramento, rexistro de erros, envío de notificacións, tamén se pode integrar con calquera outro mensaxeiro.
Fonte: www.habr.com