Amazon Connect“获取客户输入”块退出，最后一个 Lex 槽问题（自定义数据类型）的“错误”分支包含通过 Lambda 处理的未知槽值（回退转录）

【以下的问题经过翻译处理】 总而言之，这个问题整个星期都让我难过……我会尽我所能，尽可能清楚地描述这种行为……

我们将 Amazon Connect Contact Flows 与小部件“Get Customer Input”结合使用，以通过自动化的 Lex V2 机器人体验路由呼叫者。我们正在为我们的公司收集有关潜在客户需求的信息。在联系流“获取客户输入”中，我们仅在两条路径上退出：默认和错误（然后从默认，我们检查会话属性并确定流程中的后续步骤）。所有这些都按预期工作。

轰炸我们的部分是下面概述的情况：

• 在呼叫者可以选择和触发的每个不同问题意图的末尾，我们有一个自定义数据类型，用于捕获冗长的用户问题描述（对于描述他们特定法律案件的呼叫者，例如：告诉我你的受伤情况，或者是什么您希望解决的主要问题等）
• 关键是，这种自定义数据类型是一个通用的“赶上”语音到文本仅用例。我们实际上并没有试图从内部泄露这个插槽的有意义的属性。它本质上有点像语音邮件录音消息。因此，用户的答案非常开放，而且千差万别。我们完全意识到并感谢这不是通常构建插槽的方式......
• 因此，很难为这种自定义插槽类型训练数据，因为它有点像用户讲述的迷你故事，它可以是任何东西。我们已经尝试用数百个插槽话语进行训练，但我们仍然遇到很多回退（我们期望和处理）。我们之前与 AWS Lex SA 交谈过，他们认为如果我们训练 200-300 个短语，我们应该能够捕捉到所有内容。但是我们仍然会得到很高的答案，但这些答案会被遗漏……
• 所以我们不想根据任何经过训练的插槽类型话语数据来验证答案——我们只想将 inputTranscript 保存到插槽中，然后继续。
• 我们在 每个 对话轮上使用 Lambda codehook，并检查回退，如果发生回退，我们从字面上获取 inputTranscript Speech-to-Text 并手动将其保存到插槽中。
• 当我们的自定义数据类型问题不是槽列表中的最后一个问题时，这非常有效。它完全按预期工作：感知 Fallback，获取 inputTranscript，保存它，然后通过为下一个问题显式调用 DialogAction type = ElicitSlot 继续前进。
• 但是，在最后一个自定义数据类型的问题上，当 Invocation 从 DialogCodeHook 更改为 FulfillmentCodeHook 时，我们再次保存最后一个值，并调用 DialogAction type = Close。** 如果此处出现回退值，Lambda 和Lex Conversations 日志也不记录任何错误。但是 Amazon Connect“获取客户输入”会进入“错误”分支而不是“默认”分支。** 注意：如果我们对最后一个问题给出“干净”的答案（经过测试训练的答案之一） ，DialogAction type = Close 的 FulfillmentCodeHook 逻辑工作得很好，没问题......

我为工作案例或中断案例传递给 DialogAction Close 的意图有效负载完全相同——当然，只有最后一个问题槽值不同。

我的 Lambda 中没有出现错误。 Lex 对话日志中没有错误。但是 Amazon Connect 在“获取客户输入”小部件发出的“错误”路径上严重失败，而且 CloudWatch 中几乎没有来自 Connect 端的更多信息显示“为什么”它会遇到错误分支。

我已经尝试了所有我能想到的；在最后一个问题自定义数据类型回退问题上，是否还有其他人有任何想法或看到类似行为？

最后一点：我在 8 月 17 日之前和 8 月 17 日之后发布的 Lex V2 机器人中都遇到了这种行为。