I am developing a bot for banking purposes using RASA. I have intents for fund transfer, transaction history, loan, balance, bill payments, etc. I have implemented intents for handling the functionalities one at a time. And now, I want to handle multiple intents at a time.
For e.g, if a user says,
Show my latest transactions and then pay my bill after showing the balance.
How can I handle these kinds of inputs where the user asks for more than one or two functionalities in a single utterance?
I know, I can implement intents with multiple entities, but that seems to be not working for me as I have so many intents that I cannot afford to make intents with the combination of 2 or 3 entities.
Is it even possible to implement using RASA or any other technology for building a chatbot?
Approach 1 - multi-intents
You can use multi-intents (not to be confused with multi-entities). What you need to do is:
Write example nlu data for the intent separately (what you already have)
Write nlu data for the multi-intents combinations. In theory, Rasa will use both the information from both the single intent and multi-intent examples to correctly categorize. This means that you do not need that many training examples in the multi-intent
Write some stories that deal with these multi-intents
Specify a separator in the tokenizer configuration: intent_split_symbol: "+"
Please note that you need to have both NLU data for the multi-intents you want to support and stories, otherwise Rasa won't recognize them in the NLU and won't do anything in the Core.
References:
Rasa documentation for multi-intents
Blog post (be careful, the configuration changed since then, you should follow rather follow the documentation)
Example
This could give you something like this:
nlu.md
# intent:show transactions
- please show me my latest transactions
- show me my transactions
- ...
# intent:pay bill
- pay my bill please
- i want to pay my bill
- go ahead and pay the bills
- ...
# intent:show transactions+pay bill
- Show my latest transactions and then pay my bill after showing the balance.
- show me my transactions and go ahead and pay the bills
-
Note that you could write a script to automatically generate a few examples of multi-intents from the single intents
stories.md
# story 1
* show transactions
- action_show_transactions
# story 2
* pay bill
- action_pay_bill
# story 3 (combined)
* show transactions+pay bill
- action_show_transactions
- action_pay_bill
config.yml
language: "en"
pipeline:
- name: "WhitespaceTokenizer"
intent_split_symbol: "+"
- name: "CountVectorsFeaturizer"
- name: "EmbeddingIntentClassifier"
Please note that I'm using a different split symbol than the one in the documentation.
Approach 2 - instructions as entities
Another approach is to use a single intent ask_action and one or more entities that identifies your instructions.
You can then have an action action_execute_instructions that deals with all of them. It would look at the entities from the latest message, and execute whatever you need.
How you understand the instructions will strongly depend on how you chose to define the entities and how you manage to map them to the instruction you want. There is the SynonymMapper for that but it is not flexible at all and will fail if you have a new example that does not exactly match. You're better off writing your own NLU pipeline component in that case.
To be honest, I don't think this is a good approach. Entities should rather be, well, entities (ie: objects, locations, etc.)
nlu.md
# intent:ask_action
- [Show my latest transactions](instruction) and then [pay my bill](instruction) after showing the balance.
- [show me my transactions](instruction) and go ahead and [pay the bills](instruction)
- [pay the bill](instruction)
stories.md
# story 1
* ask_action
- action_execute_instructions
Recommendations
I would strongly recommend using the simplest approach. Once you have your bot live, you should review how your users use it and see if a more complex combination of intent (if you do multi-intents) is needed.
Related
Hey guys we need to realize the following workflow:
Our process looks as following:
We have a customer base with several attributes for each customer like city, type of product, segment and so on.It should be possible for the manager to choose the correct customers according to the attributes (e.g. all customer from city x and type y of product) and assign this customers to a marketing process.
The marketing process would look like:
User gets a notification call customer x
User is being asked how the call was and the user can choose from several categories (no interest, slight interest, wrong number, ....)
The logic behind what happens afterwards is in the program
THE WORKFLOW
In short:
Defining the customer range -> putting them into a process -> user gives a response in a pre defined way to the task he performed -> the process goes on
Thank you for your response!
PS. There is no need for VOIP integration.
The short answer is yes, OroCRM is flexible enough to handle completely custom workflows. Simple workflows, like the one that you described can even be configured from the user interface, without custom development.
We have a customer base with several attributes for each customer like the city, type of product, segment, and so on.
Depending on the needs, you can use one of the existing OroCRM entities as a base customer (e.g. a Lead or an Account entity) and add all the needed extra fields using the entity management. Or you can create a completely new custom entity with all the fields and relations to use it as a base customer.
It should be possible for the manager to choose the correct customers according to the attributes (e.g. all customers from city x and type y of product)
You can use OroCRM data grids to filter base customers by attributes and even create a custom grid view with predefined filters to reuse it later. The flexible reporting system also may be helpful here.
and assign these customers to the marketing process.
In OroCRM they are called workflows. There are a few predefined workflows, and you can create a completely custom within the user interface.
I'm trying to implement a read confirmation in a number of wiki pages.
I'm trying to use trackers.
General Description:
Employees in our company are assigned to read a number of official procedures.
I'm trying to implement a process where:
Each employee is assigned procedures he needs to read according to his department (Group).
Each procedure is a wiki page
At the end of each procedure there will be a confirmation form in the following format.
Users that don't need to read this procedure won't see this form.
Users that confirmed reading the document will see a message like:
You've confirmed reading this procedure.
Administrators will be able to monitor who read what procedure.
Questions:
How do I hide the tracker plugin from users who don't belong to the department (Group)
How do I display a different message once the user confirmed the read
Thanks
There are different way to achieve this and it require a bit of thinking (trade-off from a method to another), but this is what I’ll do.
Have 2 groups (before approving - after approving)
Display the procedures using a plugin listExecute and having at the end the approving checkbox to have some actions (notification, group changes, etc).
Enclosing everything in a tracker and turn it into a multipage forms can also be the way.
Your case remind me other use case I worked on including Official Procedures reading including quick test (to check if the procedures were understood) and approving mechanism. Look at https://doc.tiki.org/PluginExercise ;)
Good luck
Bernard
https://www.facebook.com/bsfez
Another, possibly simpler (? ;) way to do that would be to use just plugins group and list, maybe like this:
{GROUP(groups="This Department")}
{LIST()}
{filter type="trackeritem"}
{filter field="tracker_id" content="42"}
{filter field="tracker_field_procedurePage" content="{{page}}"}
{filter field="tracker_field_userLogin" content="{{user}}"}
{OUTPUT()}~tc~Item found, so already done~/tc~You already did this bit{OUTPUT}
{ALTERNATE()}~tc~Nothing found, show the form~/tc~{tracker trackerId=42 etc...}{ALTERNATE}
{LIST}
{ELSE}
You don't need to fill in the form
{GROUP}
This is totally untested i'm afraid, and i'm not 100% sure you can use a plugin in the ALTERNATE section, but give it a go? If it doesn't work, try using {display format="wiki plugin" etc...} which might do the trick - good luck!
Following is a use case in a workflow system
Work order enters into a system. Work order will have a target which goes through different workflow states before completing a work order.
Say Work order for a target Vehicle came into a system - workflow for this work oder involves 2 tasks say
a)wash vehicle
b)inspect vehicle
Say wash vehicle workflow task changes vehicle attribute from "not washed" to "washed". And say "inspect vehicle" workflow task changes vehicle attribute "not inspected" to "inspection done"
If user is pulling work order data user will always see latest vehicle data (in this example assuming both workflow tasks are completed user will see value "washed" and "inspection done". However when user pulls ONLY workflow Task Wash Vehicle data -> user will see "washed" -Though second task was done, workflow Task 1 will only see that that it modified. Getting data for Workflow Task 2 will see both "washed" and "inspection done"
This involves milstoning (audit trail) of data; One approach is as shown below image - where when workflow task modifies data it'll update version number, modified_ts and maintain that version number in it's own data row (via a JOIN table as depicted below). Basically this is nothing but maintaining a reference to a history record for workflow task data so when pulling workflow task data it knows which history record to pull back. please ignore parent_id and other notes, noise in a below picture. it's not relevant for this question.
I am thinking event sourcing will also be another alternative design - however don't want to apply event sourcing(or any other similar solution) as a whole sale solution but only for this particular use case (affecting only 3 or so tables where audit trail matters). I am trying to evaluate if CQRS/Event sourcing is a right fit as a partial solution (again only limited to 3-4 tables which need to preserve history/audit trail data) or ES/CQRS will be an overkill? any other thoughts?
P.S. Though this isn't related to Scala - Scala is a platform we are using hence tagging it to see if there are language specific solutions that can help. tagging Akka for finding out if ES/CQRS via Akka persistence is an option or not. Postgresql is a db - And DB triggers is not a solution I am looking for.
I have here a Websphere commerce 7 Fp 5 Aurora B2B which is using Orgs, contracts and price lists maximum order quantity that we limit each "Store" Org to buy 3 each so that there is enough to go around. We have 3 sets of entitlements to that most guys Max is 3, better stores max is 5 and a few really good ones max qty is 10.
So we don't have to worry about allocation, these rules let every store buy based on their entitlement. When they try to put more in the cart then they should, they get a message "You are requesting to order more than your allocation limit. Please change your requested quantity." I don't know where this comes from.
Some users buy for 5 or more stores which is selected at checkout during payment. This keeps those store owners from having to have a bunch of log ins to keep track of.
We recently openned up Order Management, we call it multi-cart because this enables a store owner to create more than 1 cart by going to order management and create a new order. This makes it much easier for our store owners to manage what they are buying and paying and receiving with out having to call and email our CSR teams.
But now we noticed that some stores are taking advantage of the Multi-cart to buy more that the MAX qty they are allowed. It wouldn't be so bad, but they are buying all the 1 per customer stuff and all the other stores are calling and complaining because they didn't get their share. It really isn't fair.
I was thinking of all the different places to add a SQL check of order history and pending orders. Here is what I cam up with.
ATP - Inventory check
Pro- best place since customer, sku, entitlement, and everything else pretty much happens here. It is right up front.
Con- It doens't have ship-to, so the guys with more than 1 store need to be added as an exception leading sloppy business logic that could change regularly
OrderItemAddCmdImpl and overloading ExtendOrderItemProcessCmd
Pro - Bring ship-to selection up to the front and control everything here.
Con - Not certain overhead will like it.
At checkout
Pro - this also will have everything
Con - I kind of want to reserve this for all payment handling. It is a little dirty to read throught the order lines and to kick back error with SKU.
Have the ERP handle the exception-
Con - I realized we are setup that all Orders ship complete, we would have to change this and don't really want to because there are additional credit card penalties for charges less then amount held on credit.
So, the questions are what are your thoughts on additional pros and cons?
Are there other places that I'm missing that would make more sense?
We might need to create a new CommandTask and then append it to all existing flows.
OR
As the WebSphere Commerce team to build this new logic into the next release of WebSphere Commerce.
So, for this scenario the answer was creating a JDBC Query that will be called when items are added to cart that sums the Qty by sku of pending orders.
When orderitems are added to the cart, the query will return the item in error if exceeded and not add item.
The query will again run at checkout if all orderitems being paid for exceed total qty max by SKU by shipping address on payment page allowing chance for customer to change billing address if we are limiting item max qty by shipping address.
I am building a base workflow will support around 25 Customer
all customers they matches with one basic workflow and each one has little different request lets say one customer wanna send email and another one don't wanna send email
What I am thinking to make
1- make one workflow and in the different requirement I will make switch to check who is
the user then switch each user to his requirements
(Advantages)this way powerful in maintenance and if there is any common requirements
easy to add
(Disadvantages) if The customer number increase and be like 100 and each is different
and we expect to have 100 user using the workflow but with the Different
little requirements
2- make Differnt workflow for each customer which meaning I will have a 100 workflow
in the future and in declaration instantiate the object from the specific workflow
which related to the Current user
(Advantages) each workflow is separate
(Disadvantages) - hard to add simple feature this meaning write the same thing 100
time so this is not Professional
so What I need ??
I wanna know if those only the ways I have to use in this situation or I missing another technique
One way would be to break out your workflow into smaller parts, each which do a specific thing. You could organize a layout like the following, to be able to support multiple variations of the inbound request.
Customer1-Activity.xaml
- Common-Activity1.xaml
- Common-Activity2.xaml
Customer2-Activity.xaml
- Common-Activity1.xaml
- Common-Activity2.xaml
For any new customers you have, you only need to create a root XAML activity, with each having the slight changes required for your incoming request parameters.
Option #2: Pass in a dictionary to your activity
Thought of a better idea, where you could have your workflow have a Dictionary<string, object> type be an input argument. The dictionary can contain the parameter/argument set that was given to your workflow. Your workflow could then query for the parameter set to initialize itself with that info.