Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску

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

  • Входными данными для DM является человеческое высказывание, обычно преобразованное в какое-то системно-зависимое семантическое представление компонентом понимания естественного языка (NLU). Например, в диалоговой системе планирования полета ввод может выглядеть как «ЗАКАЗ (от = TA, до = JER, дата = 2012-01-01)».
  • DM обычно поддерживает некоторые переменные состояния , такие как история диалогов, последний неотвеченный вопрос и т. Д., В зависимости от системы.
  • Выход из DM представляет собой список инструкций к другим частям диалоговой системы, как правило , в семантическом представлении, например , «ТЕЛЛЬ (летно-Num = 123, летное время = 12: 34)». Это семантическое представление обычно преобразуется в человеческий язык компонентом генерации естественного языка (NLG).

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

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

  1. DM управления вводом, которые позволяют контекстно-зависимую обработку человеческих высказываний.
  2. ДМ управления выходом. которые позволяют создавать текст в зависимости от состояния.
  3. Стратегический контроль потока
  4. Тактический контроль потока

Управление вводом DM [ править ]

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

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

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

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

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

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

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

Управление выходом DM [ править ]

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

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

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

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

DM стратегического управления потоком данных [ править ]

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

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

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

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

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

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

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

Иерархическая структура [ править ]

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

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

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

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

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

Отслеживание тем [ править ]

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

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

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

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

Заполнение формы [ править ]

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

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

  • Добро пожаловать в систему подтверждения рейсов. Какой у вас номер рейса?
    • 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 DS, разработанный в ходе Trindi проекта, позволяет авторам определить комплексное информационное состояние, и писать общие правила , которые перерабатывают это состояние. Вот пример правила:

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

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

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

Подход информационного состояния был развит позже в таких проектах, как Siridus и инструментарий Dipper .

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

Общее планирование [ править ]

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

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

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

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

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

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

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

  • Грамматические рамки. [3]
  • IPSIM (Interruptible Prolog SIMulator) в системе Circuit Fixit. [4]

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

Мастер тактического управления потоком [ править ]

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

Обработка ошибок [ править ]

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

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

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

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

Инициативный контроль [ править ]

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

Педагогические решения [ править ]

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

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

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

Выученная тактика [ править ]

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

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

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

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

Ссылки [ править ]

  1. ^ САСО-СТ
  2. ^ ПОЕЗДКИ
  3. ^ Ranta и Купер (2004)
  4. ^ Смит, Хипп и Бирманн.

Дальнейшее чтение [ править ]

  • Traum, 2008: подходы к системам диалога и управлению диалогом - конспекты лекций и библиография .
  • Аллен и др., 2001: На пути к диалоговому взаимодействию человека и компьютера . Обзор DM по сложности: с конечным числом состояний, на основе кадров, наборов контекстов, на основе планов, на основе агентов. Описание агентной системы ТРИПС.
  • Другие исследовательские работы по управлению диалогами