As far as I understand it is possible to have different responses for the same intent which is called response variation. At the moment this can only be used by classifiers as DIET (one of the responses gets selected randomly) but not by the response selector.
My question: Is it possible to somehow implement here a custom behaviour (for a custom intent classifier or a response selector) so that it is possible to track which responses for a certain intent have already been uttered by the bot so that the bot can respond differently each time for the same intent?
Thank you for your response.
Hey @Chris38, thanks for the interesting question!
Having multiple response variations is something that relates to a particular response (a.k.a action); it isn’t related to an intent. Rasa Core predicts an action and if it’s an
utter_ action with multiple response variations defined, one of those will be chosen. So, even when using response selectors, you can define multiple variations for
utter_chitchat/askhowdoing or similar. (I just checked on my simple bot with Rasa 2.2 and it works, choosing randomly from the provided response variations.)
As for tracking which response variations were used: This definitely sounds very useful, e.g. to prevent repeating the same response variation twice in a row. [Once again, choosing from multiple response variations isn’t related at all to intent classifiers or to response selectors (which can be viewed as “sub-intent” classifiers) – both of these are NLU components within Rasa. Picking a response variation happens in Core, namely in the NLG part here.] I don’t think there’s currently an easy way to track the use of response variations, but it sounds like a good use case for a separate NLG server (I recommend you look at the docs for it). Basically, Rasa Core sends the predicted action to your NLG server and there you pick a response variation based on whatever logic you want
Let me know if you’ve got any further questions.
Thank you for your reply! So I checked how to build an nlg server. But I think I need to go deeper. Picture the following:
I have a response selector and every time the user utters something a response is predicted. I want to track which responses and which response variations have already been uttered by the bot. If for a certain response all response variations have been uttered I instead want to utter a different response.
Looking into the nlg component, it does not look for me like this is the place where this behaviour should be implemented.
If for a certain response all response variations have been uttered I instead want to utter a different response.
Hmmm, how do you decide what to utter if you don’t want any of the defined response variations? I mean, imagine the user says
Hey there with intent
greet and for that you’d usually execute
utter_greet and utter one of the X defined response variations for
utter_greet. But if you run out of those response variations, how do you choose which (different)
utter_ response to execute such that it fits with the user’s intent? Or do you want to generate an additional response variation in that case, which would fit
Maybe knowing what your use case is would help me understand this better @Chris38
The use case is a bot which is able to talk about a certain topic. It should be able to recognize an argument a user utters and respond to it. But if a user utters the same argument multiple times the bot should not respond with the same argument every time but instead utter a completly different argument ( i.e. the bot changes the topic).
Ah, I see! In that case, I think there are multiple options (but take it more as “educated guesses”):
- Create your own simple policy that will make a prediction only if (by looking at the tracker) it sees that the same argument (intent) has been repeated by the user enough times, and otherwise it will leave predicting the next action to the other policies.
- Less nice, but could work in simple cases: Trigger some custom action after each user utterance, which will take care of the counting and set some status value in a slot (i.e. has the same argument been repeated enough times or not). Then, in your stories/rules, you’ll have to somehow condition on that slot to know when to predict some other response…