Как мы создаем виртуального помощника

Меня зовут Владимир Крючков, я работаю начальником разработки в группе компаний Полипластик.

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

Поделюсь опытом, как мы его разрабатывали, и к чему мы идем.

Что такое виртуальный помощник?

Слово «Виртуальный» – это значит неживой, искусственный, программа. Помощник – это тот, кто помогает нам с вами. Соответственно, виртуальный помощник – это некий алгоритм, программа с искусственным интеллектом или с подобием искусственного интеллекта, которая помогает нам выполнять какие-то операции либо действия.

Инструмент, программа, алгоритм, чат-бот, ИИ – все это аккумулятивное понятие виртуального помощника.

Я думаю, что вы все тем или иным образом взаимодействовали с виртуальными помощниками. Например, с Алисой, которая живет в колонке. Либо с Siri, которая живет в телефоне. Также можно вспомнить виртуального помощника из фильмов «Железный человек» или «Мстители» – там был искусственный интеллект, которого звали Jarvis.

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

Здесь у нас есть диалоговое окно, через которое мы можем взаимодействовать с нашим виртуальным помощником.

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

Если мы пойдем дальше и добавим сюда голосового ассистента Алису, у нас получится мобильное приложение для телефонов iOS или Android.

Если мы не хотим использовать смартфон, мы можем подключить Алису к IP-телефонии и с помощью сервиса преобразования звуков в текст получить команды для нашего помощника. А потом обратным преобразованием сделать, чтобы Алиса нам отвечала.

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

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

Зачем и как мы создали себе виртуального помощника?

Чем отличается виртуальный помощник от живого человека?

• Во-первых, виртуальный помощник не нуждается в больничных. У него нет отпуска, он не пьет кофе по утрам, не ходит на перекуры.

• Виртуальный помощник всегда поможет, не откажет – у него не бывает плохого настроения. Он всегда общительный и любезный – насколько мы его запрограммируем.

• Виртуальный помощник живет в небольшой черной коробочке, которая зовется сервером. В размере одного юнита у нас могут помещаться десятки, а может быть и сотни этих программных сущностей (зависит от решаемых задач и возможностей).

Виртуальные помощники у нас уже используется:

• при обработке больших объемов информации;

• в тестировании;

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

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

Помощник мониторинга сервисов 1С

Первая модель, которую мы создали – это помощник мониторинга сервисов 1С.

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

Данный помощник следит за работоспособностью системы – как железа, так и самой базы, в которой работают пользователи. Этот помощник реализован в рамках фреймворка «Мониторинг производительности серверов 1С».

Расскажу о проблематике, которая решалась с помощью помощника.

Если вернуться в прошлое нашей компании, то:

• Мы начинали работать вообще с Excel – заводили в Excel данные по продажам, по закупкам и т.д. Тогда мы были маленькой компанией из пятя человек, и никаких проблем не было – ни с нагрузкой, ни с чем.

• Потом мы стали побольше, и у нас появилась база на 1С 7.7.

• Потом мы перешли на 1С:Предприятие 8. В компании стало работать больше людей, появились филиалы, появился РИБ. Увеличился поток информации, количество запросов от пользователей и возникаемых проблем. Нужно было следить за тем, чтобы все работало.

• И теперь у нас в компании используется ERP, с которым мы работаем в облаке. К базе подключается множество филиалов от Дальнего Востока до Санкт-Петербурга. Еще есть Казахстан и Беларусь. Единовременно количество онлайн-пользователей у нас доходит до тысячи. Обрабатывается большой объем информации.

Это приводит к тому, что периодически в работе системы возникают различные сложности:

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

• Кроме этого, есть определенные VIP-пользователи, которые требуют уникальных моментов.

• У нас большой поток информации – постоянно поступают письма, сообщения, звонки и т.д. Нам желательно их обрабатывать как можно быстрее. Чем быстрее мы их обработаем – выделим критичные задачи – тем будет более удовлетворен наш потребитель.

