Hi,
I’m back in writing my blog with a topic which I’m working quite a lot in the last months, as chatbots or conversational bots are becoming quite popular.
The idea is to write some of the key topics that we have been working with in Dialogflow projects, the Google Cloud service to create chatbots.
The tool is coming from the bought of API.AI some time ago, and nowadays is SaaS solution where you can create conversational agents to provide service with a number of integrations or an API.
With this blog I won’t be replacing the official docs, which are here; I would try to be practical in showing how to work with Dialogflow. There will be some specifics about Spanish language in some of the later posts.
Many of the tests will be shown using Google Assistant, the assistant available in Android phones (and others), the family of Google Home devices, cars with Android Auto, etc. You can also integrate Dialogflow with mobile applications, web pages, … it is clear that the amount of use cases for using voice as a natural way to interact with customers is growing a lot.
This diagram shows the flow and the different pieces that will play a role to create a bot that will interact with us in a Google Home device:
Let’s start with the definitions shown in the diagram:
An action in Actions on Google is an app published to interact with it from any Google Assistant client. We will see later how to publish a DialogFlow agent.
An “agent” in Dialogflow is a single conversation agent published to one or several Dialogdlow integrations, or consumed via its API. The agent is linked to a Google Cloud project; we will show in a later post how to leverage additional resources in Google Cloud, or other services, to perform part of the needed actions in a agent.
A Cloud Function in Google Cloud is a piece of code, node.js only if you code inside DialogFlow, but with alternatives to use other languages, that we can use for a number of things. The Google Cloud service take the needed steps to deploy, scale, provide high availability, etc. In Dialogflow we use Cloud Functions to create the fulfillments in our agents, in other words, to create the logic and process data to provide more elaborated answers to the users.
Going into Dialogflow with deeper detail, in an agent we have to understand some additional concepts:
An Intent is a user interaction with a specific meaning that will trigger an action or answer in our bot. In general we have to define an intent for each possible message provided by the user, independently of the moment of the conversation that we find it, but not directly related to the answers that we will provide to the user, that would be created by the logic in our agent. In this video you can find more details about intent.
A training phrase is an example of what the user can say to the bot, and it will be used to build a Machine Learning model based in natural language processing. Thanks to this way of working, with Dialogflow it is not needed to define hundreds of examples with each possible variant in the language; our bot would be able to automatically interpret similar phrases. In a normal production environment the number of training phrases per intent should be around 20 to 40.
You can define literal and sample based training phrases, as we will see in a later post.
An Entity is used to extra values from the phrases provided from the users, like dates, places, amounts, etc., so you can leverage those values in your bot. There are system define entities, like dates and cities, and you can also use custom defined entities for your bot. In those customers entities, we can use synonyms for each entity and entity type; for example we can have an entity called vehicle, with a types named car and motorbike. For motorbike you can then use synonyms like bike or scooter.
You can also crear composed entities, with 2 previously defined ones; for example red car can be a composed entity consisting in a color entity and a vehicle entity. Finally you can also have user entities, which are tied to a user session with a 10 minutes duration, that can be defined in our agent code.
The key benefit of entities, is that to define a training phrase you only need to label the entity to have the natural language engine understand all the different types and synonyms for that entity, so you can greatly reduce the amount of training phrases.
There are some additional details in this video.
The parameters in an intent are the variable that you capture based on entities, and that we would the leverage in our conversation. We can make some of these parameters mandatory, so the bot will ask for them before triggering the intent answer.
The intent answer is defined within the same intent if it is a simple text that we can build with a predefined text and some parameters, but if we need to process adicional information, create more sophisticated dialogs, etc., we will need programming to define the next action or answer to be provided after the event is triggered.
This is what we call a fulfillment, and is the responsible for the logic in our bot. We can create it with a web service, programmed externally to Dialogflow, or we can leverage the code editor in Dialogflow, based in node.js, which will deploy a Google Cloud Cloud Function for us. In this blog we are going to use this last option.
A context is the way to flag in which step of the conversation of an agent we are. For example, when de detect that user wants to make a reservation, we will define and output context called “reservation”. Using this context as the input context for an intent, it will only be triggered if the context has been already defined.
One example of context usage are the intents for yes/no answers. If our dialog with the user has several questions that might be answer with yes/no, we would need to define one yes and no intent for each possible context, so each yes/no will get into the proper conversation flow, and the answer/action that it provides is linked to the conversation that the user is having.
The follow-up intents allow us to restrict intents to moments after previos intents were matched. I have read in several docs that is better to avoid them and have all or most of the intents un-nested, but I don’t know why.
In this third and last video you will find an explanation of context and how to define the conversation flow with them. Later we will see that creating a diagram with the conversation flow, the context and parameters will be quite useful to create our agent.
Our last definition is for events, which are predefined or user defined actions in our fulfillments, that allow us to trigger a particular intent. In fact, every bot will start with a triggering event; in the case of Google Assistant, when our agent is call a “Welcome” event will be created, and by default an intent called “Default Welcome Intent” will be executed.
In the following posts we will see more details on how to work on the following topics in Dialogflow:
- This post
- Building Intents and conversation flows
- Call a fulfillment to process information
- Use of Entities, parameters and contexts
- Connecting to a DataStore database
- Using events to call Intents
- Creating rich answers for surfaces
- How to add a second language to our bot
- Authentication with account linking
I will be updating the links as I create the new posts. If you have any special interest please leave a comment so I can prioritize the posts.
For the examples I will use an agent called “Martinez Hotels”, a fake hotel brand that I use in my demos. For the moment we can do quite simple reservations, what we will improve it over time.
Regards,
Jamarmu
============================================================
I work for Google Cloud, but this post are personal ideas and opinions
