Классификация диалоговых систем

Подходы и технологии, используемые при создании бота, зависят от типа и назначения системы. Традиционная классификация диалоговых систем опирается на 2 критерия:

• 

Ориентированность на задачу (goal-oriented) VS общее назначение.

• 

Закрытая VS открытая предметная область (домен).

Goal-oriented боты разрабатываются для решения конкретных задач ― выдачи информации по запросу, выполнения операций (проверка баланса, подключение тарифа и т.п.).

Диалоговые системы общего назначения (так называемые боты-«болталки») направлены исключительно на поддержание диалога и развлечение пользователя.

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

Системы с открытым доменом предполагают универсальные возможности использования ― к ним относятся ассистенты типа Алексы от Amazon или Алисы от Яндекса. Большинство таких систем выполняют роль интерфейса к специализированным сервисам (например, фраза «Алиса, давай закажем билет в кино» вызывает специализированный сервис по бронированию билетов в сети кинотеатров). Открытый домен здесь – инструмент продвижения интерфейса на рынке пользователей.

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

Рис. 1. Пример классификации чат-ботов.

Для большинства бизнес-задач достаточно goal-oriented бота с ограниченной областью знаний; стремление охватить все предметные сферы и создать универсального собеседника (AI) в теории может привести к созданию «настоящего» искусственного интеллекта.

Технологии

Классическая архитектура

Рассмотрим архитектуру классического бота (Рис. 2).

Рис. 2. Архитектура классического бота.

Модуль понимания естественного языка

Модуль понимания естественного языка (Natural Language Understanding, сокращенно NLU, NLP Engine) – один из ключевых модулей любой диалоговой системы. Он обеспечивает структуризацию и «понимание» (интерпретацию) сообщений пользователя. Существует несколько способов коммуникации с ботом: предопределенные диалоговые кнопки (например, «Да» и «Нет»), ключевые слова (/start, /bye и т.д.) и общение в свободной форме с использованием произвольного текста на естественном языке. В общем случае свободу общения можно представить в виде Рис. 3.

Рис. 3. Свобода общения.

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

Классификация сообщений (Intent Classification). Она может производиться с применением как нейронных сетей (наиболее популярны архитектуры на основе рекуррентных ячеек GRU/LSTM), так и классических алгоритмов машинного обучения (наивный байесовский классификатор, логистическая регрессия), которые успешно применяются в случае небольшого количества обучающих данных. Любому сообщению пользователя должен соответствовать определенный класс (интент). Например, сообщения «привет», «хай», «добрый день» могут быть классифицированы в один класс intent_hello, а сообщения «до свидания», «пока», «удачи» – в класс intent_bye. Сообщения, класс которых с достаточной вероятностью определить не удалось, относятся к классу no_match. В общем и целом, все интенты разделяют на General intents (например, интенты приветствия и прощания) и Domain intents (например, интенты заказа конкретной пиццы или бронирования гостиницы на определенный день).

Выделение именованных сущностей (Named Entity Extraction, Named Entity Recognition, Slot Filling). Сущности представляют собой единый лексический элемент определенного типа (географическое название, имя, дата и т.п.). Так, в сообщении «Покажи расписание рейсов из Москвы в Париж 12 августа» именованными сущностями являются «Москва», «Париж» и «12 августа». Выделение сущностей может быть реализовано как на основе регулярных выражений (шаблонов, паттернов) и справочников, так и посредством NER Network – специально обученной нейронной сети с архитектурой many-to-many.

Модуль управления диалогом

Модуль управления диалогом (Dialog Management Module, сокращенно DM) – ядро чат-бота, которое управляет текущим контекстом и реализует требуемый функционал. Контекст представляет собой «память» бота обо всех (или последних) действиях и сообщениях. Не все диалоговые модули поддерживают контекст, и не всегда в нем есть необходимость. Например, в простых вопросно-ответных системах нет необходимости поддерживать контекст. В случае примитивных диалогов используют следующие типы DM: switch statement (т.е. полное отсутствие контекста, аналогично поисковым системам) или FSM (finite-state machine) – конечный автомат, представляющий собой однонаправленный диалог без сохранения полученных от клиента данных для других диалогов в рамках той же сессии. В случае goal-oriented чат-бота использование контекста обязательно, и тогда DM включает в себя:

Dialog State Tracking (DST) – компонент, отслеживающий текущее состояние (state) диалоговой машины и допустимые переходы между стейтами. Сохраняет и отслеживает все сообщения клиента и ответные действия системы, чтобы помочь компоненту Policy Learning оптимально выбрать следующий шаг.

