Building chatbots: more tips and tricks

Share this post:

You build your first chatbot and it is working ok. Did you know that you can make chatbots even more interactive? That you can access conversation metadata and application variables inside the dialog nodes? You can even use predicates to tailor output to the usage scenario. As a follow up from our “Lessons and Tips from a Chatbot Hackathon“, let’s dig deeper into important features of the IBM Watson Conversation service on the IBM Cloud with Bluemix.

Intents, Entities, Context

When you have worked with chatbots or conversation services, then you already know that the key concepts are intents and entities. To start with, intents are the purpose or the goals the user asks for. Is it a weather- or a stock market-related question? Next, an entity represents a class of object or data type. Amazon, IBM, Google and Microsoft could be entities for the “company” the user wants the stock info for. San Francisco and Friedrichshafen could be cities and today, tomorrow or Sunday could be the dates for which I need the weather forecast. A special kind of entity are system entities. They are built-in and, once enabled, automatically detect numbers, persons, locations, dates and more in user

Architecture for Chatbot based on Conversation service

input and the simplify the handling of those found values.

To understand what is going on, the context and context variables are used. They identify which user is chatting. Plus, they tell about the current step in a conversation. Even more, they carry application-related data throughout the dialog. In summary, they allow to build applications based on the Watson Conversation service and to pass vital information into and retrieve data from it (see the architecture diagram).

All three, intents, entities, and context can and should be used in dialog nodes. They enable decisions about the next step in a conversation, about which response to choose. Moreover, they allow to tailor responses to exactly that specific ongoing chat. Hence, using intents, entities, and context as part of responses are an important ingredient to a lively, human-like interaction in chatbots.

Conditions, Data Access, Expressions

Responses for chatbots are defined in dialog nodes. In general, each dialog node has a name, optional conditions to check and one or more response. Conditions and responses both have access to the mentioned metadata and can include expressions. What are typical conditions?

  • A check for an intent: Is the user goal to learn about weather, an insurance topic or a video of dancing cats?
  • A test for an entity: Does it involve a location like San Francisco or Friedrichshafen, or an animal like cat or fish?
  • An evaluation of a context variable to see whether the username was set, the temperature in the forecast is higher than 35°C or the list of suggested videos is empty.
  • A logical combination of all the above: If it is a weather-related question (intent), the location is Friedrichshafen (entity) and the predicted temperature is high, then enter the dialog node and return a response with a variation of “It will be hot at Lake Constance”.

To write and process a condition, access to the dialog metadata is necessary. IBM Watson Conversation offers both a generic form as well as shorthand data access. They are documented as part of the supported expression language:

  • The generic form consists of a JSON object or list with the type as name: intents[], entities[], context (and some more). Not going into details, an array-like access (entities[‘location’]) and a dot-notation (context.temperature) are possible.
  • The shorthand uses “#” as prefix for a specific intent (#weather), the “@” for entities (@location) and “$” for context variables ($temperature).

Those expressions can be used in the conditions for a dialog node, in the responses and for setting context variables. Because the purpose of responses are to produce textual output, the expressions need to be embedded into the response text. Then, an expression is evaluated. The syntax for an evaluation is “<? expression ?>“. An example would be: The expected temperature today is <? $temperature ?> °C. The same applies to setting context variables.

Building Better Chatbots

Once you have mastered the art of using expressions in conditions and responses, you probably want to write more sophisticated expressions. And yes, it is possible and you are allowed to. 🙂

The expression language in IBM Watson Conversation is based on SpEL, the Spring Expression Language. It allows to apply functions, methods and filters to the data. SpEL provides regular expressions. Its feature set has ternary operators, projections and selections on lists or collections, and much more. It is a powerful tool to explore. It is core to building better chatbots. Using SpEL helps to design chatbots that are situation- and data-driven, resulting in what I call “smart conversations”.

The example in the screenshot shows a slightly more complex SpEL expression with a ternary operator. The context variable “shorter” is assigned a concatened string. The result depends on a length comparison of two entities. Interestingly, not the entitiy values but the strings from the user input are taken into consideration (literal.length()). Depending on how the predicate result, either the first or second sub-expression is processed. Thus, a string value in all upper case or all lower case is assigned to the context variable.

Expression in Context Variable

Expression in Context Variable

We will discuss the example above and other more complex expressions in another blog post. In the meantime, I would recommend heading over to this collection of sample expressions for the IBM Watson Conversation service. I created the GitHub repository to collect and explain samples with expressions like those discussed today.

If you have feedback, suggestions, or questions about this post, please reach out to me on Twitter (@data_henrik) or create an issue against the mentioned GitHub repository. Moreoever, check out the tool I created to manage conversation workspaces.

More Watson Stories

Securely Access MongoDB from a Spring Boot App Running on Bluemix Kubernetes Using Kubernetes Secrets

This example builds on my previous post where I showed how to access a Bluemix MongoDB service from a Spring data app running locally. In that simple example the MongoDB credentials were either hard coded in the application or specified manually on the command line.

Continue reading

Accessing a Bluemix MongoDB Service from a Java Spring Boot Application

In this blog post I'll show how to access a Compose for MongoDB database running on IBM Bluemix from a Spring boot application running locally. Spring is a popular open source framework and container for Java applications. MongoDB is a popular open source document oriented NoSQL database that uses JSON-like documents.

Continue reading

Spring, Liberty and Single Sign On

Have you ever wondered how you could protect your Spring app with the Bluemix SSO service? In this article, we’ll cover how you can convert a Spring application running on Liberty from using a manually configured Open ID Connect (OIDC) Server, to using the Bluemix Single Sign On service. A short while ago I wrote […]

Continue reading