Менеджер диалогов

В этой статье есть несколько проблем. Помогите улучшить ее или обсудите эти проблемы на странице обсуждения . ( Узнайте, как и когда удалять эти сообщения ) В этой статье не представлен достаточный контекст для тех, кто не знаком с предметом .Пожалуйста, помогите улучшить статью, предоставив читателю больше контекста . ( Февраль 2016 )( Узнайте, как и когда удалить это сообщение ) Для проверки данной статьи необходимы дополнительные цитаты .Пожалуйста, помогите улучшить эту статью , добавив ссылки на надежные источники . Неподтвержденный материал может быть оспорен и удален. Найти источники:  "Dialog manager" – новости  · газеты  · книги  · ученый  · JSTOR ( Февраль 2016 )( Узнайте, как и когда удалить это сообщение ) ( Узнайте, как и когда удалить это сообщение )

Менеджер диалогов (DM) — это компонент диалоговой системы (DS), отвечающий за состояние и ход разговора. Обычно:

• Входными данными для DM являются человеческие высказывания, обычно преобразуемые в некоторое системно-специфическое семантическое представление компонентом понимания естественного языка (NLU). Например, в диалоговой системе планирования полетов входные данные могут выглядеть как "ORDER(from=TA,to=JER,date=2012-01-01)".
• DM обычно поддерживает некоторые переменные состояния , такие как история диалогов, последний неотвеченный вопрос и т. д., в зависимости от системы.
• Выходные данные DM представляют собой список инструкций для других частей диалоговой системы, обычно в семантическом представлении, например, "TELL(flight-num=123,flight-time=12:34)". Это семантическое представление обычно преобразуется в человеческий язык компонентом генерации естественного языка (NLG).

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

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

1. Управление вводом, обеспечивающее контекстно-зависимую обработку человеческих высказываний.
2. Управление выводом, которое позволяет генерировать текст в зависимости от состояния.
3. Стратегическое управление потоком, которое решает, какие действия должен предпринять агент диалога в каждой точке диалога.
4. Тактическое управление потоком, которое принимает некоторые тактические решения в разговоре (обработка ошибок, контроль инициативы и т. д.).

Человеческий вклад имеет разное значение в зависимости от контекста. Например, в DS по планированию путешествия:

• Компьютер: Откуда вы хотите отправиться?
  • Человек: Тель-Авив.
• Компьютер: Куда вы хотите прибыть?
  • Человек: Газа.

Значение названия города зависит от ранее заданного вопроса. DM может сохранить этот вопрос в переменной состояния и использовать его для преобразования «Тель-Авив» в «Я хочу выехать из Тель-Авива» и преобразования «Газа» в «Я хочу прибыть в Газу».

Эта функция находится на границе между NLU и DM: в некоторых системах она включена в NLU, например, в контекстно-зависимые правила Милворда (2000); в то время как в других системах она включена в DM, например, в модуль разрешения NP Мирковича и Каведона (2005).

Другая функция между NLU и DM — определение того, какие входные высказывания являются частью одного высказывания. Вот пример из диалога переговоров о работе:

• Предлагаю зарплату 20 000 шекелей.
• и машина
• Условия выплаты пенсии будут определены позднее.

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

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

Похожая функция существует в ChatScript (фреймворк для создания чат-ботов): каждый раз, когда DS использует определенное правило, DM отмечает это правило как «использованное», чтобы оно не использовалось снова.

Недавняя DS для технической помощи ^{[ требуется цитата ]} использует передовые правила машинного обучения для выбора лучших терминов для описания предметов. Например, если DM замечает, что разговаривает со взрослым, он будет использовать такие термины, как «левая рука»; если он замечает, что разговаривает с ребенком, он будет использовать менее технические термины, такие как «рука, на которой вы носите часы».

Эта функция находится на границе между DM и NLG.

Основная роль DM — решить, какие действия должен предпринять агент диалога в каждой точке диалога.

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

• Компьютер: «Какие силы действуют на электрон?»
  • Человек: «Электрическая сила».
    • Компьютер: "Верно"
    • [перейти к следующему вопросу]
• Компьютер: «Какие силы действуют на массу?»
  • Человек: «Электрическая сила».
    • Компьютер: «Неверно, масса не имеет заряда».
    • [перейти к уроку по электричеству]

DM хранит указатель на нашу текущую позицию в сценарии. Позиция обновляется в соответствии с человеческим вводом.

Существует множество языков и фреймворков, позволяющих авторам определять структуры диалогов, например: VoiceXML (оптимизирован для речевых диалогов), AIML, Facade и ChatScript (оптимизированы для чат-ботов), CDM (на основе Java, оптимизирован для диалогов управления устройствами) и TuTalk (оптимизирован для диалогов обучения).

Кроме того, структура диалога может быть описана как диаграмма состояний, используя стандартный язык, такой как SCXML . Это делается в DomainEditor (фреймворк для тактических допросов персонажей).

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

