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

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

Определение

Диалоговая система – это система, созданная для общения с пользователем в естественном для него виде: в виде диалога. В первую очередь такие системы или, как их часто называют, боты, возникли для того, чтобы упростить взаимодействие людей с компаниями или сервисами. Например, спросить у умной колонки прогноз погоды быстрее, чем искать телефон, открывать браузер и печатать запрос.

Немного из истории

1966 - 1-й чатбот: Элиза. Элиза была одним из первых чатботов, разработанных Джозефом Вайценбаумом. Она была основана на правилах и имитировала психотерапевта, способного поддерживать беседы с пациентами. Элиза могла отвечать на вопросы, задавать встречные вопросы и делать вид, что она заботится о чувствах собеседника.

В этом боте были заложены очень базовые правила сопоставления шаблонов. В Элизе использовался минимальный контекст (обычно учитывается только последнее высказывание). Также были правила сопоставления ключевых слов и определенный приоритет. Пример: если слова "подобно" и "связь" встречаются, бот может задать вопрос "в чем заключается связь?". Имеются запасные варианты ответов, такие как "Понимаю. <следующий вопрос>" или "Пожалуйста, продолжите". Способность отвечать и ссылаться на предыдущие высказывания пользователя. Сигнализация о понимании, повторение и переформулирование фраз пользователя.

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

1990-е/2000-е годы - системы, основанные на поиске - В этот период времени чатботы начали использовать системы поиска и выбора наиболее подходящих ответов на основе ключевых слов в вопросах пользователей. Это был шаг вперед, но чатботы все еще оставались ограниченными в своей способности понимать естественный язык.

2015+ - огромный всплеск генеративных моделей - В последние годы наблюдается огромный прогресс в области диалоговых систем благодаря развитию генеративных моделей и нейронных сетей. Это позволило создавать более естественные и разнообразные ответы, делая чатботов более полезными и интересными для пользователей.

Разновидности Диалоговых Систем

Диалоговые системы бывают разными. В первую очередь они принципиально различаются задачами: одни помогают людям совершить те или иные действия, а другие просто болтают обо всем на свете.

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

Основанный на правилах (Rule-based):

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

Преимущества: Прост в создании и понимании, можно точно контролировать ответы.

Недостатки: Ограничен в способности обрабатывать сложные и контекстные запросы. Требует большого объема правил и может быть неэффективным для больших объемов данных.

Основанный на данных (Data-Driven):

Извлекающий (Retrieval):

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

Преимущества: Эффективен в получении точных ответов, особенно если корпус содержит много разнообразных данных.

Недостатки: Может быть неэффективным при отсутствии подходящего ответа в корпусе. Не способен генерировать оригинальные ответы.

Генеративный (Generative):

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

Преимущества: Способен создавать более разнообразные и оригинальные ответы, чем retrieval-based модели. Может обрабатывать невидимые запросы. Может обрабатывать неизвестные запросы.

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

Также диалоговые системы могут разделяться в зависимости от того, какую задачу они выполняют: решение каких-то конкретных вопросов или же поддержка полноценного разговора.

Целеориентированные (Task-oriented) диалоговые системы:

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

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

Примеры задач:

Бронирование ресторанов и билетов на самолет.

Поиск расписаний автобусов.

Управление умным домом.

Чатоориентированные (Chat-oriented) диалоговые системы:

Эти системы не сосредоточены на выполнении конкретных задач. Вместо этого они ориентированы на социальное общение и развлечение пользователя.

Предназначены для социального общения и развлечения пользователя.

Могут заниматься чисто "пустой болтовней" или попытками создания уникальной "персоны" для более интересного взаимодействия.

Примеры:

Чат и общение для развлечения.

Установление связи с пользователем, создание определенной "персоны".

Участие в игре "Тест Тьюринга".

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

Традиционная/Закрытая (Single/Closed-domain) область:

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

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

Мульти-область (Multi-domain):

В этом случае диалоговая система объединяет несколько отдельных систем, каждая из которых специализируется на определенной области. Например, у Google, Alexa или Siri может быть несколько таких систем, каждая для разных областей, но они объединены в одну систему.

Открытая область (Open-domain):

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

Стоит отметить, что чаще всего у ботов встречаются две комбинации: Open domain + Chat - боты, предназначенные для живого общения с людьми как Алиса от Яндекс или ChatGPT от OpenAI. И Closed Domain + Task oriented боты, которые чаще всего используются для решения каких либо бизнес задач и общения с клиентами для сбора необходимой информации.

Task oriented

