A year ago, our beloved HR department asked us to write a chat bot that would help newcomers adapt to the company.
Let's make a reservation that we do not develop our own products, but we provide our clients with a full range of development services. The story will be about our internal project, for which the customer is not a third-party company, but our own HR. And the main task, with limited availability of people, resources, time, is to complete the project on time and release the product.
To begin with, we describe the tasks that had to be solved.
Developers are mostly introverts and do not like to talk, it is much easier to write your question in an electronic chat. With a bot, you donβt have to think about who to ask, who to call, where to go, and in general, where to look for information, and whether it is relevant.
The second problem is information - there is a lot of it, it is in different sources, it is not always available and needs to be constantly supplemented and updated.
The company has almost 500 employees, they are located in different offices, time zones, cities in Russia and even abroad, there are usually a lot of questions, so another task is to reduce the burden on HR staff associated with the most frequent questions asked by employees.
It was also necessary to automate the processes: the arrival of newcomers to the company, sending messages to managers and mentors of newcomers, sending automatic reminders about courses and tests that a newcomer needs to pass for successful adaptation.
Based on business requirements, technical requirements were formed.
The bot should work on the basis of Skype (historically, it happened that they use it in the company), so the service on Azura was chosen.
To restrict access to it, we began to use the authorization mechanism via Skype.
ParlAI library was used for text recognition
You also need an administrative web portal for configuration, training, debugging, mailing settings and other tasks.
In the process of working on the project, we encountered a number of problems and difficulties.
For example, there were technical problems - with an Azure account. Microsoft did not want to activate our subscription due to some technical difficulties within their service. For almost two months we could not do anything about it, Microsoft support eventually shrugged and sent us to partners who successfully set everything up and gave us an account.
The most difficult stage was the start of the project, when you need to choose what we will use, what the architecture will be, how and where to store data, and how the components and modules of the system will interact with each other.
In our case, in fact, the ordinary problems of starting any project were further complicated by staffing. The specifics of our business is such that, unlike commercial ones, developers often work on internal projects who do not have sufficient knowledge in the necessary areas - they just happened to be on the bench waiting for the next big cool commercial project. It is logical that with motivation in such a situation, things were also very difficult. Productivity drops low, the team is often simple, as a result, you have to persuade (motivate) or change a person. When you change the developer, you need to conduct training, transfer knowledge, and again essentially start the project. Each new developer saw the architecture in his own way and scolded the previous ones for their decisions and someone else's code. Rewriting started from scratch.
This went on for about half a year. We were just marking time, refactoring the code and not writing anything new.
Also, on internal projects, as a rule, there is almost no documentation, and it was difficult to understand what needs to be done at any given time, and what are the priorities now. It was necessary to create a permanent team, establish processes, conduct planning and evaluation for at least three months. But how to do this when the project is not commercial, which means that you need to invest man-hours to a minimum, and at the same time get the result no worse than for an external customer?
We have identified a pool of resources that have participated in the development of the project, are familiar with it and want to work on it. Compiled a schedule of employment of people on projects. We assessed and coordinated the work, and entered these works into the "holes" between the main projects. After 4 months, we received a working prototype of the application.
Now let's talk in more detail about the functionality of the bot, about the architecture and technical solutions.
One of the main requirements of HR was the recognition of text written by the user to correctly answer the question. You can write to him - I want to go on vacation, I want to go on vacation or I would like to go on vacation, and he will understand and answer accordingly. Or suddenly an employeeβs chair is broken, and he wants to write βthe chair is brokenβ or βMy chair is crackedβ or βThe back of the chair has fallen offβ, with proper training, the bot will recognize such requests. The quality of text recognition itself depends on the training of the bot, which we will talk about later.
The next requirement and part of the functionality is the bot dialog system. A system was developed in which the bot can conduct a dialogue and understand the context of the current issue. In response to your question, he can ask any clarifying questions and continue the conversation if we have trained the bot to do this. Skype supports simple menu items to prompt users for options to continue conversations. Also, if we had a dialogue, but suddenly decided to ask a question off topic, then the bot will also understand this.
The bot allows you to send various artifacts to the user based on his personal data. For example, at his location. Suppose if a person wants to find a toilet, then he will be shown a map of the office leading him to the toilet. And the card will be selected depending on which office of the company the employee is located in.
One of the most important tasks is the protection of personal information of users. We cannot allow every person to access the sensitive data that our bot operates on. The need for authorization for such a bot is an integral part of it. The bot asks the user to pass authorization before he can conduct any dialogue with him. This happens the first time an employee contacts the bot. Authorization itself redirects the user to the appropriate page, where the user receives a token, which he then inserts into a Skype message. If authorization is successful, then you can start communicating with the bot.
Authorization goes through Skype - portal-authorization service, corporate network and LDAP. Thus, authorization depends on the current data about the user in the corporate network.
During the development of the bot, we realized that we needed some kind of system built into the functionality of the portal that could help HR to quickly debug the bot. We have added a portal page where HRs can see the bugs reported by users while working with the bot and solve them with the help of retraining or leave them for developers.
The ability to train a bot right on the portal was not planned from the very beginning. During the development process, we realized that bot training is the most common task that HR employees will perform when working with it, and sending text files to developers for additional bot training is completely unacceptable. It eats up too much time and generates too many bugs and problems.
We wrote the UI on the portal for User-frirendly learning of the bot. It allows HR to see the current training of the bot, retrain it and make adjustments to the current training. Learning is represented by a tree structure, in which nodes, that is, branches, are a continuation of the dialogue with the bot. You can create simple questions and answers, or weighty dialogues, it all depends on HR and their needs.
A few words about the architecture of the solution.
The architecture of the solution is modular. It includes services responsible for various tasks, namely:
β’ Skype bot service on Azure - accepts and processes user requests. This is a fairly simple service that first receives a request and performs its initial processing.
β’ Admin portal - a service that provides a web interface for configuring the portal and for the bot itself. The bot always addresses the portal first, and the portal already decides what to do with the request next.
β’ Authorization service - provides authentication mechanisms for the bot and for the admin portal. Authorization occurs via the Oauth2 protocol. If authorization is positive, the service performs authorization in the corporate network according to valid user data, so that the system can control errors associated with out-of-sync data.
β’ AI A text recognition module written in python and using the ParlAI framework for text recognition itself. This is a neural network, at least in the current implementation. We use the tfDiff algorithm to understand questions. The module provides an API for communicating with it and learning.
In conclusion, I want to say that this is our first experience in creating a chat bot, and we tried to make the system as simple as possible, but at the same time functional, with minimal labor costs for it. I think we have a very interesting product. With its own learning system, error logging, notifications, it can also be integrated with any other messenger.
Source: habr.com