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

Question

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

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

用户要求 3 个城市。

调用 Webhook 并选择 3 个随机城市。此时，webhook 服务还创建了一个用户实体 @user-cities用于通过 REST API 进行的 session 。我们甚至可以将 SQL 标识符作为键，将城市名称作为可能的同义词。

在后面的意图中，我们引用 @user-cities对于一个参数。当根据他之前的城市列表向 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包含歌剧院或海滩条目的用户实体，但不包含有关钟楼的任何内容。而对于“伦敦”，我们可能会添加有关塔楼和桥梁的实体，但不会添加有关海滩的实体。

重点是你想从用户那里听到什么，而不是你想记住的谈话内容。