Автоматизацию мониторинга мы начали с обработки логов технологического журнала.

Круто, когда у вас черный пояс по парсингу запросов, но давайте представим, что у нас большая нагруженная система. Если мы включим логирование технологического журнала – а это сбор определенных событий, у нас за час может получиться количество информации, сопоставимое с несколькими томами «Войны и мира». Обработать это практически нереально. А если в реальном времени, то невозможно.

Самая классная идея – отдать это все на откуп какой-то программе. Чтобы она сама все это посмотрела и сказала – хорошо у нас здесь все или не очень.

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

У нас был пример, в котором данная функциональность помогла. С помощью этой системы нам удалось обнаружить, что одной из версий платформы происходили проблемы с rphost – они начинали плохо работать и через некоторое время зависали. После этого падал rmngr, все становилось колом, и помогала только перезагрузка системы, а это – время, которое неправильно отнимать у пользователей, они нам приносят деньги и продают товары. Мы сразу обнаружили проблему и смогли ее оперативно решить.

Эта система опирается на данные конфигурации «Мониторинг производительности», которая выложена в открытом доступе, если кому-то интересно код посмотреть – залезайте, смотрите внутренности.

На вход мы собираем всю информацию, которую можем получить:

• технологический журнал;

• показатели из RAS;

• показатели по железу;

• очередь;

• память и т.д.

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

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

У меня был диалог с коллегами на Инфостарте о применимости данной технологии. Они говорили, что проще работать по старинке – взять 10-15 графиков, найти, где проблема, и исходя из этих данных сделать выводы, как действовать.

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

А в данном случае я считаю, что нам не нужен ни один график. Единственное, что нам нужно – это суждение: все плохо либо все хорошо. Если у нас все плохо, мы начинаем искать решение проблемы.

Здесь опять плюсом приходит то, что в процессе работы вы нарабатываете какую-то базу знаний. У вас уже есть кейсы, которые вы используете – эти кейсы вы передаете системе и обучаете ее. А она вас после этого в случае какой-то критичной ситуации информирует, если все плохо. Сообщает меры, которые нужно предпринять. И вы уже спокойно в этом режиме работаете, тем самым, поддерживаете высокую планку качества предоставляемого сервиса.

Эта система у нас работает и уже нам помогает. Особенно в рамках обработки большого объема информации и прогнозирования каких-либо ситуаций.

Мы не стоим на месте, предлагаем новые идеи, пробуем. Если получается, используем. Если нет, идем дальше.

Модель №2. Помощник тестировщика 1С

Следующая модель, которую мы использовали, это – помощник тестировщика.

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

Проект с помощником тестировщика мы реализовали на базе фреймворка Тестирование 3.0 – он также выложен на GitHub.

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

Здесь я говорю в основном про формирование сценарных и интеграционных тестов. Юнит-тесты пока предполагается писать руками. Хотя вроде уже есть нейросети, которые понимают код и могут программировать. Возможно, скоро они заменят нас даже в этом.

Представим следующую ситуацию: мы сидим на работе, и к нам прилетает задача – добавить тест на новую печатную форму счета-спецификации.

• Мы садимся за компьютер, пишем в чате или говорим в микрофон: «Привет, Лариса! Я хочу сделать новый тест, который будет проверять счет-спецификацию».

• Она говорит: «Расскажи подробнее, что ты имеешь в виду, чтобы я смогла как-то тебе помочь».

• Мы говорим: «Процесс выглядит так – создай заказ клиента, отгрузи его, потом выбери необходимую форму, распечатай и т.д.»

• Она говорит: «Как создать заказ – знаю. Как отгрузить – знаю. Как распечатать – не знаю. Покажи».

• Мы открываем базу, запускаем, ищем заказ и жмем кнопку «Печать». А потом сохраняем записанный лог и передаем ей.

