（十四）RASA story

作者简介

作者：孟繁中

原文：https://zhuanlan.zhihu.com/p/334635257

转载者：杨夕

面筋地址：https://github.com/km1994/NLP-Interview-Notes

个人笔记：https://github.com/km1994/nlp_paper_study

故事和规则都是用户和会话助手之间对话的表示。它们被用来训练对话管理模式。故事被用来训练机器学习模型，以识别对话中的模式，并将其归纳为看不见的对话路径。规则描述了应该始终遵循相同路径并用于训练规则策略的小部分对话。

一个故事包括：

• 故事：故事的名字。该名称是任意的，不用于培训；您可以将其用作故事的可读参考。

• 元数据：任意和可选，不用于培训，您可以使用它来存储有关故事的信息，例如作者

• 步骤列表：组成故事的用户消息和操作

stories:
- story: Greet the user
  metadata:
    author: Somebody
    key: value
  steps:
  # list of steps
  - intent: greet
  - action: utter_greet

每个步骤可以是以下步骤之一：

• 由意图和实体表示的用户消息。

• 或语句，其下包含两个或多个用户消息。

• 机器人的行动。

• 一张Form。

• 插槽已设置事件。

• 一个检查点，它将故事与另一个故事连接起来。

用户消息

所有用户消息都使用intent:key和可选的entities:key指定。在编写故事时，您不必处理用户发送的消息，而是直接利用来自NLU管道的输出的实体和意图，引用相对应的消息发送。用户消息的格式如下：

stories:
- story: user message structure
  steps:
    - intent: intent_name  # Required
      entities:  # Optional
      - entity_name: entity_value
    - action: action_name

这个配置的意思是，当pipeline输出的意图是intent_name的时候，输出响应action_name

动作

bot执行的所有操作都是用action:key后跟操作名来指定的。在写故事时，你会遇到两种类型的动作：

Response:从utter_开头，向用户发送特定的消息。并且必须和domain中定义的模板匹配。

针对自定义动作，动作的名字可以从自定义动作类的name方法返回。尽管，对于这个命名没有规则上的限制，但是最好的实践方式是以action_开头。

stories:
- story: story with a response
  steps:
  - intent: greet
  - action: utter_greet

Custom_Action:从Action开始，运行任意代码并发送任意数量的消息（或无）。

stories:
- story: story with a custom action
  steps:
  - intent: feedback
  - action: action_store_feedback

Forms

表单是一种特定类型的自定义操作，它包含在一组所需插槽上循环并向用户请求此信息的逻辑。在域中的“Forms”部分中定义Forms。一旦定义好，Forms的快乐路径指定为一个规则。您应该在故事中包含形式的中断或其他“不愉快的路径”，以便模型可以概括为看不见的会话序列。作为故事的一个步骤，表单采用以下格式：

stories:
- story: story with a form
  steps:
  - intent: find_restaurant
  - action: restaurant_form                # Activate the form
  - active_loop: restaurant_form           # This form is currently active
  - active_loop: null                      # Form complete, no form is active
  - action: utter_restaurant_found

操作步骤激活窗体并开始在所需的插槽上循环。active_loop:restaurant_form步骤指示当前有一个活动表单。与slot_was_set step非常相似，表单step不会将表单设置为active，而是指示它应该已经被激活。同样，active_loop:null步骤表示在执行后续步骤之前，任何表单都不应处于活动状态。

Slots

在键槽“slot_was_set”下指定插槽事件：使用插槽名称和可选的插槽值。插槽充当机器人的内存。插槽由实体或自定义操作设置，并由插槽slot_was_set在step中的被故事引用。例如：

stories:
- story: story with a slot
  steps:
  - intent: celebrate_bot
  - slot_was_set:
    - feedback_value: positive
  - action: utter_yay

这意味着故事要求feedback_value slot的当前值为positive，会话才能按指定继续。是否需要包含slot的值取决于slot类型以及该值是否应该影响对话。如果值不重要，可以不填写，如上文，就可以不写“positive”。

checkpoints

