Stories

A training example for the Rasa Core dialogue system is called a story. This is a guide to the story data format.

Note

You can also spread your stories across multiple files and specify the folder containing the files for most of the scripts (e.g. training, visualization). The stories will be treated as if they would have been part of one large file.

Format

Here’s an example from the bAbI dataset (converted into Rasa stories):

## story_07715946    <!-- 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

This is what we call 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 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. For example, if an action returns a SetSlot event, this is shown as the line - slot{"slot_name": "value"}

Checkpoints

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. It makes sense to use them if a story block is repeated very often in different stories, but stories without checkpoints are easier to read and write. Here is an example story file which contains checkpoints:

## first story
* hello
   - action_ask_user_question
> check_asked_question

## user affirms question
> check_asked_question
* affirm
  - action_handle_affirmation

## user denies question
> check_asked_question
* deny
  - action_handle_denial

Note

Unlike regular stories, checkpoints are not restricted to starting with an input from the user. As long as the checkpoint is inserted at the right points in the main stories, the first event can be an action or an utterance as well.

OR Statements

Another way to write shorter stories, or to handle multiple intents the same way, is to use an OR statement. For example, if you ask the user to confirm something, and we want to treat the affirm and thankyou intents in the same way. The story below will be converted into two 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:

## story
...
  - utter_ask_confirm
* affirm OR thankyou
  - action_handle_affirmation

Note

Adding lines to your stories with many OR statements will slow down training.

👋 I can help you get started with Rasa and answer your technical questions.