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