Action_default_fallback already defined


(Anders) #1

Fixed/hack/work-around: I don’t think this is the right approach but I got the fallback to work. I modified rasa_core.train to suport a new argument, in short:

   fallback = FallbackPolicy(core_threshold=fallback_threshold,
                                    nlu_threshold=fallback_threshold)

        policies.append(fallback)
    

    agent = Agent(domain_file, policies)

domain.yml

templates:
  utter_default:  
    - "You are speaking nonsense my friend"

I start the training with:

python -m rasa_core.train -d domain.yml -s “$STORY” -o models/current/dialogue --epochs 120 --fallback 0.3

Edit: So I came across ´ActionDefaultFallback´ in the changelog, and found ´utter_default´ in the documentation. But when I add ´utter_default´ to my domain.yml, there still isn’t any fallback in the bot. What else do I need to set up for the default fallback to work?

I want to define a default fallback action action_default_fallback but I get the error when I run rasa_core.train

ValueError: Action names are not unique! Found two actions with name ‘action_default_fallback’. Either rename or remove one of them.


(Akela Drissner) #2

Hmm what’s the most recent edit on this? :smiley: is it working now or not? So yeah the fallback policy isn’t currently part of the train script, we’re aware of that and it should be. At the moment we just have a separate python file for the specific bot and define all the policies we want there. However, since you’ve already modified the train script – do you mind submitting a PR to Core for this?


(Anders) #3

I will clean it up and submit for a PR.


(Akela Drissner) #4

Actually looks like it was already implemented with this PR https://github.com/RasaHQ/rasa_core/pull/828

Sorry about that, but thanks for bringing it to our attention!


(Anders) #5

Yes I noticed today as well when I did a pull. Good timing that I didn’t finish the code myself :wink:


(Anders) #6

Is the default fallback disabled by default? rasa_core.constants.py the vars DEFAULT_NLU_FALLBACK_THRESHOLD and DEFAULT_NLU_FALLBACK_THRESHOLD are set to 0.0. If I understood the theory behind intent classification then the probability can never be equal zero. I am tempted to set a float value myself, unless 0.0 is actually a valid value.


(Akela Drissner) #7

Yes it’s disabled by default, but you can pass the nlu/core thresholds with the --nlu_threshold and --core_threshold flags to the train script