The course is part of these learning paths
This course is the first in a two-part series that explores how to create a chatbot using Google Dialogflow. We'll take an introductory look at what the Google Dialogflow tool is used for and look at the basic steps and components required to make a chatbot. We'll cover the concepts and technical aspects to consider when building a chatbot, and then put these into context by applying them to a real-world scenario.
- Understand the fundamentals of creating chatbots using Dialogflow
- Learn how chatbots interact with users
- Understand the technical aspects of developing a Dialogflow application
- Learn how the concepts covered in the course can be applied to a real-world scenario
- Anyone looking to build chatbots using Google Dialogflow
In order to get the most out of this course, you should have at least a basic understanding of:
- Computer science techniques
- REST APIs and SQL
- Google Cloud Platform
So to move away from conceptual theory and start digging into the nuances and realities of building an actual Dialogflow agent, let's build off a previous example and let's take the banking concierge bot and start looking at how this might interact with a real user.
Let's take Edith. Edith is a user that wants to check the bank account balance on one of her payment cards. She might send a text message saying, "Hey what is my bank account balance for account?" And then she might also add her bank account number or payment card number like, 1234a.one, two, three, four, A.
If we look at the entity and intent nap, you could follow it down. We know she's talking to the banking concierge agent, because that's the number she's texting. We've also successfully detected the intent that she wants to do, check bank account balance.
So from here, we need to understand the parameters and entities required. We know from the model that account number is a required entity. There's also an optional entity, which is date of balance, but for now we've just simply defined that we're going to check the bank account balance with a parameter that a slot filled for the entity account type or account number.
But I do wanna highlight one very important nuance here. Assumed defaults are very powerful. By having data balance, being assumed a default to today, allows us to add a lot of functionality to the chatbot that power users could take advantage of, but regular users might not to worry themselves with.
Somebody might say, "What is my bank account balance for last Friday?" A newer user or someone like Edith who maybe has never used a banking account bot before, doesn't need to understand that this functionality even exists. And by taking, well, you could call it an opinionated approach to creating a chatbot, we create a highly flexible, highly functional chatbot that doesn't have a steep learning curve like it would if you only had required parameters.
So in this example, Dialogflow is then able to make an API call to the backend service saying, "Hey, we have a user asking for their bank account, here is the number and the intent is to check the balance." And the API will turn that all into a SQL statement or maybe a noSQL statement, depending on how the bank runs our infrastructure and outcome a response, aka the fulfillment.
So we say, "Hi Edith, your bank account balance is $250." Now for those of you listening in that have experience with PII or payment card information, sometimes abbreviated PCI, you might think that this is insecure and frankly you're 100% right. We could do things such as validate phone number and validate other tokens. This is just a high-level example, but it's very important to know stuff such as tokens, phone numbers, and other secure parameters can actually be included as part of session variables, which is something we'll discuss briefly in a little bit.
So let's just put a pin in that for now, but just know we can secure this more and more as we grow. But the really important concept here and something that's key to understanding any new interface that you're putting on top of data, because really that's all Dialogflow is, is a new interface, is that Edith needs no understanding to underlying banking technology.
What we've done is actually make data that is otherwise unaccessible to the common public, maybe someone that a banking analyst with a SQL statement or maybe a website program who has access to a custom API and we've made this data accessible to general humans, because everybody can have a day-to-day conversation and that's how a chatbot aims to understand people.
But what if there's a problem? Users aren't always going to ask a perfect question of our chatbot the first time and it's our jobs to help guide them to the right answer. So when Edith asks, "What is my account balance?", we can look at the entity map and see that there's an issue. Not only because do we not have an optional date entity, we also don't have the mandatory account number.
So how do we handle this? Remember, Dialogflow can handle multi-stage conversations and what we're going to do is a query follow-up and have a question that says, "Hey, what account are you talking to?" This is actually a short-circuited response. This could be called a slot filling query and Dialogflow does not have to make a call to the backend to do this.
To be able to do this, Dialogflow actually interprets which parameters and entities are mandatory and ask predefined follow-up questions to guide the user through the next steps. And when the user starts to answer this, they don't need to the research the entire query and repeat it.
Edith doesn't need to say, "What is my bank account balance for one, two, three, four, A?" All she has to do is respond with one, two, three, four, A and watch Dialogflow direct it in with the original question, combine these two separate lines with the intermediate Dialogflow clarification into a single well-defined backend call. And to use this, revisit the agent intent entity map.
You can now say that everything is successfully filled out. A backend call is made and the backend doesn't even know that there was a follow-up question. All the backend sees is, is that a single call was made, which were able to fulfill the response very natively. And the second important nuance here is that it's important to control the conversation. This allows us to help guide users to ask better questions.
Never assume your user is going to know how to use your bot. Never assume they're gonna read the FAQ, read the documentation or check a Read Me, Dialogflow should be programmed in such a way that it helps guide people to ask the best possible questions.
So the important takeaway here, just to put it in a quick stound snippet, is Dialogflow is able to help users ask better, smarter questions and it also manages the conversation flow. Dialogflow takes an active role in the conversation, not just a passive role in trying to listen to what the user is asking them.
Calculated Systems was founded by experts in Hadoop, Google Cloud and AWS. Calculated Systems enables code-free capture, mapping and transformation of data in the cloud based on Apache NiFi, an open source project originally developed within the NSA. Calculated Systems accelerates time to market for new innovations while maintaining data integrity. With cloud automation tools, deep industry expertise, and experience productionalizing workloads development cycles are cut down to a fraction of their normal time. The ability to quickly develop large scale data ingestion and processing decreases the risk companies face in long development cycles. Calculated Systems is one of the industry leaders in Big Data transformation and education of these complex technologies.