Transformer课程 业务对话机器人Rasa 3.x 基本概念 训练数据格式_rasa x3.0

Transformer课程 业务对话机器人Rasa 3.x 基本概念 训练数据格式
本文讲解Rasa助手的不同类型的训练数据，以及该训练数据的结构。

概述

Rasa开源使用YAML作为统一和可扩展的方式来管理所有训练数据，包括NLU数据、故事和规则。

您可以将训练数据拆分为任意数量的YAML文件，每个文件可以包含NLU数据、故事和规则的任意组合。训练数据解析器使用top level keys确定训练数据类型。

域使用与训练数据相同的YAML格式，也可以跨多个文件拆分或合并到一个文件中。域包括响应和表单的定义。有关如何格式化域文件的信息，请参阅域的文档。

传统格式

寻找标记数据格式？它在Rasa 3.0中被删除，但您仍然可以找到有关标记NLU数据和标记故事的文档。如果您的训练数据仍采用标记格式，建议使用Rasa 2.x将数据从标记转换为YAML。《迁移指南》解释了如何做到这一点。

High-Level Structure

每个文件可以包含一个或多个具有相应训练数据的keys。一个文件可以包含多个keys，但每个key在单个文件中只能出现一次。可用的keys是：

• version
• nlu
• stories
• rules

您应该在所有YAML训练数据文件中指定版本keys。如果您没有在训练数据文件中指定版本keys，Rasa将假定您使用的是您所安装的Rasa开源版本支持的最新训练数据格式规范。 Rasa开源版本可能大于您在计算机上安装的版本的训练数据文件。目前，Rasa 3的最新训练数据格式规范 是3.0。

示例：

version: "3.0"

nlu:
- intent: greet
  examples: |
    - Hey
    - Hi
    - hey there [Sara](name)

- intent: faq/language
  examples: |
    - What language do you speak?
    - Do you only handle english?

stories:
- story: greet and faq
  steps:
  - intent: greet
  - action: utter_greet
  - intent: faq
  - action: utter_faq

rules:
- rule: Greet user
  steps:
  - intent: greet
  - action: utter_greet

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

要指定测试故事，您需要将它们放在单独的文件中：
tests/test_stories.yml

stories:
- story: greet and ask language
- steps:
  - user: |
      hey
    intent: greet
  - action: utter_greet
  - user: |
      what language do you speak
    intent: faq/language
  - action: utter_faq
1
2
3
4
5
6
7
8
9
10
11

测试故事使用与故事训练数据相同的格式，并且应该放在一个前缀为test_的单独文件中。

| 管道符号

如以上示例所示，用户和示例键后面跟着|（管道）符号。在YAML中，标识保留缩进的多行字符串。这有助于在训练示例中保留诸如“，”等特殊符号。

NLU Training Data

NLU训练数据由按意图分类的示例用户话语组成。训练示例还可以包括实体。实体是可以从用户消息中提取的结构化信息片段。您还可以向训练数据中添加额外的信息，如正则表达式和查找表，以帮助模型正确识别意图和实体。

NLU训练数据在nlu键里面定义。可在此键下添加的项目包括：

• 按用户意图分组的训练示例，例如，可选带注释的实体

nlu:
- intent: check_balance
  examples: |
    - What's my [credit](account) balance?
    - What's the balance on my [credit card account]{"entity":"account","value":"credit"}
1
2
3
4
5

• 同义词 Synonyms

nlu:
- synonym: credit
  examples: |
    - credit card account
    - credit account
1
2
3
4
5

• 正则表达式 Regular expressions

nlu:
- regex: account_number
  examples: |
    - \d{10,12}
1
2
3
4

• 查找表 Lookup Tables
  查找表是用于生成不区分大小写的正则表达式模式的单词列表。格式如下:

nlu:
- lookup: banks
  examples: |
    - JPMC
    - Bank of America
1
2
3
4
5

在训练数据中提供查找表时，该表的内容将合并到一个大型正则表达式中。此正则表达式用于检查每个训练示例，以查看它是否包含查找表中条目的匹配项。

查找表正则表达式的处理方式与在训练数据中直接指定的正则表达式相同，可以与regexFeatureizer或RegexEntityExtractor一起使用。查找表的名称受与正则表达式功能名称相同的约束。

Conversation Training Data

会话训练数据#

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

故事由以下部分组成：

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

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

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

故事#

故事由以下部分组成：

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

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

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

stories:
- story: Greet the user
  metadata:
    author: Somebody
    key: value
  steps:
  # list of steps
  - intent: greet
  - action: utter_greet
1
2
3
4
5
6
7
8
9

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

• User Messages 用户消息，由意图和实体表示。

• or statement, ，其下包含两条或多条用户消息。

• action。

• form 表格。

• slot_was_set 为这一事件设置了一个插槽。

• 一个检查点，将故事连接到另一个故事。

User Messages

所有用户消息都使用intent:key和可选的entities:key指定。

在编写故事时，您不必处理用户发送的消息的特定内容。相反，您可以利用NLU管道的输出，该管道使用意图和实体的组合来引用用户可以发送的具有相同含义的所有可能消息。

用户消息的格式如下：

stories:
- story: story with a slot
  steps:
  - intent: greet
  - slot_was_set:
    - name
  - action: utter_greet_user_by_name
1
2
3
4
5
6
7

例如，要表示“我想查询我的信用余额”这句话，其中信用是一个实体：
I want to check my credit balance

stories:
- story: story with entities
  steps:
  - intent: account_balance
    entities:
    - account_type: credit
  - action: action_credit_account_balance
1
2
3
4
5
6
7

在此处包含实体也很重要，因为策略学习基于意图和实体的组合预测下一个操作（但是，您可以使用“使用实体”属性更改此行为）。

