Best practice for Virtual agent design using IBM conversation service

1     Introduction

This document serves as a guideline for best practices for IBM Watson conversation service for the design of the intents, entities and Dialog development.

This doesn’t serve as a documentation for the service rather a guide created from experience with past conversation projects, and also understanding of Machine learning and NLP structure of the conversation service.

1.1    Prerequisites

Read IBM Conversation Documentation on the following topics:

1.      Intent creation

2.      Entity creation

3.      Dialog Design

2     Intents

It’s understood that intents imply the purpose of user statement or question that helps the dialog to identify the correct response.

The structure of Intents should be as generic as possible, also variations added to create such an intent should all agree to the same parameter in the intent sentence structure. This is to avoid complications as the project moves on and more intents are being added.

The best practice for this is to link each intent with a NLP Structure, for this we use a simple design of a primary structure and a secondary structure.  primary verb and a secondary verb structure is what I call Parent Child Structure. In this article, we will cover the parent child Intent creation design that facilitates the creation of this generic structure.

2.1    Identification

The Identification of the proper Intent of each of the training sample is done by identifying the parent and the child structure. Where the name of the intent will reflect those 2 properties as follows:

Child_Parent

The name of the child is followed by an underscore “_” and then followed by name of the parent.

After Identifying the Structure for the parent and the child(optional) we assign a name for each that reflects on the verb in each of the structure. Throughout the article, we will highlight the parent structure in Bold and child in underline.

2.2    Structure

The Intent Parent group is identified by complex structure depending on the Input Sample NLP structure while child group is identified by a single verb or a noun.

Normally your training sample should contain samples as the user would type them, which lies mostly in those sentence structures:

2.2.1     Interrogative sentence

Interrogative Pronoun (Question word)+Primary Verb + Subject + secondary Verb/Noun +Entity.

Parent Structure: Question Word +Primary Verb

Child Structure: secondary Verb/Noun

Sample: What is the cost of TV license?

Parent structure: What is (Information)

Child structure: cost (Price)

Result Intent: Cost_Information

2.2.2     Imperative sentence

2.2.2.1     Direct

Primary Verb +Entity.

Parent Structure: “Imperative”

Child Structure: Primary Verb

Sample: Turn on the AC

Parent structure: Imperative

Child structure: Turn on (Operation)

Result Intent: Operation_ Imperative

2.2.2.2     Indirect

Subject(I) + Verb(want/need) + Primary Verb + entity

Parent Structure: “Imperative”

Child Structure: Primary Verb

Sample: I need to see my balance.

Parent structure: Imperative

Child structure: need to see (inquiry)

Result Intent: Inquiry_ Imperative

2.2.3     Declarative Sentence

Subject + Primary Verb +Object

Parent Structure : “Declarative”(fixed)

Child Structure : Primary Verb

Sample: I have a R323 router.

Parent structure: “Declarative”

Child structure: have (Ownership)

Result Intent: Ownership _ Declarative

Examples:

Any Child group in this sense can be grouped with a parent group to construct multiple intents as follows:

How do I pay?

Intent: Payment_Process

What Payment options are available?

Intent: Payment_Information

How do I connect to the internet?

Intent: Connection_Process

3     Entities

Entities are business terms related to the industry domain of the client and also to specific terms used by the client that conveys business terms.

You can think of the entities as a dictionaries, the service looks up terms identified in its Entities dictionaries.

When creating Entities, the following points need to be put in consideration:

1.      Entities are created for business key concepts with different values for each concept

2.      Synonyms contain different terms that relies the same meaning and also different misspellings that still deliver the same value*

3.      Entities are used in the classifier training , so if the variations created for an intent contain some of the values present in the entities, the Intent will be trained that the presence of the entity is something to consider while deciding on the confidence level.

3.1    Entity Structure

In one of the previous examples we had

                                               Where can I get a TV?

In that example the Entity is identified as TV marked in Italic, But what entity should be mapped for the word TV?

The general structure is as follows:

• Entity Name: Generic Type (wouldn’t be caught in the User input)
• Value (Sub Type)
•  …….
•  Default_Value (containing generic terms that refer to the entity without being specific to the client business terms)

Example:

• Entity Mobile
• ·        Samsung galaxy s6 : (synonyms) S6, Galaxy 6 , etc.
• ·        Samsung galaxy s5
• ·        Iphone 7
• ·        Default_Value s6 : (synonyms) Mobile, phone , handheld, etc.

