Original article was published on Artificial Intelligence on Medium
Rasa Vs Dialogflow -Faceoff (Part 1)
Have you ever wanted to build a virtual assistant but got lost in the abundance of available frameworks or platforms? Are you currently researching on how to build a scalable Virtual Assistant for your business or enterprise requirements? You have come to the right place.
Though in this blog we will mainly cover two players, Dialogflow and Rasa, and what you need to pay your attention to are the bases on which we do the comparison.
To cater to a business requirement there are several parameters involved which can make or break a product, like the choice of platform, budget, features required, time, third-party integrations, mainly scalability, and a few more.
“There has been a more than 160% increase in client interest around implementing chatbots and associated technologies in 2018 from previous years,” says Van Baker, VP Analyst at Gartner. “This increase has been driven by customer service, knowledge management, and user support.”
Companies generally follow three approaches while selecting Virtual Assistant Platforms:
- R&D — they try to build a small piece of the use cases on several platforms to see how they perform, based on this, they decide what works best for them. This approach is mainly used in the business to have time and resources.
- Service Provider — If a business hires a service provider, they tend to leave it on the service provider to choose. This at times is a risk that some businesses take, the reason I consider it a risk is because most service providers then use platforms they have closely worked with and find a workaround to fit the use case into the platform of their preference.
While I don’t think this approach is entirely wrong, sometimes business owners aren’t aware to what extent they can utilize virtual assistants and we still see some adoption issues.
- From Scratch — Most businesses prefer if IP and data flow are in their control, and as there aren’t a lot of on-prem platforms available. This approach involves a lot of time, resources, and skills with money due to obvious reasons.
This step from an architecture and a development standpoint with keeping the long term goals of the use case in mind is crucial. As it isn’t cost-effective to migrate the virtual assistant from one platform to the other. Even if you plan to use a hybrid approach to bring another platform just to support the use case, which will require a complex architecture design.
In the past year, we have received several queries in our Co-learning lounge community, which has led to us creating this blog. We have used two major players in the market Dialogflow and Rasa, the comparison is done in terms of the developer as well as the business owner’s perspective. If you are still in the initial stage of building a Virtual Assistant, or in a PoC stage wanting to scale it up to the full-fledged product — you have come to the right place. Let’s get started then!
Are you already using a platform or building a product using an existing platform? Let us know in the comments below what impacted your decision to choose that for your use case.
A virtual assistant platform must have the following 3 components to help you provide a better conversational experience to your users:
- Dialogue Management
- Action Fulfilments
Natural Language Understanding (NLU) as the name says — tries to comprehend the user’s input and extract relevant information that is needed to perform respective actions. The main role of NLU here is to help understand the intent of the conversation and extract information called “entity” from the conversation that is needed to perform business logic or user action.
Both the platforms that we are going to compare in this blog use machine learning-based NLU.
Dialogue management component is responsible for managing the content during a conversation and mainly responsible for managing the context of the conversation.
Action Fulfilments are nothing but third-party activities that are involved like Database call, API request, or a custom logic trigger.
Most of the platform providers excel in NLU service but still dig for data while developing to help the accuracy of language understanding. Every platform has been built a certain way and is unique in most areas even though they use the same core components.
Now lets deep dive into the comparison
After careful consideration, I have divided the comparison into four unique brackets which I personally think should be the decision point when it comes to evaluating different platforms. All four sections are prioritized in order of their importance. To make it more specific, I have split each section into two parts: Business Owner and Developer. Choose the one of your interest and let’s jump right in.
Virtual Assistant platforms come with several features, but most are different in nature. These features play a key role in our selection process.
1. Business Owners
These features are those which give an extra edge or flexibility to the software.
This is a basic requirement that every platform must provide as ease of use is a sign of good user experience. This reduces the learning curve for the user and helps in seamless onboarding and adoption.
Dialogflow is super easy to use as a platform that even a non-tech non-coder can easily understand and use. You will surely need guidance and design an approach before developing the bot for complex flows but those as well can be done with some ease when compared to Rasa.
Rasa is a developer-friendly open-source voice assistant framework, but it can take more time to get familiar with Rasa architecture. However, Rasa X is a toolset that layers on top of Rasa Open Source, making it easier to develop virtual assistants through interactive learning, review conversations, project configuration, identify the next steps in development, and improve your assistant.
Dialogue management performance:
This is a differentiating factor for the selection of a bot framework. As most of the conversational bots are state-based, meaning the conversational flow is configured and it will exactly follow that. This is a very crucial factor to consider because dialogue management quickly gets pretty complex as the scope of the bot increases.
Rasa uses stories as a format to train Transformers based dialogue management modules (named as core). Since it’s a deep learning-based module, it’s performance is clearly based on the data. It can be evaluated using Rasa CLI.
Dialogflow has a context-based conservation approach; it provides you with an easy option to configure contexts for an intent. You can either set the context through the UI in the input and output contexts section or via the fulfilments using functions provided in the API.
Intent/entity recognition performance:
This is quite a subjective measure. The simple rule is the more the merrier, and better the savior — meaning more and better data is the key. This defines the performance of the model. A lot of us do not understand the importance of data when it comes to the development of the Chatbot. Yes, platforms are built on trained NLP and NLU engines, but each chatbot that has been built has a different set of conversation designs and solves different industry problems. To get the best outcome, you need a decent amount of data and the quality of the data should be good too and only when providing good quality data will the platform be able to work at its best. Developing a Voice Assistant is like teaching and raising a baby.
With respect to Dialogflow, there have been instances where it has worked with limited amounts of data but as we know Google works with state-of-the-art technology to support its products and has a lot of data in store for training Dialogflow’s core model. At the end of the day, nothing is perfect as Dialogflow has its flaws in other aspects. On the platform, we also have a section named Validation that indicates that there is a specific intent/s that needs more training data for it to perform better. We also have been provided with system entities, that help reduce a lot of effort by creating a basic set of entities like date rate, numeric, unit length, and so on.
Rasa, on the other hand, has a custom pipeline selection based on the amount of training data. For less data, you can use the pre-trained model and with more data, you can train from scratch by choosing a Pipeline. Additionally, Rasa provides functionality to evaluate Intent/entity evaluation can be done using Rasa evaluation NLU model options
Hand-over to an agent for live chat:
Both do not have direct agent handover support with live chat agent platforms but can be configured to integrate with custom chat agent platforms. Well, when to handover to an agent is partly a design practice. Agent handover can be triggered when the default/fallback intent gets triggered consecutively. We can use a few platforms to help us develop these transitions in a seamless manner. For example kommunicate.io, BotCopy. In Dialogflow we can use events/socket events to do this handoff manually you can also refer to this repo for reference: Agent human handoff node.js
Importing training data of different format:
Most of the time data is stored at different places in different formats. It will be nice to have a custom training data importer in the bot framework.
Rasa recently added a Training Data Importers option to import data of different formats and from different sources.
In Dialogflow, we do not have the option to import or use training data in any format. Training Tool in Dialogflow accepts only a single line per phrase as training data. You will need to create a .txt file and in each line, just add one phrase and have that as the training data. You can choose to upload a single .txt file or multiple files zipped together but make sure it doesn’t exceed 3MB. 3MB for text data is good enough but using the training tool is a bit of tedious exercise.
Both the platforms provide a rich set of languages but Dialogflow is a clear winner w.r.t their list of supported languages. Dialogflow also has multi-language and local support being said that at times we need more than that based on our user base. To support this we generally add Google Translator to the overall architecture to support more regional languages.
Rasa is more like a DIY platform that allows you to add multilingual support with the help of some inbuilt components like spaCy. Additionally, you can also create your own custom component to support any language.
Analytics and reports:
Analytics is important to monitor bot performance so you can work to further improve the user experience you’re providing.
Dialogflow provides a basic set of analytical features that assist in knowing the number of sessions, intents, and the flow of questions. But if the flow grows complex this feature doesn’t assist. For example, if you want to know the number of users, returning users, a number of unanswered questions, and so on. You can either choose to build based on your needs or find an existing one like Chatbase and Dashbot
Rasa enterprise edition has support for analytics. It includes pre-defined KPIs in the analytics tab to see no of sessions, users and messages etc. Additionally, data can be exported using their data API which can be used to make custom reporting and integrate with existing tools.
Integrations (Voice and text):
This is important to deploy the bot to multiple channels.
Speech-to-text (STT) and text-to-speech (TTS) support:
Aren’t we used to Siri? How convenient is it with just a single command we can get so many things done nowadays. That is the exact reason enterprise solutions need STT and TTS features.
The enterprise version of Dialogflow has these features already built-in and waiting to be enabled. It also adds an extra touch of sentiment analysis at the end.
As of now Rasa currently does not have a ready to use the feature. But there are various open-source options available to fulfill this requirement. You can make use of Rasa’s Blog on how to build a voice assistant with open source Rasa and Mozilla tools
Also, look at demo voice bots built by the community at the Rasa showcase.
For any enterprise, this feature is THE most important because “Prevention is better than cure” and this is something that the company can’t overlook.
Dialogflow provides service account-based (private key) authentication — We all know that Google can’t compromise with product security. With the help of Firebase fulfilments, we can even add headers as well as auth tokens to interact with external APIs.
Rasa by default provides two authentication methods built-in token and JWT based auth. Read more HTTP API. An added advantage is, you have the flexibility to deploy it on your own private cloud or on-premise which will give you more control over data exposure and adds to overall data security. Rasa’s on-premise deployment capability allows us to track the data flow which provides an assured approach towards deploying models in large companies where traceability and compliance are the keys.
Pricing is something we all need to consider when using any of these platforms. Dialogflow has a Freemium plan which provides a good amount of feature that is required for the initial set of development work unless the requirement needs the use of TTS/STT, Sentiment analysis, and a few more such features.
Rasa, on the other hand, is open-source where you can use it as much as you can without any costs from the platform provider perspective but having said that when we talk about deploying the bot we need to incur the server cost.
You can read more about Dialogflow plans here — Freemium + Enterprise
To read more about Rasa here — Open-sourced + Enterprise
Dialogflow’s enterprise plan is transparent, you know what you will be paying once you move from free to an enterprise plan. Whereas you will need to contact Rasa’s sales for custom pricing.
Well, now that’s the end of Part 1 of our Dialogflow vs Rasa blog where we covered it from a business owner perspective. In the next part, we will deep dive into the developer’s perspective and also talk about support.
If you liked what you just read, please help others find it: hold the 👏 icon for as long as you think this article is worth. Thanks a lot! See you in Part 2. Make sure to invite your developer this time 😜