Stories
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
- Evaluating Models
- Validate Data
- Configuring the HTTP API
- Deploying your Rasa Assistant
- Cloud Storage
NLU
- About
- Using NLU Only
- Training Data Format
- Choosing a Pipeline
- Language Support
- Entity Extraction
- Components
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.8.2
Stories
Rasa stories are a form of training data used to train the Rasa’s dialogue management models.
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 corresponding intents (and entities where necessary) while the responses of an assistant are expressed as corresponding action names.
A training example for the Rasa Core dialogue system is called a story. This is a guide to the story data format.
Format
Here’s an example of a dialogue in the Rasa story format:
## greet + location/price + cuisine + num people <!-- name of the story - just for debugging -->
* greet
- action_ask_howcanhelp
* inform{"location": "rome", "price": "cheap"} <!-- user utterance, in format intent{entities} -->
- action_on_it
- action_ask_cuisine
* inform{"cuisine": "spanish"}
- action_ask_numpeople <!-- action that the bot should execute -->
* inform{"people": "six"}
- action_ack_dosearch
What makes up a story?
A story starts with a name preceded by two hashes
## story_03248462. You can call the story anything you like, but it can be very useful for debugging to give them descriptive names!The end of a story is denoted by a newline, and then a new story starts again with
##.Messages sent by the user are shown as lines starting with
*in the formatintent{"entity1": "value", "entity2": "value"}.Actions executed by the bot are shown as lines starting with
-and contain the name of the action.Events returned by an action are on lines immediately after that action. For example, if an action returns a
SlotSetevent, this is shown asslot{"slot_name": "value"}.
User Messages
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).
Actions
While writing stories, you will encounter two types of actions: utterance actions and custom actions. Utterance actions are hardcoded messages that a bot can respond with. Custom actions, on the other hand, involve custom code being executed.
All actions (both utterance actions and custom actions) executed by the bot are shown as lines starting with - followed by the name of the action.
The responses for utterance actions must begin with the prefix utter_, and must match the name of the response defined in the domain.
For custom actions, the action name is the string you choose to return from the name method of the custom action class. Although there is no restriction on naming your custom actions (unlike utterance actions), the best practice here is to prefix the name with action_.
Events
Events such as setting a slot or activating/deactivating a form have to be explicitly written out as part of the stories.
End-to-End Story Evaluation Format
The end-to-end story format is a format that combines both NLU and Core training data into a single file for evaluation.