Enabling Business Intelligence in Chatbots with Amazon Lex

In this fast-paced digital age, organizations need a fast and efficient way of gathering information. Especially in a customer-driven market like fintech, “time is money ”. Decisions will have to be made accurately and fast. Incorrect decisions can lead to severe consequences or lost customers. In several fintech applications, information is made available through reporting solutions, presentations, charts, etc. What customers find difficult is digging out the specific report or data needed through a multitude of mouse-clicks and then spending a lot of time analyzing them. There is a critical need for one central point from which a variety of data can be delivered to the user in an efficient and effective process. AWS technology and tools open several avenues to make this possible.

Amazon Lex – Machine Learning As a Service

Amazon Lex is one service that enables state-of-the-art chatbots to be built. It has redefined how people in the industry perceive building chat-bots. Bots themselves have gradually evolved from typical question-answering bots to more complex ones that can perform an array of functions. Amazon Lex offers features that tackle several complexities faced while building the previous generation of chatbots. The intent fulfillment, dialogue flow, and context management features of Amazon Lex help to make conversation with a chat-bot as human-like as possible.

This blog discusses how information can be retrieved from databases with a simple question asked to Kasper (the name of our bot). The following components of this blog will give a clear understanding to the user, how everything is built, networked, and coupled with a custom user interface.

Solution Architecture

Kasper is a chatbot built specifically for a lending platform to retrieve various data points based on specific inquiries. Like all bots, Kasper is also built on intents, utterances, and slots. After adding intents, its corresponding utterances, and slots, a few slots need to be added as custom slots. For example, there was a query – “show clients where invoice amount is greater than 20000”.  In the utterance section of Kasper, it was recorded as below:

 

Here ‘cola’ and ‘operatora’ are slot variables under custom slots ‘columnname’ and ‘operator’ respectively.

Natural Language to SQL Conversion

All the responses that require output from the database are sourced with the help of a lambda function. The JSON response from the lambda function contains the input transcript, intent, and slots information. The back-end application then receives the response from the lambda function, segregates the JSON, and classifies information into the corresponding intent and slots. The application extracts the slots and intents and then proceeds to build the query.

Responses from Kasper

Responses from Kasper can result in different formats of data. There can be single value responses, images, tables, etc. The types of responses are automatically determined from the intents. A custom website with a chat window has been developed for interacting with Kasper. The chat window can take in both texts, as well as audio inputs. The following are the detailed sections explaining each response type, with their corresponding chat window.

 

Response type I – Single values

There are instances where users might want to know about a sum or count or any other single value response. For example, an inquiry might be “count the number of clients whose due date is within 2 weeks” or “sum of the invoice amount of all clients“. The responses of these queries will be just a single value eg. “10,000”.

Response type II – Images and Tables

1. Tables

Images and tables are the next type of responses Kasper delivers. Once the SQL query is constructed, it connects with the database and retrieves data and stores it in a pandas dataframe. This dataframe can be exported as an html table for previewing through the chat window. It can also be downloaded in the form of a csv file.

2. Images

From the pandas dataframe, different charts/graphs can be derived. When an image response is expected, charts are generated using python libraries, saved to a file, and then exported to the chat window. Two types of images are generated – one is a thumbnail and the second is the actual image. Kasper is equipped with a feature named Auto-visualization. According to the dataframe, the function will decide what type of graph or chart has to be plotted. There are numerous rules applied before making that decision. For example, the function determines whether a specific column features continuous or categorical values. The resulting graph is plotted based on such combinations.

Response type III – Fallback mechanism with response card

The third type of response are response cards – a response to clarify the intention of the user. Suppose the user asks an ambiguous question like this “what is the amount of Apollo Inc. “. The chatbot will find the query to be missing some keywords because the user did not specify the type of amount (either invoice amount or balance amount). Kasper then prompts back with a list of possible options, so the user can select the appropriate option and receive the accurate result.

Kasper is a chatbot that has evolved to its current operational capabilities because of maximizing Amazon Lex’s potential and accommodating other significant AWS services to its architecture. Currently, Kasper can solve important natural language to SQL problems and a few FAQ questions as well. It can also be modified for other domain problems to suit specific needs. Over time, more capabilities will be possible to add and could serve as a first-line substitute for human support personal, freeing up your support team to help address more critical issues more quickly. If you’re interested in how a chatbot might improve your operations, schedule a Free assessment with our Machine Learning team today.

Want to learn more?

Source link

By ASNF