Rasa原文--Stories

目录

Stories

Format#

User Messages#

Actions#

Events#

Form Events#

Checkpoints and OR statements#

Checkpoints#

Or Statements#

End-to-end Training

---

Stories

故事是一种训练数据，用于训练助手的对话管理模型。故事可以用来训练模型，从而归纳出看不见的对话路径。

Format#

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 intents (and entities when necessary), while the assistant's responses and actions are expressed as action names.

Here's an example of a dialogue in the Rasa story format:

stories:
- story: collect restaurant booking info  # name of the story - just for debugging
  steps:
  - intent: greet                         # user message with no entities
  - action: utter_ask_howcanhelp
  - intent: inform                        # user message with no entities
    entities:
    - location: "rome"
    - price: "cheap"
  - action: utter_on_it                  # action that the bot should execute
  - action: utter_ask_cuisine
  - intent: inform
    entities:
    - cuisine: "spanish"
  - action: utter_ask_num_people

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_entitiesattribute).

Actions#

All actions executed by the bot, including responses are listed in stories under the action key.

You can use a response from your domain as an action by listing it as one in a story. Similarly, you can indicate that a story should call a custom action by including the name of the custom action from the actions list in your domain.

Events#

During training, Rasa Open Source does not call the action server. This means that your assistant's dialogue management model doesn't know which events a custom action will return.

Because of this, events such as setting a slot or activating/deactivating a form have to be explicitly written out as part of the stories. For more info, see the documentation on Events.

Slot Events#

Slot events are written under slot_was_set in a story. If this slot is set inside a custom action, add the slot_was_set event immediately following the custom action call. If your custom action resets a slot value to None, the corresponding event for that would look like this:

stories:
- story: set slot to none
  steps:
    # ... other story steps
    - action: my_custom_action
    - slot_was_set:
      - my_slot: null

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. - action: restaurant_form) is used in the beginning when first starting a form, and also while resuming the form action when the form is already active.

• A form activation event (e.g. - active_loop: restaurant_form) is used right after the first form action event.

• A form deactivation event (e.g. - active_loop: null), which is used to deactivate the form.

Checkpoints and OR statements#

Checkpoints and OR statements should be used with caution, if at all. There is usually a better way to achieve what you want by using Rules or the ResponseSelector.

Checkpoints#

您可以使用检查点来模块化和简化培训数据。检查点是有用的，但是不要过度使用它们。使用大量的检查点会很快使您的示例故事难以理解，并且会减慢培训的速度。

Here is an example of stories that contain checkpoints:

stories:
- story: beginning of flow
  steps:
  - intent: greet
  - action: action_ask_user_question
  - checkpoint: check_asked_question

- story: handle user affirm
  steps:
  - checkpoint: check_asked_question
  - intent: affirm
  - action: action_handle_affirmation
  - checkpoint: check_flow_finished

- story: handle user deny
  steps:
  - checkpoint: check_asked_question
  - intent: deny
  - action: action_handle_denial
  - checkpoint: check_flow_finished

- story: finish flow
  steps:
  - checkpoint: check_flow_finished
  - intent: goodbye
  - action: utter_goodbye

与常规的故事不同，检查点并不局限于从用户输入开始。只要检查点插入到主要故事的正确位置，第一个事件也可以是自定义操作或响应。

Or Statements#

写短篇故事的另一种方法，或者用同样的方式处理多个意图，是使用or语句。例如，如果你让用户确认某件事，而你想用同样的方式来对待affirm和thankyou的意图。下面的故事将在培训时转换成两个故事:

stories:
- story:
  steps:
  # ... previous steps
  - action: utter_ask_confirm
  - or:
    - intent: affirm
    - intent: thankyou
  - action: action_handle_affirmation

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. Overusing OR statements will slow down training.

End-to-end Training

With end-to-end training, you do not have to deal with the specific intents of the messages that are extracted by the NLU pipeline or with separate utter_ responses in the domain file. Instead, you can include the text of the user messages and/or bot responses directly in your stories. See the training data format for detailed description of how to write end-to-end stories.

You can mix training data in the end-to-end format with labeled training data which has intents and actions specified: Stories can have some steps defined by intents/actions and other steps defined directly by user or bot utterances.

We call it end-to-end training because policies can consume and predict actual text. For end-to-end user inputs, intents classified by the NLU pipeline and extracted entities are ignored.

Only Rule Policy and TED Policy allow end-to-end training.

• RulePolicy uses simple string matching during prediction. Namely, rules based on user text will only match if the user text strings inside your rules and input during prediction are identical.

• TEDPolicy passes user text through an additional Neural Network to create hidden representations of the text. In order to obtain robust performance you need to provide enough training stories to capture a variety of user texts for any end-to-end dialogue turn.

Rasa policies are trained for next utterance selection. The only difference to creating utter_ response is how TEDPolicy featurizes bot utterances. In case of an utter_ action, TEDPolicy sees only the name of the action, while if you provide actual utterance using bot key, TEDPolicy will featurize it as textual input depending on the NLU configuration. This can help in case of similar utterances in slightly different situations. However, this can also make things harder to learn because the fact that different utterances have similar texts make it easier for TEDPolicy to confuse these utterances.

End-to-end training requires significantly more parameters in TEDPolicy. Therefore, training an end-to-end model might require significant computational resources depending on how many end-to-end turns you have in your stories.