Writing Text Bots with Amazon Lex

Writing Text Bots with Amazon Lex

In my last blog article, I wrote of the framework I developed to create SMS text bots. This framework uses the Avaya Breeze® Platform to send and receive text messages, Context Store to manage individual chat sessions, and IBM Watson to turn incoming text messages into actionable items. This division of labor allows anyone to create very sophisticated text bots with a minimal amount of effort and zero programming. As I said, if you can draw it on a whiteboard, you can build it into an application.

Despite its name recognition, Watson isn’t the only artificial intelligence (AI) and natural language processing (NLP) game in town. This is certainly true in the consumer space which is dominated by the likes of Amazon Alexa and Google Home. Where once we used our fingers to turn on radios, flick light switches, and press buttons on thermostats, we now use our voices to instruct a machine to do them for us.

So, after finishing up the work on my Breeze/Watson text bot, I started thinking, “Could I do the same thing with other AI platforms?” The answer, of course, was “yes.” The services that allow Alexa to hear, process, and act upon human requests aren’t exclusively bound to Echoes and Echo Dots. Those capabilities live in the cloud and are available to anyone who wants to build applications on them.

This led me to the second incarnation of my text bot framework. It still uses Avaya Breeze and Context Store to manage texts and users, but the new version allows me to replace Watson with Amazon Lex. Actually, replace isn’t the right word. I am simply allowing bot developers to choose between two powerful platforms that can process incoming human language messages and generate the appropriate responses.

From a Distance

From a distance, IBM Watson and Amazon Lex look very much alike. They both process human language to come up with Intents, Entities, and Dialogs. The tools to build their bots aren’t all that different, either. You define AI constructs and train bots with utterances that become associated with those constructs. However, there are differences and those differences can be used by Avaya Breeze developers to add cool functionality to their SMS bots.

One thing that Amazon does that I could not find in Watson is the ability to define and configure “slots.” The easiest way to think of a slot is as a variable in a phrase. For example, you can create a slot called “AppointmentType” that contains a list of services a business provides. If you were building a bot for a dental office, the services might be “cleaning,” “whitening,” and “checkup.” Using slots, a valid training utterance would be, “I want to schedule a {AppointmentType}. At runtime, the bot would only accept appointment types of cleaning, whitening, and checkup. Any other request would cause the bot to reply with something like, “I am sorry. I am unable to provide that service.”

Amazon also supports a basic state machine that gives developers information that can be used to further refine a bot’s actions and responses. Returning to my dental office example, a bot might flow through the following states:

  1. ElicitIntent (what does user want – e.g., Appointment)
  2. ElicitSlot (what kind of appointment – e.g., Cleaning)
  3. ElicitSlot (what day for appointment – e.g., Next Wednesday)
  4. ElicitSlot (what time of day – e.g., 2:00 pm)
  5. ConfirmIntent (verify appointment type, day, and time)
  6. ReadyForFulfilment (let the user know that appointment has been made)

For those of you that like to get under the hood, Amazon does all this with JSON-formatted responses. These responses contain the State, Intent, Response, and Slot values. For example, this is the actual JSON that Amazon Lex returns when a user asks for a cleaning appointment.

{
"dialogState": "ElicitSlot",
"intentName": "MakeAppointment",
"message": "When should I schedule your cleaning?",
"messageFormat": "PlainText",
"responseCard": null,
"sessionAttributes": null,
"slotToElicit": "Date",
  "slots": {
    "AppointmentType": "cleaning",
    "Date": null,
    "Time": null
  }
}

Note that the Date and Time slots have yet to be filled. This will occur in subsequent messages to the bot.

Finally, this is the JSON that Amazon returns to confirm an appointment. Notice that all slots are complete.

{
"dialogState": "ReadyForFulfillment",
"intentName": "MakeAppointment",
"message": null,
"messageFormat": null,
"responseCard": null,
"sessionAttributes": null,
"slotToElicit": null,
  "slots": {
    "AppointmentType": "cleaning",
    "Date": "2018-03-24",
    "Time": "12:00"
  }
}

It’s up to the bot developer to use or to ignore this information, but for me, the more I am told, the better my solution.

Putting Amazon Lex to Work

As I did with my Watson-based bot, I built a Breeze workflow that put Amazon Lex through the paces. The beauty is that I could go back to my previous workflow and swap out the Watson task with the Amazon counterpart. This essentially gave me the same bot functionality that I had with the Watson version. In fact, the SMS user would not be able to tell the difference.

Amazon Lex

Next, I took advantage of the state machine and slot capabilities that Amazon provides. This required minimal extra work on my part, but it created a better customer experience that hid even further the fact that the text responses were all machine generated. Think Turing Machine.

Mischief Managed

There are times when too many choices can stifle creativity, but this is not one of them. I love it that I can pick and choose from AI engines to create the right bot for the right application. I can even envision solutions that use more than one engine. For instance, I might want to use IBM Watson for tone/sentiment detection and Amazon Lex for its state machine. And with Breeze, it’s as simple as dragging and dropping my way to bot heaven.

Views All Time
Views All Time
1429
Views Today
Views Today
5