Как устроен виртуальный помощник для data-сервисов в «Магните»

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

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

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

Чат-бот реализован на платформе 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 сервер:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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