Постановочная проверка / разбор в Amazon Lex

Question

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

Например, открывающее предложение может быть«Я хочу отправить 4 ящика из почтового индекса A в почтовый индекс B по 3 на 3 на 3 м каждая».Эти адреса должны быть проверены, что может включать в себя взад и вперед (вы имели в виду этот почтовый индекс, или, может быть, это состояние? Это недопустимое совпадение, пожалуйста, выберите из этого списка и т. Д ...).

Кроме того, порядок проверки может быть странным.Например, можно иметь пригород, почтовый индекс и слот is_valid.Есть несколько возможностей: они могут ввести действительный S + P, просто S, недопустимый S один, действительный S и P, которые являются индивидуально действительными, но не совпадают, и т. Д. В некоторых случаях я хочу отложить проверку, чтобы использоватьдругая информация, например, если был указан неверный пригород, но действительный почтовый индекс, я бы использовал почтовый индекс, чтобы сообщить предложения для правильного пригорода.Однако, если был задан неверный пригород, но нет почтового индекса, нет смысла просить почтовый индекс, потому что я хотел бы сначала получить действительный пригород.Таким образом, наличие порядка слотов «пригород», «почтовый индекс», «is_valid» не совсем обрезает, насколько я могу судить.

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

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

Итак, мой вопрос: насколько сложно / разумно, чтобы вызовы проверки в Lambdas действительно приводили к побочным путям в разговоре?Раньше я делал что-то вроде этого в настройке заполнения слотов, располагая слоты is_valid повсюду (особенно, если я не хочу просто выдавать ошибку 'not valid' и роботически повторять первоначальный вопрос«).Есть ли лучший способ?

Кроме того, как можно управлять намерениями «прервать»?То есть набор намерений, который будет вызывать «вы хотите перезагрузить?»вопросы, которые вернутся в исходное состояние, если пользователь ответит «нет», и, в идеале, если они скажут «да», могут вернуться к определенной точке разговора (что, я полагаю, было бы достигнуто, просто сбросив соответствующие слоты на пустые)

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

Извинения за слово рвота.

Answer 1

Ничего себе, вот что я могу предложить:

1.Сложность валидации

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

Создание сложного алгоритма валидации и диалогастандартная практика для разработчиков Lex сервисных ботов.Поэтому вполне разумно ожидать, что вам придется делать это самостоятельно в Лямбде или где-то еще и просто использовать Лямбду в качестве посредника.Таким образом, проблема в ваших руках, и, возможно, вы сможете найти API, которые вы можете использовать для проверки адресов и почтовых индексов, например, Google Maps, чтобы упростить эту часть.

2.Слоты 'is_valid'

Ранее я делал что-то подобное в настройке заполнения слотов, располагая слоты is_valid повсюду (особенно если я не хочу просто бросать isn't valid' error и роботизированно задайте оригинальный вопрос ').Есть ли лучший способ?

У Лекса действительно есть лучший способ: sessionAttributes!Хорошей практикой является создание только слотов для хранения значений, необходимых для выполнения каждого намерения.Для всего, что угодно , вы можете с радостью положиться на sessionAttributes для отслеживания пути разговора, достоверности слотов, истории слотов, истории намерений, намерений прерывания и т. Д., И т. Д., И т. Д., Насколько вы можете себе представить,Это полностью зависит от вас, как организовать свою логику бота и отслеживать текущие и прошлые состояния конвоа там.

Например: у вас может быть слот: postalCodeA
И в sessionAttributes такжеиметь: postalCodeA_valid, postalCodeA_confirmed, postalCodeA_attempts и т. д.

И использовать эти значения sessionAttributes для определения пути разговора в вашей логике.Когда вы обнаружите, что слот недействителен, вы можете сохранить это значение в списке ..._attempts или ..._history в sessionAttributes, затем установить ..._valid на false, сбросить слот на null и повторновызовите этот слот с сообщением, объясняющим, почему он недействителен, или попробуйте извлечь адресный слот вместо слота почтового индекса.

3.Inrupt Intents

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

Как я уже намекал ранее, ответ на этот вопрос также sessionAttributes!Когда ваш пользователь находится внутри одного намерения (intentA), Лекс сначала попытается заполнить текущий извлекаемый слот своим вводом, но если он не совпадает, Лекс также проверит, соответствуют ли входные данные высказываниям другого намерения.Таким образом, у вас может быть намерение прерывания (intentB) с такими высказываниями, как «давайте начнем сначала», «не будем думать», «создадим резервную копию» и т. Д. Затем во всех ваших обычных намерениях вы сохраняете резервную копию значений слотов этого намерения в * 1047.*, а также что-то вроде last_intent, чтобы знать, где пользователь ранее находился в случае его изменения.

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

1. пользователь вводитintentA
2. intentA заполняет некоторые слоты и выполняет их резервное копирование в sessionAttributes
3. , пользователь говорит, что запускает «позволяет начинать заново» intentB
4. intentB запрашивает подтверждение отмены intentA

(Да) intentB выполняет намерение после удаления значений intentA из sessionAttributes и возвращает пользователя, чтобы начать с elicitIntent, и спрашивает: «Как еще я могу вам помочь?"

(Нет) intentB передает пользователя обратно в intentA (который, как вам известно, потому что вы отслеживали sessionAttributes.last_intent) и отправляет подтверждение продолжения работы с intentA с помощью confirmIntent: «Хорошо, я все еще помню, где мы остановились, не могли бы выАйк, чтобы продолжить {действие интенты}? "(ответ будет отправлен в intentA, где вы сможете с этим справиться).

(если пользователь хочет продолжить с intentA) intentA заполняет новые пустые слоты с sessionAttributes и использует другие значения sessionAttributes для продолжения вашего алгоритма до точки, где он остановился, предоставляя тот же явный слот, который былпоследний, и пользователь впечатлен интеллектом вашего бота.=)