Теперь, когда мы ознакомились с наиболее частыми способами делениями диалоговых систем и узнали, в чем их отличие, перейдем к конкретным видам систем. А именно, остановимся подробнее на разделении диалоговых систем по цели - Task oriented и Chat oriented.

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

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

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

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

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

Определим основные понятия для того, чтобы ввести классическую архитектуру.

Намерение (англ. intent) — желание пользователя в рамках произесенной фразы.

Именованная сущность (англ. named entity) — слово во фразе пользователя, которое можно отнести к определенному типу.

Слот (англ. named entity) — параметр запроса пользователя, ограниченный множеством допустимых значений.

Домен (англ. domain) — область знаний, которая относится к запросу пользователя.

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

ASR (Automatic Speech Recognition). На вход поступает речь пользователя, которая затем распознается и переводится в текст. Результат работы компонента называют гипотезой, так как полученный текст может соответствовать исходному сообщению не полностью. Проблемы: шум, акценты, большая дистанция, эхоподавление…

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

Например "I’m looking for a restaurant" мог бы иметь такие гипотезы:

"I’m looking for a restaurant" (уверенность 0.8)

"uhm looking for a restaurant" (уверенность 0.4)

"looking for a rest tour rant" (уверенность 0.2)

Здесь цифровые значения (0.8, 0.4, 0.2) представляют собой оценки вероятности правильности каждой гипотезы. Чем ближе оценка к 1, тем больше вероятность того, что гипотеза правильна.

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

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

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

Проблемы: восстановление после плохой ASR, неоднозначность, вариация.

Итак, основные задачи на этапе NLU включают в себя:

Определение намерения (Intent Detection): Это определение того, что пользователь хочет сделать или узнать. Например, пользователь может иметь намерение узнать расписание автобусов или забронировать стол в ресторане. Это называется "действием диалога" или "намерением".
Тегирование слотов и значений (Slot-Value Tagging): Это связано с извлечением конкретных атрибутов из сообщения, таких как дата, время, местоположение, цена и т. д. Эти атрибуты могут быть связаны с определенным намерением. Например, если пользователь хочет узнать время автобуса, "время" будет слотом, а "11:34" - его значением.
Действия диалога (Dialogue Acts): Это определение типа действия, которое выполняет пользователь в сообщении. Например, это может быть действие "информировать", "запрашивать" или "подтверждать". Эти действия помогают понять намерение пользователя.

В итоге, этап NLU помогает перевести текстовое сообщение пользователя в структурированное представление, которое легче интерпретировать для последующей обработки и формирования ответа в диалоговой системе.

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

Состоянием диалога или контекстом является информация, которая была получена при общении с пользователем ранее. В соответствии с текущим состоянием выбирается политика поведения системы, корректируется семантический фрейм. В качестве поставщика знаний может выступать СУБД или Web API.

Иногда вместо DM рассматривают сочетание Dialog State Tracker (DST) + Dialog Policy.

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

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

DP - этап, цель которого заключается в принятии решения о следующем действии системы, то есть о том, какой диалогический акт сгенерировать. Более формально, на i-м ходе в разговоре мы хотим предсказать, какое действие Ai следует выполнить.

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

Большинство систем вводят определенные стратегии и действия, связанные с подтверждением и отклонением. При использовании стратегии явного подтверждения система задает пользователю прямой вопрос для подтверждения своего понимания.

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

В соответствии с выбранным действием осуществляется генерация ответа пользователю на естественном языке. Для генерации применяются генеративные модели или шаблоны.

После того как был выбран диалогический акт, нам нужно сгенерировать текст ответа пользователю. Задачу генерации естественного языка (NLG) в архитектуре информационного состояния часто моделируют в два этапа: планирование контента (что сказать) и реализация предложения (как сказать). Здесь мы предположим, что планирование контента было выполнено диалоговой политикой, которая выбрала диалогический акт для генерации и выбрала некоторые атрибуты (слоты и значения), которые планируются для передачи пользователю (либо для предоставления пользователю ответа, либо как часть стратегии подтверждения).

Генеративные модели