Ravenclaw (DM для целеориентированных диалогов, основанный на коммуникаторе CMU) позволяет автору расширенное, многоуровневое описание структуры диалога, например:

• Задача бронирования номера:
  • Авторизоваться
    • Спросить имя пользователя
    • Спросить пароль пользователя
  • Выбор комнаты
    • Выбор здания
    • Выбор номера комнаты
  • Выбор времени
  • Заканчивать

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

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

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

Фреймворки для чат-ботов, такие как ChatScript, позволяют контролировать структуру беседы с темами . Автор может создавать правила, которые фиксируют тему, которая

• тема: ДЕТСТВО (ребенок мальчик девочка молодой)
• т: У меня было счастливое детство.
• т: Но все закончилось слишком рано.
• ...

Если человек произносит одно из слов в скобках, DM помнит, что тема — «ДЕТСТВО». Теперь чат-бот начинает рассказывать историю под заголовком «ДЕТСТВО», пока бот контролирует разговор (пользователь пассивно отвечает, говоря, что думает, типа «ОК» или «верно»). Однако если пользователь задает вопросы, система может либо ответить напрямую, либо использовать строку истории, которую она собиралась рассказать в любом случае.

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

Распространенное использование диалоговых систем — замена форм. Например, агент по бронированию билетов должен спросить человека о времени и месте отправления, а также времени и месте назначения — как если бы человек заполнял форму с этими 4 слотами.

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

• Добро пожаловать в систему подтверждения рейса. Какой у вас номер рейса?
  • United 123 8 августа из Лос-Анджелеса
• Из какого города Вы вылетаете?
  • Я сказал тебе, Лос-Анджелес, 8 августа
• Извините, я не понял. Какой у вас город отправления?
  • Вылет из Лос-Анджелеса 8 августа.
• Укажите день отправления.
  • Ты не слушаешь! 8 августа!
• Назовите, пожалуйста, день отъезда?
  • 8 августа
• Подтверждено, что рейс United 123 вылетит из Лос-Анджелеса в Лондон в 14:00 8 августа.

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

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

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

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

• ПУТЕШЕСТВИЕ = {МЕСТО ОТПРАВЛЕНИЯ, ВРЕМЯ ОТПРАВЛЕНИЯ, МЕСТО НАЗНАЧЕНИЯ, ВРЕМЯ НАЗНАЧЕНИЯ}

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

Подобные DS были разработаны в Массачусетском технологическом институте , например, Wheels (для поиска объявлений о продаже подержанных автомобилей), Jupiter (для получения прогнозов погоды) и другие.

Простые DM обрабатывают заполнение слотов бинарно: слот либо «заполнен», либо «пуст». Более продвинутые DM также отслеживают степень заземления — насколько мы уверены, что действительно поняли, что сказал пользователь: было ли это «Только что недавно представлено», «Снова представлено», «подтверждено», «повторено» и т. д. Мы также можем позволить автору указать для каждой части информации степень, в которой нам НУЖНО ее понимать, например, для конфиденциальной информации нужна более высокая степень. DM использует эту информацию для управления ходом диалога, например, если человек сказал что-то о деликатной теме, и мы не уверены, что поняли, то DM задаст вопрос подтверждения. См. Roque and Traum (2008).

TrindiKit Архивировано 2012-02-23 в Wayback Machine DS, разработанный в ходе проекта Trindi Архивировано 2012-05-11 в Wayback Machine , позволяет авторам определять сложное информационное состояние и писать общие правила, обрабатывающие это состояние. Вот пример правила:

интегрироватьОтвет: предварительные условия: («Если человек дал релевантный ответ на обсуждаемый в данный момент вопрос...») в(SHARED.LM, ответ (usr, A)) fst(SHARED.QUD, Q) релевантный_ответ(В, О) эффекты: («... затем удалите его из обсуждаемого вопроса и добавьте его к общей основе») поп(SHARED.QUD) уменьшить(Q, A, P) добавить(SHARED.COM, P)

В зависимости от входных данных и состояния DM решает, какие правила применимы, и применяет их для получения нового состояния.

Это может помочь авторам повторно использовать общие правила для правил управления диалогами, основанные на теориях диалогов. DS, разработанные с помощью TrindiKit, включают: GoDiS, MIDAS, EDIS и SRI Autorate.

Подход на основе информационного состояния был позднее разработан в таких проектах, как Siridus (архив 2012-03-23 ​​на Wayback Machine) и Dipper toolkit.

Другим примером диалогового менеджера на основе информационного состояния является FLoReS. Он использует пропозициональное информационное состояние для кодирования текущего состояния и выбирает следующее действие с помощью процесса принятия решений Маркова . Этот диалоговый менеджер реализован в программном обеспечении jmNL.

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

