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.
• 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 format intent{"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.

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.

Actions

While writing stories, you will encounter two types of actions: utterance actions and custom actions. 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.

Events

Events such as setting a slot or activating/deactivating a form have to be explicitly written out as part of the stories. You can read more about events here.

Slot Events

Slot events are written as - slot{"slot_name": "value"}.

Form Events

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. - restaurant_form) is used in the beginning when first starting a form.
• A form activation event (e.g. - form{"name": "restaurant_form"}) is used right after the first form action event.
• A form deactivation event (e.g. - form{"name": null}), which is used to deactivate the form.

Checkpoints and OR statements

Checkpoints and OR statements should both be used with caution, if at all. There is usually a better way to achieve what you want by using forms and/or retrieval actions.

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. Read more about Testing Your Assistant.