Lex vs Luis: choosing the right solution to create bots for your business

I’ll avoid a long intro about the new age of automated solutions, artificial intelligence and cognitive services, mostly because right now that’s not news given its prevalence in the tech space. What I really want to delve into is how AI and automation is currently being used specifically in terms of chatbots.

Social Networks — forging ahead

It seems all of the most popular networking and messaging platforms had their hands on some insider knowledge because, generally, they all seem to understand how users would want to consume and collaborate with businesses and web services. All the major players in software development and cloud services are in the race, providing a number of 3rd party deep learning systems, voice recognition software and AI for conversation, programmes.

What’s the business when you need a bot?

What if you don’t have thousands of hours and hundreds of developers dedicated to building your own AI? The answer is a simple one: Use an already existing solution to take your business further.

I’d like to take you through my experiences with two great services, which we used to create the Elio and Olivia chatbots: Amazon Lex and Microsoft Luis. Our primary goal was to integrate these bots into social and business messengers, such as Facebook and Slack. However, the question we’re left with is: which option is better?

There’s Amazon Lex…

A serverless solution without an individual backend that stores everything on AWS cloud and is available in the most commonly used languages.

Serverless, really? Well, sort of. This appears to be the simplest solution to train the Lex, using desired phrases and intents as well as writing scripts for Lambda’s function which claims to be an alternative to writing your own back-end code and using built-in integration with Facebook messenger. Lambda allows you to use either Node.js or Python, but eventually we did have 2 additional back-ends/ APIs to serve our bots based on Lex technologies. As we all know, the devil is in the details.

Choose the right domain before making a decision, in other words — choose the scope of your activity and be clear on what your business actually does.

Lex has a predefined list of subjects and related entities it is able to recognize and recommend, including: movies, music, countries, locations, dates, times numbers, genders, cars, airports and other faceless domains. It is therefore simple to create a bot that can help you order pizza, rent a car or find and book a hotel, because the information required from the user is already validated by built-in types preprogrammed into Lex. Once all fields have been filled, you just fire the serverless Lambda script to perform the intended action based on the information received from the user.

However, in our case we wanted to create a skin assessment bot that could take a user through a several step survey, to help them find the appropriate cosmetics. Here we had a really specific objective with specific questions covering: skin complexion, skin concerns and sensitivity etc.

Our developer was required to:

• Validate the input according to domain logic
• Check if these inputs were correct
• Make suggestions to users on how to make the correct input

As there was no OOTB answer on how to do this, the solution to this issue was to write our own API which could interact with current online cosmetic shops and incorporate all of those filters and attributes. The Lambda script can then use the API as a third party end-point.

This is the first additional back-end service

Do we really want Lex to know all of our crazy ideas and business specifics? A question for another day perhaps.

But in the meantime, let’s think about the auditory and group conversations

While developing the skin assessment as a FB chatbot we also had to create another DevOps chatbot for Slack. His name is Elio.

Elio integrates into a group chat/channel. The challenge, however is that he is triggered by each message, sent within the specific channel in which he is added. For example, if Mario chats with Alex in this channel, Elio will interject with an error report along the lines of “Sorry, I did not understand what you said?” after every message that doesn’t match Elio’s knowledge base.

I am sure you’d agree that this is pretty clumsy and most definitely not seamless.

The solution? We replaced the built-in Lex integration for Slack with a custom one. Replacing it with a custom integration — an owned back-end mediator service that uses the Slack API and Amazon API Gateway and connecting them together in a seamless chat. This allows us to detect messages which cannot be understood by Lex and prevent it from communicating when real people are speaking.

This is our second additional back-end service and that’s what we have here…

Is Luis the solution or just another alternative?

On the one hand Luis is a more flexible solution for more complicated chatbots and for group chats, however, the truth is that Luis is not simple to implement.

Luis has a more sophisticated learning system and there is more power in luis.ai console than Lex. With Lex you can easily get a content manager or another stakeholder to help you define entities and/or types and fill in user utterances. It is not that simple with Luis.

Be aware — This may be more challenging for non-tech peeps but the diagram explains perfectly the complexities associated with Luis.

With Luis all of the actions for each user’s intent can only be created from the application side i.e. only by developers. By using this client-app-binding approach, you can handle any errors that are not recognized user inputs, making it ideal for group chats.

Luis has a bunch of shared sources and an existing bot framework to build a chat based on Luis’ intents and logic.

Luis also has many integrations with popular social messengers and platforms, such as: Slack, Facebook, Twillio, Skype, Web widgets, email etc.

So in my humble opinion:

Both Lex and Luis’ systems have nice features but require careful consideration dependent on your goals, domain, subject and flow. You need to really interrogate these things before you make a decision.

• Lex is perfect for clear, easy flow conversational assistance for booking, searching and to construct a personal assistant that can help with daily routines by passing simple and strict commands. In combination with Alexa speech service, it might be a really fancy and handy serverless solution. The truth is I would never use a huge system like Luis for these kinds of simple actions. It is the system I prefer for more complicated flows and it really is an effective solution for a chatbot with more complicated actions
• Lex is really good system to build DevOps bots with, especially if you prefer Amazon’s environment and services — it provides easy access for all of your AWS powers by using a specific Amazon role
• If you want to avoid additional back-end applications, do not use Lex in group chat conversations as Luis is far more effective within this context
• Lex is an effective system for when you want your less techie team members like your product owner or content manager to be more actively involved, whereas Luis requires a technically experienced person
• Regarding the samples described above, as a techie myself I would use Luis instead of Lex , solely because of the specifics of domain logic, flow, target auditory and because I have skills in Node.js and .NET

Never rush — make the right decision

Mario Grunitz

Previous story

Meet Pavel, WeAreBrain’s UX Design Dynamo

Next story

Creating a personality for your chatbot using clever copy