Best Practices for Realistic Chatbots
Best Practices for Realistic Chatbots
Check out some guiding principles for designing realistic chatbots. These practices are critical when designing a successful dialog-based solution.
Join the DZone community and get the full member experience.Join For Free
The most visionary programmers today dream of what a robot could do, just like their counterparts in 1976 dreamed of what personal computers could do. Read more on MistyRobotics.com and enter to win your own Misty.
More and more chatbots are being developed — and there are good reasons for it. However, not all chatbot projects succeed. Often, user acceptance testing is missing. The dialog system might not have hit the nerve and might not have fit into the target environment. Would you talk with a friend who does not remember your name is repeating the same five phrases over and over again? I would not. So what can be done to make chatbots more lively, more human-like? Here are some best practices and ideas on how to implement them.
I started my series on chatbots with lessons and tips from a chatbot hackathon. In that article, I focused on general aspects of building dialogs and designing a conversation system. The language needs to fit the audience. This is something we will look at again today. In a recent blog post, I shared tips and tricks for building chatbots. It is possible to carry context throughout a conversation and embed conditions and advanced expressions into the dialog flow and single responses. We will use that to implement some of the best practices found below. Building life-like chatbots could also mean giving the bot a face. The open-source project TJBot (pictured) is an example of that. The TJBot can listen, speak, and see, give additional feedback, and interact using its arm and its light. Note that we won’t cover those aspects (i.e.g hardware design or user interfaces) in this blog entry.
Best Practices for Realistic Chatbots
You understand the basics of chatbots. You know about the advanced capabilities of the IBM Watson Conversation Service. Now, let’s take a look at some guiding principles and best practices for designing lively chatbots to help us make a conversation interesting to the user. They are critical for a successful dialog-based solution.
- Freedom and flexibility. Guide the users, but don’t restrain them.
- Variety. Don’t repeat yourself. Tailor the messages to the situation.
- Flow and state. Have follow-up questions where needed. Let the conversation flow. Remember what you already did and where you need to go.
- Information gathering. Keep tabs of what you need to know and what you already know. Gather relevant information.
- Mood and tone. Try to “get” the user mood and adapt the conversation to it.
- Learning. Analyze finished chats. Improve future conversation by training the system.
What do those recommendations mean in practice? I am going to provide some ideas of how the best practices can be implemented with the IBM Watson Conversation Service (WCS).
Freedom and Flexibility
The WCS has the concepts of intents, entities, and dialogs. Developers create individual dialog nodes within a dialog. Each node can have multiple responses that Watson can pick from. This can be either sequentially or randomly. In a conversation flow, conditions can be placed on nodes so that they are only visited in specific situations. It is possible to jump to other nodes in a dialog to react to user input and to a certain situation. Moreover, expressions to evaluate variables and the conversation metadata can be embedded into responses. Thus, a high degree of freedom and flexibility can be achieved.
Using context variables and conditions (the techniques described in the recent blog), responses can be tailored to the current state of the conversation. A response could be a template, not a static text. User-specific and flow-related data is then filled into the response template. This can be done in WCS directly using embedded expressions. Another technique is to place special markers or keywords into a response; for example,
ORDER_LIST. Then, the chatbot application could replace the markers with the actual data. A simple example is in the TJBot “tell the time” recipe. In the
tellTheTime function, the marker
todays_date is replaced by an app-generated, timezone-dependent string with the time.
Other applications use an indicator as a WCS-delivered response; for example,
list_guests. The app creates the returned response from strings fetched from a database and maybe based on templates. In that case, Watson responses help to compose context-specific messages. The chatbot application generates the final answer. It is important that answers vary to keep them interesting. Build answers based on the information the bot has like a real person would do.
Flow and State
Watson Conversation maintains a conversation state and context. The metadata helps drive the conversation. Conditions on that metadata and user data should determine the dialog flow. Most users are not chatting for fun, but for a purpose. Hence, each time it "speaks," the chat needs to move towards that goal.
Users provide data to reach a goal; for example, booking a flight, obtaining status information or ordering goods. They want to provide that data only once. Thus, it is important to know the required data to finish that process. Furthermore, each bit and byte obtained from the user needs to be remembered. IBM WCS has a relatively new feature called slots. First, slots allow defining what data is needed overall. Second, slots help easily keep tab of what information was entered by the user and help tailor questions to only ask for what is still missing. Thus, slots improve the user experience.
Data from slots is kept in the conversation context. The context is the “dialog memory.” It carries the user data throughout the dialog flow. See my previous blog with tips and tricks on using the chat context.
Mood and Tone
Do you know Marvin, the depressed and bored robot from The Hitchhiker’s Guide to the Galaxy? Marvin seems to be misplaced (by purpose). How would you feel about a cheery chatbot when you are discussing your credit score? Or about a very formal conversation for ordering fast food? Be sure to design the dialog to match the situation. Moreover, consider a dynamic analysis of the ongoing conversation. IBM offers the Tone Analyzer, Natural Language Understanding, and Natural Language Classifier services to extract the current sentiment and to further annotate and analyze what the user is saying. The techniques discussed above can be used to react with an appropriate, varied, tailored answer that shows that the bot understood and remembers what has been said so far.
The IBM Watson Conversation Service is a cognitive service. Hence, a core feature is to learn and to improve. Developers enhance the learning and training by analyzing finished conversations and by providing feedback to Watson. By reviewing logs and, if necessary, changing detected intents, the service learns. Conversations get better and better. Also, by looking over the finished conversation, developers also learn how well the chatbots are working.
In this blog entry, I provided some best practices to build lively chatbots. User-centric design (“How would you (want to) chat with a real person?”) is essential. The recommendations discussed above should give you ideas to design such bots. The IBM Watson Conversation Service provides the technical foundation.
If you have feedback, suggestions, or questions about this post, please reach out to me or create an issue against the mentioned GitHub repository.
Published at DZone with permission of Henrik Loeser . See the original article here.
Opinions expressed by DZone contributors are their own.