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

0

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

我们将 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 机器人中都遇到了这种行为。

1개 답변
0

【以下的回答经过翻译处理】 Amazon Lex现在提供了FreeFormInput Slot类型,这可能是一个值得尝试的好事情。内置函数可以识别由单词或字符组成的字符串。解析的值是用户提供的完整的自由表单输入。

profile picture
전문가
답변함 일 년 전

로그인하지 않았습니다. 로그인해야 답변을 게시할 수 있습니다.

좋은 답변은 질문에 명확하게 답하고 건설적인 피드백을 제공하며 질문자의 전문적인 성장을 장려합니다.

질문 답변하기에 대한 가이드라인