Actions

bot执行的所有操作都使用action:键和action名称进行指定。在编写故事时，您将遇到两种类型的动作：

• Responses 从utter_开始，向用户发送特定消息。例如

stories:
- story: story with a response
  steps:
  - intent: greet
  - action: utter_greet
1
2
3
4
5

• Custom actions 从action_开头，运行任意代码并发送任意数量的消息（或不发送）。

stories:
- story: story with a custom action
  steps:
  - intent: feedback
  - action: action_store_feedback
1
2
3
4
5

Forms

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

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
1
2
3
4
5
6
7
8

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

表单可以被中断并保持活动状态；在这种情况下，中断应该发生在动作：步骤之后，然后是活动的循环：步骤。表单的中断可能如下所示：

stories:
- story: interrupted food
  steps:
    - intent: request_restaurant
    - action: restaurant_form
    - intent: chitchat
    - action: utter_chitchat
    - active_loop: restaurant_form
    - active_loop: null
    - action: utter_slots_values
1
2
3
4
5
6
7
8
9
10

Slots

插槽事件在slot_was_set:下指定，带有插槽名称和插槽值（可选）。

插槽充当机器人的内存。根据域中指定的插槽映射，插槽由默认操作action_extract_slots 插槽设置，或由自定义操作设置。它们由slot_was_set步骤中的故事引用。例如：

stories:
- story: story with a slot
  steps:
  - intent: celebrate_bot
  - slot_was_set:
    - feedback_value: positive
  - action: utter_yay
1
2
3
4
5
6
7

这意味着故事要求反馈值槽的当前值为正值，对话才能按指定继续。

是否需要包含插槽的值取决于插槽类型以及该值是否可以或应该影响对话。如果值不重要，例如文本插槽，则只能列出插槽的名称：

stories:
- story: story with a slot
  steps:
  - intent: greet
  - slot_was_set:
    - name
  - action: utter_greet_user_by_name
1
2
3
4
5
6
7

默认情况下，任何插槽的初始值均为null，您可以使用该值检查插槽是否未设置：

stories:
- story: French cuisine
  steps:
  - intent: inform
  - slot_was_set:
    - cuisine: null
1
2
3
4
5
6

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
1
2
3
4
5
6
7
8
9
10
11
12

例如，故事开头的检查点也可以以设置的插槽为条件

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
1
2
3
4
5
6
7
8
9
10

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

OR statement

OR 步骤是以相同方式处理多个意图或插槽事件的方法，而无需为每个意图编写单独的故事。例如，如果您要求用户确认某些内容，您可能希望以相同的方式对待确认和感谢意图。包含or步骤的故事将在训练时转换为多个单独的故事。例如，以下故事将在训练时转换为两个故事：

stories:
- story: story with OR
  steps:
  - intent: signup_newsletter
  - action: utter_ask_confirm
  - or:
    - intent: affirm
    - intent: thanks
  - action: action_signup_newsletter
1
2
3
4
5
6
7
8
9

也可以将or语句与插槽事件一起使用。下面的意思是，故事需要设置名称槽的当前值，该值为joe或bob。此故事将在训练时转换为两个故事。

stories:
- story:
  steps:
  - intent: greet
  - action: utter_greet
  - intent: tell_name
  - or:
    - slot_was_set:
        - name: joe
    - slot_was_set:
        - name: bob
  # ... next actions
1
2
3
4
5
6
7
8
9
10
11
12

就像检查点或语句一样，它们也很有用，但如果您使用了大量检查点或语句，则最好重新构造您的域和/或意图。
不要过度使用

过度使用这些功能（检查点和OR语句）会降低训练速度。

Rules

规则列在rules键下，看起来类似于故事。规则还有一个steps 键，其中包含与故事相同的步骤列表。规则还可以包含对话和条件键。这些用于指定应用规则的条件。

带有条件的规则如下所示：

rules:
- rule: Only say `hey` when the user provided a name
  condition:
  - slot_was_set:
    - user_provided_name: true
  steps:
  - intent: greet
  - action: utter_greet
1
2
3
4
5
6
7
8

Test Stories

测试故事检查消息是否正确分类以及动作预测。



测试故事使用与故事相同的格式，除了用户消息步骤可以包括用户来指定用户消息的实际文本和实体注释。下面是一个测试故事的示例：
1
2
3
4
5

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
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

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

rasa test
1

如果你想了解更多关于测试的知识，可以直接去测试你的助手。

End-to-end Training

新版本2.2

端到端训练是一种实验性的特征。我们引入实验性功能以获得社区的反馈，因此我们鼓励您尝试！但是，将来可能会更改或删除该功能。如果您有反馈（正面或负面），请在Rasa论坛上与我们分享。

通过端到端训练，您不必处理NLU管道提取的消息的特定意图。相反，您可以使用用户密钥将用户消息的文本直接放在故事中。

这些端到端用户消息的格式如下：

stories:
- story: user message structure
  steps:
    - user: the actual text of the user message
    - action: action_name
1
2
3
4
5

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

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

类似地，您可以使用bot键，后跟您希望bot说出的文本，将bot话语直接放在故事中。

只有机器人说话的故事可能是这样的：

stories:
- story: story with an end-to-end response
  steps:
  - intent: greet
    entities:
    - name: Ivan
  - bot: Hello, a person with a name!
1
2
3
4
5
6
7

您还可以有一个混合的端到端故事：

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
1
2
3
4
5
6
7
8
9
10
11
12
13
14

Rasa端到端训练与标准Rasa方法完全集成。这意味着您可以使用由操作或意图定义的某些步骤和由用户消息或机器人响应直接定义的其他步骤来创建混合故事。