Бот нам поможет

image
Год назад наш любимый HR отдел обратился с просьбой: написать чат бота, который поможет в адаптации новичкам в компании.

Тут надо сказать сразу, что мы не разрабатываем собственных продуктов, но для клиентов оказываем полный спектр услуг по разработке. Рассказ пойдет о нашем внутреннем проекте – продукте, для которого заказчиком является не третьесортная компания, а наш собственный HR. И главная задача при отсутствии людей, ресурсов, времени его выполнить.

Для начала опишем задачи которые предстояло решить.
Разработчики — люди в большинстве своём интроверты и не любят разговаривать, гораздо проще написать свой вопрос в электронном чате. К тому же не надо думать, кого спросить, кому позвонить, куда идти и вообще где расположена информация и актуальная ли она.
Вторая проблема это и есть эта информация, информации много, она в разных источниках, не всегда есть вообще в принципе и более того она нуждается в постоянном дополнении и обновлении.
В компании много сотрудников, они находятся в разных офисах, в разных часовых поясах, в разных городах России и даже за рубежом, вопросов обычно очень много, поэтому еще одна задача — это снизить нагрузку на HR персонал, связанную с наиболее частыми вопросами, задаваемыми сотрудниками.
Необходимо было также автоматизировать процессы: прихода новичков в компанию, рассылки сообщений менеджерам и наставникам новичков, отправки автоматических напоминаний о курсах и тестах, которые необходимо пройти новичку для успешной адаптации.

На основе бизнес требований были сформированы технические.
Бот должен работать на основе Скайпа (исторически так сложилось, что пользуются в компании им) поэтому выбран был сервис на Азуре.
Для ограничений доступа к нему мы стали использовать механизм авторизации через скайп.
Для распознавания текста использовали библиотеку Парл AI.
Так же необходим административный web портал для настройки, обучения, отладки, настройки рассылок и других задач.
image

В процессе работы над проектом мы столкнулись с целым рядом проблем и сложностей.

Например, были проблемы технического характера, к примеру, с аккаунтом к Азур.
Майкрософт никак не хотел активировать нашу подписку из-за каких-то технических сложностей внутри их сервиса. Почти два месяца мы не могли ничего с этим сделать, поддержка Майкрософта в итоге развела руками и отправила нас к партнерам, которые успешно все настроили и выдали нам аккаунт.

Наиболее сложным этапом был старт проекта, когда нужно выбрать, что используем, какая будет архитектура, как и где хранить данные и как компоненты и модули системы будут взаимодействовать друг с другом.

В нашем случае по сути рядовые проблемы старта любого проекта осложнялись еще и стаффированием кадрами. Специфика нашего бизнеса такова, что в отличие от коммерческих, над внутренними проектами часто трудятся разработчики, у которых нет достаточных знаний в нужных областях – они просто волею судьбы оказались на лавке в ожидании следующего большого крутого коммерческого проекта. Логично, что с мотивацией в такой ситуации дела обстояли тоже весьма непросто. Производительность падает низко, в команде часто простой, в итоге приходится уговаривать (мотивировать) или менять человека. При смене разработчика нужно проводить обучение, передавать знания и опять по сути стартовать проект. Каждый новый разработчик видел архитектуру по-своему и ругал предыдущих за принятые ими решения и чужой код. Начиналось переписывание с нуля.
Так продолжалось около полугода. Мы просто топтались на месте, рефакторили код и ничего не писали по сути нового.

Также на внутренних проектах как правило нет почти никакой документации, и сложно было понять, что нужно делать в каждый момент времени и какие сейчас приоритеты. Необходимо было создать постоянную команду, наладить процессы, провести планирование и оценку хотя бы на три месяца. Но как это сделать, когда проект не коммерческий, а это значит людские и временные ресурсы инвестировать нужно по минимуму, и при этом результат получить не хуже, чем для внешнего заказчика?

Мы определили пул ресурсов, которые участвовали в разработке проекта, знакомы с ним и хотят над ним работать. Составили расписание занятости людей на проектах. Провели оценку и согласование работ, и вписали эти работы в «дырки» между основными проектами. Через 4 месяца такой работы мы получили рабочий прототип приложения.

Теперь давайте поговорим подробнее о функциональности бота, об архитектуре и технических решениях.

Одним из главных требований HR было распознавание текста, написанного пользователем для корректного ответа на вопрос. Ему можно написать — я хочу пойти в отпуск, хочу в отпуск или пойти бы в отпуск, и он поймет и ответит соответствующим образом. Или вдруг у сотрудника сломался стул, и он хочет написать — «стул сломался» или «У меня стул треснул» или «Спинка у стула отвалилась», при правильном обучении бот распознает такие запросы. Качество распознавания текста само собой зависит от обучения бота, о котором мы поговорим позднее.

Следующим требованием и частью функционала является система диалогов бота. Была разработана система, при которой бот может вести диалог и понимать контекст текущего вопроса. Он может в ответ на ваш вопрос задать какие-либо уточняющие вопросы и продолжить разговор, если мы обучили бота сделать это. Скайп поддерживает простые пункты меню для подсказки пользователям о возможных вариантах продолжения диалогов. Также если мы вели диалог, но вдруг решили задать вопрос не по теме, то бот тоже это поймет.

Бот также дает возможность отправлять различные артефакты пользователю, основываясь на его личных данных. К примеру, на его локации. Например, если человек захотел найти туалет, то ему будет показана карта офиса ведущая его в туалет. И карта будет показана в зависимости от того, в каком офисе компании находится сотрудник.

Одной из важнейших задач является защита личной информации пользователей, мы не можем позволить каждому человеку получить доступ к конфиденциальным данным, которыми оперирует наш бот. Необходимость в авторизации для такого бота является неотъемлемой его частью. Бот просит у пользователя пройти авторизацию прежде, чем он сможет вести с ним какой либо диалог. Это происходит при первом обращении сотрудника к боту. Сама авторизация переадресует пользователя на страничку Авторизации, где пользователь получает токен, который потом вставляет в скайп-сообщение. Если авторизация проходит успешно, то можно начинать общение с ботом.


Авторизация проходит через скайп — портал- authorization service, корпоративную сеть и LDAP. Таким образом авторизация зависит от текущих данных о пользователе в корпоративной сети.

В процессе разработки бота мы поняли, что нужна некая система, встроенная в функционал портала, которая сможет помочь HR производить быструю отладку бота. Мы добавили такую страницу портала, на которой HRы могут увидеть ошибки, зафиксированные пользователями при работе с ботом и решить их с помощью переобучения или оставить для разработчиков.

Обучение. Возможность обучения бота прямо на портале не была заложена с самого начала. В процессе разработки мы поняли, что обучение бота это самая частая задача, которую будут выполнять сотрудники отдела HR при работе с ним, и что кидать файлики текста разработчикам для до обучения бота совершенно неприемлемо. Это съедает слишком много времени и порождает слишком много ошибок и проблем.
image
Мы написали UI на портале для User-frirendly обучения бота. Он позволяет HR видеть текущее обучения бота, до обучать его и вносить коррективы в текущее обучение. Обучение представлено древовидной структурой, в которой ноды, то есть ветви являются продолжением диалога с ботом. Можно создавать простые вопросы-ответы, а можно увесистые диалоги, все зависит от HR и их нужд.

Несколько слов об архитектуре решения.

image
Архитектура решения модульная. В нее входят сервисы, отвечающие за различные задачи, а именно:
• Сервис скайп бота на азуре — принимает и обрабатывает запросы пользователей. Это достаточно простой сервис, который первым принимает запрос и производит его первичную обработку.

• Админ портал — сервис предоставляющий веб интерфейс для настройки портала и для самого бота. Бот всегда обращается сначала к порталу, а портал уже решает, что делать с запросом дальше.

• Сервис авторизации — как несложно догадаться, этот сервис предоставляет механизмы аутентификации для бота и для админ портала. Авторизация происходит по протоколу Oauth2. При авторизации сервис проводит авторизацию в корпоративной сети согласно с валидными данными пользователя, так что может контролировать ошибки, связанные с рассинхроном в данных и прочее.

• AI Модуль — модуль распознавания текста, написанный на питоне и использующий Фреймворк ParlAI для самого распознавания текста. Это нейронная сеть, по крайней мере в текущей реализации. Мы используем алгоритм tfDiff для понимания вопросов. Модуль предоставляет API для общения с ним и обучения

В заключение хочу сказать, что это наш первый опыт в создании чат бота и мы старались его сделать как можно проще. Думаю у нас получился весьма интересный продукт. Хотя понимаю, что многие скажут, что простой веб сайт решает все поставленные задачи, и бот для телеграмма пишется намного быстрее и легче… Но мы сделали то, что сделали и очень хочется, что бы этот опыт был тоже кому то полезен.
Источник: habr.ru