Conversation Patterns with IBM Watson

Following on from an earlier article, where I introduced some common patterns used to build chat bots, we’re now going to look at building some of those patterns using IBM Watson. If you haven’t used the Watson Assistant service before, you may want to read about the basics of building a bot with Watson in “Getting Chatty with IBM Watson”.

Getting started

You can add more conditions to “welcome” nodes if you want to have different introductions depending on some external factor, e.g. it could say “good morning”, “good afternoon” or “good evening” depending on the time.

You could also provide different guidance depending on whether this was the user’s first time using the bot.

Don’t repeat yourself

“Sequential” is useful for providing an initial detailed answer and then more concise answers after. “Random” is good for mixing it up.

Memory

You can set variables in the context using the context editor, which is accessed via the 3 dot menu in the response section of the node editor.

Often it is necessary to remember the topic that is being discussed, as users will not always repeat the entities. For example, a user might ask “Where is the bar?”, and then follow up with “and what time does it close?”. This second question is still about the bar but there is nothing in the user input that tells us. In this case, we can store the topic in the context, and then have nodes conditioned on that context variable in the places where that topic makes sense.

You could deal with this situation by having follow up nodes, however you would then need to account for the different orders in which the user could ask, which would add a lot of extra nodes. Using the context means we can keep our dialog tree simpler and more manageable.

Follow up questions

Be careful with using an “anything_else” node here. Sometimes users don’t respond to your questions, and by having an “anything_else” node here, we are assuming that the user’s next input is a response to our question. This is something to consider in each use case as you may want it in some situations but not others.

Gather information

There is now an easier way to gather information than what is described below. Have a look at “Gathering Information with IBM Watson Assistant”. I’ll leave the method below as maybe it will still be useful in some cases.

So first let’s create a node that responds to the user asking to subscribe to a service. As a response to #subscribe, we ask for the user’s name and date of birth.

As a follow up, we check if that information has been stored and finish the information gathering if it has. Initially, of course, we won’t have the information, so this node will be skipped.

Then we check to see if the user has provided the name. If they have then we store it in context and Jump To the node below. Similarly we then check for date of birth in the input and if it’s there store it and jump to the next node. We can use the system entities @sys-person and @sys-date to recognize these pieces of information.

Now we check for missing information. If we don’t have something then we prompt for it. After prompting we Jump To the user input before for this section, to allow the user to answer the question.

Finally we have an “anything_else” node to catch other inputs and return us back to the first node.

Specific fallbacks

This shows that the bot has understood the question and just hasn’t been told where something is.

Update: A new feature in Watson Assistant enables conditioned responses on each node, so you may not need to nest your nodes as described above. For details, see “Differentiating the same with Watson Assistant

Business process

Help

Feedback

  • implicitly by understanding when the user’s indicates whether or not the bot responded well
  • explicitly by asking the user for feedback

In the first case, you will need to add intents to understand good and bad feedback, e.g. “awesome thanks!” might be an example of positive feedback, and “you stupid bot!” might be an example of negative feedback.

In the second case, you can add an option to your app for rating each response. Alternatively, the bot could specifically ask if a response was good or not as a follow up question and then record the user’s response. The benefit of adding an option in the app is that the feedback is less in your face - the user doesn’t feel that they need to give feedback. The benefit of having the bot ask is that you can build it in the dialog and not have to write more code in your app. My preference is to use a less intrusive feedback mechanism in the app to avoid annoying your users.

You can implement both implicit and explicit feedback mechanisms in the same bot.

There is more detail on getting feedback in “Bot Feedback with IBM Watson

Don’t talk about…

A simple way to do this is to define an entity, e.g. @dont-talk-about, with values for each of the topics, e.g.

You will then need to create a node with the condition @dont-talk-about. This node needs to be put before any nodes that check for intents, so that we don’t start matching those.

Tone

The IBM Watson Tone Analyzer service can enable this. You will need to call this from your app and pass the result in as part of the context, which you can then condition on in your dialog.

See Santa’s Little Twitter Bot for an example of using Tone Analyzer in a bot.

FAQ

Long Tail

The IBM Watson Discovery service can help with this. You will need to call Discovery from your app. You could do this when your Assistant API returns saying it can’t answer, or by detecting certain topics in your dialog and setting a value in the context to tell the app to call Discovery.

Go build a bot

Find more of my Watson articles in the Conversational Directory.

User Experience Developer | IBM Watson