Policy Learning (Dialog Policy, PL, DP) – компонент, определяющий дальнейшие действия бота на основе текущего состояния и контекста. Вариантами последующих действий могут быть: формирование ответного сообщения, обращение во внешнюю информационную систему за дополнительной информацией, условный переход в другой стейт (context switching) и тому подобное. Policy Learning может быть реализован на основе правил (rule based), на основе предобученной классической нейронной сети (supervised learning), которая сама определяет, что лучше делать дальше, либо с использованием подхода обучения с подкреплением (reinforcement learning). Первый вариант получил наибольшее распространение из-за простоты реализации и отсутствия необходимости обучения на большом объеме дата-сетов.

Модуль генерации ответов

Модуль генерации ответов (Response Generator Module, Natural Language Generator, NLG) – формирование ответа клиенту в соответствии с данными, полученными из диалогового модуля и из внешних информационных систем. В общем случае выделяют следующие архитектуры RGM:

Извлечение данных (Retrieval Based Modelling) – в простейшем случае ответом является статичный текст. Для «оживления» сценария бот может случайным образом выбирать вариант из предописанного набора статичных текстов (например, для прощания с пользователем всякий раз использовать случайный вариант из доступного списка: «пока», «приятно было пообщаться», «до свидания» и т.д.). Ответ может быть динамическим, т.е. включать в себя результаты, полученные из внешних систем: к примеру, значение баланса счета или время вылета самолета. Варианты генерации ответа статичным или динамическим текстом являются самыми распространенными из-за простоты реализации, отсутствия необходимости обучения и предсказуемости результата.

Рис. 4. Архитектура RGM: извлечение данных.

Порождение (Generative Modelling) – формирование ответа на основе работы нейронной сети (как правило, архитектура кодировщика-декодера). В таком случае содержание ответа полностью формируется предобученной нейронной сетью. Подход нашел свое отражение в вопросно-ответных системах, но в классических чат-ботах он применяется крайне редко из-за сложности обучения и риска неожиданных ответов (пример ― известная ситуация с ботом Microsoft, который в результате бесконтрольного самообучения стал генерировать расистские высказывания).

Рис. 5. Архитектура RGM: порождение.

Извлечение с улучшением (Retrieve and Refine) ― гибридный метод. Известно, что генеративные модели склонны давать общие, более «безопасные» ответы («да», «нет», «не знаю»), в то время как Retrieval Based модели ограничены набором предзаписанных ответов, которые могут не полностью соответствовать контексту текущего диалога. Модель Retrieve and Refine комбинирует два описанных выше подхода. В гибридной модели Retrieve and Refine ответы, обнаруженные моделью Retrieval Based, подаются на вход генеративной модели в качестве дополнительного контекста. Генеративная модель формирует окончательный ответ бота.

Рис. 6. Архитектура RGM: извлечение с улучшением.

Интерфейс ввода-вывода

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

Рис. 7. Пример архитектуры текстового бота.

Как правило, используют следующие дополнительные интерфейсные модули:

• 

для голосовых ботов – системы синтеза (Text to Speech, TTS) и распознавания (Automatic Speech Recognition, ASR) речи. Их качество достигло такого уровня, что при общении отличить живого человека от синтезированного голоса не всегда просто (впрочем, во многих решениях используются предзаписанные реплики, сознательно имитирующие человеческую речь – с придыханием, паузами, фоновым шумом). Существует довольно много разработчиков этих решений в России (ЦРТ, Яндекс, АСМ-Решения) и в мире (IBM, Google, Microsoft, Nuance). Чтобы стандартизировать методы интеграции подобных систем, разработаны интерфейсы протокола управления медиаресурсами (MRCP) и удаленного вызова процедур (gRPC).

• 

для неголосовых систем широко применяются уже зарекомендовавшие себя протоколы HTTP REST/WebSocket. Они гораздо проще в реализации, т.к. не требуют распознавания голоса в режиме онлайн. Разработчики вправе как использовать общепринятые интерфейсы, так и создавать свои собственные – в случае, если новая разработка по каким-либо критериям лучше существующих.

Различия MRCPv1 и MRCPv2

Протокол MRCPv1 (RFC 4463) был разработан совместными усилиями компаний Cisco, Nuance и Speechworks в 2006 г. Последовавший за ним MRCPv2 (RFC 6787) стал развитием первой версии. Табл. 3.3.1 демонстрирует ключевые отличия двух протоколов.

RTSP и SIP/SDP являются клиент-серверными текстовыми протоколами (аналогичны HTTP) и достаточно схожи между собой по формату и параметрам сообщений. Также в обоих случаях транспорт голосового потока реализуется протоколом RTP (Real-time Transport Protocol).