Enable ResponseSelector to execute CustomActions

Rasa Open Source
1

Hi all,

some time ago, Rasa introduced the RetrievalActions to us which are quite helpful in terms of organizing / separating content that the bot should be capable of uttering / processing.

As far as I have seen, the feedback is mostly very positive and I’d like to suggest an (imho) important enhancement:

If I am not wrong - and please correct me if so - the ResponseSelector currently only chooses the utterance-to-go out of responses.md which works pretty good, but it isn’t capable of executing an Action, e.g. CustomActions.

I for myself could really use this feature since in terms of completeness I would expect that I am able to use the same feature-set while designing the responses than I would have by designing them as “normal” utterances.

@erohmensing @dakshvar22 Maybe this would be something we could contribute to your implementation?

How about the rest - any feedback on this idea?

Regards
Julian

1 Like
2

@JulianGerhard Thanks for proposing this. Have a couple of questions -

  1. Do you want to call a custom action internally from a retrieval action, or do you want a custom action to be called as a follow up action?
  2. If the custom action is a follow up action, can’t it be included in your stories as a follow-up action after the retrieval action?
  3. If you want to only call a custom action as response to a retrieval intent, then how would the response selector be trained without any response text for that retrieval intent?

Let me know your thoughts.

1 Like
3

Hi @dakshvar22,

good questions - thanks for that. I try to explain my thoughts by giving a concrete example.

My config-setup would be:

- name: "ResponseSelector"
  retrieval_intent: allowed_faq

Imagine this form, that is one of the main tasks of my bot:

## service_ticket_form
* open_service_ticket
    - service_ticket_form
    - form{"name": "service_ticket_form"}
* allowed_faq
    - respond_allowed_faq
    - form{"name": "service_ticket_form"}
    - form{"name": null}
    - action_restart

Further this is a snippet from my responses.md:

## ask_topic
* allowed_faq/ask_topic
    - The possible topics are industry, chemistry and flowers

## ask_responsible_department
* allowed_faq/ask_responsible_department
    - The responsible department varies depending on the topic

Now imagine there are up to 20 different responses that I want the bot to be able to give to certain questions from the user during processing the form. I think that the ResponseSelector is perfectly suited for this case if I want to avoid writing tons of storylines.

Now what if one ore more responses results in not only one response-utterance rather than a specific follow up action that should be injected in the story like this:

## ask_responsible_department
* allowed_faq/ask_responsible_department
    - The responsible department varies depending on the topic
    - action_retrieve_responsible_department_based_on_slot

One could argue that via the traditional way, we would embedd the variable value like this:

- The responsible department varies depending on the topic: {topic}

but as you already stated out, the utterance is part of the training data hence embedding variables might cause issues and aswell point three of the following could be the case.

Three things are interesting here:

  1. This implementation would give the possibility (unlike your suggestion) to execute response-specific follow up actions without the necessity to extend the stories (which keeps them clean imho)
  2. We could reuse your logic to use the “action_” affix to separate training material from story material inside the responses.
  3. Sometimes variables depend on computations / calculations that happen outside of the form such that we couldnt buffer/cache their values unless there is the necessity to fetch them. This necessity could be bound on the response-intent.

What do you think? Is this nonsense? :smiley:

Kind regards
Julian

4

This implementation would give the possibility (unlike your suggestion) to execute response-specific follow up actions without the necessity to extend the stories (which keeps them clean imho)

I believe you have access to the chosen response in the tracker, can you use that to make the follow up response-specific?

## ask_responsible_department
* allowed_faq/ask_responsible_department
    - The responsible department varies depending on the topic

In my opinion, this use case seems like you’re trying to abstract away the stories to handle everything via custom actions, which makes you use the context via the custom actions, rather than via the model itself, making it unlearnable. Wouldn’t this decrease the accuracy of a machine learning model trying to perform on unseen stories? If a response is context-specific, I don’t think it should be a response selector intent.

One could argue that via the traditional way, we would embedd the variable value like this: - The responsible department varies depending on the topic: {topic} but as you already stated out, the utterance is part of the training data hence embedding variables might cause issues and aswell point three of the following could be the case.

I’m not sure how it affects the model, but I could see this possibly being supportable – we already have the regex logic for how to fill those variables, we could use the same logic to ignore the variables

Sometimes variables depend on computations / calculations that happen outside of the form such that we couldnt buffer/cache their values unless there is the necessity to fetch them. This necessity could be bound on the response-intent.

This is the most compelling argument for me personally, it would be nice not to have to write stories to answer a simple code/api call chitchat or q&a like “what time is it?” i would be wary about it getting to complicated though, for my reasons about abstracting away context stated above.