What is the better way to write stories in RASA

Question

I am building a demo chatbot using RASA. I have two ideas to write stories.nlu. One is to write whole conversation flow in each story, another one is to write a small reusable stories with checkpoints.

Example 1 : Big Story with Whole Conversation

- story: User greets and provides duration, and symptoms
  steps:
  - intent: greet
  - action: utter_greet
  - intent: report_disease
    entities:
    - disease: fever
  - action: action_determine_disease
  - action: action_ask_duration
  - intent: provide_duration
    entities:
    - duration: 3
  - action: action_ask_symptoms
  - intent: provide_symptoms
    entities:
    - symptoms: cough
    - symptoms: body ache
  - action: action_suggest_fever_response
  - action: action_reset_slots
  - intent: thanks
  - action: utter_you_are_welcome
  - intent: goodbye
  - action: utter_goodbye

Example 2 : Small Story with Checkpoints

  - story: User greets the bot
    steps:
      - intent: greet
      - action: utter_greet
      
  - story: User thanks the bot
    steps:
      - intent: thanks
      - action: utter_thanks
  
  - story: Give disease 
    steps:
      - intent: inform_disease
      - or:
        - slot_was_set:
            - disease: fever
        - slot_was_set:
            - disease: stomach ache
      - action: utter_ask_for_duration

  - story:  provide  duration 
    steps:
      - intent: give_number
        entities:
        - number: 3
      - action: action_set_number_entity
      - checkpoint: allergy_checkpoint

  - story: provide symptoms 
    steps:
      - checkpoint: symptoms_checkpoint
      - intent: provide_symptoms
        entities:
        - symptoms: cough
      - action: action_divert_to_disease

My question is, which approach is best way to build when it comes to large training data set. I could not find any related document on Web. Can anybody suggest

Answer 1

Simply put, using one approach over the other depends on the use-case and will vary from feature to feature within the chatbot. There should be a mixed use of the approaches rather than using only one or the other.

Approach 1: Big story with whole conversation

This general approach should be used commonly in your chatbot. The bulk of a particular feature's possible conversation flows should be translated into stories.

• conversation-like stories can maximize the accuracy of your bots action predictions
• a mix of small stories, rules, and larger conversational stories can improve your models training time and performance
• reduces development/maintenance overhead

Recommended approach:

- story: Transfer funds
  steps:
    - intent: transferFunds
    - action: action_transfer_funds
    ....

- story: Open account
  steps:
    - intent: openAccount
    - action: action_open_account
    ....

Redundant approach:

- story: Transfer funds then open account
  steps:
    - intent: transferFunds
    - action: action_transfer_funds
    ....
    - intent: openAccount
    - action: action_open_account
    ....

- story: Open account then transfer funds
  steps:
    - intent: openAccount
    - action: action_open_account
    ....
    - intent: transferFunds
    - action: action_transfer_funds
    ....

Some parts of the big stories are unneeded, like accounting for greeting and goodbye intents and the beginning and ending of the story. These intents should be handled by small stories/rules:

- story: User greets and provides duration, and symptoms
  steps:
    - intent: greet                     # remove
    - action: utter_greet               # remove
    - intent: report_disease
      entities:
      - disease: fever
    - action: action_determine_disease
    ....
    - action: action_suggest_fever_response
    - action: action_reset_slots
    - intent: thanks                    # remove
    - action: utter_you_are_welcome     # remove
    - intent: goodbye                   # remove
    - action: utter_goodbye             # remove

Approach 2: Small Story with checkpoints

• Useful for breaking up large, repetitive stories into reusable portions
• Useful for achieving branching without setting setting a slot or adding additional stories/rules/intents

Example of when it may be useful to use checkpoints:

- story: Disclaimer message checkpoint
  steps:
    - checkpoint: disclaimer_message
    - action: utter_disclaimer_message
    - action: action_disclaimer_logic
    - checkpoint: disclaimer_message_end

# story that branches many ways before disclaimer checkpoint
- story: User wants to see offer on product - pre-disclaimer
  steps:
    - intent: seeOffer
    - action: utter_see_offer_message
    - action: action_show_offer_types
    ...
    - action: action_get_offer_selections
    - checkpoint: disclaimer_message

- story: User wants to see offer on product - post-disclaimer
  steps:
    - checkpoint: disclaimer_message_end
    - action: utter_all_offers_message
    - action: action_show_all_offers

Like mentioned in approach #1, smaller stories are good for small, generic intents like "hello", "goodbye", "fallback". However, a rule would work better since it achieves the same outcome while having less impact on model training.

Example of greet intent as rule:

- rule: User greets the bot
  steps:
    - intent: greet
    - action: utter_greet

Checkpoints should be used sparingly. It is often better to use a rule or different story approach to achieve what you are trying to implement.

• Excessive checkpoint use can make it difficult for action predictions policies to accurately predict what action should be executed next.
• If the length of a checkpoint story exceeds max_history then action prediction based on previously executed actions becomes ambiguous and can produce undesired behavior.
• Excessive checkpoint usage will increase the time it takes to train a model. This becomes more important the larger the chatbot becomes.
• Most usages of checkpoints can be better implemented with the ResponseSelector or rules.