Deploying Banking Bot using Amazon Lex
In our daily life we often have ambiguous or incomplete sentences. For example, when a customer is talking to a banking partner, he may say “What is my balance?” This request is unclear and difficult to remove if the customer intends to verify their credit card or check the account balance. Maybe he just has a bank account check. The agent can provide a good customer experience by looking at the account details and acknowledging that the customer is referring to the account review.
In customer service, agents should always resolve this uncertainty when interpreting the user’s purpose using the contextual data available to them. Bots have the same flaws and must know the right purpose by adding contextual data about the customer. Amazon Lex provides enhanced understanding and confidence in natural language. It is constantly improving the service based on customer feedback and research progress. These improvements done for better precision in purpose classification. You will know more about user input not included in the training data (except for domain word sets). In addition, it provides support for a trust mark to determine the likelihood of a pair with a specific purpose. Reliability scores for the first five goals emerged as part of the answer. It provides one with a better way to deal with ambiguous scenarios like the one we described. In these cases, when two or more goals are related to high trust, relying on trust when classifying intention can help you determine when to use business logic to create clarity, i.e. the purpose of the user. If a user has only one credit card, Lex can open the balance to show the credit card. If the user has a credit card and account check, Lex can also ask a straightforward question such as, “Is that for your credit card or account check?” before proceeding with the consultation. You now have a better understanding of how to manage the flow of speech and deliver more effective speeches. This post shows how you can use these improvements with confidence scores to trigger the best response based on business knowledge.
Building a Lex bot
This post uses the following conversations to model a bot. If the customer has only one account with the bank:
User: What is my balance?
Agent: Enter your PIN to confirm
Used: 5555
Agent: Your current account balance is $ 1,234.00It also serves as an alternative communication channel, where the customer has multiple
accounts:
User: What is my balance?
Agent: Of course. Is it for your checking account or credit card?
User: my credit card
Agent: Enter your CVV number to confirm on your card
Used: 1212
Agent: The balance on your credit card is $ 3,456.00
The first step is to set up an Amazon Lex bot to assist with balance requests, wire transfers, and payment processing. GetBalanceCreditCard, GetBalanceChecking and GetBalanceSavings provide information about your account balance. PayFills allows you to transfer and pay for TransferFunds to transfer money from one account to another. Finally, you can also use OrderCheck to run checks. If a user requests that the Lex bot is not processed for any purpose, the recovery target is triggered
Deploying the sample Lex bot
Follow these steps to crash the bank. For this post, you created the Amazon Lex bot BankingBot and an AWS Lambda function called BankingBot_Handler.
1. Download Amazon Lex bot definition and Lambda code.
2. Select the Lambda console Build function.
3. Enter the name of the function in BankingBot_Handler.
4. Select the latest Python running (for example, Python 3.8).
5. In the Permissions section, select Create New Duty with Common Lambda Permits.
6. Select the Create function.
7. If your new Lambda feature is available, select the Actions in the Feature Code section and upload the .zip file.
8. Select the BankingBot.zip file you downloaded.
9. Select Saving.
10. Select Actions, Import Amazon Lex Console.
11. Select the BankingBot.zip file you downloaded and select Import.
12. Select the BankingBot bot in the Amazon Lex console.
13. In the Compliance section, for each purpose, including a replacement purpose
(BankingBotFallback), select the AWS Lambda function and select14. BankingBot_Handler function from the drop-down menu.
15. When prompted to Add permission to Lambda function, choose OK.
16. When all the intents are updated, choose Build.
At this point, you should have a working Lex bot.
Setting confidence score thresholds
You are ready to set the trust score threshold. This setting determines when Amazon Lex wants to set the default backend based on target confidence scores. Follow these steps to configure the settings:
1. Select Settings in the Amazon Lex console and choose General.
2. In case of us-east-1, us-west-2, ap-south-2 or eu-west-1, go to Advanced options and
select Yes to choose the accuracy score feature to enable the trust score feature .
These improvements and trust score support are enabled by default in other regions.
3. For Confidence score threshold, enter a number between 0 and 1. You can choose to
leave it at the default value of 0.4.4. Choose Save and then choose Build.
When the bot is configured, Amazon Lex surfaces the confidence scores and alternative intents in the PostText and PostContent responses:
“alternativeIntents”: [
{
“intentName”: “string”,
“nluIntentConfidence”: {
“score”: number
},
“slots”: {
“string”: “string”
}}]
Using a Lambda function and confidence scores to identify the user intent
User “Can I get my account balance?” When he makes such a dark request. The Lambda feature matches the targets recovered by Amazon Lex. If multiple goals have been restored, check if the main goals have the same scores as AMBIGUITY_RANGE. For example, one goal has a confidence score of 0.95 and the other a score of 0.65. , the first goal may be correct. However, if one goal is 0.75 points and the other 0.72 points, you can set two goals aside using the business knowledge of your application. In our case, if the customer has multiple accounts, the functionality is configured to answer an explanatory question such as, “Is this for your credit card or to verify your account?” ? “But if the customer only has one account (for example, a check), put the balance back into that account If you use confidence scores, Amazon Lex returns a probable destination and four optional targets with the corresponding points in each answer. If all trust scores are below the set threshold, Amazon Lex has an AMAZON. FallbackIntent target, an AMAZON.KendraSearchIntent target, or both. You can use the default section or set your threshold. Below is a sample code of the Lambda code that was downloaded when you started this bot. You can customize it to use Amazon Lex with any bot.Lambda shifts the functionality of the handler functionality, but for the purposes of GetBalanceCreditCard, GetBalanceChecking, and GetBalanceSavings, it switches to the specified_intense. The Determ_intent function examines the main event reported by Lex, as well as alternative purposes. If an alternate purpose for the user is useful (based on their accounts) and included in the AMBIGUITY_RANGE content of the main event, add it to the list of possible events.
possible_intents = []
# start with the top intent (if it is valid for the user)
top_intent = intent_request[“currentIntent”]
if top_intent[“name”] in valid_intents:
possible_intents.append(top_intent)
# add any alternative intents that are within the AMBIGUITY_RANGE
# if they are valid for the user
if intent_request.get(“alternativeIntents”, None):
top_intent_score = top_intent[“nluIntentConfidenceScore”]
for alternative_intent in intent_request[“alternativeIntents”]:
alternative_intent_score =
alternative_intent[“nluIntentConfidenceScore”]
if top_intent_score is None:
top_intent_score = alternative_intent_score
if alternative_intent[“name”] in valid_intents:
if abs(top_intent_score — alternative_intent_score) <=
AMBIGUITY_RANGE:
possible_intents.append(alternative_intent)
If there is only one possible intent for the user, it is fulfilled (after first eliciting any missing slots).
num_intents = len(possible_intents)
if num_intents == 1:
# elicit any missing slots or fulfill the intent
slots = possible_intents[0][“slots”]
for slot_name, slot_value in slots.items():
if slot_value is None:
return elicit_slot(intent_request[‘sessionAttributes’],
possible_intents[0][“name”], slots, slot_name)
# dispatch to the appropriate fulfillment method
return
HANDLERS[possible_intents[0][‘name’]][‘fulfillment’](intent_request)If there are multiple possible intents, ask the user for clarification.
elif num_intents > 1:
counter = 0
response = “”
while counter < num_intents:
if counter == 0:
response += “Sure. Is this for your “ +
INTENT_TO_ACCOUNT_MAPPING[possible_intents[counter][“name”]]
elif counter < num_intents — 1:
response += “, “ +
INTENT_TO_ACCOUNT_MAPPING[possible_intents[counter][“name”]]
else:
response += “, or “ +
INTENT_TO_ACCOUNT_MAPPING[possible_intents[counter][“name”]] + “?”
counter += 1
return elicit_intent(form_message(response))
If there are no possible intents for the user, the fallback intent is triggered.
else:
return fallback_handler(intent_request)
To test this, you can change the test user configuration in the code by changing the return value
from the check_available_accounts function:
# This could be a DynamoDB table or other data store
USER_LIST = {
“user_with_1”: [AccountType.CHECKING],
“user_with_2”: [AccountType.CHECKING, AccountType.CREDIT_CARD],
“user_with_3”: [AccountType.CHECKING, AccountType.SAVINGS,
AccountType.CREDIT_CARD]
}
def check_available_accounts(user_id: str):
# change user ID to test different scenarios
return USER_LIST.get(“user_with_2”)
Lex’s reliability scores can be found on the Amazon Lex console or in the LambWatch Logs log file for the Lambda feature. You can also use trust scores to test different versions of your boat. For example, if you add new goals, statement, or closing value, you can test bots and check trust scores for the desired effect of the changes.
Hence, this way we can deploy a banking bot using Amazon Lex.
