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

Менеджер диалогов (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, вероятно, должен сохранять временную метку каждого произнесения.

Выход-управление DM

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

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

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

Эта функция находится на границе между ДМ и НЛГ.

Стратегический контроль потока DM

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

integrateAnswer:
  preconditions: ("If the human gave a relevant answer to a question currently under discussion...")
    in(SHARED.LM, answer (usr, A))
    fst(SHARED.QUD, Q)
    relevant_answer(Q, A)
  effects: ("... then remove it from the Question Under Discussion, and add it to the shared ground")
    pop(SHARED.QUD)
    reduce(Q, A, P)
    add(SHARED.COM, P)

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

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

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

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

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

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

Inform(Speaker,Hearer,Predicate):
  Precondition: Knows(Speaker,Predicate) AND Wants(Speaker,Inform(Speaker,Hearer,Predicate))
  Effect: Knows(Hearer,Predicate)
  Body: Believes(Hearer,Wants(Speaker,Knows(Hearer,Predicate)))

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

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

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

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

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

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

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

Тактика управления потоком DM

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

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

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

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

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

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

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

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

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

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

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

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

Изученная тактика

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

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

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

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

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

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