Диспетчер диалогов - Dialog manager

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

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

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

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

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

Вход-контроль DM

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

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

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

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

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

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

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

Выход-контроль DM

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

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

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

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

DM стратегического управления потоком

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

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

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

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

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

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

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

Иерархическая структура

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

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

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

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

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

Отслеживание тем

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

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

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

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

Заполнение формы

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

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

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

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

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

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

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

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

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

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

Простые DM обрабатывают заполнение слотов бинарно: либо слот «заполнен», либо он «пуст». Более продвинутые DM также отслеживают степень заземления - насколько мы уверены, что действительно поняли, что сказал пользователь: было ли это «Недавно введено», «Введено снова», «подтверждено», «повторено» и т. д. Мы также можем разрешить автору указывать для каждого часть информации, степень, в которой мы НЕОБХОДИМО ее понять, например конфиденциальная информация требует более высокой степени. DM использует эту информацию для управления ходом диалога, например, если человек сказал что-то о деликатном предмете, а мы не уверены, что поняли, тогда DM выдаст вопрос подтверждения. Видеть Рок и Траум (2008).

Информационное состояние

В TrindiKit DS, разработанная в Тринди project, позволяет авторам определять сложное состояние информации и писать общие правила, которые обрабатывают это состояние. Вот пример правила:

интегрироватьAnswer: preconditions: ("Если человек дал соответствующий ответ на вопрос, который в настоящее время обсуждается ...") в (SHARED.LM, ответ (usr, A)) fst (SHARED.QUD, Q) related_answer (Q, A ) effects: ("... затем удалите его из обсуждаемого вопроса и добавьте на общую землю") pop (SHARED.QUD) reduce (Q, A, P) add (SHARED.COM, P)

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

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

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

Другой пример диспетчера диалога на основе информационного состояния: ЦЕНТРЫ. Он использует пропозициональное информационное состояние для кодирования текущего состояния и выбирает следующее действие, используя Марковский процесс принятия решений. Этот менеджер диалогов реализован в программное обеспечение jmNL.

Генеральная планировка

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

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

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

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

Аналогичный подход используется в ПОЕЗДКИ (DS для совместного решения проблем с несколькими агентами). Они разделили управление диалогами на несколько модулей:

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

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

  • Грамматические рамки, см. Ранта и Купер (2004).
  • IPSIM (прерываемый симулятор пролога) в системе Circuit Fixit; см. Smith, Hipp & Biermann.

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

Тактический флоу-контроль DM

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

Обработка ошибок

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

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

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

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

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

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

Педагогические решения

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

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

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

Выученная тактика

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

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

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

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

дальнейшее чтение