Introduction
Rasa is an open-source chatbot framework to create and automate conversational applications. It provides several features to help you efficiently develop your bot. You can generate your training data, train your model, run tests, and connect your bot to APIs and different messaging channels.
How does it work?
The Rasa framework contains two libraries, Rasa Core and Rasa NLU.
Rasa NLU performs the natural language understanding of the framework. It can be used to interpret and classify intents (user statements of intent). It can also extract “named entities” based on machine learning techniques to make the bot able to understand the user inputs.
Rasa Core manages the conversation state using the following parameters to execute the action needed and send a message to the user:
- Tracker is used to keep track of the conversation history and save it in memory.
- Policy is the decision-maker of Rasa, it decides on what action the bot should take at every step in the conversation.
- Featurizer with the help of tracker, it generates the vector representation of the current conversation state so the action can pass later a tracker instance after every interaction with the user.
Even though Rasa can participate in a dialog, it just doesn’t use dialog trees. The chart below shows an example of a real chatbot project in progress. This bot focuses on helping people tackle their depression thoughts and boost their mental health.
Rasa depends on one of the most interesting concepts in computer science called a FSM (Finite State Machine) which you can use to define how your software works. Here is are the basics of how a FSM works:
- It is a computational model that consists of one or more states.
- There can be only in a single active state at any given time.
- An input to the machine causes a transition from the current state to the next state.
- Each state defines the rules that determine which state to switch to based on the inputs to the machine.
The diagram above shows an example of an FSM. Here, shapes represent the machine (bot) states, this machine starts with an initiator or start state called OPEN and ends with a terminator or exit state called END.
The Get to know some depression statistics is an example of inputs a user can enter to change the current state. The user input defines the state to switch to and the machine switches to the next state before processing the next user input. However, it is also possible to create a state transition back to the same state. In this case the user input will keep the machine running in the same state.
Let’s take an example of a light bulb. As seen above, this object has two states, it’s either turned on or turned off at any given time. If we turn on the bulb, this can cause a transition from turned off to turned on and vice versa. ON defines the state to switch to which is OFF, and OFF defines the state to switch to which is ON. In other words, if the current state is ON, clicking on ON changes nothing, but pushing OFF changes the state to OFF. If we are in state OFF, pressing OFF keeps the machine in the same state, but pushing ON makes a transition to state ON.
Conversation flow
In Rasa, stories represent and manage the conversation flow between the user and the bot. Here, the user inputs are defined as intents which are just the identifiers you defined in the training data. The bot responses are defined as actions. In other words, stories define the dialog tree. The dialog tree is actually a graph – connections between bot states. A FSM and a dialog tree are just a special kind of graph. Each state is something the bot will do or say. The edges or transitions between states are the actions or statements the user makes. So, the stories create the design of the conversation that determines the steps of the entire interaction.
NLU and Intent classification
NLU can define the training data and the example utterances to categorize what the user wants to achieve during an interaction with a bot. Another of using NLU module is to identify and extract the structured information from user inputs. The overall meaning of the user input is called its intent. The entities are small pieces of information, usually a word or two, that the bot extracts from the user statement.
Rasa gives you the freedom to define the NLU training data by classifying the user utterances into categories that represent intents. Those components are the skeleton of NLU to describe what users might say in each category, you can give them any name you want but it is preferable for each intent to have a name that matches the goal users like to accomplish with that intent.
Entity recognition
The term ENTITIES belongs to a big area of research in NLP named NER which stands for Named Entity Recognition. Researchers and professors use the academic term “entities” to refer to a particular object in the world (person, animal, place, thing, and even concept).
In Rasa, entities are structured pieces of information that can be extracted from user messages, it can hold important detail about the user like numbers, dates, names so that the bot could use them later in the conversation. Let’s take an example for a flight booking, it would be very useful for your bot to know which detail in user input refers to a destination.
Also, there are other ways entities can be extracted in Rasa:
- Synonyms can be used in case users may refer to the information the bot wants to extract in multiple ways, so the bot can map the extracted entities to a single value.
-
Lookup tables used to extract words users may say that refer to the entities you set in your training examples.
-
Regular expressions help you to assign a pattern to an entity name to improve the extraction.
Entities can be extracted with regular expressions or other NLP algorithms like neural networks and word vectors. Regular expressions are much faster but more brittle than more sophisticated NLP algorithms that use neural networks to extract entities and recognize intent.
Note that before you decide whether you should use entities or not, it’s preferable to think about what information the bot needs for the user goals.
Rasa policies
Policies in Rasa are the decision-makers in every step of a conversation, each policy predicts the action with a particular confidence level. A policy with a high level of confidence is the one that decides on the action needed for the next step of a conversation, and the policy priority will be considered in case of the same confidence levels.
There are different machine learning policies and each policy has its own way to make a decision:
- TED policy is a transform embedding architecture that performs next action prediction and entity recognition tasks based on transformer encoders.
-
UnexpecTED intent policy is an auxiliary policy that enables the assistant to review the conversation so that can handle properly the unexpected user intents.
-
Memoization policy compares the current conversation to the available stories in the training data. If there is a matching, the next action will be predicted with a confidence level of 1.
-
Augmented memoization policy learns from stories in the training as Memoization policy does. The only difference is the forgetting mechanism that helps Augmented memoization find a match by reducing the conversation history.
On the other hand, rule-based policies are fixed behavior policies that tackle conversations and make predictions based on the scenarios you trained them. Also, they can be used in tandem with machine learning policies.
Useful features
Rasa has some other useful features that can help to manage the conversation state and improve the bot performance. For example, Tracker Store keeps track of your conversation history as you interact with your bot, the conversation will be stored in the memory or in the SQL database.
Another feature that can be important for evaluating your bot is called Markers. This feature is used to express the important events in dialogs and mark them when they occurred. It helps to evaluate the bot performance based on how those specific events play out in a conversation. In other words, markers are kind of conditions that allow you to mark the points of interest in your dialog to evaluate your bot. As some code examples highlighted in this blog, you can create an independent story with Markers and you can set up a Tracker Store along with to keep track of the conversation and export the Markers.
Common problems
However, some features in Rasa can cause some redundancy and confusion while improving the bot performance. For example, the entity extraction feature is useful for filling forms or getting information from the user, but the feature is not designed to make if and else decisions to create forks in the dialog tree.
Also, the lookup table doesn’t work properly when the user puts in a truly “unseen” item, an item that you didn’t put into the lookup table. On the other hand, intents in Rasa are callable at all times and the checkpoints that are used to reduce the repetitivity can make the conversation flow hard to understand and make the bot miss everything. In addition, the unfriendly documentation can be very difficult for newbies to go along with and even hard sometimes for developers to understand.
Conclusion
To conclude, this blog post introduced Rasa which provides a platform to create and maintain conversational chatbots. We discussed how Rasa operates in the background, and then we demonstrated how this framework designs the dialog without any need for dialog trees. The blog highlighted some strengths and weaknesses Rasa has in terms of intent classification and entity extraction with a particular focus on some features that might have some future customization to improve the framework performance.
Hopefully, this blog post meets your expectation. If you have any questions, feel free to connect and hit me up at any time on LinkedIn.
See you in the next blog and keep moving forward!
References
Rasa open source documentation
Finite State Machines – Massachusetts Institute of Technology
Named Entity Recognition – Natural Language Processing of Semitic Languages
Markers in Rasa Open Source