How To Use An Actions Skill In IBM Watson Assistant
Actions Should Be Implemented Only In Specific Cases
Introduction
An additional skill has been added to the dialog & search skills available for addition to a Watson Assistant. This third skill is actions skill. The new skill allows for rapid development of a conversational dialog.
This rapid development environment is made possible by a very simple and intuitive user interface.
User Input constraints are used; this offloads some of the data structuring to the user.
Validation message, Number of tries and messages after a last try are available.
When you apply input constraints to the ways in which customers can reply, validation occurs automatically.
Validation helps customers understand what is expected from them. For example, if the assistant expects a number, and the customer provides a sentence of text with no discernible number in it, you can show a message that explains that the assistant needs a number.
Disambiguation is very prevalent. Both within an action but also in presenting a user with an option on the best suited action.
Disambiguation occurs when your assistant finds that more than one action can fulfill a customer’s request, and asks the customer for clarification. Instead of guessing which action to take, your assistant shows a list of the possible actions to the customer, and asks the customer to pick the right one.
The approach taken with Actions is one of an extreme non-technical nature. The interface is intuitive and requires virtually no prior development knowledge or training. User input (entities) variables are picked up automatically with a descriptive reference.
Conversational steps can be re-arranged and moved freely to update the flow of the dialog.
Updates can be saved automatically, machine learning takes place in the background.
And the application (action) can be tested in a preview pane.
There is something about Actions which reminds me of the Microsoft’s Power Virtual Agent interface. The same general idea is there, but with Watson the interface is more simplistic and minimalistic. And perhaps more a natural extension of the current functionality.
A Few Key Considerations
- You can think of an action as an encapsulation of an intent. An action is defined by a set of user input examples. No intents are defined, an Actions skill is an intent-less implement. A type of end-to-end approach. Deprecating the use of intents.
- An action is a single conversation to fulfill an intent and capture the entities. An conversational extension of the subject.
- A single action is not intended to stretch across multiple intents or be a horizontally focused conversation.
- Think of an action as a narrow vertical and very specific conversation.
How To Use Actions
Firstly, Actions should be seen as another type of skill to complement the other two existing skills;
- dialog skills &
- search skills.
Actions must not be seen as a replacement for dialog skills.
Actions can be used as a standalone implementation for very simple applications. Such simple implementations may include:
- Customer satisfaction surveys,
- Customer or user registration etc.
- Short and specific conversations.
Most importantly, actions can be used as a plugin or supporting element to dialog skills.
Of course, your assistant can run 100% on Actions, but this is highly unlikely or at least advisable. You will always have a collection of skills in your assistant.
The best implementation scenario is where the backbone of your assistant is constituted by one or more dialog skills, and Actions are used to enhance certain functionality within the dialog. And a search skill can be added for discovery.
This approach can allow business units to develop their own actions, due to the friendly interface. And subsequently, these Actions can then plugged into a dialog.
This approach is convenient if you have a module which changes on a regular basis, but you want to minimize impact on a complex dialog environment.
Within a dialog node, a specific action that is linked to the same Assistant as this dialog skill can be invoked. The dialog skill is paused until the action is completed.
An action can also be seen as a module which can be used and reused from multiple dialog threads.
When adding actions to a dialog skill, consideration needs to be given to the invocation priority.
Here is some key invocation rules to keep in mind:
- If you add only an actions skill to the assistant, the action skill starts the conversation.
- If you add both a dialog skill and actions skill to an assistant, the dialog skill starts the conversation.
- And actions are recognized only if you configure the dialog skill to call them.
- If you are looking for a tool to develop prototypes, demos or proof of concepts, Actions can stand you in good stead.
Mention needs to be made of the built-in constrained user input, where options are presented. Creating a more structured input supports the capabilities of Actions.
Disambiguation between Actions within an Action Skill is possible and can be toggled on or off. This is a very handy functionality. It should address actions skill conflicts to a large extend.
System actions are available and these are bound to grow in scope.
How NOT To Use Actions
It does not seem sensible to build a complete digital assistant / chatbot with actions. Or at least not as a standalone conversational interface. There is this allure of rapid initial progress and having something to show. However, there are a few problems you are bound to encounter…
Conversations within an actions skill are segmented or grouped according to intents. Should there be intent conflicts or overlaps, inconsistencies can be introduced to the chatbot.
Entity management is not as strong within Actions as it is with Dialog skills. Collection of entities with a slot filling approach is fine.
For more advance conversations, where entities need to be defined and detected contextually Actions will not suffice.
Compound entities per user utterance will also pose a challenge
Compound intents, or multiple intents per user utterance is problematic.
If you are use to implementing conversational digression, actions will not suffice.
Lastly…
Positives
- Conversational topics can be addressed in a modular fashion.
- Conversational steps can be dynamically ordered by drag and drop.
- Collaboration
- Variable management is easy and conversational from a design perspective.
- Conditions can be set.
- Complexity is masked and simplicity is surfaced.
- Design and Development are combined.
- Integration with current solutions and developed products is possible
- Formatting of conversational presentation is encouraged.
- This is a first step for IBM in terms of end-to-end training and deprecating intents.
Negatives
- If used in isolation scaling impediments will be encountered.
- Still State Machine Approach.
- Linear Design interface.
