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

Модуль генерации ответов (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).

Многие разработчики реализуют собственный стек MRCP, но в то же время существует кроссплатформенная реализация стека UniMRCP с открытым кодом, распространяемая по лицензии Apache License 2.0, которая нашла широкое применение у поставщиков решений синтеза и распознавания речи.

Табл. 1. Сравнительная характеристика протоколов MRCPv1/MRCPv2.

Сквозное обучение

Ранее была рассмотрена классическая архитектура goal-oriented бота и его ключевые компоненты. Как уже было отмечено, каждый из них может быть реализован как с применением нейронной сети, так и без нее. Классическая архитектура допускает также частичное использование нейронных сетей: например, компонент NLU может быть реализован нейросетью, а модули управления диалогом и генерации ответов ― на основе правил (rule-based). Таким образом, можно отметить гибкость и адаптируемость архитектуры классического бота, в которой каждый компонент может оптимизироваться и дорабатываться отдельно от других.

Развитие нейронных сетей и глубокого обучения привело к появлению новых подходов к реализации ботов:

• 

Сквозное обучение

(end-to-end learning) ― в этом подходе сохраняется классическая архитектура бота, но все ее компоненты представлены нейронными сетями. Обучение производится сквозным методом, т.е. на каждом экземпляре обучающего диалога все компоненты обучаются как единое целое, а не по отдельности.

• 

Диалоговые модели, полностью управляемые данными

(Fully data driven Conversation Models) ― в этом подходе уже не применяется классическая архитектура. Весь бот представляет собой одну глубокую нейронную сеть, классическим примером которой является ChatGPT