Информировать(Говорящий,Слушающий,Предикат): Предпосылка: Знает(Говорящий,Предикат) И Хочет(Говорящий,Информирует(Говорящий,Слушающий,Предикат)) Эффект: Знает(Слушатель,Предикат) Тело: Верит(Слушатель,Хочет(Говорящий,Знает(Слушатель,Предикат)))

Разговор можно вести с помощью общего планировщика, например SOAR (Сильные стороны, Возможности, Стремления и Результаты). Планировщик сохраняет текущее состояние и пытается построить план для достижения цели, используя заданные операции.

Похожий подход используется в SASO-ST ^[1] (DS для многоагентного обучения переговорам). Использование SOAR позволяет включать сложные эмоциональные и социальные модели, например: агент может решить, основываясь на действиях человека, хочет ли он сотрудничать с ним, избегать его или даже атаковать его.

Похожий подход используется в TRIPS ^[2] (DS для многоагентного совместного решения проблем). Они разделяют управление диалогом на несколько модулей:

• Менеджер ссылок - имея слово (например, «женщина»), определите, к какому объекту в мире оно относится (например, «WOM1234»).
• Менеджер задач — определение действий по решению проблем, которые пытается выполнить пользователь (создание новой цели, расширение существующей цели и т. д.).
• Менеджер по устному переводу — в дополнение к вызову первых двух, также определите обязательства по дискурсу, например: «ответить на последний вопрос».
• Поведенческий агент — решает, как достичь цели, которую хочет пользователь. Агент использует несколько агентов, ориентированных на конкретные задачи, которые занимаются фактическим планированием.

Другой тип планирования — доказательство теорем . Диалог можно описать как попытку доказать теорему. Система взаимодействует с пользователем, чтобы предоставить «недостающие аксиомы», которые помогут завершить доказательство (это называется «обратная цепочка»). Этот подход был реализован:

• Грамматическая структура. ^[3]
• IPSIM (прерываемый симулятор Prolog) в системе Circuit Fixit. ^[4]

Менеджер диалогов может быть подключен к экспертной системе , что даст возможность отвечать на вопросы с использованием конкретных экспертных знаний.

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

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

• Просто предположите, что наиболее вероятная интерпретация верна, и продолжайте разговор ( без подтверждения );
• Продолжайте разговор, но добавьте несколько слов, которые показывают понимание, например: «Хорошо, вы хотите пойти в ресторан. Куда именно?» ( неявное подтверждение ).
• Спросите пользователя, что именно он хотел сказать ( явное подтверждение ): «Вы имеете в виду X?», «Вы сказали X или Y?» и т. д.
• Скажите пользователю: «Я не понял, повторите, пожалуйста».

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

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

Некоторые DS имеют несколько режимов работы: режим по умолчанию — это режим инициативы пользователя , в котором система просто спрашивает «что я могу для вас сделать?» и позволяет пользователю вести беседу. Это хорошо для опытных пользователей. Однако, если между пользователем и системой возникает много недопониманий, DM может решить перейти к смешанной инициативе или инициативе системы — задавать пользователю явные вопросы и принимать один ответ за раз.

Тактические решения другого типа принимаются Cordillera (учебная DS для обучения физике, созданная с использованием TuTalk). Во многих моментах урока DM должен решить:

• Сообщите ли ученику какой-либо факт или попытайтесь вытянуть из него этот факт, задавая наводящие вопросы.
• Попросить ли ученика обосновать свой ответ или просто пропустить обоснование и продолжить.

Эти решения влияют на общее качество обучения, которое можно измерить путем сравнения экзаменов до и после обучения.

Вместо того, чтобы позволить человеку-эксперту написать сложный набор правил принятия решений, более распространено использовать обучение с подкреплением . Диалог представлен как процесс принятия решений Маркова (MDP) — процесс, в котором в каждом состоянии DM должен выбрать действие, основываясь на состоянии и возможных вознаграждениях за каждое действие. В этой настройке автор диалога должен определить только функцию вознаграждения, например: в диалогах обучения вознаграждением является повышение оценки ученика; в диалогах поиска информации вознаграждение положительно, если человек получает информацию, но также есть отрицательное вознаграждение за каждый шаг диалога.

Затем методы RL используются для изучения политики, например, какой тип подтверждения следует использовать в каждом состоянии? и т. д. Эта политика впоследствии используется DM в реальных диалогах.

Учебное пособие по этой теме написали Лемон и Ризер (2009).

Другой способ изучения политики диалога — попытаться подражать людям, используя эксперименты «Волшебника страны Оз», в которых человек сидит в скрытой комнате и говорит компьютеру, что говорить; см., например, Passonneau et al (2011).

• Traum, 2008: Подходы к диалоговым системам и диалоговому управлению - Конспект лекций и библиография.
• Allen et al., 2001: Towards Conversational Human-Computer Interaction. Обзор DM по сложности: конечно-статистические, основанные на фреймах, наборы контекстов, основанные на планах, основанные на агентах. Описание системы TRIPS на основе агентов.
• Больше исследовательских работ по управлению диалогом