The goal of this article is to help you discover some advanced features of the memory management tools we provide on SAP Conversational AI. Through this article you will learn how to use the memory to manage the context as well as remember previous interactions in a smart way. This tutorial is meant to be for advanced users, if you haven’t built your first bot, don't hesitate to find beginner tutorials on our blog first!
The memory is a persistent object that is created for every conversation per user. Memory stores by default requirements that are asked within the Bot Builder. You can modify the memory of the bot through the interface of the Bot Builder within the requirements or within the actions tab, it is also possible to update/set the memory through the API of the Bot Builder. To access the memory simply use ‘_memory’ under the triggers or the actions tab.
The use case consists of building a bot that can help our clients to unlock their SIM card or get their invoice. In order to do this, we need to authenticate the user. Once the client has been authenticated the bot will execute the remembered request, ask for a feedback and store it. To start, let’s create two intents 'sim-card' and 'see-invoice'. In this specific use case the bot does not need to contain any entity.
Here is the diagram representing the flow:
Here is how it will look like within the Bot Builder:
The first two skills within our builder are 'sim-card' and 'see-invoice'. Those two skills do not contain any triggers as they will be called only once the client is authenticated, nor do they contain requirements. The skills 'sim-card' and 'see-invoice' will only display a hardcoded message such as detailed below.
(Don't worry, "memory.customer.phone" will be explained later on)
The use case flow starts with the skill 'auth-start' which is going to be triggered by both our two new intents 'sim-card' and 'see-invoice'. The goal of this skill is to check if a client has been authenticated before actually executing the request. The skill does not contain any requirements. In actions the bot checks if our user is authenticated or not. If yes, then the memory should contain a customer variable and will call the corresponding skill else the bot will store the requested intent and launch the authentication skill 'auth-ask'.
If _memory.customer is-present means that the bot checks if within the memory there is a variable customer that exists. If that is true, then it redirects to the right skill and instead of choosing a skill from the dropdown menu the bot uses the memory to dynamically redirect to the right skill. By doing {{nlp.intents[0].slug}} the bot will get the slug (or name) of the intents which are 'sim-card' and 'see-invoice'. As the intent’s slug name is the same as the skill’s name, it will get evaluated as got to 'sim-card' skill or 'see-invoice' skill.
If _memory.customer is-absent means that there is no variable customer stored in the memory. Therefore, the bot needs to authenticate the user. In order not to ask our client about the previous request, the bot stores the user’s intent by adding a memory field named 'user_intent' and assigning the value "{{nlp.intents[0].slug}}". This needs to be put into quotes in order for the Bot Builder to interpret it.
The 'auth-ask' skill needs to gather two requirements: the phone number of the client (phone entity) as well as the secret code of the client (number entity). Once added within the requirements the bot will store those values within a single customer variable in the memory and then erase previous fields. The bot will then ask the client to confirm if this is the right phone number and pin. In this case, the bot needs to wait for the user’s input as for it to work, the next skill needs to be triggered only when the user answers 'yes' or 'no'.
The 'auth-validation' skill has two requirements that are 'yes' and 'no' under the same 'validation' alias. Within the action the bot checks if the user said 'yes' or 'no'
If _memory.validation.slug is 'yes’. If that is true, the bot will unset validation and then redirect dynamically to the right skill using the requested intent in the first skill using the memory.
If _memory.validation.slug is 'no'. Clear the memory with the customer information gathered and also validation, then redirect to the skill 'auth-ask' to start the process from the beginning.
Once redirected to the correct skill 'sim-card' or 'see-invoice', they will display a static message and then redirect to 'ask-feedback'. The goal here is to gather a feedback regarding the experience of the bot, the 'ask-feedback' skill has two requirements 'yes' and 'no' to ask the users if they want to give a feedback. If they say no, close the conversation, else then set in the memory a variable 'wait_feedback' to 'true'. The bot will propose to choose between 5 choices and redirect to the 'save-feedback' skill.
This is where the magic happens. The Bot Builder works like a stack: each skill that gets triggered goes within the stack and the last skill that has been triggered gets at the top of the stack. When the Bot Builder receives a sentence, it will go through the top of the stack first and then go down. Meaning the Bot Builder will try to validate the conditions of the skill at the top of the stack.
The Skill 'save-feedback' has a trigger that is if _memory.wait_feedback is-present, as the previous skill redirected to this skill, the skill is now at the top of the stack. The condition will always be true as the variable within the memory was set in the previous skill. That means whatever the user says the Bot Builder will trigger this skill anyway and therefore bypass the NLP.
'save-feedback' has no requirements. Action will store the answer of the customer by setting a new field within the memory capturing {{nlp.source}}.
The memory is a very powerful tool that allows you to do lots of things within the Bot Builder. Here are the key things you should keep in mind going forward:
- You can save the current intent for later using {{nlp.intents[0].slug}}
- You can dynamically go to a skill using your memory {{memory.user_intent}}
- You can bypass the NLP to store a free text entry chaining two skills together with a memory field
The whole bot can be found at this address.
Hope you enjoyed this tutorial, and join our Slack if you need any assistance! We also warmly invite you to join our Meetup group where you'll find the next sessions of our workshops at our Paris office, an unique opportunity to learn more about our platform and chat with our team.
What is memory?
The memory is a persistent object that is created for every conversation per user. Memory stores by default requirements that are asked within the Bot Builder. You can modify the memory of the bot through the interface of the Bot Builder within the requirements or within the actions tab, it is also possible to update/set the memory through the API of the Bot Builder. To access the memory simply use ‘_memory’ under the triggers or the actions tab.
Our example use case
The use case consists of building a bot that can help our clients to unlock their SIM card or get their invoice. In order to do this, we need to authenticate the user. Once the client has been authenticated the bot will execute the remembered request, ask for a feedback and store it. To start, let’s create two intents 'sim-card' and 'see-invoice'. In this specific use case the bot does not need to contain any entity.
Here is the diagram representing the flow:
Here is how it will look like within the Bot Builder:
Our 'sim-card' and 'see-invoice' Skills
The first two skills within our builder are 'sim-card' and 'see-invoice'. Those two skills do not contain any triggers as they will be called only once the client is authenticated, nor do they contain requirements. The skills 'sim-card' and 'see-invoice' will only display a hardcoded message such as detailed below.
(Don't worry, "memory.customer.phone" will be explained later on)
The authentication flow
The use case flow starts with the skill 'auth-start' which is going to be triggered by both our two new intents 'sim-card' and 'see-invoice'. The goal of this skill is to check if a client has been authenticated before actually executing the request. The skill does not contain any requirements. In actions the bot checks if our user is authenticated or not. If yes, then the memory should contain a customer variable and will call the corresponding skill else the bot will store the requested intent and launch the authentication skill 'auth-ask'.
Case 1
If _memory.customer is-present means that the bot checks if within the memory there is a variable customer that exists. If that is true, then it redirects to the right skill and instead of choosing a skill from the dropdown menu the bot uses the memory to dynamically redirect to the right skill. By doing {{nlp.intents[0].slug}} the bot will get the slug (or name) of the intents which are 'sim-card' and 'see-invoice'. As the intent’s slug name is the same as the skill’s name, it will get evaluated as got to 'sim-card' skill or 'see-invoice' skill.
Case 2
If _memory.customer is-absent means that there is no variable customer stored in the memory. Therefore, the bot needs to authenticate the user. In order not to ask our client about the previous request, the bot stores the user’s intent by adding a memory field named 'user_intent' and assigning the value "{{nlp.intents[0].slug}}". This needs to be put into quotes in order for the Bot Builder to interpret it.
The authentication ask
The 'auth-ask' skill needs to gather two requirements: the phone number of the client (phone entity) as well as the secret code of the client (number entity). Once added within the requirements the bot will store those values within a single customer variable in the memory and then erase previous fields. The bot will then ask the client to confirm if this is the right phone number and pin. In this case, the bot needs to wait for the user’s input as for it to work, the next skill needs to be triggered only when the user answers 'yes' or 'no'.
The authentication validation
The 'auth-validation' skill has two requirements that are 'yes' and 'no' under the same 'validation' alias. Within the action the bot checks if the user said 'yes' or 'no'
Case 1
If _memory.validation.slug is 'yes’. If that is true, the bot will unset validation and then redirect dynamically to the right skill using the requested intent in the first skill using the memory.
Case 2
If _memory.validation.slug is 'no'. Clear the memory with the customer information gathered and also validation, then redirect to the skill 'auth-ask' to start the process from the beginning.
Feedback skills, or how to save a free text entry
Once redirected to the correct skill 'sim-card' or 'see-invoice', they will display a static message and then redirect to 'ask-feedback'. The goal here is to gather a feedback regarding the experience of the bot, the 'ask-feedback' skill has two requirements 'yes' and 'no' to ask the users if they want to give a feedback. If they say no, close the conversation, else then set in the memory a variable 'wait_feedback' to 'true'. The bot will propose to choose between 5 choices and redirect to the 'save-feedback' skill.
This is where the magic happens. The Bot Builder works like a stack: each skill that gets triggered goes within the stack and the last skill that has been triggered gets at the top of the stack. When the Bot Builder receives a sentence, it will go through the top of the stack first and then go down. Meaning the Bot Builder will try to validate the conditions of the skill at the top of the stack.
The Skill 'save-feedback' has a trigger that is if _memory.wait_feedback is-present, as the previous skill redirected to this skill, the skill is now at the top of the stack. The condition will always be true as the variable within the memory was set in the previous skill. That means whatever the user says the Bot Builder will trigger this skill anyway and therefore bypass the NLP.
'save-feedback' has no requirements. Action will store the answer of the customer by setting a new field within the memory capturing {{nlp.source}}.
Finishing up
The memory is a very powerful tool that allows you to do lots of things within the Bot Builder. Here are the key things you should keep in mind going forward:
- You can save the current intent for later using {{nlp.intents[0].slug}}
- You can dynamically go to a skill using your memory {{memory.user_intent}}
- You can bypass the NLP to store a free text entry chaining two skills together with a memory field
The whole bot can be found at this address.
Hope you enjoyed this tutorial, and join our Slack if you need any assistance! We also warmly invite you to join our Meetup group where you'll find the next sessions of our workshops at our Paris office, an unique opportunity to learn more about our platform and chat with our team.
- SAP Managed Tags:
2 Comments
| User | Count |
|---|---|
| 14 | |
| 13 | |
| 11 | |
| 11 | |
| 11 | |
| 11 | |
| 10 | |
| 9 | |
| 9 | |
| 7 |
