I have a use case where some slots/entities are set based purely on how the communication/SMS came into the core system. For example, we have phone numbers configured so that if phone number is x, then an entity “foo”:“A” and if the phone number is y, then “foo”:“B”.
These phone numbers are attached to A and B respectively in the real world (in some kind of marketing website), so it’s expected that when a user enquires via phone number x, then they are talking about “foo”:“A” without ever referring to it in the SMS conversation.
How does one pass the slot “foo”:“A” to the bot, such that even if the user utters “Hello”, the bot still knows that the inquiry from the user is for “foo”:“A”? Let me know if there are other details I should provide.
Maybe you can try using “foo” as a categorical slot and create stories like this:
In domain.yml:
slots:
foo:
type: categorical
values:
- A
- B
In stories.md:
## hello foo A
* hello
- slot{"foo": "A"}
- utter_hello_A
## hell foo B
* hello
- slot{"foo": "B"}
- utter_hello_B
If i’m not mistaking anything, the bot will learn to use the information of slot “foo” to decide on the correct action to take (utter_hello_A or utter_hello_B). Of course if you want to apply this to more intents, you also have to create more stories correspondingly, so it’s probably not very effective if you are planning to achieve this on a bigger scale than a few intents.
Exactly @fuih. My worry is deploying such kind of “meta slots” at scale. If I have to pass such slots (and these need not be the only ones) with every kind of intent, it becomes really messy very quickly and turns into a similar kind of state problem Alan spoke about here - A New Approach to Conversational Software - Rasa Blog - Medium.
Tagging @Juste, @amn41 to see if there are any easier ways to handle this kind of use case.
thanks @ganeshv ! interesting problem - can you give an example of the different kinds of slots you expect to be set for the user? Sounds like you’re worried about having many levels of branching?
The idea is to be able to pass various kinds of information to the bot that is outside the conversation. So let’s say in a sales context, the customer reaches out by texting a particular number (so we know which marketing channel they came through and we tie that with say, one object in our data model) and makes no mention of this object in the conversation ever.
So if the phone number were generic, they may say, I’m interested in foo under object bar, but since the customers see an ad for bar with the phone number referenced above, the conversation may never mention bar as they are already talking to agents representing object bar. In other words, it’s setting a context for the bot that originates outside the message and is possible that it may never be mentioned.
Additionally, in our use case, there could be multiple actions possible for the same message and in such cases, some actions are better than others.
For example, in the channel they reached out, they simply say “I’m interested in foo”. Depending on where the customer is in the sales lifecycle, we may do one or a combination of -
book an appointment to talk about foo
add foo to an existing appointment
send them a quote about foo if they have already talked about foo
ask to void an existing agreement on foo2 if it exists, to switch to customer’s new interest in foo
Again, this is context that the human participants would be aware of when they read the same message, but I was trying to send these slot(s) to the bot so that it can choose the right story to proceed.
This is at an early stage still and I’m also very new to using Rasa, so we’re open to your thoughts on how to execute this best.
And yes, branching is a concern. Of the ones mentioned, we may only have a subset of information outside the message to pass to the bot. There are some pieces of information (like the marketing channel) that will always be available to us by the time we send the message to a Rasa instance.
hi Ganesh - thanks for clarifying. I think if you have lots of potentially branching logic based on these external events, the easiest way to achieve that is to create a custom action class. You can use the implementation of the FormAction as inspiration rasa-sdk/forms.py at master · RasaHQ/rasa-sdk · GitHub
Alternatively, you could use an actual form and post the slots as user inputs to the channel, e.g. pretending that the user had sent messages informing your bot about these slots
Used the triggerConversationIntent method to both initialize the conversation and inject slots that were determined through methods outside the conversation.
