How To Create A Chatbot With Google Dialogflow
Basic Overview Of Dialogflow and How It Compares with Other Cloud Environments
Introduction
There are a number of Conversational AI and Conversational UI development environments available, to build what we will call a chatbot. To some of these environments the barrier to entry is quite high, to other again not so much.
Lower barrier of entry might attract much attention initially, but then run into impediments when scaling. Dialogflow has seemingly a very low barrier of entry if you consider cost, ease of use and accessibility.
The other factor attracting users to Dialogflow is the desire to build interfaces on Google Assistant , Google Home and other Google related devices.
My Top 5 Most Popular Bot Medium Stories:
- The Four Pillars of Chatbot Architecture
- What You Wish You Knew About Chatbots
- Your Chatbot Should Accommodate These Six Entity Types
- Do’s and Don’ts For Building Your Chatbot
- Why Your Chatbot Conversation Must Allow For Digression
If you want to learn and familiarize yourself with the basic structure and key components of chatbot architecture, Dialogflow is an excellent playground to get started and experiment.
Intents
Intents are the front line of any chatbot, they can be seen as the verb. Also the working word or phrase, the intention of the user conversing with your chatbot.
Hence the first action you will perform is to detect what the intention of the user is. Creating intents in Dialogflow is top of the list, for good reason. First you can name your intent, and add training phrases. The training phrases will be used by Dialogflow to train its cognitive model.
You will see there is an item called Events. Events is a very handy tool, we will not use it in this example. However, in short, you can trigger your intent based on an event and not user input. This is particularly useful with Google Assistant on different devices.
Conveniently, you can test the intent by inputting text in the testing pane and seeing if your intent is triggered.
Entities
If intents are the verbs, entities are the nouns. These are the key elements you want to capture form user input.
For a weather application, it will be a city, or a region.
In most cases entities are detected automatically and are also fully contextual. This means that you do not need a finite list of entities, but Dialogflow can detect the entity based on contextual awareness in terms of the user’s utterance.
In the image above, an European city is automatically detected; other cities can be annotated manually.
The image to the left is an example of how a word can be selected, and by clicking an appropriate entity can be selected to assign that word to.
The system entities of Dialogflow is very strong and established.
Multiple entities can defined within an expected utterance. This is the way as humans usually speak.
For instance, “I want to travel from Lisbon to Amsterdam on Thursday at 5pm”.
Here is an example of training phrases or sentences being annotated with the city name. You need to be creative with the wording of your utterance to ensure you cover most permutations.
Again we see a general trend in chatbot development environments, where entities and intents merge to some degree.
Testing
This is a distinct advantage of Dialogflow, testing is easy and can be done incrementally as you progress. In general incremental testing is real easy with cloud based solution.
Another helpful thing is the fact that the saving of changes and the training of the agent goes very fast. There is no long wait period to build the model prior to you being able to test.
Testing input and output can be in text or voice. Should you not want to test in the Dialogflow test pane, you can break out tot he Google Assistant Simulator in seconds.
Essential should Google Assistant be your primary medium of choice for taking your conversational experience live. You can view the raw API response also, which is of great use for documentation and development.
Integration
Integration points are referred to by Dialogflow as Fulfillment. Within the intent you can define if there is any integration. In this example you will see I used the Inline editor. This simple webhook captures the entity of City and returns it with a custom dialog.
The actual dialog to be displayed to the user can also be defined in the integration point.
package.json
{
"name": "DialogflowFirebaseWebhook",
"description": "Firebase Webhook dependencies for a Dialogflow agent.",
"version": "0.0.1",
"private": true,
"license": "Apache Version 2.0",
"author": "Google Inc.",
"engines": {
"node": "6"
},
"scripts": {
"lint": "semistandard --fix \"**/*.js\"",
"start": "firebase deploy --only functions",
"deploy": "firebase deploy --only functions"
},
"dependencies": {
"firebase-functions": "^2.0.2",
"firebase-admin": "^5.13.1",
"googleapis": "^27.0.0",
"actions-on-google": "2.2.0",
"dialogflow-fulfillment": "0.5.0"
}
}index.js
/**
* Copyright 2017 Google Inc. All Rights Reserved.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/'use strict';const functions = require('firebase-functions');
const {google} = require('googleapis');
const {WebhookClient} = require('dialogflow-fulfillment');exports.dialogflowFirebaseFulfillment = functions.https.onRequest((request, response) => {const agent = new WebhookClient({ request, response });function Weather(agent) {
const city = agent.parameters['geo-city'];agent.add(`The weather in ${city} is fine and mild.`);
}let intentMap = new Map();
intentMap.set('AskCity', Weather);
agent.handleRequest(intentMap);
});
Context
Context can be managed by making use of Dialogflow as merely an API and performing this within your own framework. But also, you can set the context within the intents.
You get the option to define input and output context. The time the context is valid can also be set. An option is the use follow-up intents. Again, for a larger implementation I am sure you will move the dialog management out of the Dialogflow environment.
Knowledge Base
Knowledge Connectors are still in beta, and might change over time. It is not included in this tutorial, but it is worth a few considerations.
This is analogous to how IBM Watson Assistant can be integrated to Watson Discovery. Watson Discovery can be searched using natural language, and this allows Watson Assistant to default to Discovery in an attempt to fulfill the intent.
Cisco MindMeld has a similar concept where they use Elasticsearch to create a knowledge base option.
This is a powerful option to have, it can add huge resilience to your chatbot.
So in essence knowledge connectors compliment and support intents. Documents can be parsed which can include FAQ’s, address lists etc.
To configure, you define one or more knowledge bases, which are collections of documents.
This is a feature which can also be make available to agents to search a knowledge base in their attempt to help a caller. But a knowledge base must be seen as a fallback option due to the fact that the responses might lack precision. You will also have less control over the response, as opposed to intents.
Using Dialogflow API
Creating a test application, wire-frame, mock-up or prototype is always fulfilling and satisfying. And, indeed, you do get the sense of the immense natural language processing power you have access to. There is also a realization of the potential of this technology.
However, in most cases when the chatbot goes into production, it can be fast and efficient, but as it grows in users, functionality and mediums (mediums aka channels; for instance RCS, WhatsApp, Messenger etc.) the architectural design is tested.
Scaling becomes problematic and enhancements and growth are impeded by technological restrictions. Hence it is of utmost importance that the architecture of the solution is well planned and thought out.
For using Dialogflow as an API, the sequence of events can be seen as follows:
- The end-user types or speaks an expression.
- Your service sends this end-user expression to Dialogflow in a detect intent request message.
- Dialogflow sends a detect intent response message to your service. This message contains information about the matched intent, the action, the parameters, and the response defined for the intent.
- Your service performs actions as needed, like database queries or external API calls.
- Your service sends a response to the end-user.
- The end-user sees or hears the response.
In most cases Dialogflow will be used as an API to facilitate the NLU in terms of:
- intent detection,
- entity and slot capture
- and what the response should be.
There will be a framework which facilitates the communication with Dialogflow, and also other system integration points like CRM and the like.
You will also need to implement a mediation layer, which will take the chatbot dialog and transform it into the right media for the medium. For Messenger the chatbot dialog will be displayed differently as opposed to WhatsApp, or Text Messaging or the Web.
Conclusion
If you are looking at building a quick interface, especially speech, for Google Assistant this is ideal. If you will not have multiple dialog turns and complex dialogs to manage and contextual awareness, this is your path. The handling of entities is very good; in most cases the entity is detected automatically.
If not, there might be better options…
When looking at the cloud solutions available, Dialogflow is a very intuitive and fast way of getting started. One of the advantageous will be cost and ease of access.
Creating intents are straightforward, and the convergence of intents and entities are evident and necessary. Dialogflow’s auto detection of entities when entering user utterances is intuitive and detects the intent of the developer.
The Integration points what Dialogflow refers to as fulfillment can be tricky, but you have the choice to create your own JSON based integration point or hosting it on Cloud Functions for Firebase.
The latter is what I used for the example.
Obviously this is a convenient way of getting your chatbot, or conversational application out on Google Assistant, which facilitates access to a multitude of devices.
The Standard Edition of Dialogfow has no charge, but there are quotas involved, so some consideration will have to be given to expected volumes and how this might impact cost.
The obvious disadvantage is that you will be at the behest of Google and affect by changes they make to their solution. Your chatbot will live in the cloud, and protection of private information and other related concerns will always exit.
The question is, do we want to also farm-out our chatbot to Google. This is where Rasa is gaining traction, and organizations have a growing appetite to have a local, contained installation.
Managing the dialog will become complex and an issue, if you are using Dialogflow for Google Assistant it will suffice, and it is actually very convenient. However, the moment you start building more complex dialog structures, you will have to facilitate state management and context management to another environment.
Articles On Other Bot Frameworks
Read More Here…
The source project is here:
