Dialogues With Dialogflow
An Introduction to Dialogflow
What is Dialogflow?
Dialogflow is a natural language understanding platform used to design and integrate a conversational user interface into mobile apps, web applications, devices, bots, interactive voice response systems, and related uses.
Applications of Dialogflow
Dialogflow used in a variety of applications some of them are,
- Customer service artificial intelligence (AI) agents: Interfaces programmed to answer questions, access orders, make appointments, and take requests.
- Internet of things (IoT): Dialogflow can be applied to IoT devices to make them better at understanding context and responding with precision.
Now we are going to see some of the basic concepts of Dialogflow.
Intent Matching
Intent matching is how we figure out what a user wants. When we’re building a conversational experience, our number one task is to understand what our users are saying. With Dialogflow, our fundamental tool for doing this is the intent. We create an intent for anything a user might request.
Think about a conversational app to handle customer service for a bike repair shop. The Users Intent will be Checking prices, Booking a repair, Get opening hours, Checking repair status, Paying a bill, Ordering parts, etc. For each intent, we provide examples of the various ways the user might communicate it.
We’ll only need a few examples to get started. Dialogflow will use this information to train a machine-learning model to understand not just the examples we’ve entered, but numerous other phrases that mean the same thing.
Now whenever the user says something, our model will match it so whichever intent is a good fit. And for each intent, we can specify how our app will respond.
Let’s see an example of intents being matched. We can see our intents on the right, along with our example phrases, and our user interaction on the left.
Notice how even when the user words their question differently from the examples in our intent, we still know what they mean. That’s possible thanks to our machine-learning model.
So we’ve seen how the examples we provide in our intents train a machine learning model that matches what the user says to one intent or another. A typical Dialogflow agent, which represents a single conversational experience, might have anywhere from a few to thousands of intents, each trained to recognize a specific user need.
we can even build agents that can understand and respond to multiple languages. As people use our agent, we can incorporate what they say into its intents as training examples. So the more usage we get, the smarter our agent becomes.
Entity Extraction
Often when a user expresses an intent, they want our agent to act on specific pieces of information contained within their statement. In addition to matching the statement to an intent, it’s often helpful to pick out any important facts from dates and times to names and numbers. In Dialogflow, we use entities to automatically extract this type of information from what the user says.
For common concepts including dates, place names, and amounts with units, Dialogflow can pick out critical information using its built-in system entities.
It’s also easy to define our own developer entities by providing a list of words or phrases that fit with a given concept. So for a bike repair shop, we could create one entity for types of bike and another for service options.
Now when we create an intent and add example phrases, Dialogflow will recognize which entities might be present. We can also annotate any examples that Dialogflow hasn’t recognized automatically. When a user says something that matches this intent, the values for any matching entities will be automatically extracted, and we can use those values in our backend code to give the user what they’re asking for.
Let’s see an example of entities extracting values. we can see a list of some of our system and developer entities on the right and the user interaction on the left.
In this example, the word “today” was automatically matched by the system date entity. It was resolved to a date string that we can use in our backend.
In this example, we matched three entities. One of them is the system data entity matching “next Thursday.” The other two are developer entities that match a type of service and a type of bike.
But as we all know, conversations are often messy and complicated. Let’s see an example that shows how Dialogflow’s AI shines when handling complex conversations.
The user’s question mentioned both mountain bike and road bike, and it specified three dates yesterday, today, and tomorrow. Despite all this information, our agent was able to pick out the correct day and bike type for the appointment. This is possible because entities are identified based on the information we provide in our intents examples. Dialogflow’s AI can predict where meaningful entities are likely to appear in the text and ignore any distractions.
Dialogflow has three types of entities. Let’s explore how they differ. System entities are built into Dialogflow. Here are just a few examples. They cover common use cases, such as numbers, dates and times amounts with units, and geography. Developer entities allow us to define our own entity based on a list of words, either through the Dialogflow console, our API, or by uploading a CSV. Any word in the list will be matched by the entity.
We can also provide synonyms for the words in the list, if there are multiple ways of saying the same thing, like fix versus repair. And enabling the automated expansion feature allows our agent to capture words beyond those defined in our entities list by analyzing both the position and meaning of entities in our intents example phrases.
We can even create composite entities which combine two or more entities to describe concepts with multiple attributes, like a blue mountain bike, which includes both a bike type and the color. Finally, user entities are special entities that can be defined for a specific user session. They allow us to match transient things, like the details of a user’s previous orders or a list of their local store’s special offers, and they expire 10 minutes after a conversation.
User entities are created programmatically using our API. We now know that intents help us to understand what the user wants and entities give us the details of what they’re talking about.
Dialog Control
we can use intents and entities to capture what our users want to do and the specific things they mention. But there’s more to conversation than making a single statement and getting a single reply. The conversation is a process where two speakers negotiate meaning and understanding through their back and forth. That back and forth over time is what we call a dialogue. So let’s explore how dialogue works in Dialogflow.
There are two types of dialogues we need to consider. We have linear dialogues and non-linear dialogues. Linear dialogues are used in the process of collecting all the information necessary to complete a required action, like booking an appointment or placing an order. Nonlinear dialogue is something closer to a real conversation with branches, twists, and turns based on changes in context.
Let’s take a closer look at linear dialogue. Imagine we’re asking an agent
to book an appointment to repair a bike. Before the agent can help us
it needs to know a few things, the type of service required, the date, and the time. It might be that the user provides all of this information in one statement. In this case, we now know the type of service they need, the date, and the time so we can satisfy their request.
But what if the user only gave us some of the information? Fortunately, Dialogflow can help. When we add entities to an intent, it’s possible to mark them as required. This means that if the user doesn’t say something in their first statement, Dialogflow will automatically prompt for the necessary information, and we can customize the prompt so it sounds natural. We call this feature slot filling.
In the above example, we mark service type, date, and time as required. Since service type is currently missing, Dialogflow will now prompt for it. Slot filling can be incredibly powerful. We can support thousands of possible conversation paths just by checking a few boxes. The user can even go back and change things they’ve already set.
Linear dialogue can be pretty impressive. But it only works when we have a specific set of facts we wish to collect. Non-linear dialogue is something closer to a real-life conversation. When the user says something, it’s interpreted in the context of what was said before. To illustrate, let’s see an example.
In the above example, we saw includes two yes/no questions. When the user answers the first question, our agent knows the user is confirming that booking. As a result, it asks about sending a reminder. When the user answers the second question, our agent knows they are confirming the reminder, not the booking.
To understand which question is being answered and wherein the conversation we are, Dialogflow uses a concept called contexts. For each intent, we can define multiple input and output contexts. In this case, our book repair intent has the output context confirm-repair. When a specific intent is matched, its output contexts are attached to the current conversation state. In this case, the conversation’s contexts now include confirm-repair.
Each intent may also have input contexts. If an intent specifies the input context confirm-repair, it will only be matched if the confirm-repair context is currently attached to the conversation. In our example, we have four intents that match a yes or no from the user. But two of them are yes or no to confirming the repair, while the other’s a yes or no to send a reminder.
We can use context to ensure only the appropriate intent is matched. We add the input context confirm-repair to our repair.yes and no intents. To the yes intent, we also add the output context confirm-reminder. Then we add the input context confirm-reminder to our reminder.yes and no intents.
Because of how we set both intents input contexts, the repair.yes or no intents will only match after the book repair intent and the reminder.yes or no intents will only match after the repair.yes. In addition to acting as a filter, contexts apply a bias to intent matching. So faced with two options, Dialogflow will be more likely to match a given user statement to an intent that has a matching input context.
Contexts expire automatically after 20 minutes. And we can also specify how many subsequent turns of conversation they’ll last. We can also use an intent output context to update or remove any contexts that are currently applied. Contexts are extremely powerful. They can even be used to store data, like the values of parameters, and make it available to subsequent intents.
Another useful tool in our quest to build conversations is the follow-up intent. It provides a shortcut for the common usage of contacts. For a given intent, we can add follow-up intents that will only be triggered after the initial intent has been matched. We can use these to match things like yes or no in answer to a specific question posed by an intent, like in our earlier example.
By making them specific to a single intent, we avoid accidentally matching any yes or no answers given elsewhere in the conversation. Follow-up intents make use of contexts, So we can use them as a shortcut for this powerful feature.
Another useful feature is the fallback intent. fallback intents are triggered
if a user’s input is not matched to any of the available intents. We can use them to help guide the user in the right direction. Every agent comes with a default fallback intent, and we can create follow-up fallback intents that use contexts to ensure that they will only be matched after a specific intent has been triggered.
Key Terms used in Dialogflow
- Agents: A Dialogflow agent is a virtual agent that handles conversations with our end-users. It is a natural language understanding module that understands the nuances of human language.
- Intents: An intent categorizes an end user’s intention for one conversation turn. For each agent, we define many intents, where our combined intents can handle a complete conversation. When an end-user writes or says something, referred to as an end-user expression, Dialogflow matches the end-user expression to the best intent in our agent.
- Entities: Each intent parameter has a type, called the entity type, which dictates exactly how data from an end-user expression is extracted.
- Contexts: Dialogflow contexts are similar to natural language context. If a person says to us “they are orange”, we need context to understand what “they” is referring to. Similarly, for Dialogflow to handle an end-user expression like that, it needs to be provided with the context to correctly match an intent.
- Events: Intents are normally matched when an end-user expression matches an intent training phrase. However, we can also trigger intents using events. Events can be invoked in many ways.
- Fulfillment: By default, our agent responds to a matched intent with a static response. If we’re using one of the integration options, we can provide a more dynamic response by using fulfillment. When we enable fulfillment for an intent, Dialogflow responds to that intent by calling a service that we define.
- Integrations: Dialogflow integrates with many popular conversation platforms like Google Assistant, Slack, and Facebook Messenger. If we want to build an agent for one of these platforms, we should use one of the many integration options. Direct end-user interactions are handled for us, so we can focus on building our agent. Each integration handles end-user interactions in a platform-specific way, so see the documentation for our integration platform for details.
References
- Documentation: https://cloud.google.com/dialogflow/es/docs
- Basics of Dialogflow: https://youtube.com/playlist?list=PListM28kf0CNiMdmz-Ta5UcLR-ePCOW__
- Deconstructing Chatbots: https://youtube.com/playlist?list=PLIivdWyY5sqK5SM34zbkitWLOV-b3V40B
