Samyang Rasa Baru
Validating Form Input#
After extracting a slot value from user input, you can validate the extracted slots. By default Rasa Open Source only validates if any slot was filled after requesting a slot.
Forms no longer raise ActionExecutionRejection if nothing is extracted from the user’s utterance for any of the required slots.
You can implement a Custom Action validate_
- validate_restaurant_form
When the form is executed it will run your custom action.
This custom action can extend FormValidationAction class to simplify
the process of validating extracted slots. In this case, you need to write functions
named validate_
The following example shows the implementation of a custom action which validates that the slot named cuisine is valid.
from typing import Text, List, Any, Dict
from rasa_sdk import Tracker, FormValidationAction
from rasa_sdk.executor import CollectingDispatcher
from rasa_sdk.types import DomainDict
class ValidateRestaurantForm(FormValidationAction):
def name(self) -> Text:
return "validate_restaurant_form"
def cuisine_db() -> List[Text]:
"""Database of supported cuisines"""
return ["caribbean", "chinese", "french"]
def validate_cuisine(
dispatcher: CollectingDispatcher,
) -> Dict[Text, Any]:
"""Validate cuisine value."""
if slot_value.lower() in self.cuisine_db():
return {"cuisine": slot_value}
return {"cuisine": None}
You can also extend the Action class and retrieve extracted slots with tracker.slots_to_validate to fully customize the validation process.
Session configuration#
A conversation session represents the dialogue between the assistant and the user. Conversation sessions can begin in three ways:
the user begins the conversation with the assistant,
the user sends their first message after a configurable period of inactivity, or
a manual session start is triggered with the /session_start intent message.
You can define the period of inactivity after which a new conversation session is triggered in the domain under the session_config key.
Available parameters are:
The default session configuration looks as follows:
session_expiration_time: 60 # value in minutes, 0 means infinitely long
carry_over_slots_to_new_session: true # set to false to forget slots between sessions
This means that if a user sends their first message after 60 minutes of inactivity, a new conversation session is triggered, and that any existing slots are carried over into the new session. Setting the value of session_expiration_time to 0 means that sessions will not end (note that the action_session_start action will still be triggered at the very beginning of conversations).
A session start triggers the default action action_session_start. Its default implementation moves all existing slots into the new session. Note that all conversations begin with an action_session_start. Overriding this action could for instance be used to initialize the tracker with slots from an external API call, or to start the conversation with a bot message. The docs on Customizing the session start action shows you how to do that.
The config key in the domain file maintains the store_entities_as_slots parameter. This parameter is used only in the context of reading stories and turning them into trackers. If the parameter is set to True, this will result in slots being implicitly set from entities if applicable entities are present in the story. When an entity matches the from_entity slot mapping, store_entities_as_slots defines whether the entity value should be placed in that slot. Therefore, this parameter skips adding an explicit slot_was_set step manually in the story. By default, this behaviour is switched on.
You can turn off this functionality by setting the store_entities_as_slots parameter to false:
store_entities_as_slots: false
If you're looking for information on the config.yml file, check out the docs on Model Configuration.
A story is a representation of a conversation between a user and an AI assistant, converted into a specific format where user inputs are expressed as intents (and entities when necessary), while the assistant's responses and actions are expressed as action names.
Here's an example of a dialogue in the Rasa story format:
- story: collect restaurant booking info # name of the story - just for debugging
- intent: greet # user message with no entities
- action: utter_ask_howcanhelp
- intent: inform # user message with entities
- action: utter_on_it # action that the bot should execute
- action: utter_ask_cuisine
- action: utter_ask_num_people
While writing stories, you do not have to deal with the specific contents of the messages that the users send. Instead, you can take advantage of the output from the NLU pipeline, which lets you use just the combination of an intent and entities to refer to all the possible messages the users can send to mean the same thing.
It is important to include the entities here as well because the policies learn to predict the next action based on a combination of both the intent and entities (you can, however, change this behavior using the use_entities attribute).
All actions executed by the bot, including responses are listed in stories under the action key.
You can use a response from your domain as an action by listing it as one in a story. Similarly, you can indicate that a story should call a custom action by including the name of the custom action from the actions list in your domain.
During training, Rasa does not call the action server. This means that your assistant's dialogue management model doesn't know which events a custom action will return.
Because of this, events such as setting a slot or activating/deactivating a form have to be explicitly written out as part of the stories. For more info, see the documentation on Events.
Slot events are written under slot_was_set in a story. If this slot is set inside a custom action, add the slot_was_set event immediately following the custom action call. If your custom action resets a slot value to None, the corresponding event for that would look like this:
- story: set slot to none
# ... other story steps
- action: my_custom_action
There are three kinds of events that need to be kept in mind while dealing with forms in stories.
A form action event (e.g. - action: restaurant_form) is used in the beginning when first starting a form, and also while resuming the form action when the form is already active.
A form activation event (e.g. - active_loop: restaurant_form) is used right after the first form action event.
A form deactivation event (e.g. - active_loop: null), which is used to deactivate the form.
In order to get around the pitfall of forgetting to add events, the recommended way to write these stories is to use interactive learning.
Custom Slot Mappings#
The slots_mapped_in_domain argument provided to the required_slots method of FormValidationAction has been replaced by the domain_slots argument, please update your custom actions to the new argument name.
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:
In addition, you can override the required_slots method to add dynamically requested slots: you can read more in the Dynamic Form Behavior section.
If you have added a slot with a custom mapping in the slots section of the domain file which you only want to be validated within the context of a form by a custom action extending FormValidationAction, please make sure that this slot has a mapping of type custom and that the slot name is included in the form's required_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 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.
Using a Custom Action to Ask For the Next Slot#
As soon as the form determines which slot has to be filled next by the user, it will
execute the action utter_ask_
from typing import Dict, Text, List
from rasa_sdk import Tracker
from rasa_sdk.events import EventType
from rasa_sdk.executor import CollectingDispatcher
from rasa_sdk import Action
class AskForSlotAction(Action):
def name(self) -> Text:
return "action_ask_cuisine"
self, dispatcher: CollectingDispatcher, tracker: Tracker, domain: Dict
) -> List[EventType]:
dispatcher.utter_message(text="What cuisine?")
If there is more than one asking option for the slot, Rasa prioritizes in the following order:
Calling Responses from Custom Actions#
You can use the responses to generate response messages from your custom actions. If you're using Rasa SDK as your action server, you can use the dispatcher to generate the response message, for example:
from rasa_sdk.interfaces import Action
class ActionGreet(Action):
return 'action_greet'
def run(self, dispatcher, tracker, domain):
dispatcher.utter_message(template="utter_greet")
If you use a different custom action server, your server should return the following JSON to call the utter_greet response:
"template":"utter_greet"
To use forms with Rasa Open Source you need to make sure that the Rule Policy is added to your policy configuration. For example:
Define a form by adding it to the forms section in your domain. The name of the form is also the name of the action which you can use in stories or rules to handle form executions. You also need to define slot mappings for each slot which your form should fill. You can specify one or more slot mappings for each slot to be filled.
The following example form restaurant_form will fill the slot cuisine from an extracted entity cuisine and slot num_people from entity number.
You can define a list of intents to ignore for the whole form under the ignored_intents key. Intents listed under ignored_intents will be added to the not_intent key of each slot mapping in the form.
For example, if you do not want any of the required slots of a form to be filled when the intent is chitchat, then you would need to define the following (after the form name and under the ignored_intents keyword):
The required_slots keyword was introduced. The following syntax is deprecated and will be removed in 3.0.0:
# this format is deprecated
Once the form action gets called for the first time, the form gets activated and will
prompt the user for the next required slot value. It does this by
looking for a response called
utter_ask_
To activate a form you need to add a story or rule, which describes when the assistant should run the form. In the case a specific intent triggering a form, you can for example use the following rule:
- rule: Activate form
- intent: request_restaurant
- action: restaurant_form
- active_loop: restaurant_form
The active_loop: restaurant_form step indicates that the form should be activated after restaurant_form was run.
A form will automatically deactivate itself once all required slots are filled. You can describe your assistant's behavior for the end of a form with a rule or a story. If you don't add an applicable story or rule, the assistant will automatically listen for the next user message after the form is finished. The following example runs the utterance utter_all_slots_filled as soon as the form your_form filled all required slots.
# Condition that form is active.
- active_loop: restaurant_form
# Form is deactivated
- action: restaurant_form
- requested_slot: null
# The actions we want to run when the form is submitted.
- action: utter_submit
- action: utter_slots_values
Users might want to break out of a form early. Please see Writing Stories / Rules for Unhappy Form Paths on how to write stories or rules for this case.
Rasa Open Source comes with four predefined mappings to fill the slots of a form based on the latest user message. Please see Custom Slot Mappings if you need a custom function to extract the required information.
The from_entity mapping fills slots based on extracted entities. It will look for an entity called entity_name to fill a slot slot_name. If intent_name is None, the slot will be filled regardless of intent name. Otherwise, the slot will only be filled if the user's intent is intent_name.
If role_name and/or group_name are provided, the role/group label of the entity also needs to match the given values. The slot mapping will not apply if the intent of the message is excluded_intent. Note that you can also define lists of intents for the parameters intent and not_intent.
not_intent: excluded_intent
In from_entity mapping, when an extracted entity uniquely maps onto a slot, the slot will be filled even if this slot wasn't requested by the form. The extracted entity will be ignored if the mapping is not unique.
In the example above, an entity date uniquely sets the slot arrival_date, an entity city with a role from uniquely sets the slot departure_city and an entity city with a role to uniquely sets the slot arrival_city, therefore they can be used to fit corresponding slots even if these slots were not requested. However, entity city without a role can fill both departure_city and arrival_city slots, depending which one is requested, so if an entity city is extracted when slot arrival_date is requested, it'll be ignored by the form.
The from_text mapping will use the text of the next user utterance to fill the slot slot_name. If intent_name is None, the slot will be filled regardless of intent name. Otherwise, the slot will only be filled if the user's intent is intent_name.
The slot mapping will not apply if the intent of the message is excluded_intent. Note that you can define lists of intents for the parameters intent and not_intent.
not_intent: excluded_intent
The from_intent mapping will fill slot slot_name with value my_value if user intent is intent_name or None. The slot mapping will not apply if the intent of the message is excluded_intent. Note that you can also define lists of intents for the parameters intent and not_intent.
The from_intent slot mapping will not apply during the initial activation of the form. To fill a slot based on the intent that activated the form, use the from_trigger_intent mapping.
not_intent: excluded_intent
The from_trigger_intent mapping will fill slot slot_name with value my_value if the form was activated by a user message with intent intent_name. The slot mapping will not apply if the intent of the message is excluded_intent. Note that you can also define lists of intents for the parameters intent and not_intent.
- type: from_trigger_intent
not_intent: excluded_intent
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.
Session configuration#
A conversation session represents the dialogue between the assistant and the user. Conversation sessions can begin in three ways:
the user begins the conversation with the assistant,
the user sends their first message after a configurable period of inactivity, or
a manual session start is triggered with the /session_start intent message.
You can define the period of inactivity after which a new conversation session is triggered in the domain under the session_config key.
Available parameters are:
The default session configuration looks as follows:
session_expiration_time: 60 # value in minutes, 0 means infinitely long
carry_over_slots_to_new_session: true # set to false to forget slots between sessions
This means that if a user sends their first message after 60 minutes of inactivity, a new conversation session is triggered, and that any existing slots are carried over into the new session. Setting the value of session_expiration_time to 0 means that sessions will not end (note that the action_session_start action will still be triggered at the very beginning of conversations).
A session start triggers the default action action_session_start. Its default implementation moves all existing slots into the new session. Note that all conversations begin with an action_session_start. Overriding this action could for instance be used to initialize the tracker with slots from an external API call, or to start the conversation with a bot message. The docs on Customizing the session start action shows you how to do that.
Dynamic Form Behavior#
By default, Rasa will ask for the next empty slot from the slots listed for your form in the domain file. If you use custom slot mappings and the FormValidationAction, it will ask for the first empty slot returned by the required_slots method. If all slots in required_slots are filled the form will be deactivated.
You can update the required slots of your form dynamically. This is, for example, useful when you need to fill additional slots based on how a previous slot was filled or when you want to change the order in which slots are requested.
If you are using the Rasa SDK, we strongly recommend that you use the FormValidationAction and
override required_slots to fit your dynamic behavior. You must implement
a method extract_
from typing import Text, List, Optional
from rasa_sdk.forms import FormValidationAction
class ValidateRestaurantForm(FormValidationAction):
def name(self) -> Text:
return "validate_restaurant_form"
async def required_slots(
domain_slots: List[Text],
dispatcher: "CollectingDispatcher",
domain: "DomainDict",
additional_slots = ["outdoor_seating"]
if tracker.slots.get("outdoor_seating") is True:
additional_slots.append("shade_or_sun")
return additional_slots + domain_slots
If conversely, you want to remove a slot from the form's required_slots defined in the domain file under certain conditions, you should copy the domain_slots over to a new variable and apply changes to that new variable instead of directly modifying domain_slots. Directly modifying domain_slots can cause unexpected behaviour. For example:
from typing import Text, List, Optional
from rasa_sdk.forms import FormValidationAction
class ValidateBookingForm(FormValidationAction):
def name(self) -> Text:
return "validate_booking_form"
async def required_slots(
domain_slots: List[Text],
dispatcher: "CollectingDispatcher",
domain: "DomainDict",
updated_slots = domain_slots.copy()
if tracker.slots.get("existing_customer") is True:
updated_slots.remove("email_address")
Multiple Domain Files#
The domain can be defined as a single YAML file or split across multiple files in a directory. When split across multiple files, the domain contents will be read and automatically merged together.
Using the command line interface, you can train a model with split domain files by running:
rasa train --domain path_to_domain_directory
The intents key in your domain file lists all intents used in your NLU data and conversation training data.
Checkpoints and OR statements#
Checkpoints and OR statements should be used with caution, if at all. There is usually a better way to achieve what you want by using Rules or the ResponseSelector.
You can use checkpoints to modularize and simplify your training data. Checkpoints can be useful, but do not overuse them. Using lots of checkpoints can quickly make your example stories hard to understand, and will slow down training.
Here is an example of stories that contain checkpoints:
- story: beginning of flow
- action: action_ask_user_question
- checkpoint: check_asked_question
- story: handle user affirm
- checkpoint: check_asked_question
- action: action_handle_affirmation
- checkpoint: check_flow_finished
- story: handle user deny
- checkpoint: check_asked_question
- action: action_handle_denial
- checkpoint: check_flow_finished
- checkpoint: check_flow_finished
- action: utter_goodbye
Unlike regular stories, checkpoints are not restricted to starting with user input. As long as the checkpoint is inserted at the right points in the main stories, the first event can be a custom action or a response as well.
Another way to write shorter stories, or to handle multiple intents or slot events the same way, is to use an or statement. For example, if you ask the user to confirm something, and you want to treat the affirm and thankyou intents in the same way. The story below will be converted into two stories at training time:
- action: utter_ask_confirm
- action: action_handle_affirmation
You can also use or statements with slot events. The following means the story requires that the current value for the name slot is set and is either joe or bob:
- action: utter_greet
or statements can be useful, but if you are using a lot of them, it is probably better to restructure your domain and/or intents. Overusing OR statements will slow down training.
