Rasa: substitute auto slot filling with customizable action

[Ghostvv]

related to https://github.com/RasaHQ/rasa/issues/6090

Instead of autofill slots in domain.py, create a default action that is unfeaturized and always executed after user utterance unless there is an active_form and by default fill the slots with the same entities, if action_fill_slots is present in the domain, it'll run it which will allow users to create their own slot-filling logic (basically a cut version of FormAction's extract->validate). Effectively, this customization will serve as continuation of nlu pipeline but with access to the tracker

[Ghostvv]

@wochinge what do you think?

[nbeuchat]

I very much like this idea!

I see a few use cases from our side:

• For our apartment search bot, it can help us set (or edit) user preferences outside of our standard preferences form. The reason we cannot use automatic slot filling is that users may use the same entities (ex: price, unit type, etc.) to select an apartment (ex: _I want to schedule a viewing for the two-bedroom apartment you showed me_) or to set the preferences (ex: _Can you show me 2 bedroom apartments?_). In the first case, we do not want to auto-fill the slots while in the second, we want to. I know you can also predict an action to change preferences in the second case and use the extracted entities but the auto slot filling would not rely on this prediction.
• The other use-case as @Ghostvv mentioned would be to add context to our bot like the user city to correctly disambiguate neighborhoods that the user may mention (in this case, we would also need to do the same disambiguation in the preferences form but that's ok as it's only two places instead of everywhere where the bot needs this info)

[nbeuchat]

@Ghostvv do you know if this feature will make it soon to Rasa? I have a great use case for it at the moment (similar to point 1 above), just wondering if I should wait for it or try an alternative. Thanks!

[wochinge]

@Ghostvv By unfeaturized you mean that we wouldn't even add the action execution to the tracker? We could also subclass from LoopAction and effectively making it a default form. The problem I see with that is that it somewhat clutters the tracker events.

do you know if this feature will make it soon to Rasa?

@nbeuchat We are currently working towards a Rasa Open Source 2.0 which means we are currently not cutting releases in the usual rhythm and that this feature would be released as part of 2.0 (which is still in the alpha stage)

[nbeuchat]

Thanks for the update @wochinge! Very much looking forward to 2.0 :rocket:

[Ghostvv]

@wochinge I'd not use the loop action in terms of active loops, etc. But rather a "simple" action with specific name that doesn't have feature string and is not a dialogue turn (it is ignored in generate all prior trackers)

[wochinge]

I see. Neat idea. Somewhat brings aspect-oriented programming to Rasa Open Source 👍
What I also like about it that everything is logged transparently in the tracker instead of having the SlotSet events coming out of nowhere.

How would that affect tracker.last_action_name? As far as I know a lot of code depends upon tracker.last_action_name == ACTION_LISTEN to check whether we just had a user utterance. We'd need to make sure that the slot filling action somewhat stays under the radar then (in that case it might be better to have a separate Event).

Might need to ignore these special actions in the Rasa X UI though to keep the displayed conversations clean.

[Ghostvv]

if it is not ActionExecuted then it'll automatically stay under the radar

[wochinge]

So you'd introduce a new event a la UnfeaturizedActionExecuted?

[Ghostvv]

I'd call it SlotFillingAction directly (or smth else related to slot filling)

[Ghostvv]

depends, do we want it to be general? then yes SilentActionExecuted or smth

[Ghostvv]

it'll be a breaking change? then it should go in 2.0rc1

[wochinge]

The change shouldn't be breaking, so we can do that in 2.1 . Also, we need to focus upon the open tasks for the RC and shouldn't add even more things which aren't strongly related to new 2.0 features which we planned for.

[Ghostvv]

I thought it would be braking, that's why I added it, if it's not then fine