We use Dialogflow entities to capture values.
Here is the official definition:
That might sound a bit too vague, but there is a reason for that. Entities can actually be used to capture a lot of things, as you will see in this article.
The story of the 4416-intent agent
As you might know, Dialogflow has a maximum of 2000 intents per agent.
So here is an email exchange I had with a reader recently (paraphrased).
Reader: How many intents can I have in an agent?
Reader: What if I need more?
Me: Why do you need more?
Reader: So I had this agent already built out, which will provide a response based on the user’s city for a handful of cities. I want it to give a suitable answer for every city on the planet.
As it happens, there are over 4000 cities on the planet, and the reader wanted to create an intent for each one.
While I didn’t find out what actually happened, here is what I believe happened:
This reader had likely created a chatbot using a non-AI platform such as Chatfuel. Since Chatfuel doesn’t have the concept of entities, you will need to do a lot of intent definitions to get such a chatbot to work.
A better way
Here is a better way to do it. Create a Dialogflow entity called CityList.
Now in your intent, when you use a city name from your list in the training phrase, it gets automatically annotated (that is, Dialogflow highlights the entity’s name and tells you that it could infer that it was a city belonging to the CityList you declared).
So what does this mean?
It means that you can capture all the city names you are interested in inside a single intent, and simply upload a list of cities into the entity called CityList.
An even better way
You might be thinking: the list of cities in the world is very well known, so why doesn’t Dialogflow do all this heavy lifting for us automatically? Why do I have to create a list of cities? Why can’t it just infer these values itself?
As it turns out, that’s exactly what Dialogflow does!
In that case, the entities are called system entities because the system (i.e. Dialogflow) already knows about them.
For example, let us see what happens when I type an entity not declared in CityList.
So when you type a value which isn’t in the CityList entity you can see that Dialogflow is still able to annotate it. But this time, the entity is @sys.geo-city and not @CityList as in the previous image.
The @sys prefix is an indication that it is a system entity.
As it turns out, Dialogflow can automatically infer most of the world’s cities*.
So the reader could have probably used just a single intent chatbot.
Types of entities
There are three types of entities in Dialogflow.
These are predefined entities – i.e. these are values Dialogflow can extract out of the box, with no assistance from the bot creator. They have the prefix @sys. Here is a list of system entities you can identify in Dialogflow:
- dates and times
- numbers (including flight numbers)
- amounts with units – currency, length, area etc.
- unit names
- geography – address, zip code, capital, country, city, state, airport etc
- contact – email and phone number
- music artist and music genre
The entities you declare – such as CityList – are called developer entities.
There is also the concept of “short lived” entities called user entities. A good example of this is the idea of a user’s custom playlist of songs. (Obviously, since it is end user specific, there isn’t a way to declare these as developer entities). This is a somewhat advanced concept so I won’t be going into it in too much detail here.
Hopefully, you can now see why the documentation defines entities as “powerful tools for extracting parameter values from natural language inputs”.
* This shouldn’t be generalized to all places – such as smaller towns. Dialogflow usually cannot infer those automatically from user input, especially for towns and smaller size locations outside US.