• И она нам говорит: «Теперь я знаю, как это делать. Поехали».

Здорово, да?

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

Также настройки окружения.

Сейчас у нас в бета-тесте около 300 параметров окружения, я думаю, когда мы выложим эту модель в продакшен, в ней будет не менее тысячи параметров, в рамках которых она будет принимать те или иные решения.

На слайде показано, как устроена данная система.

Внутри есть специальная обработка, в которой содержится алгоритм так называемого иерархического дерева поведений, которое, исходя из определенных параметров в системе (какое окно открыто, какие кнопки доступны, какие заказы сделаны, какие у нас заданы клиент, организация и т.д.) выполняет какие-либо операции.

Дальше – мы воздействуем на эту обработку следующим образом.

• Можем передать ей готовый существующий сценарий или запись действий

• Можем задать какие-то параметры и как-то передать ей информацию через чат-интерфейс.

• Она оперирует готовой базой сценариев – кликает, что-то делает.

• Все это вместе дает нам готовый динамический сценарий. Либо мы даже можем с ее помощью тестировать автоматически – это то, к чему мы и идем.

Давайте рассмотрим пример проверки бизнес-процесса продажи.

После начала выполнения сценария она непосредственно у нас запрашивает информацию, которая ей требуется:

• Организацию, на которой будем тестировать;

• Клиент;

• Склад;

• Валюту;

• Номенклатуру и ее количество.

Сохраняет заказ, проводит и закрывает. Подробнее ознакомиться с выполнением сценария можно в видео на YouTube.

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

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

По опыту скажу – если в базе миллионы документов, самая большая проблема при проведении документа в том, как обновляется динамический список. Когда мы на него кликаем, он обновляется медленно. А если у нас используются еще какие-то сортировки, тут вообще база «умирает».

Модель №3. Помощник коммуникатор

Последняя, третья модель, над которой мы недавно начали работать, – это помощник коммуникатор.

После успешного опыта разработки первой и второй модели я решил сделать себе помощника для работы. Я – руководитель разработки и, хотя все мои сотрудники хорошо работают, мне нужно обязательно проверять, что они следуют определенным стандартам.

Мы все работаем в системе багтрекинга Jira, ведем в ней задачи – в нее у нас аккумулируются все инциденты. Там же сидит наш отдел поддержки. Все это связывается, и получается очень удобно. Есть инцидент, под этот инцидент в задаче есть решение, связанное с задачей в отдел разработки. Все связано, и все классно.

Назначение этой модели – она помогает в разработке и поддержке.

Как я сказал, мы планируем ее использовать в двух частях.

• Первая часть – в рамках разработки. Есть определенные правила, которым у нас должны следовать разработчики. Они должны обязательно документировать, что они сейчас делают. Что сделали, какая информация там была изменена. Это все включается в Git и т.д. Плюсом есть интересные вопросы, когда у нас разработчик делал какой-то проект, но в силу определенных причин он может что-то забыть или пропустить. Но у нас есть база знаний, и система нам подскажет: «Ребята, вы здесь забыли это продумать. Проведите еще такой тест и посмотрите». Она нам помогает, подсказывает решение каких-то проблем.

• Также это интересно с точки зрения службы сопровождения, потому что у нас есть VIP-пользователи, которые не любят ждать. А еще страшнее, когда бывают определенные случаи, когда система не позволяет что-то сделать. Стоит машина на воротах, а они не могут провести отгрузку и распечатать документы из-за каких-то проблем. Такие вопросы нам нужно отлавливать и решать максимально быстро. Здесь нам как раз помогает то, что она поймет, что это за проблема, посмотрит в базу знаний и скажет: «Здесь нужно делать вот так». Конечно, часть проблем сначала уходит на понимание, что и когда произошло, происходит поиск решений, неподходящие отсеиваются, потом производится тестирование и проверка. Зато потом мы можем найти, что мы делали полгода назад, когда была такая же проблема и т.д. Все это сильно снижает издержки.

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

