何时在对话流中使用用户实体？

Question

在Dialog Flow (API.ai) 中的数据上下文在哪里，我询问了如何保留特定于用户的数据。例如，用户要求提供城市列表，webhook 服务随机选择三个。如果您稍后想引用此列表中的城市，则需要以某种方式存储它。这个问题的答案是它可以在上下文中来回转移。

现在我在文档中阅读了有关用户实体的信息。这对我来说是一个未知的概念。我现在的问题是：我们是否也可以将用户实体用于这样的流程？例如：

1. 用户要求 3 个城市。
2. 调用 Webhook 并选择 3 个随机城市。此时，webhook 服务还@user-cities通过 REST API 为正在进行的会话创建一个用户实体。我们甚至可以将 SQL 标识符作为键，将城市名称作为可能的同义词。
3. 在后面的意图中，我们参考@user-citiesfor 参数。当根据他之前的城市列表向 webhook 服务提供有效城市时，将提供标识符。然后，Webhook 服务可以使用此标识符来提供有关该城市的其他信息。

示例流程：

User:  Please provide me some interesting cities.
Agent: What about New York, Berlin and Barcelona?
User:  Please tell me more about Barcelona!
Agent: Sure, Barcelona is ...

我还没有尝试过这个，但我想知道这是否是用户实体的一个很好的应用程序？后续问题是：何时使用用户实体，何时将数据保留在上下文中？

Answer 1

虽然这可以工作......有点......它并不是真正的用户实体的良好应用。最大的问题是，您现在正在进行 API 调用来为“this”或“that”或“that first one”等术语创建别名。并且您不断更改这些实体定义，包括删除旧别名和设置新别名。

用户实体最适合您了解该用户与其他用户不同的信息。以您的城市为例，您可以使用用户实体来存储一个人最喜欢的城市或他们对这些城市的任何昵称。用户登录后，您就可以设置@user_cities他们的城市昵称，现在就可以使用了。

更新 使用另一个示例，再次使用您的城市框架。

选择特定城市后，您可以更改其功能和别名的用户实体。因此，如果用户选择“悉尼”，您可以创建一个@feature包含歌剧院或海滩条目的用户实体，但不包含有关钟楼的任何条目。而对于“伦敦”，我们可能会添加有关塔和桥的实体，但不会添加有关海滩的实体。

重点是您想从用户那里听到什么以及您想记住对话的内容。