Rasa Vs Dialogflow — Detailed Comparison (For Developers)

Are you a developer who wants to know how and what to compare when choosing a Virtual Assistant platform then you have come to the right place.

In this blog, we will go through the platform features from a developer perspective. Just in case if you have missed our Part 1 of Dialogflow vs Rasa or if you are a business owner and confused about which platform works best for your use case then please check that out. As we also discussed core components to be considered while taking the platform into comparison and deep-dived into features that business owners take into account before selecting a platform.

3. Developers

Keyword-based bot building (No NLP):

This was the oldest way to build virtual assistants when AI was not around. Though this approach is no longer preferred.

Yes, there are ways to build a completely just flow based on a button-based bot in Dialogflow that works based on keywords.

In Rasa, we can build using a keyword intent classifier. This classifier is intended only for small projects or to get started.

Types of bots: FAQ assistant | Contextual assistant | Personalized assistant

FAQ assistant is the most common type of assistant right now and can be easily built with most bot frameworks.

Building contextual assistants need true conversation AI elements. Even in a FAQ assistant, we can have context with a multi-step approach. The question is — will that provide a good conversational experience? No, rather it will just increase the developer’s time and effort in managing intents and evaluating its conversational flow. But to make this work, we need to manage the context in the conversation, to make sure we handle anything and everything. As per our experience with both the platforms Rasa has an upper hand in providing developers with the flexibility to manage the context in complex conversations compared to Dialogflow.

Dialogue management is even trickier if a developer has to change or update the conversational flow through the Dialogflow context. A tool with flow visualization would have been very helpful.

In Rasa, the dialogue is managed with stories and it is trickier to go through all stories again and update or change directly in the source file as it might break the previously working behavior (Because it is ML-based on implementation). But overall, Rasa is better at handling such scenarios as it has other features to evaluate redundancy checks. Rasa X has a feature where we can easily save correct conversations as tests, so we don’t have to write them out ourselves. Both data validation and tests should be run in a continuous integration pipeline that we trigger whenever we update the scope of the project.

A personalized assistant is something that gets to know you over time. Maybe this sort of assistant will be a reality in the next couple of years.

Ref: Conversational AI: Your Guide to Five Levels of AI Assistants in Enterprise

Customization:

We think no platform is perfect to solve all business requirements, hence some amount of customization features are required to qualify the platform for the project. There could be a hack or a workaround but the platforms must provide that kind of flexibility.

Rasa gives complete freedom to configure NLU, Core, Integration, Deployment, etc. Refer to Rasa docs for more.

Dialogflow, on the other hand, doesn’t allow any customizations on its code but you can only customize in fulfilments.

Context management:

As most of our conversations are contextual and that’s what makes virtual assistants conversational and AI-driven. Context management is the heart of the dialogue management module.

Both Rasa and Dialogflow use slots to manage contexts. A slot is nothing but a memory of the assistant. Rasa’s LSTM/Transformer-based core takes slots, current intent, and entity to predict the next action of the bot. In Dialogflow managing, context is a bit tricky but once you get a hold of it’s working you can develop good conversation assistants but when you have complex conversations with hundreds of intents and entities it becomes difficult to manage it.

Dialogue management:

We very well know that writing tons of if-else statement-based conversational flow is infeasible. Hence, this feature is critical while keeping truly ML-based virtual assistants in mind.

Rasa’s dialogue is designed and trained using Stories. It’s the first-ever ML-based dialogue management approach combined with a rule-based approach that involves using a custom action file for creating tighter control over the flow. Creating stories can be made natural by the interactive learning option provided by Rasa. That way building a chatbot is more natural compared to building traditional ways. Read more about dialogue management here: The Rasa Core Dialogue Engine

Dialogflow uses more of a rule-based approach and manages Dialogue via context itself.

SDKs and APIs:

Rasa SDK provides the tools you need to write custom logic in python.

Dialogflow has its own SDK in different languages.

4. Ease of development, deployment, and debugging

This is one of the crucial features when selecting the platform. As everyone wants to make their life easier. Especially developers 😛

