Initial slot values break rule policy by being integrated into all rules by default #11395
Labels
area:rasa-oss 🎡
Anything related to the open source Rasa framework
type:bug 🐛
Inconsistencies or issues which will cause an issue or problem for users or implementors.
Rasa Open Source version
3.2.4
Rasa SDK version
3.2.0
Python version
3.7
What operating system are you using?
Linux, OSX
What happened?
Was trying to build a concept bot with some basic task switching logic and noticed I couldn't get certain rules to work. After some bug hunting I found that initial slot values are implicitly integrated into all rules. Thus, if you change the initial value during the conversation, none of your rules will apply anymore: 🥳🎉
Minimal example to reproduce:
nlu
rules
config: default
domain
When you have a look at the rules that are produced with and without initial value for the slot
has_said_hi
you will see the following:rules in the trained rule_policy.json (from the model tar.gz) without initial value:
rules in the trained rule_policy.json (from the model tar.gz) with initial value:
As you can see the initial value for
has_said_hi
was incorporated into all rules as[1.0, 0.0]
which is the boolean slot representation forfalse
.What you will experience when you train this bot is the following: the greet rule won't work. What happens is that the slot has_said_hi get's filled, and afterwards there are no applicable rules and the bot will reset the previous user message (unsetting the slot again). So you can get a good bye but never get the bot to greet you back.
I think it's quite a serious bug, as it basically renders rules almost useless when using slots with initial values and it is super surprising that initial values are causing this. Instead, initial values should not be incorporated into rules.
Command / Request
Relevant log output
The text was updated successfully, but these errors were encountered: