Создание чат-бота с помощью Amazon Lex и AWS Lambda

Создание чат-бота с помощью Amazon Lex и AWS Lambda

Это всеобъемлющий обзор от идеи до реализации

Введение

Amazon Lex следует базовой архитектуре чат-ботов, которой придерживаются все крупные облачные поставщики диалогового ИИ. Вам нужно будет создать намерения, объекты, ваш сценарий (формулировка диалога) и, конечно же, поток диалога.

Диалоговый поток также называют конечным автоматом или пользовательской историей.

Следует отметить, что все среды разработки чат-ботов очень похожи по подходу и базовой архитектуре.

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

Единственная реальная инновация и отказ от некоторых из этих общепринятых архитектурных столпов исходит от Расы.

Базовая архитектура

Намерения

В Lex идея намерений соответствует тому, что делают IBM и Microsoft (LUIS и Power Virtual Agent). Lex позволяет создавать намерения, для которых можно добавить ряд фраз вызова. Намерения — это единичные намерения; однако Rasa работает над несколькими намерениями с помощью своего конвейера Tensorflow. Подробнее об этом читайте здесь.

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

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

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

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

Сущности

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

Вот где Lex отстает от разработок, которые я видел с Microsoft LUIS, IBM Watson Assistant и особенно с Rasa. В этих средах происходит конвергенция намерений и сущностей. Особенно в LUIS имеется очень богатый набор типов сущностей, которые можно настроить.

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

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

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

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

Здесь раса исключительна; у них есть учебник, в котором вы разрабатываете погодный чат-бот, чтобы определять погоду в любом городе мира. Итак, вы можете себе представить, что невозможно иметь конечный список всех названий городов мира. Название города должно быть определено по контракту.

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

Итак, это действительно разочаровывает отсутствие настоящей конфигурации контекстуальной сущности.

Скрипт

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

Также можно сформулировать ответ клиента или приглашение в сервисе AWS Lambda Python и передать этот сценарий или диалоговое окно Лексу.

Диалоговый поток (конечный автомат)

Диалоговый поток (также известный как управление состоянием или управление состоянием) аналогичен тому, как Microsoft LUIS вписывается в структуру ботов Microsoft.

Lex позволяет настраивать среду NLU, API NLU. Но для переменных сеанса, управления диалогами и задач, связанных с конечной машиной, вам необходимо подключиться к функции Lambda. Или просто используйте Lex в качестве API-интерфейса NLU и напишите структуру своего бота на другом языке; как C#, Python, или использовать фреймворк типа Django.

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

Впоследствии функция Lambda должна вернуть Lex полезную нагрузку JSON. Соединение можно протестировать через текстовую консоль, и во время тестирования будет видна полезная нагрузка JSON.

Тот факт, что эта часть архитектуры находится за пределами среды Lex, можно рассматривать как как силу, так и слабость.

IBM Watson Assistant имеет очень аккуратный встроенный диалоговый менеджер с расширенными параметрами настройки.

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

Использование Lex в качестве API NLU

Чтобы сделать вашу среду Lex доступной в виде спокойного API с URL-адресом, ключом доступа и секретным ключом, вам необходимо использовать Amazon IAM (управление идентификацией и доступом).

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

Вам необходимо убедиться, что регион, в котором определен ваш экземпляр Amazon Lex, отражен в вашей подписи безопасности Amazon в Postman, а также в URL-адресе.

Во-вторых, вам нужно использовать Post. Логика заполнения слота

лямбда

Это код Python для функции Lambda… вы можете видеть, где я извлекаю сущность и имя намерения из входящей полезной нагрузки JSON.

Сразу же я создаю исходящие полезные данные с двумя переменными сеанса с именами key1 и key2.

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

def lambda_handler(event, context):
    entity = event["currentIntent"]["slots"]["Name"].title()
    intent = event["currentIntent"]["name"]
    
    response =  {
                  
    "sessionAttributes": {
    "key1": "value1",
    "key2": "value2"
  },
                        "dialogAction":
                        {
                            "fulfillmentState":"Fulfilled",
                            "type":"Close",
                            "message":
                                {
                                    "contentType":"PlainText",
                                    "content": "The intent you are in now is "+intent+"!"
                                }
                        }
                    
                }
    return response

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

Вывод

Проблема с большими облачными решениями NLU/NLP всегда будет оставаться проблемой защиты личной информации. Здесь Rasa остается надежным решением, если вы хотите запустить локальную и изолированную установку. Cisco MindMeld также является опцией.

Сравнение Lex с Watson Assistant и Microsoft LUIS действительно подчеркивает слабую функциональность контекстных объектов Lex. Невозможно установить истинные контекстуальные объекты, которые не могут иметь конечный список значений. Выбор типов сущностей также невелик.

Здесь Microsoft LUIS лидирует с точки зрения типов сущностей, которые действительно зависят от контекста.

Лекс не упоминает орфографическую коррекцию, отступление, нечеткое соответствие и т. д.

Очевидно, что Amazon Lex хорошо справляется со всем, что связано с AWS; и пользователи Lex склонны использовать Lambda и мобильные сервисы AWS после запуска.

Когда речь заходит о Microsoft и IBM Watson Assistant, у пользователя определенно гораздо больше свободы. Не говоря уже о Расе.

Если у вас тесные отношения с AWS в вашей организации и вы используете множество сервисов AWS, то Lex — сильный соперник. Кроме того, если вы принимаете во внимание стоимость; что является огромным соображением и препятствием в целом для IBM Cloud.

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

Больше обо мне…

Окончательный комплект документов…

https://docs.aws.amazon.com/lex/index.html

Вот хорошая статья о соединении с почтальоном