В последнее время все больше крупных компаний выделяют свои ресурсы на создание искусственных диалоговых помощников (Алиса от Яндекса, Ассистенты Салют от Сбер и др). С такими системами можно, хоть и не в полной мере, поддерживать диалог. Ассистенты умеют выполнять простые команды: ставить таймер или будильник, вызывать такси, управлять умным домом. Но в то же время разработка таких систем стоит больших денег, а также ресурсов на поддержку. В большинстве своем многим предприятиям не требуется, чтобы система умела поддерживать диалог, а просто отвечала на конкретный вопрос. Аналог современных вопросно-ответных систем появился в 60-х годах XX века и назывался экспертными системами. Экспертная система включала в себя оболочку на естественном языке и позволяла задавать вопросы на узкую тематику. С развитием методов обработки естественного языка вопросно-ответные системы стало возможным выделить в отдельный класс и не акцентировать их под решение специализированной задачи. В статье описан процесс создания вопросно-ответной системы, в частности, с какими трудностями пришлось столкнуться, какие технологии использовались, и приведен реальный пример практического использования на базе поступающих заявок в Приемную комиссию МТУСИ.
Проблемы чат-ботов
В начале стоит разобраться с вопросом, а почему вопросно-ответная система на данный момент не может быть частью чат-бота. Современные диалоговые системы, как российские, так и иностранные, предназначены в первую очередь для проведения человека по какому-то заранее заготовленному сценарию, к примеру при проведении опроса. В таких системах чаще всего анализируются короткие фразы пользователей, не превышающие 10–12 слов. В основе таких систем чаще всего лежит использование регулярных выражений и простейшей статистической обработки, так как ответ необходимо выдавать почти моментально, особенно в голосовых каналах. Такой подход почти невозможно применить при обработке длинных сообщений, например, для автоматизации первой и второй линии техподдержки.
Вторым существенным недостатком чат-ботов является именно неправильное позиционирование их как системы. Люди в большинстве своем ожидают увидеть короткие ответы, которые решат их проблему, к примеру, инфо-бот для поликлиники, который по запросу клиента сообщает время работы того или иного врача, но при этом любую систему способную “отвечать на вопросы“ называют чат ботом.
Архитектура решения
Для того чтобы определиться с архитектурой решения, сначала нужно решить как система будет использоваться: преимущественно только в облаке или же на стороне клиента. От этого зависит, можно ли делать архитектуру основанной на микросервисах, или стоит прибегнуть к монолитной архитектуре. Конкретно в случае построения вопросно-ответной системы с большим потоком заявок монолитная архитектура отпадает, так как намного проще использовать уже готовые сервисы по контейнеризации системы и ее масштабированию.
Вопросно-ответная система должна:
принимать заявки из различных каналов (CRMсистемы, Социальные сети, Телефония и др.).
производить классификацию текста на заданные тематики, соблюдая SLA< 1 секунды на ответ.
записывать логи своей работы.
иметь интуитивно понятный интерфейс.
Разберем подробнее каждый из пунктов.
Вопросно-ответная система должна уметь принимать заявки из различных каналов связи пользователей.
На этом этапе есть несколько проблем. Первая из них состоит в том, что люди в разных каналах общаются по-разному. Это можно наблюдать на примере любого текстового канала и голосового. В голосовом канале человек хуже формулирует свои мысли, и поэтому длина вопроса становится больше. Голосовой канал, прежде всего, должен предусматривать диалог между двумя пользователями, а не четко сформулированный вопрос и заранее заготовленный ответ. Это же касается и сравнения, к примеру, почтовых обращений (через электронную почту) и обращений в социальной сети, где сообщения пользователя подразумевает диалог. Все перечисленные моменты стоит учитывать при проектировании вопросно-ответных систем и в дальнейшем правильном их позиционировании на рынке.
Вторая проблема техническая. При постановке требования к системе о возможности ответа и в голосовом канале появляется проблема синтеза и распознавания речи. Решить задачу можно с использованием сторонних сервисов по синтезу и распознаванию, такими как Yandex SpeechKit, Speech-To-Text от компании Google и другими похожими сервисами. Однако при этом возникает дополнительная финансовая нагрузка. Сюда также стоит отнести проблематику формирования выборки для классификации. При использовании голосового канала в ней обязательно должны присутствовать примеры вопросов, взятые непосредственно из телефонии.
Классификатор
Классификатор является основным компонентом вопросно-ответной системы. Так как этот компонент является самым ресурсозатратным, то необходимо ввести ограничение на ответ классификатора в 1 секунду. Такое ограничение вносит трудности при разработке классификатора и влечет дополнительные финансовые затраты, так как современные алгоритмы классификации текста преимущественно работают на GPU, а при таком ограничении их использование становится необходимостью. В блок с классификацией также стоит добавить и все дополнительные программы для обработки текста и исправления ошибок (пользователя или ASR). Более подробно о классификаторе мы поговорим ниже.
Вопросно-ответная система должна записывать логи
Логирование можно сделать с помощью стандартных реляционных баз данных, но, к сожалению, быстрые исправления в них потом могут стать довольно проблемной частью. Поэтому лучше на первом этапе работы, когда до конца не ясны все взаимосвязи между таблицами, использовать NoSql данных, к примеру MongoDB. MongoDB позволяет хранить неструктурированную информацию.
Реализация
Система в общем виде состоит из 4 компонентов, а именно:
BotServer – микросервис для обработки текстовых сообщений и их классификации.
ApiGateway – микросервис для маршрутизации всех запросов в системе между микросервисами.
База данных MongoDB, которая содержит всю необходимую информацию для работы системы, а также логи ее работы.
Сайт для возможности удобного использования системы.
Разберем подробнее, из чего состоит каждый из микросервисов, за исключением MongoDB, так как данная СУБД является стандартными сервисом, и кроме коллекций в ней ничего нет.
BotServer
Микросервис для классификации, написанный на языке программирования Python. Позволяет проводить классификацию текста с возможностью изменить способ векторизации. Базовый функционал микросервиса может векторизовать текст несколькими способами: Word2Vec, FastText, STS, ElMO и BERT.Такой объёмный выбор алгоритмов позволяет разработчику тонко настроить (в удобном интерфейсе) работу системы. Каждый из алгоритмов может быть удобно применять в зависимости от ситуации.К примеру, у пользователя системы пока нет большого количества данных для обучения классификатора, поэтому он может воспользоваться базовой моделью, основанной на OneHot encoding. Также BotServer содержит в себе дополнительные скрипты для обработки текста, поиск и исправление опечаток, интеллектуальный поиск дублирования текста в разных классах, лемматизацию текста и выделение именованных сущностей. Классификация текста осуществляется с помощью метода опорных векторов с линейный ядром. Стоит отметить, что тонкая настройка алгоритма классификации тут не нужна, так как выборка в системе не статична и постоянно изменяется. Микросервис работает в режиме многопоточности и способен обрабатывать до 50 запросов в секунду.
ApiGateway
Микросервис для маршрутизации запросов внутри системы, создания коллекций в базе данных и тд. Написан на языке программирования Go. Выбор языка Go при разработке микросервиса обусловлен тем, что необходим был очень быстрый язык программирования, чем не может похвастаться Python, хотя разработка на нем происходит в разы быстрее.ApiGateway является единственным незаменимым микросервисом системы, так как является связующим звеном между остальными элементами. ApiGateway способен маршрутизировать более 1000 запросов в секунду.
Frontend
Главное требование в Fronted части – это интуитивно понятный интерфейс пользователя. Написан на языке программирования Javascript с использованием фреймворка Vue. Интерфейс позволяет проводить обучение классификатора, заносить новые статьи, вопросы и ответы к ним и многое другое. Ниже на картинках представлен интерфейс системы.
Результаты работы
Вопросно-ответная система участвовала в работе приемной комиссии 2021 года в МТУСИ (Московской технический университет связи и информатики). Вопросы в адрес приемной комиссии поступают из 3 различных каналов: голосовой канал, социальные сети (преимущественно ВКонтакте) и CRM-система Jivosite, виджет которой размещен на сайте приемной комиссии. Сотрудники приемной комиссии обучили вопросно-ответную систему ответам на часто задаваемые вопросы, число которых к началу приемной компании составило 49 штук, автоматизировав таким образом два из трех каналов поступления заявок. Система в пиковой нагрузке (последние дни подачи согласий на зачисление) обрабатывала по 5000 заявок в день. За все время приемной кампании было обработано более 45000 тысяч обращений. Процент правильных ответов системы составил 33,7%, что для первого этапа системы можно оценить как «хорошо». В дальнейшем сотрудники приемной комиссии будут расширять базу ответов, и этот результат будет улучшен. Примеры ответов системы.
Вопросно-ответная система может быть довольно быстро внедрена в похожие заведения. В июле 2021 года в экспериментальном порядке система была развернута в университете МАИ за 2 дня. При этом сотрудникам университета понадобилось только изменить ответы на статьи.