检查点在故事的开头或结尾用checkpoint:key指定。检查点是连接故事的方法。它们可以是故事的第一步，也可以是最后一步。如果它们是一个故事的最后一步，那么这个故事将被连接到另一个故事，当模型被训练时，这个故事将以同名的检查点开始。下面是一个以检查点结尾的故事的示例，以及以相同检查点开头的故事的示例：

stories:
- story: story_with_a_checkpoint_1
  steps:
  - intent: greet
  - action: utter_greet
  - checkpoint: greet_checkpoint

- story: story_with_a_checkpoint_2
  steps:
  - checkpoint: greet_checkpoint
  - intent: book_flight
  - action: action_book_flight

故事开头的检查点也可以根据设置的插槽而定，例如：

stories:
- story: story_with_a_conditional_checkpoint
  steps:
  - checkpoint: greet_checkpoint
    # This checkpoint should only apply if slots are set to the specified value
    slot_was_set:
    - context_scenario: holiday
    - holiday_name: thanksgiving
  - intent: greet
  - action: utter_greet_thanksgiving

检查点可以有助于简化培训数据并减少其中的冗余，但不要过度使用它们。使用大量的检查点会很快让你的故事难以理解。如果在不同的故事中经常重复一系列步骤，那么使用它们是有意义的，但是没有检查点的故事更容易阅读和编写。

OR statement

OR，step是以相同的方式处理多个意图的方法，而不必为每个意图编写单独的故事。例如，如果你要求用户确认某件事，你可能想用同样的方式来对待肯定和感谢。带有或步骤的故事将在培训时转换为多个单独的故事。例如，培训时将转换为两个故事：

stories:
- story: story with OR
  steps:
  - intent: signup_newsletter
  - action: utter_ask_confirm
  - or:
    - intent: affirm
    - intent: thanks
  - action: action_signup_newsletter

测试故事检查消息的分类是否正确以及动作预测。测试故事使用与故事相同的格式，只是用户消息步骤可以包含一个用户来指定用户消息的实际文本和实体注释。下面是一个测试故事的例子：

stories:
- story: A basic end-to-end test
  steps:
  - user: |
     hey
    intent: greet
  - action: utter_ask_howcanhelp
  - user: |
     show me [chinese]{"entity": "cuisine"} restaurants
    intent: inform
  - action: utter_ask_location
  - user: |
     in [Paris]{"entity": "location"}
    intent: inform
  - action: utter_ask_price

可以使用以下命令运行测试：

rasa test

rasa支持分段评估各个组件，具体参考：https://rasa.com/docs/rasa/testing-your-assistant

End-to-end Training

通过端到端培训，您不必处理由NLU管道提取的消息的特定意图。相反，您可以使用user key将用户消息的文本直接放在故事中。这些端到端用户消息的格式如下：

stories:
- story: user message structure
  steps:
    - user: the actual text of the user message
    - action: action_name

此外，还可以添加可由TED策略提取的实体标记。实体标记的语法与NLU训练数据中的相同。例如，下面的故事包含了“我总是可以去吃寿司”的用户话语。通过使用NLU训练数据[sushi]（cuisine）中的语法，可以将sushi标记为cuisine类型的实体。

stories:
- story: story with entities
  steps:
  - user: I can always go for [sushi](cuisine)
  - action: utter_suggest_cuisine

类似地，你可以直接把机器人的话语放在故事中，方法是使用机器人键后跟你想让机器人说的文字。一个只有机器人说话的故事可能是这样的：

stories:
- story: story with an end-to-end response
  steps:
  - intent: greet
    entities:
    - name: Ivan
  - bot: Hello, a person with a name!

也可以是混合方式的，

stories:
- story: full end-to-end story
  steps:
  - intent: greet
    entities:
    - name: Ivan
  - bot: Hello, a person with a name!
  - intent: search_restaurant
  - action: utter_suggest_cuisine
  - user: I can always go for [sushi](cuisine)
  - bot: Personally, I prefer pizza, but sure let's search sushi restaurants
  - action: utter_suggest_cuisine
  - user: Have a beautiful day!
  - action: utter_goodbye

Rasa端到端培训与标准Rasa方法完全集成。这意味着您可以将一些由操作或意图定义的步骤与由用户消息或bot响应直接定义的其他步骤混合在一起。