Picking up specific information to your conversation | Entities in Dialogflow
Imagine yourself talking to someone and at the end of the conversation she/he says: Sorry, I didn’t pay attention, I know you were talking to me but I forgot what you were talking about… What happens then? Conversation doesn’t flow.
It’s for this reason that it’s not only important to know that a conversation has started, it’s also important to collect important information from it, in order to generate alternative responses or flows when talking with our users.
And how can we collect information ?. Through Entities in Dialogflow. But what is an Entity?
They’re powerful tools used to extract required information from a natural conversation. Any important data you wish to obtain from the conversation must have its respective entity created. It’s not necessary to create entities for every possible word or phrase, only for the necessary data.
All right, enough talking and let’s get started!
How do I use Entities?
When we create an Intent, Dialogflow gives us the “Training phrases” section where we will put the entries that will activate the Intent for the user.
How do we use an Entity here? Well, let’s imagine we make an application for our bike shop (Yeah, I love bikes 😆) and one of the entrances is: My road bike is broken, can I go tomorrow?
Even this part is more than enough to activate the Intent, but we don’t collect data in any way. There are two ways to collect them (Example Mode & Template Mode).
Example Mode
The example mode is activated by default in your “Training phrases”. In this mode, words that match your entities will be highlighted in color, and if they don’t match the first time, you can always double-click on the word or phrase you want to be recognized and choose the corresponding entity.
So far so good, but what if I need to validate more than one date? It would be something like this:
So what can we do, one option is to finish putting all the available dates on the calendar and then finish when we are old or . . .
Template Mode
To access this mode, we need to click on the icon on the left and see it change to a “@”
Then, instead of writing a lot of sentences about different dates, we can do something like this:
As you can see, now instead of writing the matches, type the name of the entity (invoked by @) and then Dialogflow will match all the words and phrases of that entity.
Whichever mode you use to match the words, in both cases you need to define the parameters where you will store the data obtained by the entity.
Parameters
Through a parameter, we can connect a word or phrase to a specific entity. We can place them in two sections, “Training Phrases” section and “Action & Parameters” section.
In both sections we observe that there are 3 equal fields: Parameter Name, Entity and Value.
- Parameter Name: It’s the name given as a variable to take the matched value of the entity. It is very important to define them at the beginning, because if a value is not paired with a variable, the console will give them an error when trying to display a simulation. Normally the console automatically puts a name, but if you want you can change it, remember that the name is defined after the colon of the entity. You can change it from any section: “Training Phrases” section or “Action & Parameters” section.
However, always remember to homogenize the names, having different names from the same entity could cause troubles.
- Entity: Name of the entity that matched. Dialogflow has three types of entities:
System Entities
Pre-built entities provided by Dialogflow that facilitate the most commonly used concepts in a conversation.Developer Entities
If you need to recognize more specific or less common words or phrases in your conversation, you can create your own entity to match the data.User Entities
Entities that can be defined for a specific user session. User entities and sessions last 30 minutes.- Value: The Value, is the value obtained from the coincidence between a word or phrase and an entity. Note that in this section you must be very careful of the options that value can offer us, these are default and original.
But, What is the difference between choosing a default and original value?. Let’s take the date as an example, if we ask something like: My road bike is broken, can I go tomorrow? Where “tomorrow” is matching for a Entity. If we invoke an Intent with that phrase, the result obtained would be something like:
But if we mark the original value, the result would be the following:
If we choose to choose the original option, the Intent will literally return what the user said and if we leave it in default, the Intent will return the value interpreted by the Entity. And what kind of values can we obtain according to the Entity? Well, that depends on what entity we’re working, for example:
System Entities
As you know, Dialogflow manages its own entities that greatly help to identify common data in a conversation. This means that we do not have to create any entities of any kind on our own in the Dialogflow console. Among some of them we have:
There are many other system variables, you can find more information about them in the following link. Also there are many ways in which we can use the entities of the system, here are some examples:
During this post we have used @sys.date a lot, so let’s use another one like @sys.unit-length. If we receive “ten meters”, as a result we’ll obtain: {“amount”:10, “unit”: “m”}; unless we use the “original” property we saw earlier and as a result we would get “ten meters” again.
Remember that all values are returned by Dialogflow as JSON
Developer Entities
If we have everything in the System Entities that Dialogflow handles most commonly, what about what it doesn’t handle? There is no such thing as @sys.bikes. So. . . What should we do? Create our own entity.
First go to the left navigation bar and then go to the Entities section, then click on the Create Entity button and let’s get started!
The first thing we will find is a screen where the following main data are required: Entity Name, Primary Value (Reference Value) and Synonyms.
- Entity Name: The name that will identify the entity we are going to create.
- Reference Value: Main word that will serve as a tag to group other phrases with the same semantic value.
- Synonyms: Similar words that represent the same semantic value as the Reference Value.
So, let’s take the bicycle shop as an example, the first thing to create is the entity that contains the types of bikes, let’s call it the @bike-type.
We now have an entity called bike-type with three values, Road, Mountain and Cross bike, each with their respective synonyms. And now with this, we can identify the variables we need when the user asks us something.
Remember that these entities will never return the synonym, on the contrary the Reference Value, unless you select value.original as we saw above. But wait!!, we’re missing a feature of our entities: Automated Expansion.
Automated Expansion - Allows your agent to capture words beyond those defined in your entities list by analyzing both the position and meaning of entities in your intents example phrases. by Dan Imrie-Situnayake
It’s a great feature that it practically allows our entity to grow on its own. Obviously it’s always better to have all the possible options mapped out, but in case we are missing one, Dialogflow can help us with that.
What about if the entity we want to create is a little more complex? A case that happened to me some time ago is that I wanted to capture the value of my country’s currency, the Peruvian Sol (Sol Peruano - PEN). Perhaps you could tell me: for coins there is @sys.unit-currency. So let me tell you that my currency is not yet supported by Dialogflow. I hope someday yes 😆. Then what could I do? I could use a system variable to always capture a numerical value near the word “sol” or “soles” (Spanish words that in English might sound like Sun). But I would leave aside the word “Sol” or “Soles”, and if someone said something that begins with “Sol” and didn’t refer to the currency of my country? Well, I found a way out of my dilemma. Composite Entities.
Composite Entities
When you need to conceptualize an entity with more than one attribute, something more complex than a system entity or a normal entity created by us, you can build your Composite Entity.
Let us take the example of the currency of my country: the “Sol Peruano” (PEN). There are only two possibilities to say it, in singular or plural (Sol or Soles). An important point to take into consideration is the amount, it would be too long to create an entry for each possible number so I can use a system entity to capture the amounts. With that in mind, we can build our composite entity.
First we created an entity that houses the variations of the “Sol” currency.
Then, we create an entity that contains the types of the “Soles” and the amounts that the request may contain.
In order to create your composite entity, you must turn off synonyms. After that you refer the entities you need, for the amount we will use a “number” system entity, and to identify the currency, we mention the entity we created previously. Let’s not forget to put a name for the variables of each entity, otherwise we won’t be able to get the values of what the user says correctly.
Summary, our entity uses:
- Mount: Value of type @sys.number. This will represent the numerical amount of my currency.
- Currency: Value of type @pen-types. This will represent the type of currency I am using.
If we invoke our intent with a phrase like: My road bike costs 20 soles? we can get the following values:
Where currency parameter is “Sol” and the mount parameter is 20.
And last but not least we have the User Entities. These entities are updated per user session, so they usually only last 10 minutes. These types of entities need to be created from the console for then you can modify their content. However, you can also create them from the API. For example, let’s assume you want to list hospitals, restaurants, museums or something specific about a city. If we first chose London we would have a list of museums, for example, very different if we had chosen Paris or Peru. For more information about this type of entities visit this Link. I think I’ll need an exclusive post for this section. 🙄 🤔
Conclusion
It’s good that we have well defined our Intents for everything that the user can say, however it’s just as important to define our Entities, since as I said at the beginning, it’s useless to know that your other party is talking if you don’t understand what it says or do not understand the important information of what it wants to say.
