Considerations For Chatbot Migration from Amazon Lex to Rasa
And Using The Migration Process As An Opportunity for Chatbot Improvement
Introduction
Migration of a chatbot or any Conversational AI/UI environment is not something which will happen often. Invariably during the initialization of the chatbot process, organizations opt for a familiar and mainstream solution technology.
With user and functionality growth, impediments to scaling are often encountered, these might include:
- Cloud hosting cost.
- Some cloud providers charge per functionality added.
- Lack of collaboration tools.
- Waiting & being dependent on cloud providers to roll out required features and functionality.
- Introduction of languages and vernacular.
- Difficulty in offsetting cost with savings or revenue from the chatbot.
- The challenge with the big cloud NLU/NLP solutions will always remain the issue of protection of personal information and control of data.
Lex Architecture
There are two general approaches to chatbot architecture. The first being a situation where the elements are combined and cannot be decomposed.
The second is where the components are decomposable and can be used separately.
For instance, with Rasa, the chatbots NLU component can be made available as an API.
Lex follows very much the same approach, where provision is made for intents, entities and the script component. Some of the script can also vest in a Lambda function, but more about that later.
Intents
With Lex, the idea of intents are inline with what IBM and Microsoft (LUIS and Power Virtual Agent) are doing.
Lex allows for the creation of intents for which a range of invocation phrases can be added.
Based on these invocation phrases, an intent can be detected based on user input. Once the journey has entered into a specific intent, the process of collection entities start.
Entities
Firstly, if intents are the verbs, entities are the nouns. In the case of a travel chatbot, entities will be dates, places, modes of transport etc. Lex does not refer these nouns as entities; but rather slots.
If intents are user verbs, then entities can be seen as user nouns. These entities are then closely linked to the intent. Multiple entities can be detected, with each assigned to a different role, or subset. Read more detail on this here.
Lex does a good job of making sure the slots are all filled, you can set the priority of these slots, if they are mandatory and also configure follow-up prompts to ensure they are filled.
Script
The script for the chatbot will mostly be defined within Lex, and ample provision is made for confirmation prompts, follow-up prompts, and final prompts.
It is also possible to formulate a customer response, or prompt, within an AWS Lambda Python service, and pass this script or dialog back to Lex.
Dialog Management
The dialog flow (also known as state management or dialog management) is analogous to how Microsoft LUIS fits into the Microsoft bot framework.
Lex allows for the configuration of the NLU environment; a NLU API. But for session variables, dialog management and state machine related tasks, you need to connect to a Lambda function. Or, merely use Lex as a NLU API and write your bot framework in another language; like C#, Python, or use an framework like Django.
The demo application I wrote was in Python and made use of Lambda for the state management, conditions, decision trees and the like. Lex expects the Lambda function to receive a JSON payload.
Subsequently the Lambda function needs to return a JSON payload to Lex. The connection can be tested via the text console and the JSON payload is visible during testing.
The fact that this leg of the architecture sits outside of the Lex environment can be seen as a strength and also a weakness.
IBM Watson Assistant has a very neat built-in dialog manager with advanced configuration options.
But there are those who prefer to have a programmatic or code environment where it can be developed. Should the chatbot become large, it might become hard to manage and somehow it will have to be segmented.
Migration
Let’s look at the migration process in two parts:
- NLU
- Dialog
NLU
Before you export the Amazon Lex bot, you need to ensure that it is built and published within the console. If not, the elements you see in the console might not reflect in the JSON export file.
So be sure to click on Build and then Publish.
When exporting your chatbot from the Lex interface, you have the option to select the appropriate version. Take note there are two platform options; Amazon Lex and Alexa Skills Kit (ASK).
The SDK option yields a more generic and useable format from a Rasa perspective. JSON queries can be used to extract the data of interest.
Below is an extract from the Lex ASK export… The format is very convenient and similar to the Rasa nlu.md file.
{"intents":
[{"name":"BookCar",
"samples":[
"I am getting the car in {PickUpCity} on {PickUpDate} and dropping at George. I am {DriverAge} and I want {CarType}", "I will be getting the car in {PickUpCity} on {PickUpDate} and dropping at George. I am {DriverAge} and I want {CarType}", "I will pick up the car in {PickUpCity} on {PickUpDate} and return it at George. I am {DriverAge} and I want {CarType}", "I am getting the car in {PickUpCity} on {PickUpDate} and dropping at Cape Town."],
And here is another example from book hotel intent.
{"name":"BookHotel",
"samples":[
"Book a hotel", "I want a make hotel reservations", "Book a {Nights} night stay in {Location}"],
Creating intents will be a straight-forward process from the examples. It is convenient that the entity name is defined in the user utterance example denoted with curly brackets.
The only drawback is that entity examples are not included within the utterance examples. So for this step possible manual intervention is required. With file manipulation, entity values can be extracted.
Below is an example of entity/slot names and values. Again, with JSON queries these can be extracted.
[{"name":"RoomTypeValues",
"values":[
{"name":{"value":"deluxe","synonyms":[]}},
{"name":{"value":"queen","synonyms":[]}},
{"name":{"value":"king","synonyms":[]}}]},
{"name":"CarTypeValues",
"values":[
{"name":{"value":"standard","synonyms":[]}},
{"name":{"value":"full size","synonyms":[]}},
{"name":{"value":"midsize","synonyms":[]}},
{"name":{"value":"luxury","synonyms":[]}},
{"name":{"value":"economy","synonyms":[]}},
{"name":{"value":"minivan","synonyms":[]}}]}],Amazon really encourages developers to use built-in slot types. When exported these are empty, and hence will demand manual intervention to complete.
On entities, Lex have specific prompts and confirmation prompts settings which will lost. Or at least have to be rebuilt.
Dialog Management
The chatbot elements which falls outside of NLU will have to be approach based on the methods employed. It can be assumed that for an Amazon Lex chatbot, the dialog, context and integration portions will most probably vest in a AWS Lambda function.
Each chatbot solution will have to examined to see how these elements can be best migrated to Rasa.
Slots & Forms
With Amazon Lex, slots/entities can be set to mandatory and individual prompts can be set to solicit a response from the user. It all depends on how these individual prompts are employed in your Lex bot.
Should it be used extensively, you might want to to consider using Forms in Rasa.
Conclusion
The upside is that intents and training examples can easily be migrated to Rasa. From an entity perspective, the data is available, with some effort it can also be migrated.
The problem lies with the Amazon specific entities, and Lex specific entity prompt and confirmations; this functionality will have to be instituted.
And obviously the dialog, state management and integration elements will have to be assessed.
