何时在Dialog Flow中使用用户实体？ [英] When to use user entities in Dialog Flow?

问题描述

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

In Where is the data context in Dialog Flow (API.ai) I asked how to keep user-specific data. For example, the user asks for a list of cities and the webhook service randomly picks three. If you then want to refer later to a city in this list, you somehow need to store it. The answer in the issue was that it could be transferred back and forth in the context.

现在，我在文档中了解了用户实体。这对我来说是个未知数。我的问题现在是：我们是否也可以将用户实体用于此类流程？例如：

Now I read about user entities in the documentation. This was an unknown concept to me. My question is now: could we also use user entities for such flow? For example:

1. 用户要求3个城市。


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


3. 在以后的意图中，我们指的是 @ user-cities 作为参数。将基于其先前城市列表的有效城市提供给Webhook服务时，将提供标识符。然后，webhook服务可以使用该标识符提供有关城市的其他信息。

1. User asks for 3 cities.
2. Webhook is called and 3 random cities are picked. At this moment, the webhook service also creates a user entity @user-cities for the ongoing session via the REST API. We could even have the SQL identifier as the key and the name of the city as a possible synonym.
3. In later intents, we refer to the @user-cities for a parameter. When a valid city, based on his previous list of cities, is provided to the webhook service, the identifier will be provided. The webhook service can then use this identifier to provide additional information about the city.

示例流程：

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 ...

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

I did not try this out yet, but I am wondering if this is a good applicaiton of user entities? The follow-up question would be: when would you use user entities and when would you keep the data in the context?

推荐答案

虽然这行得通...有点...但这并不是用户实体的良好应用。最大的问题是您现在要进行API调用，以为 this或 that或 that first first之类的术语创建别名。而且您正在不断更改这些实体定义，包括删除旧别名并设置新别名。

While this would work... sorta... it isn't really a good application of User Entities. The biggest issue is that you're now making an API call to create an alias for terms like "this" or "that" or "that first one". And you're constantly changing those entity definitions, including removing old aliases and setting new ones.

用户实体最适合您所知道的与该用户有所不同的事情其他用户。以您的城市为例，您可以使用用户实体存储一个人喜欢的城市或他们在这些城​​市中拥有的昵称。用户登录后，您便可以设置 @user_cities ，他们的城市昵称现在可用。

User Entities are best for things that you know about that user that will differ from other users. To use your cities as an example, you may use user entities to store a person's favorite cities or any nicknames they have for those cities. Once the user logs in, you'd then set @user_cities and their nicknames for a city are now available.

更新
要在城市框架中再次使用另一个示例。

Update To use another example, again with your cities framework.

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

You might change a User Entity for features and aliases about a particular city once it is selected. So if the user selected "Sydney", you might create a @feature user entity containing entries for the opera house, or the beach, but not anything about a clock tower. While for "London" we might add entities about a tower and a bridge, but not a beach.

重点在于您想听到的声音与您要记住有关对话的内容。

The focus is on what you want to hear from the user vs what you want to remember about the conversation.

这篇关于何时在Dialog Flow中使用用户实体？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！