Home / Conversation Design / How to debug your Dialogflow bot
Conversation Design | DialogFlow ES

How to debug your Dialogflow bot

Website Name Change

I have changed the name of this website from Mining Business Data to BotFlo. I am offering a 60% off discount on both my Dialogflow ES and Dialogflow CX courses till April 20th 2021 for people who can help me spread the word about my new website.

I recently got feedback from a reader. He was answering a question about a tool which Dialogflow should have but doesn’t.

Debugging of dialog flow , which is very important tool that should be there

Now, I don’t think you can “debug” Dialogflow by setting breakpoints the same way you would when writing code, at least not yet. But there are a few things you should learn about when you try to debug your Dialogflow bot.

Learn the basics

The first step is to learn Dialogflow itself systematically. It is a very good example of investing some additional time up front, and saving yourself hours/days/weeks in the future.

In my view, the best way to learn Dialogflow systematically is to go in the following order

  • intents
  • entities
  • contexts
  • webhooks

I call these the building blocks of Dialogflow.

You can take a look at my Step by Step Dialogflow tutorial to follow this approach.

Design a flowchart

As Yogi Berra once said: “If you don’t know where you are going, you might wind up someplace else.” 🙂

The reason you design a flowchart is to create a map for the conversation. (Note: for a pure FAQ chatbot, a flowchart isn’t necessary. However, you will often find that even in a pure FAQ bot, you would want to handle some followup questions, at which point the flowchart does become necessary).

And in my view, the best tools for creating Dialogflow flowcharts are Mindomo and XMind. And best of all, it is actually very easy to translate a flowchart created using these two tools into an actual Dialogflow chatbot.

Understand the webhook request response cycle

If you are not a programmer, you need to understand the webhook request-response cycle. This will help you in the following ways

  • get a basic understanding of the webhook flow
  • understand your requirements better
  • avoid using webhooks when you don’t need them
  • communicate your requirements better to your developers

In my Webhooks 101 course, I explain how you can learn the request-response cycle without writing any code at all.

If you are a programmer, my only tip is that you need to learn how to use ngrok so you can step through the webhook code.

In my Dialogflow Webhooks course, you can learn how to design and implement the following types of chatbots:

  • add two numbers
  • API call without parameters
  • API call with parameters
  • read data from database and answer user’s question
  • write data to database and save the input you collect from the user
  • update/manipulate context from your webhook
  • simulate slot filling inside webhook (and fill slots from your webhook code)

The code samples are in PHP, Python and NodeJS.

Note: the lecture videos were created by me, and the code samples were created by my co-instructor Raj. And that is why you see his name as the instructor on the course. (And the course website software doesn’t let me add both of our bios without messing up his instructor fees).

Understand the three primary bot structures

Even after you do all these things, there is still another important aspect to debugging your Dialogflow bot. You need to know your bot “type”.

In my experience, I have seen three primary bot “types”.

Pure FAQ bot

The one and done FAQ chatbot – here the user asks a question, and gets a response. Often this bot doesn’t have entities, which means it is easy to generate it by bulk uploading the intents from a CSV file.

Multi-turn conversation bot

When collecting inputs from the user, you usually use multi-turn conversation bots. Now, I don’t recommend using slot filling, but even a slot filling bot is technically a multi-turn conversation bot.

Reporting bot

This is the kind of bot which answers parameterized queries.

For example, in my Planets Bot, you can ask

what is the color of Earth?

and it will provide an answer.

Here color is an entity of type “attribute” and Earth is an entity of type “planet”. So you could generalize this and think that the bot can answer questions of type:

what is the attribute of planet?

That is what I mean by parameterized queries.

Debugging Dialogflow bots

Now, let us take a look at how you debug these different types of bots.

Debugging a pure FAQ bot

Debugging pure FAQ bots is generally easier because you don’t have to deal with entities and contexts (usually).

Having said that, you do need to get a good understanding of how intent mapping works under the hood.

Specifically, you should understand the following:

  • the role of stop words and stemming
  • using multiple training phrases reinforces the key terms you want to match
  • training phrase quality is an important aspect of your Dialogflow bot
  • the intent detection confidence “score” is a very useful tool when it comes to understanding the intent mapping

If you would like to learn more, I suggest getting the “Dissecting Intent Mapping” course which explains all these concepts in detail.

Debugging multi-turn conversation bots

Here, the most important concept to understand is the idea of candidate intents.

Candidate intents are all the intents that are eligible to “fire” at any given step in the conversation. If you can limit the number of candidate intents at each step in the conversation, it will make it much easier to debug your Dialogflow bot.

Once you do this, you can see why I recommend people use a context lifespan of 1. And why I don’t recommend slot filling. And why I think you should avoid follow up intents as your bot gets more complex (and debugging becomes more important). In summary, I would recommend people follow the explicative approach when creating multi-turn conversation bots.

Debugging reporting bots

Reporting bots are a little different from the other types of bots, because the most important aspect of a reporting bot is reliable entity extraction.

Two things to note here. One, it is very difficult to have “perfect” entity extraction, so you need to aim for reliable entity extraction and handle the exceptions and learn from them. Two, the regular expression entity (which was introduced in summer 2019) is an important tool in your toolbox and you should definitely spend some time understanding how to use it.

Here are some ways to ensure reliable entity extraction.

  • understand the difference between system entities, developer entities and session entities
  • learn how to identify the entities you need in your Dialogflow bot
  • learn about regular expression entities
  • learn about extending system entities to accommodate custom values

If you are interested in learning more, you can check out my Dialogflow Regexp Entity course.

What to do if you get stuck

So what should you do if you are already stuck and cannot debug your Dialogflow bot’s behavior?

Ask the following questions (and write down the answers):

1 Which intent did I expect will fire?

2 Which intent actually fired?

3 Why was it (the intent which fired) a candidate intent?

4 How can I redesign my bot so that the correct intent fires?

Note: unfortunately, this sequence of questions will not work if you use slot filling. Which is one more reason why you should avoid slot filling, in my view. 🙂

This might all seem obvious, but if you actually go through these steps in sequence, you will definitely fix your problem at the end.

If you don’t, leave a comment below this article with a link to your agent ZIP file, and I will help you figure it out.

Similar Posts