Привет! Меня зовут Александр, я главный системный аналитик в департаменте по работе с данными «Магнита». В прошлый раз в статье Как мы с минимальный затратами создали каталог данных на хранилищем мы упомянули виртуального помощника (чат‑бота) — ещё одно наше детище, которое помогает пользователям корпоративного хранилища данных (КХД) ориентироваться в данных и сервисах департамента и других подразделений, развивающих инструменты для аналитики.

Функциональность бота мы разделяем на три сценария: 

• Навигационный (задача решается ботовой платформой);

• Регистрация запросов пользователей (как мы решили вопрос с ограниченными лицензиями Jira; система рекомендаций для исполнителей);

• Помощь в поиске данных (алгоритм для поиска данных на основе метаданных — в дополнение к нашему Каталогу витрин КХД).

Подробнее о том, как работает чат-бот, читайте в статье.  

Немного об инфраструктуре и технологиях

Чат-бот реализован на платформе CraftTalk, с которой общаются пользователи из внешних сетей: Telegram, MS Teams и web-виджетов. Web-бот мы встроили в нашу базу знаний на Confluence и дэшборд на QlikSense. Например, чтобы встроить бота в Confluence, нужно было просто добавить макрос HTML на страницы пространства и зафиксировать код:  

<link rel="stylesheet"
      href="https://virtual-assistant.magnit.ru/assets/css/webchat_datagov">
<script>
    window.__WebchatUserCallback = function () {
        return {
            "uuid": AJS.params.remoteUser,
            "first_name": AJS.params.currentUserFullname,
            "sys_fio": AJS.params.currentUserFullname,
            "ADFS_login": AJS.params.remoreUser,
            "ADFS_email": AJS.params.remoteUser + "@magnit.ru"
        };
    };
</script>
<script src="//virtual-assistant.magnit.ru/assets/js/webchat_datagov"></script>

В ядре платформы бота создаются ветки меню, по которым перемещается пользователь (навигационный сценарий). При этом созданная разработчиком ветка сразу отображается и в Telegram, и в MS Teams, и в виджетах: кросс‑платформенность — это очень удобно!

Логика простых веток зашита в сценарии платформы.

А вот для выполнения сложных сценариев мы сделали API сервер на Python (FastAPI).

В свою очередь API сервер:

• Ищет информацию по вопросу пользователя в БД на PostgreSQL;

• Туда же делает записи о вопросах и отданных ответах;

• Отправляет заявки в поддержку в Jira.

Информация в БД бота в большинстве своём поступает из нашего КХД при помощи Informatica PC. По началу мы пробовали ходить напрямую в КХД из API сервера, чтобы искать ответ на вопрос пользователя, но при таком варианте сильно снижается скорость ответа. API сервер мы разместили в Яндекс Облаке.

Подробнее о наших разработках функциональности 

Запросы доступа к КХД

Пользователи получают доступ к данным КХД через ролевую модель. Но использовать его могут для разных целей: чтобы обращаться к данным напрямую (писать sql‑запросы) или чтобы просто использовать готовую отчётность, которая строится на этих данных. Разные цели и разные типы пользователей = разный уровень погружения в технологии и процессы (например, необходимые согласования для выдачи той или иной роли). Бот создаёт единую точку входа для всех типов пользователей и координирует процессы запроса и получения доступа с учётом всех требований к ним.

Для лучшего понимания делимся с вами макетом части ветки по доступам.

Что именно делает бот? 

• Определяет «тип пользователя» и направляет его в нужную ветку (сценарий);

• Проверяет, какие роли в КХД нужны для доступа к конкретному объекту и каких из них не хватает пользователю;

• Может рассказать пользователю, какие роли у него есть;

• Проверяет наличие необходимых доменных групп (LDAP) у пользователя (доменные группы используются для доступа к отчётам);

• Регистрирует задачу в Jira на ответственное за предоставление доступа подразделение;

• Добавляет в наблюдатели и просит согласовать предоставление доступа всех владельцев ролей, чьего согласования не хватает.

Поиск по КХД

У бота можно спросить, где лежит определённая информация, и он отдаст список витрин, максимально подходящих под запрос. К примеру, доставка заказов. 

Как это работает?  

На входе запрос может быть похож либо на набор полей, которые интересуют пользователя, либо на описание витрины. При этом текст может быть как на русском, так и на английском. Текст пользователя преобразуется в нижний регистр, удаляются знаки препинания и окончания слов, строка разбивается по словам на токены. После этого происходит полнотекстовый поиск по метаинформации из КХД (описание витрин/колонок). Если по всем токенам поиск был неуспешный, то происходят попытки найти частичные совпадения. На выходе результат сортируется по успешности поиска и возвращается пользователю списком имя + описание витрины. 

Обращение в поддержку

Если кратко: пользователь отвечает на вопросы бота, который регистрирует задачи в Jira (в нашем случае это либо запрос на информацию, либо инцидент).

Выбор исполнителя по задачам в Jira происходит следующим образом: 

• Если пользователь указал витрину, то по ней ищем ответственное направление.

• Пользователь сам выбирает, в какое направление отправить заявку, к примеру «Ассортимент».

К направлению (оно же компонент в Jira) привязан исполнитель по умолчанию:

После регистрации задачи бот добавляет инициатора в «наблюдатели». Если пользователя нет в Jira, вместо наблюдателей используется кастомное поле «Заинтересованные лица» (в нём фиксируется email инициатора запроса), которое реализует те же возможности.

После этого через комментарии происходит общение между исполнителем и инициатором. Нелицензированные пользователи (те, кто не работает в Jira) отвечают на письма от Jira, а текст их письма падает в заявку. Для этого используется стандартный механизм Jira по обработке входящих писем, плагин ScriptRunner, который позволил написать свой собственный обработчик с необходимой логикой и кастомный listener для уведомления нелицензированных пользователей об изменениях в заявке (Groovy + html + css для шаблона ответа).

Так мы решили проблему с ограничениями по лицензиям Jira, ведь она есть не у всех, и сделали альтернативу Jira Help Desc, которая закрывает наши потребности. Это позволило перейти в единую, удобную и понятную нашим аналитикам систему для обработки запросов пользователей. А пользователи получили единое окно входа в наши сервисы с чёткими требования к запросам.

Далее бот пробует найти в предыдущих заявках по тексту вопроса похожие и, если находит, добавляет ссылку на заявку и превью вопроса в комментарии. Комментарии могут видеть только участники проекта с группой «Эксперт», в неё входят сотрудники департамента по работе с данными.

Тексты и номера заявок мы храним в БД бота и обновляем их каждые сутки через выгрузку из API Jira. Раньше поддержка использовала OTRS вместо Jira, поэтому история собрана из двух источников. Так мы стараемся помочь исполнителям — подсказываем, что вопрос уже мог быть решён ранее.

Над чем работаем сейчас?

За первый год жизни бота выросла сложность решаемых бизнес-кейсов и алгоритмов, заложенных в инструменты. Мы сформировали команду, которая занимается развитием и сопровождением продукта и теперь можем более пристально следить за user experience:    

• проводим серию интервью с пользователями и оффлайн опросы; 

• отслеживаем ситуации с ошибками, возникающими у пользователей, чтобы сразу реагировать;  

• разрабатываем метрики, по которым будем выстраивать развитие продукта; 

• проводим рефакторинг веток бота с целью их упрощения для пользователей.

Из новых технических фичей на ближайшее время планируем:  

• реализовать передачу URL страниц, где пользуются web-ботом; 

• наладить процесс оценки бота пользователями по завершению диалогов.