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

Если вы еще этого не сделали, я настоятельно рекомендую вам прочитать два предыдущих поста из этой серии:
Разработка диалогового IVR с использованием Rasa
Разработка диалогового IVR с использованием Rasa, часть 2: мост Rivr. »

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

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

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

IVR поддерживает стратегии смешанной инициативы, такие как отступления:

А также запросы на изменение или исправления:

Диалог также обрабатывает восстановление после ошибок, в том числе ошибок, характерных для голосового канала:

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

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

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

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

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

Это можно проиллюстрировать следующим образом:

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

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

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

Пользовательская политика

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

Менеджер действий

Мы создали абстракцию для управления описанным выше стеком действий. Стек — это сложный объект, который мы храним в нефункциональном слоте. Выполняемое действие зависит от ввода пользователя, а также от состояния стека.

Пользовательские шаблоны диалогов

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

Платформа модульного тестирования

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

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

Мы поделимся нашим опытом в следующих постах по мере продвижения вперед. Быть в курсе!

Первоначально опубликовано на https://www.nuecho.com 23 июля 2019 г.