4     Dialog

The document is for best practice to design Multibranch questions in a dialog, where user input in this scenario can be input text from the user or automated text from the UI when the user selects an option. Either way throughout the document user input as described above will be referred to as options.

4.1    Leaf Nodes

Are nodes that have a trigger and a response and don’t point to any following nodes, The Nodes serve as Question and answer purpose with no dialog involved.

Creation of such nodes should always be with Intents and entities(multiple) as to only be triggered when the specific purpose is inserted. Nodes that are only triggered by Intents or entities alone should be branch nodes.

4.2    Branch Question

Before the common template for branching questions be brought up, there are some key concepts that needs to be explained before presenting the template.

4.2.1     Navigation Triggers

You have 3 choices to navigate through the branches

1. Intents & entities
2. Entities
3. Exact text value

4.2.1.1     Intents and Entities

The 1st option is using Intents and entities, this option handles consecutive branch node as we would handle leaf nodes by identifying each node with an intent and an entity trigger.

4.2.1.2     Entities

The 2nd Option is usage of only entities, that’s when options are limited to one word that’s is already in our ground truth of entities, in that case the node is navigated through the entity alone.

4.2.1.3     Exact text value

The 3rd option is there if Multibranch questions will depend on choices right after identifying the root Node that cannot be fit in an entity or an intent, In this case exact phrases or sentences are checked for navigation through dialog. Such option is least preferable and should be only used if option 1 and 2 are not fit to use.

In this option, you can either check exact phrase or sentence or The UI would send a phrase indicating which option was selected as “option 1” or “option 2”.

4.2.2     Back Option

In the Navigation, The user should be able to navigate back through the Dialog nodes , a choice of “Back” option should be included that jumps from one node to the previous node.

This is done through the middleware application between the service and the user App(frontend)

By adding the previous node history in the context the app can get the user to jump back to the previous node.

4.2.3     Cancel option

In the navigation within the branch, the user should also be able to cancel the branching question and return back to the dialog root, this is supported by default as when the user asks a question outside of the branch scope the dialog then checks all other root nodes outside of the branch for a trigger.

But through the implementation of the back option, through UI requirements or presence of blocker nodes such as anything_else node inside a branch, the user is sometimes stuck inside the branch unless he provides an answer. That’s why presence of this option becomes viable.

4.2.4     Shortcut nodes

A Shortcut Node is created, which is a simple a leaf node with no response only a condition trigger that jumps to either other leaf nodes or branch nodes and placed at top of the tree for higher evaluation. The condition on the shortcut node should be as specific as possible by picking an Intent and a value within an entity to avoid blocking other nodes with correct response.

4.3    Tunneling

One of the aspects of a good conversation is the ability of Watson to cope up with user input that refers to questions inside a branch (tunneling in) or if the user asked a question while still inside the branch (tunneling out).

4.3.1     Tunneling In

In this case, the user types a statement or a question that refers to an answer inside one of the created branches. In most of these cases that means the user has written a more specific question or statement rather than the generic purposes handled by branch question.

4.3.2     Tunneling Out

In this Case, the user while in the middle of a branching question asks a question that exists outside of the branch scope, in this case the Dialog has to branch out to that question directly with back option enabled to be able to return back to the branch question if required.

4.4    Template

In the following diagram, All the concepts described above are put in the design and serve as the generic structure for creation of branching question.

In the Root Node, the Intent is only identified by the main Intent with no response, where it jumps to layer 2, Layer 2 only contains 2 nodes with Entity Trigger:

1. Branch Node that contains the Branch Main Entity with the trigger on the Default_Value indicating a general question on the subject that needs further details
2. Leaf Node with Entity’s subtypes that indicates a specific question with a specific response
3. Anything else response should always indicate to the user that Watson understood the intent but did not recognize the entity

5     Summary

In this article, we explained the new Intent Structure of Parent-Child structure, Identified Entity general structure and Introduced new concepts in Dialog design.

You should be able now to develop conversations in a more structured and scalable way that is adaptable to many of the production cases.

6     Acknowledgments

I would like to thank Debajit Ray for his support and insights that helped me design this document, Also I would like to thank Ahmed Abbas, and Wagdy Negm for their effort in reviewing this article.