Для этих систем трудно получить обучающие данные ; маловероятно, что мы увидим каждый возможный ресторан со всеми возможными атрибутами во множестве разных формулировок предложений. Поэтому в процессе реализации предложения часто используется метод делексикализации для увеличения обобщенности обучающих примеров. Делексикализация - это процесс замены конкретных слов в обучающем наборе, представляющих значения слотов, общим заполнителем, представляющим слот. Преобразование из фреймов в делексикализованные предложения обычно выполняется с использованием моделей кодировщик-декодировщик. Входом для кодировщика является последовательность токенов xt, представляющих диалогический акт и его аргументы. Таким образом, диалогический акт "РЕКОМЕНДАЦИЯ" и пары атрибут/значение "сервис: приличный, кухня: нет" могут быть представлены как плоская последовательность токенов, каждый из которых сопоставлен изученному вложению wt. Кодировщик считывает все представления входных слотов/значений, и декодер генерирует соответствующее делексикализованное английское предложение; restaurant name has decent service. Затем мы можем использовать входной фрейм от планировщика контента для повторной лексикализации (заполнения точного ресторана, района или кухни).

Шаблоны / Статистические методы

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

Основные этапы классической архитектуры на конкретных примерах

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

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

Chat oriented

Теперь рассмотрим чатоориентированные диалоговые системы, которые в основном используются для "живого" общения. Чатоориентиарованные системы обычно по типу реализации основываются на извлекающемм (retrieved) или генеративном (generative) подходе.

Char oriented системы с извлекающим типом реализации

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

Метод ответа с использованием поиска заключается в том, чтобы рассматривать ход пользователя как запрос q, и наша задача - извлекать и повторять какой-то подходящий ход r в качестве ответа из корпуса разговоров C. Обычно C представляет собой обучающий набор для системы, и мы оцениваем каждый ход в C как потенциальный ответ на контекст q, выбирая ход с наивысшим баллом. Метрикой оценки является сходство: мы выбираем r, который наиболее похож на q, используя любые методы информационного поиска (IR). Это можно сделать с использованием классических методов IR для вычисления моделей tf-idf для C и q, выбирая r, который имеет наивысший косинус tf-idf с q. Другая версия этого метода - возврат ответа на ход, похожий на q; то есть, сначала мы находим самый похожий ход t на q, а затем возвращаем в качестве ответа следующий ход r.

Char oriented системы с генеративным типом реализации

Самый новый подход по типу реализации - генеративный.

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

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

На рисунке представлена идея методов генерации и извлечения (поиска) для создания ответов в диалоге. В архитектуре генератора обычно включается более длинный контекст, формируя запрос не только из последнего сообщения пользователя, но и из всей предыдущей беседы. Рассмотрим два варианта архитектуры для создания ответов в таких чат-ботах на рисунке в верхней часте. В методе "Retrieval" (a) мы выбираем ответ, находя сообщение в корпусе, кодирование которого имеет наибольшее скалярное произведение (dot-product) с сообщением пользователя. В методе "Generation" (b) мы используем архитектуру кодирования-декодирования (encoder-decoder) для создания ответа.

На рисинке в нижней части представлен пример кодировщика-декодировщика для генерации ответов в диалогах; кодировщик видит весь контекст беседы

Еще стоит отметить такую архитектуру, как End-to-End. Эта архитектура может использоваться как для task-oriented (экспериментально), так и для chat-oriented (очень типично).Если заменить каждую часть классической архитектуры искусственной нейронной сетью, то получим эту архитектуру. Данную архитектуру также называют сквозной (англ. end-to-end trainable), так как на данных обучается каждая ее часть. Модель с данной архитектурой можно обобщить на намерения, которые не наблюдались во время обучения.
Системы "End-to-End" (от начала до конца) представляют собой подход в области разработки диалоговых систем, который обрел популярность в последнее время.

Преимущества и недостатки диалоговых систем

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

Из плюсов стоит упомянуть:

Автоматизация и Эффективность: Диалоговые системы могут автоматизировать общение с пользователями, что позволяет снизить нагрузку на операторов поддержки клиентов и улучшить эффективность работы.
Доступность 24/7: Диалоговые системы могут работать круглосуточно без перерывов, обеспечивая доступность и поддержку для пользователей в любое время.
Аналитика и Улучшение: Диалоговые системы могут собирать данные о взаимодействиях с пользователями, что помогает анализировать и улучшать качество обслуживания.

Из недостатков можно выделить:

Ошибки на уровне реплики могут включать неграмотные или бессмысленные ответы

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

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

Источники

https://ufal.mff.cuni.cz/courses/npfl099 - Statistical Dialogue Systems – Lectures from Institute of Formal and Applied Linguistics. Очень интересные и наглядные презентации с большим количеством современных статей.

https://web.stanford.edu/~jurafsky/slp3/ - Speech and Language Processing - Lectures from Stanford.

Real-World Natural Language Processing - Masato Hagiwara

Введение в диалоговые системы (Task & Chat oriented)