5 Non-Programming Items a Developer Needs to Know about Amazon Lex
Amazon has made creating a chatbot easy with Amazon Lex. It is intuitive and quick to get going and there are some excellent blogs and white papers out there to teach you how to get started. However, these resources will only be appropriate to convey very simple ideas and have basic conversation with your customers. Here are 5 additional tips to help you out.
1. ‘Help’ and ‘Hi’ – Conversations where you don’t need Lambda
Imagine you want to respond when someone asks for help. You don’t need anything except the Lex interface for that, because your responses are direct.
Them: HELP!
LexBot: I’m sorry you are having difficulty. I can help you with the following selections…
You can then use the Lex interface to write out a few groups of responses that Lex can randomly choose from to make your chatbot seem a bit more ‘real’. If there is nothing more complex than that, you can create as many chains of intents as you like and bring them together. For example:
Them (Intent trigger underlined): Hi
LexBot (Trigger ‘Hi’ intent): Hello! How is the weather?
Them (Intent trigger underlined): oooh it's raining here.
LexBot (Trigger ‘WetWeather’ intent): Oh dear, I hope it clears up soon! What would you like to ask me about today?
2. Everything Else – Conversations where you need Lambda
Once you have mastered the simple conversation chain (or really, as soon as you start to think about how a conversation works, how language works, and how people think), it turns into a much more complex situation. The Lex interface rapidly becomes constraining and this is where the setup will need to move into Amazon Lambda.
We’ve written about the power of Lambda previously. Lambda is the glue in the Amazon ecosystem. It allows integration to almost any 3rd party application.
For example, let’s say we are talking about booking a flight. This requires integration to an airline booking system and coding – which is where Lambda comes in.
Lex allows you to run Lambda code when someone asks questions, instead of sticking to the Lex configuration harness. This now provides Lex with the power of AWS and the internet at its fingertips, although you need to make sure you use it correctly and appropriately.
Back to the booking a flight example:
Them (Slot detection in bold, intent trigger underlined): I’d like to book a flight to San Francisco
LexBot (Trigger ‘BookFlight’ intent): No problem, when would you like to fly out?
Them (Slot detection in bold): Friday in the morning
LexBot: Ok, and returning?
Them (slot detection in bold): Sunday Evening.
LexBot: And where are you departing from?
Them: Dallas
LexBot: and returning there?
Them: yes
(LexBot runs some Lambda code to find a flight)
LexBot: OK, here is what I can offer you…
Several things have happened here in the background. There is some basic information we need to have before we can book a flight. This information is collected in slots, and until we have all the slots filled (date, time, locations etc.) we cannot send a request to the flight system to find an appropriate flight. Lex can keep asking questions until all the slots are filled with useful information. We can then use this information to write and run some code to interface with the booking system and look for the flights. Then Lex will present the appropriate options to the customer which they can then book via the chatbot.
3. Log your comments to Cloudwatch
Once you have the code written and you are trying to access the airline booking system, it is very important to note that Lex has little to no debugging in and of itself. It is really important for you do not only comment your code, but log all the steps that the customer is taking to Amazon Cloudwatch via your Lambda code. The very first thing that should be logged is the Trigger Event from Lex, so you can see exactly what triggered your code and what variables and information you have access to. Many times code is run that makes no sense until the event that triggered it was analyzed. It is only then discovered that there was unhandled logic because no one thought anyone would say or do that. The complexity and variations of language is amazing; people often say things you never expect. So log every step to CloudWatch in order to know exactly what is going on in your bot. This is especially important because bots only get more complex the better you get at building them. Get into good habits early! Comment your code, log your code.
4. Session Variables – what are they and how do you use them?
Your flight is booked, your customer has paid for the flight via some wonderful code you created for them in Lambda to interface to a payment gateway and you talked them through it with your LexBot. Then this happens:
Them (Intent trigger underlined): Thanks, I need a hotel as well
Well, normally we would ask someone all the same questions as for a flight booking; where are you staying, when etc, But guess what? We already know all this information! We also know how they paid for it. So we can carry all this across intents with something called ‘Session Variables’. Essentially they are the memory and current context of a conversation. If someone says “it”, we can access session variables in our Lambda code to figure out what the customer means by “it” instead of asking them for information they have already provided to us. Here is our continuing example:
Session Variables from BookFlight Intent:
- Flight1: Date1 Time1
- Flight2: Date2 Time2
- PaymentMethod: Card1
- City1: Brisbane
- City2: Sydney
- City3: Brisbane
Using this information, we can pre-populate the ‘BookHotel’ intent and simply ask the customer to confirm the information we already have. If they say “no” at any time, we just ask them for the new information and we update our slot as well as our session variables (because now “it” has changed).
From a technical point of view, be very careful when using and updating session variables as Lex is not stateful. They don’t simply ‘update’ the way you would expect. They overwrite when you pass them back, so make sure you write a Lambda function that merges and updates all your new session variables into one JSON object the way you want them updated and send back the completed object to Lex. Lex will then overwrite session variables stored with the new ones passed to it. Don’t lose your context by making this mistake.
LexBot (Trigger ‘BookHotel’ intent): That’s fine. Are you looking for a hotel in San Francisco from Date1 to Date2?
Them: yes
(Lexbot runs some Lambda code to find appropriate hotels)
LexBot: Ok, Here are some options for you to choose from…
As you can see, using session variables makes the conversation seem more natural as we humans are very good at keeping complex subjectivity stored in our heads. Context is important, and if you can really get the art of keeping a context within this chatbot, your conversations will seem more natural and useful for people.
5. Intent Hijacking – how to avoid accidentally starting over again
Them (OOPS!! Triggering intent ‘BookHotel’): Great! I’d like to stay at Hotel Comfort please
LexBot (Running ‘BookHotel’ intent from the start again): That’s fine. Are you looking for a hotel in San Francisco from Date1 to Date2?
Them: What?
LexBot: I’m sorry, I didn’t understand. Could you repeat that?
Them: …
When your utterances configured in Lex are too generic, like this example here, they can trigger situations you would not expect. The intent will start again perhaps when you are in the middle of your conversation in a different intent which will throw a customer off - and immediately you have lost them to frustration. In order to avoid this situation, make sure the utterances you set up in the intent are as specific as possible. In this case, instead of triggering on “hotel” you should set up more of the following:
- I need a hotel
- to book a hotel
- need somewhere to stay
- need to stay there
The Lex interface has a section in it that allows you to read what utterances it triggered on and, more usefully, what it DIDN’T trigger on. When you are trying and testing your bot, use this section in the Lex console wisely, as it can really help you understand how your customers are using your bot. Make sure you capture and respond to their common questions and phrases. Make sure you do not have things set too generically like in this example or intents can reset or trigger unexpectedly mid conversation.
Ultimately natural language can be complex to understand, but these 5 considerations will make development of a Lex chatbot more seamless and will enable you to bypass some common challenges.
VoiceFoundry creates and deploy chatbots for our customers, to assist with basic customer queries and relieve contact center call volumes.