Building Contents of Watson Chatbots

In today’s world Chatbots are tremendously transforming the way we interact with software by providing a great business opportunity for almost every company. Chatbots are seen in almost all the websites and also in applications. The first question I ask to myself, what is Chatbot? Chatbots are known by different names some call it “conversational gents”, some “Chatter Robot”.

Chatbots are basically a computer program that mimics written or spoken human speech in its natural format using Artificial Intelligence techniques such as Natural Language Processing (NLP) which is used for conversation purpose. In today’s era Chatbots are most commonly used in customer service space, acts as a human face of the brand for support operatives and customer satisfaction reps. We all know virtual assistants like Apple Siri or Amazon Alexa, are two most popular chatbots interacting via voice rather than text. Chatbots engages their customers in the right place, at the right time, with right information in a cost- efficient way.

Building Chatbots: Intents

Intent is the goal or purpose of the user’s input. Watson conversation expects us to add examples for each intent that our chatbots needs to address. In other words, let’s think of intents as labels for a group of examples that express a common goal or purpose. For examples we might define intent called #greetings OR this intent might be “hello”, “hi”, “hey”, ”good morning”, “good evening” .

Good news is that you’re not stuck with initial examples that you picked, you can always go back and add, edit, or delete examples for a given intent. When user specifies “hola”, “aloha”, or even “yo”, Watson would go ahead recognize the user’s greetings intent for you. Will Watson detect a 100% of all possible greetings? Probably not, but it will correctly detect most them.

Building Chatbot: Entities

Entities enable Watson to identify details in the user’s input which we can then use to provide different responses to the users. For example, “Which flowers for a birthday?”  & “What are the best flowers for Valentine’s Day?’ both express the #flower_suggestions intent; however the two requests will require different responses. So, to differentiate these two requests, we can use entities. Entities have a name and a series of values. These values, in turn, have associated synonyms. These synonyms are optional, but recommended, given that the user might enter the same concept using a different word.

When Watson Conversation parses the question from the user, it will try to first detect the matching intent and then any matching entities. Watson will figure out on its own the user’s ultimate goal and match it to an intent based on the examples that you trained it on, for entities; Watson will only detect the exact values and synonyms that we’ve specified. If you enable the fuzzy matching option, which is currently in beta, then misspellings of the specified values and synonyms will also be detected. Also, unlike intents which start with a pound symbol, entities start with @ sign. Not to be confused with Twitter handles.

Building Chatbots: Dialog

Creating a dialogue defines how your bot will respond to what the user is asking. Dialogues in Watson conversation are defined visually through a user interface that is structured around the concept of nodes. Each node has a name, a condition, and one or more responses. There are a few more bells and whistles available, but at its core we're talking about name condition and responses. The dialogue starts executing from the first node at the top. If the condition is met, it will reply to a user with a response specified in that node and stop the execution until the user has entered some new input. If the condition is not met, it will skip the response and proceed to consider the next node below. If this second node's condition is met by the user's input, the nodes response will be sent to the user. If the condition is not met, we continue to the next node, and so on.

Essentially, the execution from top to bottom continues while the node conditions fail to meet what the user inputs have entered. For the condition you can use intents, entities, a specific entity value, and a few reserved conditions like welcome, “Anything else”, “true and false”. You can also combine intents and entities with “AND “- “OR” logical combinations?

Typically you'd want to greet the user as they arrive. So the first node might use a special word, "Welcome “as the condition. Ensuring that particular node is executed the first time that the user starts interacting with the chatbot. The response, we configured in that particular node, will be our initial prompt that greets the user, inviting them to chat with our chatbot. If the user input doesn't match any of the node's conditions, by default no response will be provided to the user; and this isn't great from a user experience standpoint because nobody likes to be ignored. So it's a good idea to have also a node at the very bottom of the dialog that is always executed if the user input failed to satisfy the conditions of any of the other nodes above.

The failover condition for this node is called “Anything else”. When will this note be executed? In practice, when our bot has failed to understand the user. So in this node we should have an appropriate response that invites the user to rephrase or maybe suggest some queries that we know our bot can handle. If we only included a single response in this node the bot could get annoying rather quickly. Imagine seeing I don't understand over and over again. Hopefully our user won't trigger the “Anything else” node too often.

It always good to have multiple responses with some variations to them even if they express the same concept. For example the parent node might be triggered by the user asking, "I'd like flower suggestions for a special occasion." It doesn't provide information about which specific occasion, so the response from the node might be, "which occasion?" When the user replies with say, "Birthday," the child node that matches the birthday condition will be executed and its response, displayed to the user. For this to work, we'll need multiple children nodes, each having as its condition an Occasion value like anniversary, funeral, etc., each having an appropriate response.

A node can have multiple responses that are only processed if their own condition is met. So, instead of having multiple children nodes, one for each occasion, we could have a single node that provides different responses, depending on which Occasion value is provided in response to our request for clarification. Children nodes can have children nodes of their own, giving us the ability to create a quite complex dialogue flow.

Kindly feel free to share your comments….