谷歌操作列表响应类型后如何正确处理用户文本输入

Question

我们使用actions.intent.OPTION 来处理 Google Actions 中列表响应类型的选择。 actions.intent.OPTION 不仅处理用户选择（触摸）输入，还处理列表后的用户（语音/文本）响应，并将用户响应很好地映射到列表中的项目。它还可以在一定程度上处理拼写错误。

但是，对于不想从列表响应中进行选择的用户响应，处理起来很困难。基于谷歌官方指南 (https://developers.google.com/actions/assistant/responses#list)，我们使用建议芯片来旋转或扩展对话。

我有一个用例，其中用户可能会使用少量可能的文本来指示他/她不执行选择。例如：

bot: which food do you want?
(showing list)
- rice
- salad
- pizza
(suggestion chip)
not in this list

这些是我们可以处理的用户响应：

• 触摸列表上的选择（米饭、沙拉、披萨）
• 用户文本或语音指示列表中的项目（或类似于列表中的项目）。 Google 操作可能会将“炒饭”视为米饭选择。
• 触摸建议芯片（'不在此列表中'）表示用户不想要列表中的所有项目。我们可以处理这个对话流。

但是，如果用户说出“我改变主意”、“让我们做点别的”、“让我们再做一次”或“重新开始这一步”等其他文本，我们将无法处理此问题，因为 Google 的操作和dialogflow 自动将这些文本映射到列表中最相似的项目（字符串相似度）。

有什么好的做法来处理没有选择建议芯片旁边列表中任何项目的用户响应？我觉得一个建议芯片不足以处理用户响应的许多变化。

Answer 1

当用户通过语音选择列表项时，助手会将输入映射到键和list item 的同义词。然后将密钥作为输入发送回您的 Dialogflow 代理。当映射不成功时，actions_intents_OPTION 事件不会被触发，并且输入会像任何其他输入一样简单地与所有意图匹配。这意味着您可以通过简单地为它们添加正常意图来捕获诸如“让我们做其他事情”之类的请求。为确保此意图在列表选择流程之外不匹配，您应该在呈现列表时设置一个上下文，并将该上下文作为输入上下文添加到 ChangeMyMindIntent。

以下是更详细的工作方式：

• 正常的列表选择将由FoodSelectionIntent 捕获。此意图响应 actions_intents_OPTIONS 事件，即不需要有训练短语。它应该有 food_selection 输入上下文，以将其与其他列表选择意图分开。
• 然后，除了实际选择项目（ChangeMyMindIntent、RestartIntent）之外，您还可以为用户可以提出的所有请求添加其他意图。这些也应该具有food_selection 上下文，以便它们在对话中的任何其他点都不会匹配。
• 渲染列表时，您也设置了food_selection 上下文。这可确保下一个 Webhook 请求将包含有效的列表选择（由 FoodSelectionIntent 捕获）或您已限定为 food_selection 上下文的替代意图之一。
• 不要忘记在这个流程完成后删除food_selection上下文（将其生命周期设置为0），以免限制下一个请求的意图匹配。