Intents are the basic building block for a user’s turn in the conversation. Each intent lets you identify sample user utterances: the many different ways a user may phrase the intent, to make the conversation more robust and forgiving.
Note that Rasa uses “utter_” to indicate app responses, not user intents/utterances.
Forms are a flexible way to collect multiple pieces of information from a user (stored in slots), allowing for natural conversation rather than forcing a prescriptive sequence of turns. For example, for a bank transfer intent, the user’s initial utterance may include some, all or none of the needed information (from, to, amount).
Forms prompt users for missing information through specifically named responses. To create a prompt for collecting a specific piece of info, create a response named utter_ask_<form name>_<slot name> or utter_ask_<slot name> for each slot the form needs to fill. Forms can extract information to fill the slots in several ways, see.
For further customization, see.
Slots are the app’s memory, used to store pieces of information provided by your user or external data. They can be used to relay data back to the user, record information about the conversation, and influence the direction of the conversation. Slots are also vital to the use of forms.
For more details, see.
Entities are structured pieces of information inside a user message that are commonly used to fill slots. For example, the user message “I’d like it by tomorrow” contains information for the entity delivery_date. Entities-to-be-extracted are indicated (“annotated”) in training data such as stories and an intent’s sample utterances (“I’d like it by [tomorrow] (“delivery_date”)”)
An extracted entity will automatically fill an existing slot of the same name, unless directed otherwise.
Each entity contains values and synonyms. Note that Jargon merges the Rasa concepts of Synonyms and Lookup Tables.
Entities in Rasa are similar to slot types in voice apps.
Regular expressions recognize information in a user message by its format, which can then be mapped to an entity or intent. For example, a RegEx may map any 12-digit number in a user message to an account_number entity.
Not every app needs RegEx.
Custom actions run custom code, for maximum flexibility. Sample uses include API calls and querying databases.
A Story is a sample part of the conversation, with at least one “user says/app responds” (or intent/action) turn. Stories train Rasa's dialog management model to be able to generalize to unforeseen conversation paths. Adding stories makes your app better able to handle the various ways in which a user converses with your app. For more information, visit Rasa's documentation.
All user messages are specified via a step with the “intent:” key and an optional “entities:” key. Intent names must refer to an intent defined in the project’s training data. Entity names must refer to an entity defined in the project as well.
Each action step describes an action taken by the bot. An action step may either be a response, which must start with the prefix utter_, or a custom action, which must start with the prefix action_, or a reference to a form. Note that form actions must be used in conjunction with action_loop steps.
slot_was_set steps indicate when a slot event occurs, either after an intent or after a custom action. Stories do not set slots. The slot must be set by an entity or custom action before the slot_was_set step.
Checkpoints are specified with the checkpoint: key, either at the beginning or the end of a story. Checkpoints are ways to connect stories together. They can be either the first or the last step in a story. If they are the last step in a story, that story will be connected to each other story that starts with the checkpoint of the same name when the model is trained.
Checkpoints can help simplify your training data and reduce redundancy in it, but do not overuse them. Using lots of checkpoints can quickly make your stories hard to understand. It makes sense to use them if a sequence of steps is repeated often in different stories, but stories without checkpoints are easier to read and write.
“or” steps are ways to handle multiple intents the same way, without writing a separate story for each intent. For example, if you ask the user to confirm something, you might want to treat the “affirm” and “thankyou” intents in the same way. Stories with or steps will be converted into multiple separate stories at training time. Just like checkpoints, 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.
A Rule describes a part of the conversation that should always follow the same path, with at least one “user says/app responds” turn. Unlike stories, rules are prescriptive and should be used with restraint.