Rasa Open Source — Chatbot customization

Photo by Rock'n Roll Monkey on Unsplash

Introduction

Rasa Open Source is a machine learning framework for automated text and voice-based conversations. We already discussed it in two articles which are available at Betacom — Medium. In this article we are going to explore how to customize a Chatbot built with Rasa.

In particular, we will discuss Pipelines, Rules, Policies and how to customize them to better control and steer the conversation based on user input.

Pipeline customization

In Rasa Open Source, incoming messages from the user are processed by a sequence of components which are executed one after another in a so-called processing pipeline. Choosing an NLU pipeline allows you to customize your model and finetune it on your dataset.

Each component processes an input and/or creates an output. The order of the components is determined by the order they are listed in the config.yml file. The output of a component can be used by any other component that comes after it in the pipeline. Some of them only produce information used by other components in the pipeline, while other ones produce output attributes that are returned after the processing has finished.

Rasa Open Source will provide you with a suggested NLU config on initialization of the project, but as your project grows, you will probably need to adjust the configuration to suit the training data you are using. To get started, you can let the Suggested Config feature choose a default pipeline for you: just provide your bot’s language in the config.yml file and leave the pipeline key out or empty.

A pipeline usually consists of three main parts:

1. Tokenization, i.e. the process which split the input text into tokens (you can find more at Pipeline Components — Tokenization),
2. Featurization, i.e. the embedding process of the tokens (check Pipeline Components — Featurization for more information),
3. Intent Classification and Response Selectors — the first one is used to assign one of the intents defined in the domain file to incoming user messages, whereas the second one predicts a bot response from the set of candidate responses.

Each component can implement several methods from the Component base class; in a pipeline these different methods will be called in a specific order. Assume for example we added the following pipeline to our config.yml:

pipeline:
- name: “Component A”
- name: “Component B”
- name: “Last Component”

Source: https://rasa.com/docs/rasa/tuning-your-model/

Before the first component is created using the create function, a Python dictionary called context is created. It is used to pass information between the components and is initially filled with all configuration values. The arrows in the image above show the call order and visualize the path of the passed context. After all components are trained and persisted, the final context dictionary is used to persist the model’s metadata.

Policies

Your assistant uses policies to decide which action to take at each step in a conversation. They can be machine-learning or rule-based policies. You can customize them by specifying the policies key in your config.yml.

At every turn, each policy defined in your configuration will predict a next action with a certain confidence level. The policy that predicts with the highest confidence decides the assistant’s next action. In the case that two policies predict with equal confidence, the priority of the policies is considered. Indeed, Rasa Open Source policies have default priorities that are set to ensure the expected outcome in the case of a tie. In general, it is not recommended to have more than one policy per priority level in your configuration. If you have 2 policies with the same priority and they predict with the same confidence, the resulting action will be chosen randomly.

One important hyperparameter for Rasa Open Source policies is the max_history. It controls how much dialogue history the model looks at to decide which action to take next. You can set the max_history by passing it to your policy in the policy configuration in your config.yml. The default value is None, which means that the complete dialogue history since the last session restart is taken into account. Please note that the RulePolicy doesn’t have sich a parameter as it always considers the full length of provided rules.

More details about policies can be found at the Policies page.

Rules

Rules are a type of training data used to train your assistant’s dialogue management model. They describe short pieces of conversations that should always follow the same path.

Before going thorough it, please note that you shouldn’t overuse rules. Indeed they are great to handle small specific conversation patterns, but unlike stories, rules don’t have the power to generalize to unseen conversation paths. Thus combine rules and stories to make your assistant robust and able to handle real user behavior.

Before you start writing rules, make sure that the Rule Policy is added to your model configuration file:

policies:
  - … # Other policies
  - name: RulePolicy

To indicate that a rule can apply at any point in a conversation, start with the intent which starts the conversation and then add the actions which your assistant should perform in response to that. For example, here’s a rule that applies at the start of conversation as well as when the user decides to a send a message with an intent “greet” in the middle of an ongoing conversation:

rules:
- rule: Say hello when the user sends a message with intent `greet`
  steps:
  - intent: greet
  - action: utter_greet

Conditions can also be added to a rule in order to set requirements which have to be fulfilled for the rule to be applicable. To do so, add any information about the prior conversation under the “condition” key:

rules:
- rule: Only say `hello` if the user provided a name
  condition:
  - slot_was_set:
    - user_provided_name: true
  steps:
  - intent: greet
  - action: utter_greet

The last thing you should know about rules is that by default they will wait for the next user message when finished with the last step. If you want to hand over the next action prediction to another story or rule, you will need to add wait_for_user_input: false to the rule. This indicates that the assistant should execute another action before waiting for more user input.

Conclusion

You should now be aware of the customization process for a chatbot built with Rasa Open Source. Please always refer to the official documentation for more information about it.

We hope you enjoy the article. See you soon!