Development

Platform architecture:

Knowing how to use a platform is one thing, but knowing how the platform works is another. To utilize the platform’s functionality it is important to understand the architecture of the platform itself.

Read the below resources to know more about the respective platform architecture.

Rasa: Rasa docs and Co-learning lounge Rasa tutorial

Dialogflow: Co-learning lounge Dialogflow tutorial

Ease of learning:

Most of those who are working professionals have the issue of things that needed to be done yesterday. Gaining more skills and having a shorter learning curve is what we prefer most of the time. It doesn’t matter how good the tool is in terms of functionality but it is more important for us developers to have good resources like platform documentation and self-serving platforms.

Rasa documentations are easy to understand and to go through even though the architecture can be complex in the backend. Its interactive getting started to guide will onboard new users with ease. If you are someone who loves to understand the platform in-depth you can start with the Rasa masterclass, Algorithm Whiteboard, and NLP for Developers videos which are a perfect way for you to deep dive.

It should be easy for newbies to learn Rasa with a plethora of available learning resources but not as easy when compared to Dialogflow considering the architecture of the Rasa.

Dialogflow was built having both coders and non-coders in mind, so the platform’s usability is quite easy when compared to the learning curve in Rasa.

Ease of usability or development:

Development time and effort completely depend upon the project requirement, resources, and expertise with the platform. But the expectation from the platforms is that they assist in the reduction in time of the end-to-end development without compromising on the quality and end product.

As Rasa is primarily an on-premise platform and the open-source meaning developer has full control of engineering. It requires a setup and understanding of the platform to get started. Although Rasa is very aggressive in adding new features into the Rasa stack but those which are not supported required additional engineering to set up.

Dialogflow provides an easy-to-use platform and easy integration process to several channels which reduce most of the development time when compared to Rasa.

Setup and Configuration:

How fast can one start using the platform for their development work is also important for some if not many. Dialogflow doesn’t have any installation procedure hence no infrastructure setup is required apart from the webhook section which generally takes about a minute or two. The main winning point is you don’t require to use a server to deploy Dialogflow or webhooks. If you are familiar with Firebase functions/Lamdba functions you are good to go with a serverless architecture.

Rasa does require installation as it’s a python library. Also, the necessary configuration is required for the development of the virtual assistant which generally takes up to 15–30 minutes or more depending on if or not you will face any dependency issues. But before you get into production deployment make sure you read the Rasa deployment guide.

In-built support:

Having in-build features like small talks, basic entity support and follow-up mechanisms support developers in reducing some redundant and basic activities. While Dialoglow has most of these in-built and some of the intents and flow can be reused by downloading the intents in JSON format.

In the case of Rasa, there are no in-built intents like small talk but such a set of intents once defined can be readily reused across multiple projects. Using Duckling and Spacy’s system entities can be easily configured in the Rasa NLU pipeline. Rasa has a configuration where Fallback Response can be triggered if the intent classification and action prediction confidence is below a specified threshold value. Rasa does not have any in-built default, welcome and fallback intents like Dialogflow has.

Training Format:

Virtual assistants are meant to mimic human behavior. Just as we humans learn more over time through conversations and discussions, the expectation from virtual assistants is the same. Platforms need to be advanced enough to assist developers to train the bot more intuitively and naturally. In this case, on both platforms, NLU is trained with natural user utterances tagged with entities as shown below.

Pain is when a developer has to develop conversational flow. As mentioned above Rasa’s approach is more natural than Dialogflow, because of the story-based approach. Rasa’s interactive learning makes a developer’s life easy when it comes to developing conversational flows.

Quotas and limits:

This is important when our flow is super complex and long. As Quotas and limitations can cause blockers for developers, hence conversation designers and voice assistant developers will have to collaboratively understand the limitations of the platform and developer accordingly.

Dialogflow does have limitations in a lot of ways when it comes to the number of intents, entities, now of characters allowed in an action name, and so on. Google must have decided on the limitation after benchmarking and keeping best practices in mind.

