在 Amazon Lex 中标记 validation/parsing
Stagged validation/parsing in Amazon Lex
我想制作一个简单的报价机器人，它需要知道地址和维度。目前我已经破解了一个与 python 状态机和 rasa NLU 一起用于意图的东西，尽管数据的性质意味着大多数实体最好手动提取。
例如，开头句可能是 "i want to send 4 boxes from A postcodeA to B postcodeB they're 3 by 3 by 3m each"。这些地址需要验证，这可能涉及来回（您是指这个邮政编码，还是那个州？这不是有效的匹配项，请从此列表中选择，等等...）。
此外，验证的顺序可能很奇怪。例如，可以有郊区、邮政编码和 is_valid 槽。有几种可能性：他们可以输入一个有效的 S + P，只是 S，一个无效的 S，一个有效的 S 和 P，它们单独有效但不匹配，等等。在某些情况下，我想推迟验证以利用其他信息，例如，如果给出的郊区无效但邮政编码有效，我会使用邮政编码来告知对正确郊区的建议。但是，如果给出了一个无效的郊区但没有邮政编码，那么要求邮政编码是没有意义的，因为我想先获得一个有效的郊区。通过这种方式，据我所知，'suburb'、'postcode'、'is_valid' 的插槽顺序并不能完全削减它。
我想郊区和邮政编码的验证调用可以有自己的一组 switch 语句，这些语句查看可能同时填充的其他插槽？似乎有点先有鸡还是先有蛋，因为还需要等待对它们的验证，并且最终可能需要从 Lambda 内部调用 Lambda。例如，如果验证失败，机器人会要求提供更多信息，但 that 信息的验证可能需要 different process/lambda比原始输入
也可能是他们没有包含有关该对象的任何详细信息，在这种情况下，需要在地址内容全部整理好之后再提示。例如，如果他们没有包含有关尺寸的信息，我想问“尺寸是什么”，并允许他们只包含测量值或重量和数量 - 我将其理解为标准插槽填充。
所以我的问题是：difficult/reasonable 在 Lambdas 中进行验证调用实际上如何导致对话中出现旁路？以前我在插槽填充设置中做了类似的事情，在整个地方都有 'is_valid' 插槽（特别是如果我不想简单地抛出“无效”错误并自动重新询问原始问题')。有没有更好的方法？
此外，如何管理 'interrupt' 意图？也就是说，一组会触发 'do you want to go restart?' 类问题的意图，如果用户回答 'no'，这些问题将 return 恢复到原始状态，并且理想情况下，如果他们回答是 return 可以 return 到对话中的特定点（我想这可以通过将适当的插槽重置为空来实现）
此外，不拘泥于 Amazon Lex 的想法，任何减少样板代码量的预制案例也很好。
抱歉吐字。
哇，好的，这就是我可以提供的：
1。验证难度
how difficult/reasonable is it to have validation calls in Lambdas actually lead to side-paths in the conversation?
构建复杂的验证和对话算法是 Lex 服务机器人开发人员的标准做法。因此，期望自己在 Lambda 或其他地方执行此操作并仅将 Lambda 用作 go-between 是非常合理的。所以困难在于你自己，也许你可以找到可用于验证地址和邮政编码的 API，例如 Google 地图，使这部分变得更容易。
2。 'is_valid' 插槽
Previously i had done something like this in a slot-filling setting by having 'is_valid' slots all over the place (especially if I don't want to simply throw an 'isn't valid' error and robotically re-ask the original question'). Is there a better way?
Lex 确实有更好的方法：sessionAttributes！一个好的做法是只创建插槽来保存实现每个意图所需的值。对于 任何东西 其他，您可以愉快地依靠 sessionAttributes 来跟踪对话路径、槽有效性、槽历史、意图历史、中断意图等等，等等，等等，尽你所能想象。如何组织您的机器人逻辑并跟踪会议的当前和过去状态完全取决于您。
例如：您可以有插槽：postalCodeA
而在sessionAttributes中还有：postalCodeA_valid、postalCodeA_confirmed、postalCodeA_attempts等
并使用这些 sessionAttributes 值来确定逻辑中的对话路径。当您发现某个插槽无效时，您可以将该值保存在 sessionAttributes 中的 ..._attempts 或 ..._history 列表中，然后将 ..._valid 设置为 false，然后重新设置null 的插槽，以及 re-elicit 带有解释其无效原因的消息的插槽，或者尝试引出地址插槽而不是邮政编码插槽。
3。中断意图
Also, how would one manage 'interrupt' intents? That is, a set of intents which would trigger 'do you want to go restart?' kind of questions
正如我之前暗示的，答案也是sessionAttributes！当您的用户处于一个意图 (intentA) 内时，Lex 将首先尝试用他们的输入填充当前的引出槽，但如果不匹配，Lex 还将检查输入是否与不同意图的表达相匹配。因此，您可以使用 "let's start over"、"nevermind"、"back up" 等语句来创建中断意图 (intentB)。然后在所有正常意图中，您保留该意图的槽值的备份在 sessionAttribtues 中，以及类似 last_intent 的内容，以了解用户之前的位置，以防它发生变化。
这将允许您像这样处理中断意图：
- 用户输入 intentA
- intentA 填充一些槽，并在
sessionAttributes 中备份它们
- 用户说 "lets start over" 触发了 intentB
- intentB 要求确认取消 intentA
（是）intentB 在从 sessionAttributes 和 returns 用户擦除 intentA 值后实现意图以 elicitIntent 开始并询问 "how else may I help you?"
（否）intentB 将用户传递回 intentA（您知道这一点是因为您跟踪了 sessionAttributes.last_intent）并通过 confirmIntent 发送了继续使用 intentA 的确认："Alright, I still remember where we left off, would you like to continue {intentA action}?" （响应将发送到 intentA，您可以在其中处理）。
- （如果用户想继续使用 intentA）intentA 填充
sessionAttributes 中的新空槽并使用其他 sessionAttributes 值继续您的算法直到它停止的点，提供与上次使用的相同的引出插槽，用户对您的机器人的智能印象深刻。 =)
我想制作一个简单的报价机器人，它需要知道地址和维度。目前我已经破解了一个与 python 状态机和 rasa NLU 一起用于意图的东西，尽管数据的性质意味着大多数实体最好手动提取。
例如，开头句可能是 "i want to send 4 boxes from A postcodeA to B postcodeB they're 3 by 3 by 3m each"。这些地址需要验证，这可能涉及来回（您是指这个邮政编码，还是那个州？这不是有效的匹配项，请从此列表中选择，等等...）。
此外，验证的顺序可能很奇怪。例如，可以有郊区、邮政编码和 is_valid 槽。有几种可能性：他们可以输入一个有效的 S + P，只是 S，一个无效的 S，一个有效的 S 和 P，它们单独有效但不匹配，等等。在某些情况下，我想推迟验证以利用其他信息，例如，如果给出的郊区无效但邮政编码有效，我会使用邮政编码来告知对正确郊区的建议。但是，如果给出了一个无效的郊区但没有邮政编码，那么要求邮政编码是没有意义的，因为我想先获得一个有效的郊区。通过这种方式，据我所知，'suburb'、'postcode'、'is_valid' 的插槽顺序并不能完全削减它。
我想郊区和邮政编码的验证调用可以有自己的一组 switch 语句，这些语句查看可能同时填充的其他插槽？似乎有点先有鸡还是先有蛋，因为还需要等待对它们的验证，并且最终可能需要从 Lambda 内部调用 Lambda。例如，如果验证失败，机器人会要求提供更多信息，但 that 信息的验证可能需要 different process/lambda比原始输入
也可能是他们没有包含有关该对象的任何详细信息，在这种情况下，需要在地址内容全部整理好之后再提示。例如，如果他们没有包含有关尺寸的信息，我想问“尺寸是什么”，并允许他们只包含测量值或重量和数量 - 我将其理解为标准插槽填充。
所以我的问题是：difficult/reasonable 在 Lambdas 中进行验证调用实际上如何导致对话中出现旁路？以前我在插槽填充设置中做了类似的事情，在整个地方都有 'is_valid' 插槽（特别是如果我不想简单地抛出“无效”错误并自动重新询问原始问题')。有没有更好的方法？
此外，如何管理 'interrupt' 意图？也就是说，一组会触发 'do you want to go restart?' 类问题的意图，如果用户回答 'no'，这些问题将 return 恢复到原始状态，并且理想情况下，如果他们回答是 return 可以 return 到对话中的特定点（我想这可以通过将适当的插槽重置为空来实现）
此外，不拘泥于 Amazon Lex 的想法，任何减少样板代码量的预制案例也很好。
抱歉吐字。
哇，好的，这就是我可以提供的：
1。验证难度
how difficult/reasonable is it to have validation calls in Lambdas actually lead to side-paths in the conversation?
构建复杂的验证和对话算法是 Lex 服务机器人开发人员的标准做法。因此，期望自己在 Lambda 或其他地方执行此操作并仅将 Lambda 用作 go-between 是非常合理的。所以困难在于你自己，也许你可以找到可用于验证地址和邮政编码的 API，例如 Google 地图，使这部分变得更容易。
2。 'is_valid' 插槽
Previously i had done something like this in a slot-filling setting by having 'is_valid' slots all over the place (especially if I don't want to simply throw an 'isn't valid' error and robotically re-ask the original question'). Is there a better way?
Lex 确实有更好的方法：sessionAttributes！一个好的做法是只创建插槽来保存实现每个意图所需的值。对于 任何东西 其他，您可以愉快地依靠 sessionAttributes 来跟踪对话路径、槽有效性、槽历史、意图历史、中断意图等等，等等，等等，尽你所能想象。如何组织您的机器人逻辑并跟踪会议的当前和过去状态完全取决于您。
例如：您可以有插槽：postalCodeA
而在sessionAttributes中还有：postalCodeA_valid、postalCodeA_confirmed、postalCodeA_attempts等
并使用这些 sessionAttributes 值来确定逻辑中的对话路径。当您发现某个插槽无效时，您可以将该值保存在 sessionAttributes 中的 ..._attempts 或 ..._history 列表中，然后将 ..._valid 设置为 false，然后重新设置null 的插槽，以及 re-elicit 带有解释其无效原因的消息的插槽，或者尝试引出地址插槽而不是邮政编码插槽。
3。中断意图
Also, how would one manage 'interrupt' intents? That is, a set of intents which would trigger 'do you want to go restart?' kind of questions
正如我之前暗示的，答案也是sessionAttributes！当您的用户处于一个意图 (intentA) 内时，Lex 将首先尝试用他们的输入填充当前的引出槽，但如果不匹配，Lex 还将检查输入是否与不同意图的表达相匹配。因此，您可以使用 "let's start over"、"nevermind"、"back up" 等语句来创建中断意图 (intentB)。然后在所有正常意图中，您保留该意图的槽值的备份在 sessionAttribtues 中，以及类似 last_intent 的内容，以了解用户之前的位置，以防它发生变化。
这将允许您像这样处理中断意图：
- 用户输入 intentA
- intentA 填充一些槽，并在
sessionAttributes 中备份它们
- 用户说 "lets start over" 触发了 intentB
- intentB 要求确认取消 intentA
（是）intentB 在从 sessionAttributes 和 returns 用户擦除 intentA 值后实现意图以 elicitIntent 开始并询问 "how else may I help you?"
（否）intentB 将用户传递回 intentA（您知道这一点是因为您跟踪了 sessionAttributes.last_intent）并通过 confirmIntent 发送了继续使用 intentA 的确认："Alright, I still remember where we left off, would you like to continue {intentA action}?" （响应将发送到 intentA，您可以在其中处理）。
- （如果用户想继续使用 intentA）intentA 填充
sessionAttributes中的新空槽并使用其他sessionAttributes值继续您的算法直到它停止的点，提供与上次使用的相同的引出插槽，用户对您的机器人的智能印象深刻。 =)