Website Name Change
I have changed the name of this website from Mining Business Data to BotFlo. I am offering a 60% off discount on both my Dialogflow ES and Dialogflow CX courses till April 20th 2021 for people who can help me spread the word about my new website.
Recently I had a coaching call with a client where I explained to him why RASA was a poor choice for substituting a Dialogflow bot he was trying to build. I had taken a quick look at RASA a few months back, so I had some idea what you could and couldn’t do in it.
After I went and took a closer look, I realized that I was actually overestimating RASA’s capabilities.
As it stands now, you will probably want to avoid migrating your Dialogflow agent to RASA because it will not work as well, especially if you used ideas from my site to create a bunch of conversational turns.
Why, you ask?
Dialogflow has the notion of an explicit context…
Explicit contexts are those you specify and associate with an existing intent (preferably via a UI)
…which guards intents
Unless the input context is active, an intent cannot fire. This leads to a lot of interesting properties.
…and narrows down the list of candidate intents
…and has a lifespan
With a lifespan attached to a context, you can have contexts expiring and appearing (becoming active) in very specific ways. This means you can move the conversation to the next intent quite easily
…and has an associated fallback
What the above set of conditions mean is that you have very fine grained control over the conversation flow, even allowing for all the ways the user can go off track.
In contrast, since RASA doesn’t provide you explicit contexts, you will be performing all the above on your own (i.e. you will be reinventing the Dialogflow wheel inside your RASA bot).
But I still want to do it!
OK, if you still want to do it, it is best you follow the general advice I provide in my material even as you build your Dialogflow agent
- do not use slot filling 
- do not use follow up intents 
- always set the context lifespan to 1 
- do not use wildcard entities without a lot of consideration, and definitely don’t use them in intents which don’t have an input context 
- avoid using composite entities  – although I don’t think I will suggest this to someone who doesn’t want to export their agent to RASA. I think composite entities are very powerful tools for Dialogflow agents
- understand candidate intents thoroughly
Why? Because you will end up with a linear set of intents rather than the hierarchy of follow-up intents or the self-loop of slot filling, and you will see that it will be a lot easier to map your Dialogflow agent to the flat hierarchy of RASA intents.
By the way, even with all this in place, you might still find that RASA doesn’t give you all the functionality you need, because I don’t think it is actually possible to fully export a Dialogflow conversation to the story format provided by RASA.
Are you a RASA NLU expert? Do you disagree with my views? I would love to hear your thoughts in the comments.
On the other hand, if you are a Dialogflow user who is trying to export your agent to RASA, I would love to hear from you too on how it went once you are done.
Are you interested in a course on migrating Dialogflow to RASA NLU?
Migrating your Dialogflow agent to RASA NLU is the subject of an entire course, in my opinion. So if at least 10 people comment that they are interested in such a course, I will be happy to create one.
 Required parameters are hard to map
 Followup intents are hard to map
 I have written about this extensively on this site, for example here
 They are not well supported in RASA
 No support for composite entities in RASA