Definitive Guide on Migrating from Dialogflow to Rasa

Migrating from Dialogflow to Rasa is definitely not a piece of cake, except for training the Rasa-NLU. There are a few things that you should know about when you prepare to make this move.

Before I drop the reality bomb, give yourself a pat on the back for choosing an Open source conversational AI framework like Rasa.

As we all know, Dialogflow is a cloud-hosted tool for building chatbots - this means that your data is no longer just yours!

Well, cats don't rule this world.

Safe to say, if you're planning to give a dedicated and safe user experience, you'll have to use valuable personal information of the user and doing this on the cloud will only put that information to risk. So kudos to you for making that wise decision! 👏

Now let's get going!

Note: This article is not going to be an introduction to Rasa and its components, but more about how similar or different Rasa is from Dialogflow.

What's easy?

The first step when migrating from Dialogflow is to export all your intents and entities as a ZIP folder. Then unzip it on your local machine. Simply run the train command for Rasa NLU and voila! You have the models folder ready for intent classification. There is not much to do when you're using only the NLU. Especially, if you have an agent that is not context-based, then migrating to Rasa is just one command away.

Dialogflow to Rasa

Let's face it. Bots without context don't bring out the best user experience. Context-based bots are the real deal - with exchanges just (almost) like humans!

So when you're moving to stage 2 i.e, migrating a context based-bot from Rasa to Dialogflow, you need to know a few things before you get started.

1. Bot responses are NOT exported

When you export your agent from Dialogflow, your default responses are not exported. This means that you need to code to make your bot respond. The NLU parses the user text, understands the intent and extracts entities. So what you do with the classified intents is up to you! You can simply define a response.py file in which you give a set of predefined responses and write different functions for responding to each intent type.

2. Writing Stories

The follow-up intents in Dialogflow work based on continuous user-bot exchanges. All this happens on a single page, where you build your intents. When it comes to Rasa, this happens with the help of the Rasa Core, which requires you to design a stories.md and a domain.yml file.

Good thing is that you only have to design the templates of possible conversations and your chatbot makes decisions based on the different story paths provided by you. Always remember, if you want good conversations, build as many stories as possible as the human brain can be very unpredictable and random. The aim is to put yourself in the user's shoes.

3. Multiple intents and consecutive bot responses

Unlike Dialogflow, in Rasa, you can define multiple bot responses consecutively. For example, you might want to acknowledge the user's message and then suggest the next step. This only makes the conversation feel more polite, real and human-like.

Also, you are allowed to combine intents using any symbol based on the intent classifier you use. Humans are used to saying a lot of things at the same time. To use this, you need to add one more component to your config pipeline, the 'intent_split_symbol' and mention the symbol you're using to split the intents.

4. The Three actions

There are 3 types of actions that can be executed by Rasa Core are,

• Default actions like listen and fallback
• Utter actions used as normal bot responses
• Custom actions for going beyond simple utterances and performing functions like DB operations or calling an API like google maps

Utterances are what the bot says while actions are what the bot does.

So these are similar to default responses and Fulfilment responses of Dialogflow.

5. The Actions Server

Just as we configure a custom webhook on Dialogflow, to tell Rasa Core where to look for our actions server, we define the endpoint in the endpoints.yml file. The custom actions have to be written as a Python class using the Rasa SDK (till Rasa Core v0.15.0). The actions.py file is then used to run the actions server on the endpoint mentioned in the endpoints.yml file. By default, the Core pings the actions server on the /webhook endpoint. You need to specify the right endpoint for the Core to look for the actions class. Also, if you want to change the port on which the actions server runs, use --p option with the command to run the actions server.

6. Slots vs Entities

There is not a clear answer about the differences between slots and entities. But from my understanding, all entities need to be used as slots and to do this, while defining entities in the domain file, do not forget to set 'store_entities_as_slots' to True. If you don't do this, the core does not extract entities into these slots and consequently, it gets difficult while using a tracker to extract entities on the actions server. So beware! Always use entities as slots.

7. Visualize

Rasa Core has a very helpful feature which helps visualize how the decision tree works in the bot brain. All the stories can be visualized as flow charts which helps you understand the decision tree. Each time you add new stories with different paths and use the commands to visualize, a new stories graph is generated.

8. Bonus: Interactive Learning 🎉

To help your bot learn under your supervision, use the interactive learning mode. You can chat with your bot and see how it predicts the next action. If it's wrong, you can choose what the Bot must do and add it to your list of story paths in the stories.md file.

Now that you're exposed to the real world of building context based bots on Rasa, go ahead and try it out.

Up next: Improving chatbots learning and dialogue management.