Domain
The domain defines the universe in which your assistant operates.
In Rasa, your domain
defines the universe in which your assistant operates.
Specifically, it lists:
- The
responses
that can be used as templated messages to send to a user. - The custom
actions
that can be predicted by dialogue policies. - The
slots
that act as your assistant's memory throughout a conversation. - Session configuration parameters including inactivity timeout.
If you are building an NLU-based assistant, refer to the Domain documentation to see how intents, entities, slot mappings, and slot featurization can be configured in your domain.
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. You can also manage your responses, slots, custom actions in Rasa Studio.
Using the command line interface, you can train a model with split domain files by running:
Responses
Responses are templated messages that your assistant can send to your user.
Responses can contain rich content like buttons, images, and custom json payloads.
Every responses is also an action, meaning that it can be used directly in
an action
step in a flow.
Responses can be defined directly in the domain file under the responses
key.
For more information on responses and how to define them,
see Responses.
Actions
Actions are the things your bot can do. For example, an action could:
respond to a user,
make an external API call,
query a database, or
just about anything!
All custom actions should be listed in your domain.
Rasa also has default actions which you do not need to list in your domain.
Slots
Slots are your assistant's memory. They act as a key-value store which can be used to store information the user provided (e.g their home city) as well as information gathered about the outside world (e.g. the result of a database query).
Slots are defined in the slots section of your domain with their name, type and default value. Different slot types exist to restrict the possible values a slot can take.
Slot Types
Text Slot
A text slot can take on any string value.
Example
slots:cuisine:type: textAllowed Values
Any string
Boolean Slot
A boolean slot can only take on the values true
or false
. This is useful
when you want to store a binary value.
Example
slots:confirmation:type: boolAllowed Values
true
orfalse
Categorical Slot
A categorical slot can only take on values from a predefined set. This is useful when you want to restrict the possible values a slot can take.
If the user provides a value where the casing does not match the casing of the values
defined in the domain, the value will be coerced to the correct casing.
For example, if the user provides the value LOW
for a slot with values
low
, medium
, high
, the value will be converted to low
and stored in the
slot.
If you define a categorical slot with a list of values, where multiple of the
values coerce to the same value, a warning will be issued and you should remove
one of the values from the set in the domain. For example, if you define a
categorical slot with values low
, medium
, high
, and Low
, the value Low
will be coerced to low
and a warning will be issued.
Example
slots:risk_level:type: categoricalvalues:- low- medium- high
Float Slot
A float slot can only take on floating point values. This is useful when you want to store a number with a decimal point.
Example
slots:temperature:type: float
Any Slot
This slot type can take on any value. This is useful when you want to store any type of information, including structured data like dictionaries.
Example
slots:shopping_items:type: any
List Slot
A list slot can take on a list of values. Note that the list slot type is only supported
in custom actions when building an assistant with CALM.
List slots cannot be filled with flows in either the collect
or set_slots
flow step types.
Initial slot values
You can provide an initial value for any slot in your domain file:
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
.
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:
session_expiration_time
defines the time of inactivity in minutes after which a new session will begin.carry_over_slots_to_new_session
determines whether existing set slots should be carried over to new sessions.
The default session configuration looks as follows:
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).
note
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.
Select which actions should receive domain
New in 3.4.3
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
.
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
: