Преди година нашият любим HR отдел се обърна с молба: да напишем чат бот, който да помогне в адаптацията на новаците в компанията.
Нека уточним, че не разработваме собствени продукти, но предоставяме пълен спектър от услуги по разработка на клиентите. Разказът ще бъде за нашия вътрешен проект, за който поръчителят не е външна компания, а нашият собствен HR. Основната задача, при ограничена наличност на хора, ресурси и време, е да завършим проекта навреме и да пуснем продукта.
Първо ще опишем задачите, които трябваше да решим.
Разработчиците – предимно интроверти, не обичат да говорят, много по-лесно е да напишат въпроса си в електронен чат. С бота не е нужно да мислим кого да питаме, на кого да се обадим, къде да отидем и изобщо, къде да търсим информация и дали тя е актуална.
Втората проблема е именно информацията – тя е много, в различни източници, не винаги е налична и се нуждае от постоянно допълнение и актуализиране.
В компанията има почти 500 служители, те са в различни офиси, часови зони, градове в Русия и дори в чужбина, и обикновено има много въпроси, затова още една задача е да се намали натоварването на HR персонала, свързано с най-често задаваните въпроси от служителите.
Необходимо беше също така да автоматизираме процесите: настаняване на новаците в компанията, изпращане на съобщения до мениджърите и менторите на новаците, изпращане на автоматични напомняния за курсове и тестове, които новаците трябва да преминат за успешна адаптация.
На базата на бизнес изискванията бяха формулирани техническите.
Ботът трябва да работи на базата на Skype (исторически така се е получило, че в компанията го използват), затова беше избран услугата в Azure.
За ограниченията в достъпа започнахме да използваме механизъм за удостоверяване чрез Skype.
За разпознаване на текст използвахме библиотеката ParlAI.
Необходим е и административен уеб портал за настройка, обучение, отстраняване на грешки, настройка на разпращания и други задачи.
В процеса на работа по проекта се сблъскахме с цял ред проблеми и трудности.
Например, имаше технически проблеми с акаунта в Azure. Microsoft не искаше активира нашата абонаментна услуга поради някакви технически затруднения в техния сервис. Почти два месеца не можахме да направим нищо по този въпрос, а поддръжката на Microsoft в крайна сметка ни изпрати при партньори, които успешно конфигурираха всичко и ни предоставиха акаунта.
Най-трудният етап беше старта на проекта, когато трябваше да изберем какво да използваме, каква ще бъде архитектурата, как и къде да съхраняваме данните и как компонентите и модулите на системата ще взаимодействат помежду си.
В нашия случай обаче обикновените проблеми при старта на всеки проект се усложняваха допълнително от недостатъчно квалифицирани кадри. Спецификата на нашия бизнес е такава, че в отличие от комерсиалните проекти, много от разработчиците по вътрешните проекти често нямат достатъчни знания в необходимите области – те просто по волята на съдбата са се озовали на работа в очакване на следващия голям комерсиален проект. Логично е, че с мотивацията в такава ситуация нещата също не вървяха добре. Производителността беше ниска, в екипа имаше чести забавяния, затова трябваше да убеждаваме (или мотивираме) хората или да ги сменяме. При смяна на разработчика трябваше да проведем обучения, да предадем знания и отново по същество да стартираме проекта. Всеки нов разработчик виждаше архитектурата по свой начин и критизираше предходните за техните решения и код. Започваше пренаписването от нулата.
Така мина около полугодие. Просто останахме на място, рефакторираме кода и не написахме нищо ново.
Също така, по вътрешните проекти, обикновено, почти няма никаква документация, и беше трудно да се разбере какво точно трябва да се прави всеки момент, и какви са настоящите приоритети. Необходимо беше да се състави постоянен екип, да се наложат процеси и да се проведе планиране и оценка поне за три месеца. Но как да го постигнем, когато проектът не е комерсиален, а това означава, че инвестицията на човекочасове трябва да бъде минимална, и в същото време резултатът да бъде не по-лош от този за външен клиент?
Определихме набор ресурси, ангажирани в разработката на проекта, запознати с него и желаещи да работят по него. Създадохме график на заетостта на хората по проектите. Проведохме оценка и одобрение на работите, и вписахме тези работи в "дупките" между основните проекти. След 4 месеца получихме работещ прототип на приложението.
Сега нека да поговорим по-подробно за функционалността на бота, архитектурата и техническите решения.
Едно от основните изисквания на HR беше разпознаването на текста, написан от потребителя, за да може да се отговори правилно на въпроса. Може да се напише — искам да отида в отпуск, искам в отпуск или би отишъл в отпуск, и той ще разбере и ще отговори съответно. Или пък ако на служителя му е счупен стола и той иска да напише — "столът е счупен" или "Имам счупен стол" или "Обратната част на стола падна", при правилно обучение ботът ще разпознае такива заявки. Качеството на разпознаването на текста естествено зависи от обучението на бота, за което ще говорим по-късно.
Следващото изискване и част от функционалността е системата за диалози на бота. Бе разработена система, при която ботът може да води диалог и да разбира контекста на текущия въпрос. Той може в отговор на вашия въпрос да зададе уточняващи въпроси и да продължи разговора, ако сме обучили бота да го прави. Skype поддържа прости менюта, за да насочва потребителите относно възможните варианти за продължаване на диалозите. Също така, ако сме водили диалог и изведнъж решим да зададем въпрос извън темата, ботът също ще го разбере.
Ботът дава възможност за изпращане на различни артефакти на потребителя, основавайки се на личните му данни. Например, на неговата локация. Да предположим, че ако човек иска да намери тоалетна, ще му бъде показана карта на офиса, водеща го до тоалетната. И картата ще бъде избрана в зависимост от това в кой офис на компанията се намира служителят.
Една от най-важните задачи е защитата на личната информация на потребителите. Не можем да позволим на всеки да получи достъп до конфиденциални данни, с които работи нашият бот. Необходимостта от авторизация за такъв бот е неотменима част от него. Ботът иска от потребителя да премине авторизация, преди да може да проведе какъвто и да е диалог с него. Това се случва при първото посещение на служителя при бота. Сама авторизация пренасочва потребителя към съответната страница, където той получава токен, който после поставя в съобщение в Skype. Ако авторизацията премине успешно, може да започне общуването с бота.
Авторизацията протича през Skype — порталната услуга за авторизация, корпоративната мрежа и LDAP. Така авторизацията зависи от текущите данни за потребителя в корпоративната мрежа.
В процеса на разработка на бота осъзнахме, че е необходима система, вградена във функционалността на портала, която да помогне на HR да извършва бързо отстраняване на проблеми с бота. Добавихме такава страница на портала, където HR-ите могат да видят грешките, регистрирани от потребителите при работа с бота и да ги решат чрез дообучаване или да ги оставят за разработчиците.
Възможността за обучение на бота директно на портала не беше предвидена от самото начало. В процеса на разработка осъзнахме, че обучението на бота е най-честата задача, която служителите в HR отдела ще извършват, и изпращането на файлове с текст на разработчиците за допълнително обучение на бота е напълно неприемливо. Това отнема твърде много време и създава твърде много грешки и проблеми.
Създадохме UI на портала за удобно обучение на бота. Той позволява на HR да вижда текущото обучение на бота, да го дообучава и да прави корекции в настоящото обучение. Обучението е представено под формата на дървовидна структура, където възлите, тоест клоните, са продължения на диалога с бота. Могат да се създават прости въпроси-отговори, както и обширни диалози, всичко зависи от HR и техните нужди.
Няколко думи за архитектурата на решението.
Архитектурата на решението е модулна. В нея влизат услуги, отговарящи за различни задачи, а именно:
• Служба на Azure за Skype бот — приема и обработка запросов от потребителите. Това е достатъчно прост сервис, който първи приема заявките и извършва тяхната първоначална обработка.
• Администраторски портал — сервис, предоставящ уеб интерфейс за настройка на портала и самия бот. Ботът винаги се обръща първо към портала, а порталът вече решава какво да прави с заявката по-нататък.
• Служба за удостоверяване — предоставя механизми за аутентикация на бота и на администраторския портал. Удостоверяването става по протокола OAuth2. При положително удостоверяване, услугата провежда проверка в корпоративната мрежа на основата на валидни данни от потребителя, така че системата да може да контролира грешките, свързани с дисинхронизацията на данните.
• AI Модул за разпознаване на текст, написан на Python и използващ фреймуърка ParlAI за самото разпознаване на текста. Това е невронна мрежа, поне в текущата си реализация. Използваме алгоритма tfDiff за разбиране на въпросите. Модулът предоставя API за комуникация с него и за обучение.
В заключение, искам да кажа, че това е нашият първи опит в създаването на чат бот и се стараехме да направим системата възможно най-проста, но същевременно функционална, с минимални усилия. Мисля, че създадохме доста интересен продукт. С наша система за обучение, логиране на грешки, изпращане на известия, а също така може да се интегрира с всяко друго съобщител.
Източник: habr.com
