Há um ano, nosso amado departamento de RH nos pediu para criar um chatbot que ajudasse na adaptação de novos funcionários na empresa.
Vamos esclarecer que não desenvolvemos produtos próprios, mas oferecemos uma gama completa de serviços de desenvolvimento aos nossos clientes. Esta história será sobre nosso projeto interno, cujo cliente não é uma empresa externa, mas nosso próprio RH. A principal tarefa, dado a disponibilidade limitada de pessoas, recursos e tempo, é concluir o projeto dentro do prazo e lançar o produto.
Para começar, descreveremos as tarefas que precisavam ser resolvidas.
Os desenvolvedores são, em sua maioria, introvertidos e não gostam de conversar. É muito mais fácil escrever sua pergunta em um chat eletrônico. Com o bot, não é necessário pensar em quem perguntar, a quem ligar, para onde ir e, no geral, onde procurar informações e se elas são atualizadas.
O segundo problema é a informação – há muita, ela vem de diferentes fontes, nem sempre está disponível e precisa ser constantemente complementada e atualizada.
Na empresa, há quase 500 funcionários que estão em diferentes escritórios, fusos horários, cidades da Rússia e até mesmo no exterior. Normalmente, há muitas perguntas, então mais uma tarefa é reduzir a carga sobre a equipe de RH relacionada às perguntas mais frequentes feitas pelos funcionários.
Foi necessário também automatizar os processos: a chegada de novos funcionários na empresa, o envio de mensagens para gerentes e mentores dos novos funcionários, e o envio de lembretes automáticos sobre cursos e testes que os novos funcionários precisam concluir para se adaptarem com sucesso.
Com base nos requisitos de negócios, foram formulados os requisitos técnicos.
O bot deve funcionar com base no Skype (historicamente, é a ferramenta utilizada na empresa), portanto, foi escolhido um serviço na Azure.
Para limitações de acesso, começamos a usar um mecanismo de autenticação via Skype.
Para reconhecimento de texto, utilizamos a biblioteca ParlAI.
Também é necessário um portal web administrativo para configuração, treinamento, depuração, configuração de envios e outras tarefas.
Durante o trabalho no projeto, nos deparamos com uma série de problemas e dificuldades.
Por exemplo, houve problemas técnicos relacionados à conta no Azure. A Microsoft não queria ativar nossa assinatura devido a algumas complicações internas em seu serviço. Fomos incapazes de resolver isso por quase dois meses, e o suporte da Microsoft acabou nos mandando para parceiros que conseguiram configurar tudo com sucesso e nos forneceram a conta.
A fase mais complexa foi o início do projeto, quando era necessário escolher o que usar, qual seria a arquitetura, como e onde armazenar os dados e como os componentes e módulos do sistema interagiriam entre si.
No nosso caso, problemas comuns do início de qualquer projeto foram ainda mais complicados pelo pessoal disponível. A especificidade do nosso negócio é tal que, ao contrário de projetos comerciais, em projetos internos frequentemente trabalham desenvolvedores que não têm conhecimentos suficientes nas áreas necessárias – eles simplesmente estão à espera de seu próximo grande projeto comercial. É lógico que a motivação nessa situação também era bastante difícil. O desempenho caiu drasticamente, a equipe frequentemente ficava parada, e, no final, era preciso convencer (motivar) ou trocar a pessoa. Ao trocar de desenvolvedor, é necessário realizar treinamento, transferir conhecimentos e, essencialmente, reiniciar o projeto. Cada novo desenvolvedor via a arquitetura à sua própria maneira e criticava os anteriores por suas decisões e o código de outros. Começava a reescrita do zero.
Isso se arrastou por cerca de seis meses. Ficamos parados, refatorando o código e não escrevendo nada de novo.
Além disso, em projetos internos, geralmente não há quase nenhuma documentação, e era difícil entender o que precisava ser feito a cada momento, assim como quais eram as prioridades atuais. Era necessário criar uma equipe permanente, estabelecer processos, realizar planejamento e avaliação pelo menos para os próximos três meses. Mas como fazer isso quando o projeto não é comercial, o que significa que os horas-homem devem ser minimizados, e ainda assim alcançar resultados que não sejam piores do que os exigidos para um cliente externo?
Definimos um conjunto de recursos envolvidos no desenvolvimento do projeto, que estão familiarizados com ele e desejam trabalhar nele. Elaboramos um cronograma de ocupação das pessoas nos projetos. Realizamos uma avaliação e concordamos sobre as tarefas, inserindo essas atividades nas "lacunas" entre os projetos principais. Após 4 meses, conseguimos um protótipo funcional do aplicativo.
Agora, vamos falar em detalhe sobre a funcionalidade do bot, sua arquitetura e as soluções técnicas.
Uma das principais exigências do RH era o reconhecimento de texto escrito pelo usuário para fornecer uma resposta adequada à pergunta. O usuário pode escrever — quero tirar férias, desejo férias ou gostaria de férias, e o bot compreenderá e responderá de acordo. Ou, caso um funcionário tenha quebrado a cadeira e queira reportar — "a cadeira quebrou" ou "minha cadeira rachou" ou "a parte de trás da cadeira se soltou", com o treinamento adequado, o bot reconhecerá tais solicitações. A qualidade do reconhecimento de texto depende, naturalmente, do treinamento do bot, que abordaremos mais tarde.
A próxima exigência e parte da funcionalidade é o sistema de diálogos do bot. Foi desenvolvida uma estrutura que permite ao bot manter diálogos e entender o contexto da pergunta atual. Ele pode fazer perguntas de esclarecimento em resposta à sua pergunta e continuar a conversa, desde que tenhamos treinado o bot para fazer isso. O Skype suporta opções de menu simples para orientar os usuários sobre possíveis formas de continuar os diálogos. Se estivermos conversando, mas de repente decidirmos fazer uma pergunta fora do tema, o bot também compreenderá isso.
O bot possibilita enviar diferentes artefatos para o usuário, com base em seus dados pessoais. Por exemplo, em relação à sua localização. Suponha que uma pessoa queira encontrar um banheiro; será exibido um mapa do escritório, direcionando-a até o banheiro. E o mapa será escolhido com base no escritório da empresa em que o funcionário se encontra.
Uma das tarefas mais importantes é proteger as informações pessoais dos usuários. Não podemos permitir que qualquer pessoa tenha acesso a dados confidenciais com os quais nosso bot opera. A necessidade de autorização para tal bot é uma parte essencial dele. O bot solicita que o usuário passe pela autorização antes que ele possa ter qualquer tipo de diálogo. Isso ocorre na primeira interação do colaborador com o bot. A própria autorização redireciona o usuário para a página correspondente, onde ele obtém um token que depois insere na mensagem do Skype. Se a autorização for bem-sucedida, é possível começar a interagir com o bot.
A autorização ocorre através do Skype — portal de serviço de autorização, rede corporativa e LDAP. Assim, a autorização depende dos dados atuais do usuário na rede corporativa.
Durante o processo de desenvolvimento do bot, percebemos que era necessária uma certa estrutura, integrada à funcionalidade do portal, que pudesse ajudar o RH a realizar a depuração rápida do bot. Adicionamos uma página ao portal onde os profissionais de RH podem ver os erros registrados pelos usuários ao interagir com o bot e corrigi-los por meio do re-treinamento ou deixá-los para os desenvolvedores.
A possibilidade de treinar o bot diretamente no portal não foi planejada desde o início. Durante o desenvolvimento, percebemos que o treinamento do bot é a tarefa mais frequente que os colaboradores do departamento de RH executarão ao trabalhar com ele, e enviar arquivos com texto para os desenvolvedores para treinamento adicional do bot é completamente inaceitável. Isso consome muito tempo e gera muitos erros e problemas.
Escrevemos uma interface de usuário no portal para o treinamento amigável do bot. Ela permite que os profissionais de RH vejam o treinamento atual do bot, realizem ajustes e façam correções no treinamento vigente. O treinamento é apresentado em uma estrutura de árvore, onde os nós, ou seja, os ramos, são extensões do diálogo com o bot. É possível criar perguntas e respostas simples, assim como diálogos extensos; tudo depende do profissional de RH e de suas necessidades.
Algumas palavras sobre a arquitetura da solução.
A arquitetura da solução é modular. Ela inclui serviços que são responsáveis por diversas tarefas, a saber:
• O serviço de bot do Skype na Azure — aceita e processa os pedidos dos usuários. É um serviço bastante simples, que recebe o pedido primeiro e realiza seu processamento inicial.
• Portal do administrador — serviço que fornece uma interface web para configurar o portal e para o próprio bot. O bot sempre se dirige primeiro ao portal, que então decide como proceder com o pedido.
• Serviço de autorização — fornece mecanismos de autenticação para o bot e para o portal do administrador. A autorização ocorre pelo protocolo Oauth2. Com uma autorização positiva, o serviço realiza a autenticação na rede corporativa de acordo com os dados válidos do usuário, permitindo que o sistema controle erros relacionados à desincronização de dados.
• Módulo AI de reconhecimento de texto, escrito em Python e utilizando o framework ParlAI para o reconhecimento de texto em si. É uma rede neural, pelo menos em sua implementação atual. Usamos o algoritmo tfDiff para entender as perguntas. O módulo fornece uma API para comunicação com ele e para treinamento.
Em conclusão, quero dizer que esta é nossa primeira experiência na criação de um chatbot, e nos esforçamos para tornar o sistema o mais simples possível, mas ao mesmo tempo funcional, com o mínimo de esforço necessário. Acredito que conseguimos criar um produto bastante interessante, com seu próprio sistema de aprendizado, registro de erros, envio de notificações e também pode ser integrado a qualquer outro mensageiro.
Fonte: habr.com
