Рік тому наш улюблений HR відділ звернувся з проханням: написати чат бота, який допоможе адаптувати новачків у компанії.
Обмовимося, що ми не розробляємо своїх товарів, але клієнтам надаємо повний спектр послуг з розробки. Розповідь піде про наш внутрішній проект, для якого замовником є не стороння компанія, а наш власний HR. І головне завдання при обмеженій доступності людей, ресурсів, часу виконати проект учасно та випустити продукт.
Для початку опишемо завдання, які треба було вирішити.
Розробники - люди здебільшого інтроверти і не люблять розмовляти, набагато простіше написати своє питання в електронному чаті. З ботом не треба думати, кого запитати, кому зателефонувати, куди йти і взагалі, де шукати інформацію, і чи актуальна вона.
Друга проблема це і є інформація — її багато, вона в різних джерелах, не завжди є і потребує постійного доповнення та оновлення.
У компанії майже 500 співробітників, вони знаходяться в різних офісах, часових поясах, містах Росії і навіть за кордоном, питань зазвичай дуже багато, тому ще одне завдання - знизити навантаження на HR персонал, пов'язану з найчастішими питаннями, що задаються співробітниками.
Необхідно було також автоматизувати процеси: приходу новачків до компанії, розсилки повідомлень менеджерам та наставникам новачків, відправки автоматичних нагадування про курси та тести, які необхідно пройти новачкові для успішної адаптації.
На основі бізнес-вимог були сформовані технічні.
Бот повинен працювати на основі Скайпа (історично так склалося, що користуються в компанії ним) тому обраний був сервіс на Азурі.
Для обмежень доступу до нього ми використали механізм авторизації через скайп.
Для розпізнавання тексту використовували бібліотеку ParlAI
Також необхідний адміністративний web портал для налаштування, навчання, налагодження, налаштування розсилок та інших завдань.
У процесі роботи над проектом ми зіткнулися з низкою проблем та складнощів.
Наприклад, були проблеми технічного характеру — з обліковим записом до Azure. Майкрософт ніяк не хотів активувати нашу підписку через якісь технічні складнощі всередині їхнього сервісу. Майже два місяці ми не могли нічого з цим зробити, підтримка Майкрософта зрештою розвела руками і відправила нас до партнерів, які успішно все налаштували та видали нам обліковий запис.
Найбільш складним етапом був старт проекту, коли потрібно вибрати, що використовуємо, яка буде архітектура, як і де зберігати дані і як компоненти та модулі системи взаємодіятимуть один з одним.
У нашому випадку, по суті, рядові проблеми старту будь-якого проекту ускладнювалися ще й стаффуванням кадрами. Специфіка нашого бізнесу така, що на відміну від комерційних, над внутрішніми проектами часто працюють розробники, які не мають достатніх знань у потрібних галузях – вони просто волею долі опинилися на лавці в очікуванні наступного великого крутого комерційного проекту. Логічно, що з мотивацією в такій ситуації справи теж були дуже непростими. Продуктивність падає низько, у команді часто простий, у результаті доводиться вмовляти (мотивувати) чи міняти людину. При зміні розробника потрібно проводити навчання, передавати знання та знову по суті стартувати проект. Кожен новий розробник бачив архітектуру по-своєму і лаяв попередніх за ухвалені ними рішення та чужий код. Починалося переписування з нуля.
Так тривало близько півроку. Ми просто тупцювали на місці, рефакторили код і нічого не писали нового.
Також на внутрішніх проектах, як правило, немає майже жодної документації, і важко було зрозуміти, що потрібно робити в кожний момент часу, і які зараз є пріоритетами. Потрібно було створити постійну команду, налагодити процеси, провести планування та оцінку хоча б на три місяці. Але як це зробити, коли проект не комерційний, а це означає, що людиногодини інвестувати потрібно за мінімумом, і при цьому результат отримати не гірше, ніж для зовнішнього замовника?
Ми визначили пул ресурсів, які брали участь у розробці проекту, знайомі з ним та хочуть над ним працювати. Склали розклад зайнятості людей на проектах. Провели оцінку та узгодження робіт, і вписали ці роботи у «дірки» між основними проектами. Через 4 місяці ми отримали робочий прототип програми.
Тепер давайте поговоримо докладніше про функціональність бота, про архітектуру та технічні рішення.
Однією з головних вимог HR було розпізнавання тексту, написаного користувачем для коректної відповіді питання. Йому можна написати — я хочу піти у відпустку, хочу у відпустку чи піти у відпустку, і вона зрозуміє та відповість відповідним чином. Або раптом у співробітника зламався стілець, і він хоче написати - «стул зламався» або «У мене стілець тріснув» або «Спинка у стільця відвалилася», при правильному навчанні робот розпізнає такі запити. Якість розпізнавання тексту залежить від навчання робота, про який ми поговоримо пізніше.
Наступною вимогою та частиною функціоналу є система діалогів бота. Була розроблена система, коли бот може вести діалог і розуміти контекст поточного питання. Він може у відповідь на ваше запитання поставити будь-які уточнюючі питання і продовжити розмову, якщо ми навчили робота зробити це. Скайп підтримує прості пункти меню для підказки користувачам про можливі варіанти продовження діалогів. Також якщо ми вели діалог, але раптом вирішили поставити питання не по темі, то робот теж це зрозуміє.
Робот дає можливість відправляти різні артефакти користувачеві, виходячи з його особистих даних. Наприклад, з його локації. Припустимо, якщо людина захотіла знайти туалет, то йому буде показано карту офісу, яка веде її до туалету. І карту буде обрано залежно від того, в якому офісі компанії знаходиться співробітник.
Одним із найважливіших завдань є захист особистої інформації користувачів. Ми не можемо дозволити кожній людині отримати доступ до конфіденційних даних, якими оперує наш бот. Необхідність авторизації для такого бота є невід'ємною його частиною. Робот просить у користувача пройти авторизацію перш, ніж він зможе вести з ним будь-який діалог. Це відбувається за першому зверненні співробітника до робота. Сама авторизація переадресує користувача на відповідну сторінку, де користувач отримує токен, який потім вставляє у скайп-повідомлення. Якщо авторизація проходить успішно, можна починати спілкування з ботом.
Авторизація проходить через скайп - портал-authorization service, корпоративну мережу та LDAP. Таким чином, авторизація залежить від поточних даних про користувача корпоративної мережі.
У процесі розробки робота ми зрозуміли, що потрібна система, вбудована в функціонал порталу, яка зможе допомогти HR виробляти швидке налагодження робота. Ми додали сторінку порталу, на якій HRи можуть побачити помилки, зафіксовані користувачами під час роботи з ботом і вирішити їх за допомогою перенавчання або залишити для розробників.
Можливість навчання робота просто на порталі не була закладена з самого початку. У процесі розробки ми зрозуміли, що навчання бота - це найчастіше завдання, яке виконуватимуть співробітники відділу HR під час роботи з ним, і надсилати файли з текстом розробникам для додаткового навчання бота абсолютно неприйнятно. Це з'їдає дуже багато часу і породжує занадто багато помилок та проблем.
Ми написали UI на порталі для User-frirendly навчання бота. Він дозволяє HR бачити поточне навчання бота, донавчати його та вносити корективи у поточне навчання. Навчання представлене деревоподібною структурою, в якій ноди, тобто гілки, є продовженням діалогу з ботом. Можна створювати прості запитання-відповіді, а можна важкі діалоги, все залежить від HR та їх потреб.
Декілька слів про архітектуру рішення.
Архітектура рішення модульна. У неї входять послуги, відповідальні різні завдання, саме:
• Сервіс скайп-бота на Azure — приймає та обробляє запити користувачів. Це досить простий сервіс, який першим приймає запит та здійснює його первинну обробку.
• Адмін портал — сервіс, що надає веб-інтерфейс для налаштування порталу та самого бота. Бот завжди звертається спочатку до порталу, а портал вже вирішує, що робити із запитом далі.
• Сервіс авторизації — надає механізми автентифікації для бота та адмін порталу. Авторизація відбувається за протоколом Oauth2. При позитивній авторизації сервіс проводить авторизацію в корпоративній мережі згідно з валідними даними користувача, тому система може контролювати помилки, пов'язані з розсинхроном даних.
• AI Модуль розпізнавання тексту, написаний на пітоні і використовуючи фреймворк ParlAI для розпізнавання тексту. Це нейронна мережа, принаймні у поточній реалізації. Ми використовуємо алгоритм tfDiff для розуміння питань. Модуль надає API для спілкування з ним та навчання.
На закінчення хочу сказати, що це наш перший досвід у створенні чат бота, і ми намагалися зробити систему якомога простіше, але при цьому функціональною, при мінімальних трудовитратах на неї. Думаю, у нас вийшов дуже цікавий продукт. Зі своєю системою навчання, логування помилок, розсилок повідомлень, так само його можна інтегрувати з будь-яким іншим меседжером.
Джерело: habr.com