Policies
These docs are for version 1.x of Rasa Open Source.
User Guide
- Installation
- Tutorial: Rasa Basics
- Tutorial: Building Assistants
- Command Line Interface
- Architecture
- Messaging and Voice Channels
- Testing Your Assistant
- Setting up CI/CD
- Validate Data
- Configuring the HTTP API
- Deploying Your Rasa Assistant
- Cloud Storage
NLU
- About
- Using NLU Only
- Training Data Format
- Language Support
- Choosing a Pipeline
- Components
- Entity Extraction
Core
- About
- Stories
- Domains
- Responses
- Actions
- Reminders and External Events
- Policies
- Slots
- Forms
- Retrieval Actions
- Interactive Learning
- Fallback Actions
- Knowledge Base Actions
Conversation Design
API Reference
- Action Server
- HTTP API
- Jupyter Notebooks
- Agent
- Custom NLU Components
- Rasa SDK
- Events
- Tracker
- Tracker Stores
- Event Brokers
- Lock Stores
- Training Data Importers
- Featurization of Conversations
- TensorFlow Configuration
- Migration Guide
- Rasa Open Source Change Log
Migrate from (beta)
Reference
Versions
viewing: 1.10.8
Policies
The rasa.core.policies.Policy class decides which action to take at every step in the conversation.
There are different policies to choose from, and you can include multiple policies in a single rasa.core.agent.Agent.
Note
Per default a maximum of 10 next actions can be predicted by the agent after every user message. To update this value you can set the environment variable MAX_NUMBER_OF_PREDICTIONS to the desired number of maximum predictions.
Your project’s config.yml file takes a policies key which you can use to customize the policies your assistant uses.
In the example below, the last two lines show how to use a custom policy class and pass arguments to it.
policies:
- name: "KerasPolicy"
featurizer:
- name: MaxHistoryTrackerFeaturizer
max_history: 5
state_featurizer:
- name: BinarySingleStateFeaturizer
- name: "MemoizationPolicy"
max_history: 5
- name: "FallbackPolicy"
nlu_threshold: 0.4
core_threshold: 0.3
fallback_action_name: "my_fallback_action"
- name: "path.to.your.policy.class"
arg1: "..."
Configuring Policies
One important hyperparameter for Rasa Core policies is the max_history.
This 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’s Featurizer in the policy configuration yaml file.
Note
Only the MaxHistoryTrackerFeaturizer uses a max history, whereas the FullDialogueTrackerFeaturizer always looks at the full conversation history.
As an example, let’s say you have an out_of_scope intent which describes off-topic user messages. If your bot sees this intent multiple times in a row, you might want to tell the user what you can help them with. So your story might look like this:
* out_of_scope
- utter_default
* out_of_scope
- utter_default
* out_of_scope
- utter_help_message
For Rasa Core to learn this pattern, the max_history has to be at least 4.
If you increase your max_history, your model will become bigger and training will take longer. If you have some information that should affect the dialogue very far into the future, you should store it as a slot. Slot information is always available for every featurizer.
Data Augmentation
When you train a model, by default Rasa Core will create longer stories by randomly gluing together the ones in your stories files. This is because if you have stories like:
# thanks
* thankyou
- utter_youarewelcome
# bye
* goodbye
- utter_goodbye
You actually want to teach your policy to ignore the dialogue history when it isn’t relevant and just respond with the same action no matter what happened before.
You can alter this behavior with the --augmentation flag. Which allows you to set the augmentation_factor. The augmentation_factor determines how many augmented stories are subsampled during training.
Action Selection
At every turn, each policy defined in your configuration will predict a next action with a certain confidence level. The bot’s next action is then decided by the policy that predicts with the highest confidence.
In the case that two policies predict with equal confidence, the priority of the policies is considered. Rasa policies have default priorities that are set to ensure the expected outcome in the case of a tie.
This priority hierarchy ensures that, for example, if there is an intent with a mapped action, but the NLU confidence is not above the nlu_threshold, the bot will still fall back.
Keras Policy
The KerasPolicy uses a neural network implemented in Keras to select the next action. The default architecture is based on an LSTM, but you can override the KerasPolicy.model_architecture method to implement your own architecture.
def model_architecture(self, input_shape: Tuple[int, int], output_shape: Tuple[int, Optional[int]]) -> tf.keras.models.Sequential:
"""Build a keras model and return a compiled model. """
# Build Model
model = Sequential()
model.add(Masking(mask_value=-1, input_shape=input_shape))
model.add(LSTM(self.rnn_size, dropout=0.2))
model.add(Dense(units=output_shape[-1]))
model.add(Activation("softmax"))
model.compile(...)
return model
You can implement the model of your choice by overriding these methods, or initialize KerasPolicy with pre-defined keras model.
Embedding Policy
Warning
EmbeddingPolicywas renamed toTEDPolicy. Please use TED Policy instead ofEmbeddingPolicyin your policy configuration. The functionality of the policy stayed the same.
TED Policy
The Transformer Embedding Dialogue (TED) Policy has a pre-defined architecture...
Mapping Policy
The MappingPolicy can be used to directly map intents to actions. The mappings are assigned by giving an intent the property triggers.
intents:
- ask_is_bot:
triggers: action_is_bot
If you do not want your intent-action mapping to affect the dialogue history, the mapped action must return a UserUtteranceReverted() event...
Memoization Policy
The MemoizationPolicy simply memorizes the conversations in your training data.
Augmented Memoization Policy
The AugmentedMemoizationPolicy remembers examples from training stories for up to max_history turns...
Fallback Policy
The FallbackPolicy invokes a fallback action if certain conditions are met...
Two-Stage Fallback Policy
The TwoStageFallbackPolicy handles low NLU confidence in multiple stages by trying to disambiguate the user input...
Form Policy
The FormPolicy is an extension of the MemoizationPolicy which handles the filling of forms. Once a FormAction is called, the FormPolicy will continually predict the FormAction until all required slots in the form are filled.