Building Chatbots with Google Dialogflow
The course is part of this learning path
This course is the second part of our series on building chatbots using Google Dialogflow. In this course, we'll be taking a hands-on approach to implementing a Dialogflow chatbot, specifically focusing on the graphical user interface. You'll follow along as we cover the example of building an online banking customer service chatbot using Dialogflow.
We'll also discuss the use of databases and other knowledge sources in order to provide meaningful responses that give you the option to serve real-world information to your user.
- Learn what intents are and how to train your chatbot to look for them
- Set up entities in Dialogflow
- Understand how chatbots interact with users and how to test your chatbot
- Learn how to connect your chatbot to a data source
- Understand the user interfaces available with Dialogflow
- Learn how to use the Knowledge service to build chatbots quickly and with less configuration
- Anyone looking to build chatbots using Google Dialogflow
Before taking this course, make sure you've done Part One first. To get the most out of this course, you should also have a basic understanding of:
- Computer science techniques
- REST APIs and SQL
- Google Cloud Platform
So actually having a conversation brings us to one of my favorite features within Dialogflow. It actually has a built-in simulator on the right-hand side of the screen where you can actively test and try out your bot. This allows you to make sure that your training flows well and that your training phrases are capturing everything you meant to say and test all of these permutations and making sure it succeeds before having to put in the time to do a full-blown build and deployment.
This way, if you don't see an error, or if you do see an error, you know right away, so you could deploy with confidence or, frankly, if you're anything like me, have an error come out and go back and fix it before other people notice.
So let's simply type a phrase into the simulator, such as balance for 1234T, and then you could see in real time how the Dialogflow bot processes it. You could see that it successfully detected your intent of check card balance, and you could also see on the right hand side that it successfully parsed your credit card number to 1234T, and this is all really cool but there's still even one more thing we could do with it, and that's view the responses, and that brings us to our last point.
What is the usefulness of Dialogflow and its simulator if we can't see how it responds? So what we need to do is build some sample responses and then come back to the simulator to finish testing it completely. So as you know, responses are literally what we say back to the user, so when the user asks, what is my bank account balance for 1234e, a response is literally what gets sent back to them in their chosen language.
I want to make a distinction here, though, that a response is not what the fulfillment option says back to Dialogflow, but rather, the response to the user and what they see. The fulfillment response to Dialogflow is actually slightly different than what the user sees.
So to take the previous example of check the credit card balance for 1234e, we can actually see and slot in the parameter to the response. The parameter is slotted by using a dollar sign before the parameter name, and once again, this is where naming the entities is really useful, and by doing this slotting in with the dollar sign, you're able to create a really nice dynamic response.
So here you can see that we're able to make a customized Thank you for your inquiry regarding card number, and then slotting in the card number. That feature would be coming soon, and having that dynamically filled in without having to go to the back end. I would also like to direct everyone's attention to the plus sign next to the word default. You can actually customize how to react to different platforms based on both the intent and who we're responding to and where.
So for example, if somebody asked a question of Dialogflow over Google Messenger or Google Assistant, we could actually phrase the responses very differently. Previously, I mentioned it's important to understand the hardware device that somebody is on because they're going to have very different expectations of meaningful data. This is also a great way to dive in in how to handle different interfaces without creating separate agents or even having to create separate intents.
So, having customized responses depending on the hardware is a good way to keep your number of agents low and your number of intents condensed while adapting to the hardware that somebody is using. So with your response programmed, let's go back to the simulator, and we can now test a query against the new response system. We can type check balance for 1234e, and you can actually see, once you send it, that the intent is captured and that the default comes back with the parameter slotted in. So this means we have a well-designed intent with good parameters and a good entity-capturing system with responses.
So, what left is there? Well, what if the user makes a mistake and messes up? In one of our earlier examples, Edith forgot to include her card number. So if we don't have a credit card number, what do we do? Well, we'll have to ask her.
So let's talk about how to handle this scenario. How do we take full advantage of slot filling and the multi-step conversational model that Dialogflow uses? And that brings us to the action of parameter section of the intent menu. Now this section is automatically filled in, so you're going to see some stuff there already and it's filled in when it was assigned the parameters and the associative entities while doing training phrases.
So, if you've previously set up entities and training phrases, you'll see the corresponding entries in this section, and as a quick aside, you can actually use a quick color reference because it's consistent between the sections. So you could see the entity and parameter associated with each action, and also as a side note, it's a really important comment that the parameter name and entity name are different. This is because in some examples, we might have the same entity assigned to multiple parameters. We actually have this exact scenario where if somebody is transferring money between two of the like kind payments cards.
Now when setting up actions and parameters, a key point is to check out the check box on the left. This box allows you to mark an entity as required or not required, and if you check it, that means it's required and it'll have to do a follow-up prompt or else the intent literally cannot be processed. So when you click it, a new section appears all the way on the right hand side called prompts. This is how we instruct Dialogflow to make requests in a very clean and very easy-to-use fashion.
In this example, card number is absolutely required or else we can't look up their balance. So when we click required and we click into prompts, we can actually see how the user is going to be asked for a follow-up. We could say things such as sure, oh, but I need to get the card number first, what is it? And we can actually, on top of that, set quite a few different ones. This allows us to set some conversationality and some tone and some flavor to our bot beyond just being a pure robotic response that gives the same answer every time. And one final nuance, if you remember, is that an entity may be required, but we can also have it go to a default.
So in a previous example, we discussed something like what about time of day? So a user might ask, what is the balance of my card on last Friday? It's safe to make some assumptions about what a user's talking about, and in those cases, make a default, so unless a user specifies a period of time for their bank balance, we might just say it's today. We can configure this by clicking on dots on the right hand side of the action parameters section, and you can set it to a default but this is only present when it's required. This is useful when a user doesn't specify a time period and we assume a default, and this allows you to have your bot be both easy-to-use while labeling power users to really dive into it and have really precise answers. And with that configured, we can take it back to the simulator.
So now you could type something where you intentionally forget the card number. You could type something like, literally, card number, and you could see that Dialogflow prompts you to give it a response at this point, and at this point, you don't need to provide anything else except the card number. Dialogflow is session-aware in this sense, and you don't need to re-type card balance for 1234A. You can simply say 1234A, and it's aware of what you meant. It's also really cool because you could see it through the error processing in real time, and if you're a power user, check out the additional contexts and associated variables in the middle of the screen, and then, based off this response, we're able to see how it goes through everything and provide a real response in an end-to-end fashion.
So now, not only are you able to use the simulator for simple phrases, you're also able to use it as a real user would in a situation where they are prompted for slot filling and need help. I also want to draw your attention to one more thing on the simulator screen. At the bottom, there's a diagnostic info tab. If you're ever using the simulator yourself, be sure to click this because it gives you a bit more of a deep dive into what's going on. This shows you some of the JSONs that Dialogflow had sent to the back end for fulfillment, and in fact, if you're gonna work with a broader team, taking a few of these and sending them to a back end programmer could really help them get started while you're still programming some of the chatbot.
So now, to cap off this agent, let's go back to the requirements section and look at what intents we've actually covered and what we're looking to still make. We've done a really good job so far covering some of the intents, specifically the ones where you need an individual card balance, but what about the one where we need to check multiple cards? This could be a little tricky. You might think that all cards might actually need to be a separate intent, but if we were to do that, the separate intents would have high degree of overlap and not be good.
So interestingly, we can make the word all a valid card number even though it doesn't match the pattern. The back end would have to do a little bit extra parsing in order to look up the word all against the actual credit card numbers, but Dialogflows and regex can have additional rows for additional matching patterns, so we can make it match the word all and fill that phrase in for a back end credit card number lookup, and what this allows us to do is keep the intents nice and clean without having any overlap, and also, just thinking out loud, we should also be ready to dismiss the improper account ID that's not needed.
Now the approach we ended up needing of using regex, without any of the automated expansion or fuzzy matching, we won't really suffer from an account ID leaking in because we are very strictly looking for a credit card number, but if you wanted to make another entity that's trained to detect account ID, and then flat out dismiss it, that's also a good option because capturing entities so that there's no noise and unknown variables is really easy to set up and it should pay high dividends as you go to production.
And before we move on, let's briefly discuss the other intent, where we have to transfer money from one card to another, and this gets a little bit interesting. We actually have three parameters in here. In the phrase, $200 from card 1234A to 6543T, there's both a new entity in here, which is dollar_amount, but there's also two parameter slots for the same entity of payment card type.
Now, I touch on this briefly, but this is where the nuance between parameter field name and entity name type is important because both of these cards are the same but one is a sending card and one is a receiving card. So while although they're both the same entity and they've been trained to be slotted the same, Dialogflow has an awareness of parameters.
So when testing this and doing training phrases, be sure to mix it up. Say, send money from card 6543T to 1234A along with receive money on card 1234A from 6543T. Mix up the order and the variables so that you're not always putting the sending card before the receiving card, but there's also a new entity type of dollar_amount.
Now dollar_amount, we've discussed previously, it's a system variable that is type unit currency. Now, this is where Dialogflow shines as you're able to reuse these, even if you've made them for a separate intent, and this also applies to the credit card number entity. Entities can be shared between intents, which will make setting up this set of training phrases way easier than the first time we did it and we had to create all new entities.
So this shows how Dialogflow can expand to become easier to manage as you make it more and more sophisticated.
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.