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.
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 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?
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:
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.
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…
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.
Never rush — make the right decision
An executive’s guide to AI and Intelligent Automation. Working Machines takes a look at how the renewed vigour for the development of Artificial Intelligence and Intelligent Automation technology has begun to change how businesses operate.