As Rasa does not have such limitations, if any class is considerably high in number, however, it might cause training/testing data imbalance problems. Hence, like Dialogflow if any class is reaching the limit then it’s time to revisit the data and make necessary changes to balance out classes.

Built-in bot template or marketplace:

To provide developers with a basic understanding of workflows, and build on top of existing flows, some platforms provide chatbot templates and marketplace like Chatfuel.

As such Rasa does not have dedicated ready-to-use bot templates but it does have sample bots to start with. Rasa Example(GitHub)

Dialogflow provides a set of templates to be exact they provide 45 templates that assist a lot of developers to understand how the flow needs to be designed as well as use them for getting started with the platform.

Migration from other platforms:

Rasa supports easy migration from platforms like Dialogflow, wit.ai, Luis, IBM Watson, and more.

Dialogflow provides migration to only two platforms and that is Amazon Alexa and Google Actions (though Google Assistant works as part of Dialogflow itself) but it doesn’t allow or accept direct integration from other platforms.

Model evaluation:

The model provided by Rasa is configurable by the developer as per the requirements. This feature is much needed when we experiment with multiple configurations.

You can read more about evaluating NLU and Core models of Rasa at testing your assistant. You can also compare different configuration options to fine-tune your assistant further.

Even though Dialogflow’s backend model is a black box we still have been provided with options to tweak the ML classification threshold and choose between the Hybrid model (Rule-based and ML-based) and ML only model.

Deployment

This is an important decision factor for a lot of clients as most of them do not want the data to move through an external entity that isn’t in their full control. This is where Rasa wins without a doubt as Rasa can be run locally. It can be deployed on-prem and on the cloud. Refer to Deploying Your Rasa Assistant for information on how to deploy. As it is deployed on-prem you own your data. Although developing a virtual assistant is unlike traditional software development. Rasa does follow software engineering best practices. Refer Setting up CI/CD and Integrated Version Control. Rasa also supports S3, GCS, and Azure Storage to save your models. Refer to Cloud Storage for information.

Dialogflow is a Google Cloud Platform product and has a UI-based bot framework. The entire project and of course models will be stored and deployed in the Google cloud. We only get the flexibility to implement the backend business logic on-premise or on other cloud platforms.

Debugging

Debugging is as important as development as it eats up a lot of time. While most of the platforms are excelling in providing development features it is necessary to verify if they provide a good amount of debugging features as well. Debugging virtual assistants are unlike traditional software debugging, as the scope of the project increases it gets trickier to debug failure because of the collective effect of data in an ML-based approach. Since you can see everything under the hood and all of the code you exactly know how your trained models are performing by knowing prediction scores. Also, the evaluation methods mentioned above can help in decision-making. For the custom logic written on both platforms, traditional software debugging is applicable.

Last year probably Rasa would have been a clear winner but late last year Dialogflow introduced a section named Validation which evaluates each intent and indicates that there is a specific intent/s that needs more training data for it to perform better.

While Rasa X provides curation and fine-tuning capability. Rasa also provides us with the option to train the NLU as well as the Dialogue of the conversation while Dialogflow only provides training options in the NLU component. So Dialogflow still isn’t a winner in this case. Also, if one has a lot of training data and the bot has issues understanding most of the inputs then doing these corrections in the training section of Dialogflow is quite a tedious task.

5. Service support

Developers require support when designing conversations and implementing them with best practices in mind. Dialogflow provides community support via its Google Group, Slack, and StackOverflow. While Rasa has its own community forum and StackOverflow.

We hope that your time was worth reading the Rasa Vs Dialogflow platform battle. We will keep this blog up-to-date with the latest addition of features.

If you are STILL not sure which platform would serve you right then let us know in the comment what is still holding you from choosing?

If you are now sure which platform you are going to select for your project then let us know which one and what made you select that?

If you are already using one of them, then let us know why?

If you like what we do and want to know more about our community 👥 then please consider sharing, following, and joining it. It is completely FREE.

Also, don’t forget to show your love ❤️ by clapping 👏 for this article and let us know your views 💬 in the comment.

Join here: https://blogs.colearninglounge.com/join-us