Creating A Chatbot With Amazon Lex And AWS Lambda
This Is A Comprehensive Overview From An Idea To Implementation
Introduction
Amazon Lex follows the basic chatbot architecture adhered to by all the big cloud based Conversational AI providers. You will need to create intents, entities, your script (dialog wording) and then of course the dialog flow.
The dialog flow is also referred to as the state machine or user story.
It needs mentioning that all chatbot development environments are very similar in approach and basic architecture.
Some excel in certain areas; with others being a more complete offering. But cost is always a consideration.
The only real innovation and deprecation of some of these generally accepted architectural pillars is coming from Rasa.
Basic Architecture
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. Intents are single intents; however, Rasa is doing work on multiple intents with their Tensorflow pipeline. Read more about that here.
Again, intents can be seen as the verbs, detecting what the intention of the user is. For instance, for a bank, intents might be:
- I want to open an account.
- I need to close an account.
- What is my balance.
- I need to transfer money.
- And more.
A good way to grasp intents, is to think of a person attending to a desk in a large building’s reception, their main activity is intent detection. For every person walking through the front door and approaching the desk, the receptionist’s task is that of intent detection. What is the intent of this person.
Based on these invocation phrases, an intent is detected. Once the journey has entered into a specific intent, the process of collection entities start.
Entities
If intents are user verbs, then entities can be seen as user nouns.
Here is where Lex is behind in developments I have seen with Microsoft LUIS, IBM Watson Assistant and especially Rasa. With these environments there is a convergence of intents and entities. Especially with LUIS there is a very rich array of entity types which can be configured.
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.
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.
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.
Warning: what I have found is, that these slots are not truly contextual. Hence they still require a finite list to be checked against. Or at least a single reprompt for each entity or slog. Lex will not be able to detect a city name on the first pass from purely being trained on a list of contextual intent examples.
Here Rasa is a exceptional; they have a tutorial where you develop a weather chatbot to determine the weather in any city in the world. So you can imagine it is not possible to have a finite list of all city names n the world. The city name needs to be detected contractually.
And, this can be done on the first pass, with no finite list in the back-ground, on the first pass.
So, this is truly disappointing, the lack of a true contextual entity configuration.
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 to Lex.
Dialog Flow (State Machine)
The dialog flow (also known as state management or state 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.
Using Lex as NLU API
To make your Lex environment available as an restful API with an URL, with and access key and secret key, you will need to make use of Amazon IAM (Identity And Access Management).
Postman has an option under authentication where you can add your AWS Signature.
You need to ensure that the region where your Amazon Lex instance is defined, is mirrored in your Amazon Security Signature in Postman, and also in the URL.
Second to this, you need to use Post. The logic of slot filling…
Lambda
This is the Python code for the Lambda function…you can see where I extract the entity and intent name from the incoming JSON payload.
Immediately I create the outgoing payload with two session variables named key1 and key2.
Towards the end you can see the content or dialog wording I create to pass back to Lex.
def lambda_handler(event, context):
entity = event["currentIntent"]["slots"]["Name"].title()
intent = event["currentIntent"]["name"]
response = {
"sessionAttributes": {
"key1": "value1",
"key2": "value2"
},
"dialogAction":
{
"fulfillmentState":"Fulfilled",
"type":"Close",
"message":
{
"contentType":"PlainText",
"content": "The intent you are in now is "+intent+"!"
}
}
}
return responseThe session variables are very useful in instances where you get values back from an API and need to pass it back into the conversation.
Conclusion
The challenge with the big cloud NLU/NLP solutions will always remain the issue of protection of personal information. Here Rasa remains a solid solution should you want to run a local and contained installation. Cisco MindMeld is also an option.
Comparing Lex to Watson Assistant and Microsoft LUIS, really accentuates the weak contextual entity functionality of Lex. It is not possible to set true contextual entities which cannot have a finite list of values. The selection of entity types are also small.
Here Microsoft LUIS is leading the pack in terms of entity types, which is truly contextual.
Lex has no mention of spelling correction, digression, fuzzy matching etc.
Obviously Amazon Lex is at home with all things AWS; and there is a strong slant for Lex users to make use of Lambda, and the AWS mobile services after launching.
There is definitely much more user freedom when it comes to Microsoft and IBM Watson Assistant. Not to mention Rasa.
Should you have a strong relationship with AWS within your organization, and are using a ton of AWS services, then Lex is an strong contender. Also, if you take cost into account; which is a huge consideration and impediment in general with IBM Cloud.
More About Me…
The Definitive Document Set…
https://docs.aws.amazon.com/lex/index.html
Here is a good article on Connecting With Postman
