How I Design NL for Chatbots With Decision Tree Model of Flow
What is a Decision Tree again?
For almost a year, I have been making chatbot flows and mapping their Natural Language Understanding (NLU) with Kata Platform. Along with these experiences, I’ve designed both simple chatbots that only serve a few goals and conversational chatbots which need a more complicated NL design.
Types of chatbot flow
In Kata.ai, we make two types of chatbots flow. The first type is floating flow. Chatbots with floating flow usually doesn’t have a complicated diagram. This only consists of greetings, a list of handled topics, and fallbacks. This type of flow enables users to get immediate objectives without facing more than 1 layer of menu.
The other type of flow is a tree-like model of diagram that we like to call it, layered flow. Although we still don’t have an official term for this, a decision tree type of model consists of several layers of a menu — hence layered flow — this type of flow usually designed for a chatbot with more diverse topics and contents.
NLU vs. Keyword
Some people might ask why we need to design NL for bots with a layered flow since it usually uses keyword. Though keyword-based chatbots are relatively easy to make, we found this particular bot is tricky to build in some ways. The problem that often arises at making keyword-based chatbot is keyword overlapping. We can not implement the same keywords for two or more states, and it causes confusion in choosing proper keywords other than using numbers or unique words. Thus, although the bot’s use case is considered a piece of cake (which is never ha!), we always try to build it with NLU.
Some ask, when do we start working on the bot’s NLU? As both conversation and NL designer, I always start mapping out the bot flow first before designing the NLU. This is because the bot flow helps us to determine how complicated the NLU will be. Let’s take the diagram above as an example.
The second diagram above illustrates a bot flow that can answer user questions such as, “how to buy furniture?” or “how to refund mattress at the store?”. If you read again, both of these questions have different sentence structures. It is the reason why the bot flow has three layers of information. This layered flow will resolve incomplete user questions then point them to answers they’re looking for.
How do I map the NL for every state?
After knowing which state in the bot needs NL, we will prepare data to be trained and tested. This data is a collection of user’s sentences that can be used for creating training data. This group of user’s sentences will also be used to test the bot. We can create our own data by analyzing the bot’s use case, or we can also get it from the clients if they provide their user’s data. Remember that although we already have data to be trained, we still need to gather, analyze, and add more data to train when needed. This may seem a lot but several of the data we gather will be used to train while the rest of them can be used for testing. This way, we would have a more stable NL.
The data we gathered then classified into each state that has responses. As seen in the picture below, every state with answers — purchase info, purchase mattress info, and purchase mattress online — has its own testing data. This will help us map out the intent and entities for its NLU.
With this collection of sentences, we can define the intent and entity we need to build NLU for this bot. An intent is an input that represents the user’s purpose or intention while an entity is an object or term that helps specify the intent. Both of them are the keys to mapping out an NLU.
But how do we define intents and entities? First, identify the user’s purpose that can be answered by this bot. There are two kinds of intents we can find; buy and refund. The next step is deciding the entity. Since an entity helps the bot to define the user’s particular intention, we can determine the object or complement in the input sentence are the entities. Below is an example of how we define the intents and entities.
Now, we have figured out what we need to map out the NLU, we can list down all of the required intents and entities.
For the next step, we might want to come back to the second diagram and list down all of the states that have bot responses. We can list them in a table to make our NL map more comfortable to read.
Finally, all of the bot states have their own NL map. All that’s left is inputting training data for each intent and entity on our Kata Platform. The most confusing part of training chatbot’s NLU has ended — at least for me. The rest of the steps after designing or mapping out the NLU are mainly focused on collecting training data.
TL;DR
Chatbot with a decision tree model or layered flow can also be an NLU-based bot instead of a keyword-based. Designing NLU for this type of bot can be started by outlining the chatbot flow first. The NL designer begins to compile and determine what intents and entities are needed from this flow to be inputted into chatbots via the Kata Platform. After these steps are done, the NL designer can start training the bot based on the NLU map that has been made.
We designed the chatbot’s NLU this way so the design of the NLU that had been made could be expanded when the bot is getting updated or additional features. Of course, this will ease clients and bot developers because they don’t have to go through complicated steps to upgrade their existing bots.