На слайде показан пример обработки модели, которая засасывает информацию из Jira и ее классифицирует. Может дать какой-то совет, добавить комментарий и т.д.

Вот так выглядит прототип этой модели:

• Есть мозг, в котором настроены все эти алгоритмы.

• На вход собирается информация с Jira, из EDT и Git.

• Дальше она обрабатывается.

• И на основе базы знаний выдает рекомендации – например, по контролю качества: «Задачи закрыли, а вы не описали, в чем проблема, и не добавили информацию в базу знаний».

• Также выполняются различные рутинные операции. Согласитесь, здорово написать: «Запусти мне тесты». Она их запустила и скинула нам отчет на Skype или в Teams. Мы видим результаты и понимаем, что все готово.

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

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

Первая линия – это когда мы классифицировали ситуацию, сразу направили адресату, кто будет это делать.

Здесь я считаю, самое важное – не оставлять пользователя одного, когда он пишет свои проблемы, и ему нет ни ответа, ни привета. Он начинает переживать: «Что мне делать?»

У нас в базе работают практически круглосуточно. Технологическое окно небольшое, с 23:00 до 01:00. А дальше у нас начинается работа.

Основная служба поддержки у нас работает по московскому времени. Соответственно, здесь большой плюс будет в том, что она прочитает проблему, скажет: «Я вас поняла, сейчас мы будем решать. Успокойтесь, я с вами».

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

Как мыслит виртуальный ассистент?

Расскажу, как виртуальный помощник принимает решения – как команды пользователя трансформируются в действия системы.

У нас с вами есть какая-то команда. Это может быть голосовая или текстовая информация, возможно, какой-то скрипт.

Виртуальный ассистент интерпретирует – читает и преобразует этот скрипт в понятные ему термины.

Далее он ищет смысл и пытается в своей иерархической базе знаний найти подходящие ответы под проблему.

На основании этого ответа формируется кластер действий.

Здесь самый важный момент в том, что система у нас не линейная, а иерархическая.

Это значит, что если мы говорим системе слово «Наполеон», ей тяжело понять, это – торт или человек? Здесь нужен контекст.

Система держит контекст. Если мы говорим про торт, она из нашего общения понимает, что кто-то хочет купить торт, предложит другие варианты и т.д.

Соответственно, если у системы недостаточно информации для проведения диалога, она может задать вам какой-то дополнительный вопрос, например: «Уточните, в какой базе у вас произошла проблема? Бухгалтерий у нас много, вы работаете во многих базах. Что у вас случилось?»

Дальше, если есть какая-то проблема с производительностью – база внезапно упала, то сразу отправляем в службу администрирования инцидент: «Ребята, разбирайтесь, что произошло».

Выводы

В итоге, какие плюсы?

• Во-первых, это можно сказать «бесплатно».

• Настроенная модель быстро справляется с рутиной.

• Вам не требуется нанимать сотрудников, которым нужен офис.

• Такие человекозаменители – это реальная помощь. Я думаю, чем дальше, тем больше мы будем их использовать. Им удобно передавать рутинные операции, которые раньше мы делали руками. Вспомните про ручное тестирование. Сначала мы делали руками, потом подумали – давайте автоматизируем, сделали автоматические тесты и т.д. Это нам помогает, это войдет в нашу практику.

По факту, виртуальные помощники – это уже не идея, это реальный механизм, который можно использовать.

Часть наших идей мы выкладываем в репозитории на GitHub:

• Фреймворк «Мониторинг сервисов 1С» – https://github.com/Polyplastic/1c-parsing-tech-log

• Фреймворк «Тестирование 3.0» – https://github.com/ivanov660/TestingTool-3

• Библиотека скриптов для тестов – https://github.com/ivanov660/test-lib-logic

Те, кому интересно, могут присоединяться, спрашивать, использовать наши наработки у себя.