Rasa 4D
Select which actions should receive domain#
You can control if an action should receive a domain or not.
To do this you must first enable selective domain in you endpoint configuration for action_endpoint in endpoints.yml.
url: "http://localhost:5055/webhook" # URL to your action server
enable_selective_domain: true
After selective domain for custom actions is enabled, domain will be sent only to those custom actions which have specifically stated that they need it. Custom actions inheriting from rasa-sdk FormValidationAction parent class are an exception to this rule as they will always have the domain sent to them. To specify if an action needs the domain add {send_domain: true} to custom action in the list of actions in domain.yml:
- action_hello_world: {send_domain: True} # will receive domain
- action_calculate_mass_of_sun # will not receive domain
- validate_my_form # will receive domain
Test Conversation Format#
The test conversation format is a format that combines both NLU data and stories into a single file for evaluation. Read more about this format in Testing Your Assistant.
This format is only used for testing and cannot be used for training.
End-to-end training is an experimental feature. We introduce experimental features to get feedback from our community, so we encourage you to try it out! However, the functionality might be changed or removed in the future. If you have feedback (positive or negative) please share it with us on the Rasa Forum.
With end-to-end training, you do not have to deal with the specific intents of the messages that are extracted by the NLU pipeline or with separate utter_ responses in the domain file. Instead, you can include the text of the user messages and/or bot responses directly in your stories. See the training data format for detailed description of how to write end-to-end stories.
You can mix training data in the end-to-end format with labeled training data which has intents and actions specified: Stories can have some steps defined by intents/actions and other steps defined directly by user or bot utterances.
We call it end-to-end training because policies can consume and predict actual text. For end-to-end user inputs, intents classified by the NLU pipeline and extracted entities are ignored.
Only Rule Policy and TED Policy allow end-to-end training.
RulePolicy uses simple string matching during prediction. Namely, rules based on user text will only match if the user text strings inside your rules and input during prediction are identical.
TEDPolicy passes user text through an additional Neural Network to create hidden representations of the text. In order to obtain robust performance you need to provide enough training stories to capture a variety of user texts for any end-to-end dialogue turn.
Rasa policies are trained for next utterance selection. The only difference to creating utter_ response is how TEDPolicy featurizes bot utterances. In case of an utter_ action, TEDPolicy sees only the name of the action, while if you provide actual utterance using bot key, TEDPolicy will featurize it as textual input depending on the NLU configuration. This can help in case of similar utterances in slightly different situations. However, this can also make things harder to learn because the fact that different utterances have similar texts make it easier for TEDPolicy to confuse these utterances.
End-to-end training requires significantly more parameters in TEDPolicy. Therefore, training an end-to-end model might require significant computational resources depending on how many end-to-end turns you have in your stories.
Writing Stories / Rules for Unhappy Form Paths#
Your users will not always respond with the information you ask of them. Typically, users will ask questions, make chitchat, change their mind, or otherwise stray from the happy path.
While a form is active, if a user's input does not fill the requested slot, the execution of the form action will be rejected i.e. the form will automatically raise an ActionExecutionRejection. These are the specific scenarios in which a form will raise an ActionExecutionRejection:
To intentionally reject the form execution, you can also return an ActionExecutionRejected event as part of your custom validations or slot mappings.
To handle situations that might cause a form's execution to be rejected, you can write rules or stories that include the expected interruptions. For example, if you expect your users to chitchat with your bot, you could add a rule to handle this:
- rule: Example of an unhappy path
# Condition that form is active.
- active_loop: restaurant_form
# This unhappy path handles the case of an intent `chitchat`.
- action: utter_chitchat
# Return to form after handling the `chitchat` intent
- action: restaurant_form
- active_loop: restaurant_form
In some situations, users may change their mind in the middle of the form action and decide not to go forward with their initial request. In cases like this, the assistant should stop asking for the requested slots.
You can handle such situations gracefully using a default action action_deactivate_loop which will deactivate the form and reset the requested slot. An example story of such conversation could look as follows:
- story: User interrupts the form and doesn't want to continue
- intent: request_restaurant
- action: restaurant_form
- active_loop: restaurant_form
- action: utter_ask_continue
- action: action_deactivate_loop
It is strongly recommended that you build these rules or stories using interactive learning. If you write these rules / stories by hand you will likely miss important things.
Forms are fully customizable using Custom Actions.
Custom Output Payloads#
You can send any arbitrary output to the output channel using the custom key. The output channel receives the object stored under the custom key as a JSON payload.
Here's an example of how to send a date picker to the Slack Output Channel:
text: "Make a bet on when the world will end:"
initial_date: '2019-05-21'
Using Responses in Conversations#
Calling Responses as Actions#
If the name of the response starts with utter_, the response can directly be used as an action, without being listed in the actions section of your domain. You would add the response to the domain:
- text: "Hey! How are you?"
You can use that same response as an action in your stories:
- action: utter_greet
When the utter_greet action runs, it will send the message from the response back to the user.
If you want to change the text, or any other part of the response, you need to retrain the assistant before these changes will be picked up.
Persistence of Slots during Coexistence#
In Coexistence of NLU-based and CALM systems the action action_reset_routing resets all slots and hides events from featurization for the NLU-based system policies to prevent them from seeing events that originated while CALM was active. However, you might want to share some slots that both CALM and the NLU-based system should be able to use. One use case for these slots are basic user profile slots. Both the NLU-based system and CALM should likely be able to know whether a user is logged in or not, what their user name is, or what channel they are using. If you are storing this kind of data in slots you can annotate those slot definitions with the option shared_for_coexistence: True.
shared_for_coexistence: True
shared_for_coexistence: True
In the coexistence mode, if the option shared_for_coexistence is NOT set to true, it invalidates the reset_after_flow_ends: False property in the flow definition. In order for the slot value to be retained throughout the conversation, the shared_for_coexistence must be set to true.
Channel-Specific Response Variations#
To specify different response variations depending on which channel the user is connected to, use channel-specific response variations.
In the following example, the channel key makes the first response variation channel-specific for the slack channel while the second variation is not channel-specific:
- text: "Which game would you like to play on Slack?"
- text: "Which game would you like to play?"
Make sure the value of the channel key matches the value returned by the name() method of your input channel. If you are using a built-in channel, this value will also match the channel name used in your credentials.yml file.
When your assistant looks for suitable response variations under a given response name, it will first try to choose from channel-specific variations for the current channel. If there are no such variations, the assistant will choose from any response variations which are not channel-specific.
In the above example, the second response variation has no channel specified and can be used by your assistant for all channels other than slack.
For each response, try to have at least one response variation without the channel key. This allows your assistant to properly respond in all environments, such as in new channels, in the shell and in interactive learning.
The requested_slot slot#
The slot requested_slot is automatically added to the domain as a slot of type text. The value of the requested_slot will be ignored during conversations. If you want to change this behavior, you need to add the requested_slot to your domain file as a categorical slot with influence_conversation set to true. You might want to do this if you want to handle your unhappy paths differently, depending on what slot is currently being asked from the user. For example, if your users respond to one of the bot's questions with another question, like why do you need to know that? The response to this explain intent depends on where we are in the story. In the restaurant case, your stories would look something like this:
- story: explain cuisine slot
- intent: request_restaurant
- action: restaurant_form
- active_loop: restaurant
- requested_slot: cuisine
- action: utter_explain_cuisine
- action: restaurant_form
- story: explain num_people slot
- intent: request_restaurant
- action: restaurant_form
- active_loop: restaurant
- requested_slot: cuisine
- requested_slot: num_people
- action: utter_explain_num_people
- action: restaurant_form
Again, it is strongly recommended that you use interactive learning to build these stories.
Custom Slot Mappings#
If none of the predefined Slot Mappings fit your use
case, you can use the
Custom Action validate_
If you're using the Rasa SDK we recommend you to extend the provided FormValidationAction. When using the FormValidationAction, three steps are required to extract customs slots:
The following example shows the implementation of a form which extracts a slot outdoor_seating in a custom way, in addition to the slots which use predefined mappings. The method extract_outdoor_seating sets the slot outdoor_seating based on whether the keyword outdoor was present in the last user message.
from typing import Dict, Text, List, Optional, Any
from rasa_sdk import Tracker
from rasa_sdk.executor import CollectingDispatcher
from rasa_sdk.forms import FormValidationAction
class ValidateRestaurantForm(FormValidationAction):
def name(self) -> Text:
return "validate_restaurant_form"
async def required_slots(
slots_mapped_in_domain: List[Text],
dispatcher: "CollectingDispatcher",
domain: "DomainDict",
) -> Optional[List[Text]]:
required_slots = slots_mapped_in_domain + ["outdoor_seating"]
return required_slots
async def extract_outdoor_seating(
self, dispatcher: CollectingDispatcher, tracker: Tracker, domain: Dict
) -> Dict[Text, Any]:
text_of_last_user_message = tracker.latest_message.get("text")
sit_outside = "outdoor" in text_of_last_user_message
return {"outdoor_seating": sit_outside}
By default the FormValidationAction will automatically set the requested_slot to the first slot specified in required_slots which is not filled.
