RaSa2.5.x训练数据之一：训练数据格式(Training Data Format)

本文介绍进入Rasa助手的不同类型的训练数据，以及训练数据的结构。

概述(Overview)

Rasa开源使用YAML作为一种统一的、可扩展的方式来管理所有训练数据，包括NLU数据、故事和规则。
您可以将训练数据拆分到任意数量的YAML文件上，每个文件都可以包含NLU数据、故事和规则的任意组合。训练数据解析器使用top level keys确定培训数据类型。
domain使用与培训数据相同的YAML格式，也可以跨多个文件拆分或合并在一个文件中。domain包括响应(responses)和表单(forms)的定义。有关如何格式化domain文件的信息，请参阅域文档。

传统格式
开源Rasa1.x数据格式？它们现在已被弃用，但您仍然可以找到有关markdown格式的NLU数据和markdown格式的故事数据的文档。

高级结构(High-Level Structure)

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

• version
• nlu
• stories
• rules

您应该在所有YAML训练数据文件中指定版本键(keys)。如果未在训练数据文件中指定版本键(keys)，Rasa将假定您使用的是已安装的Rasa开源版本支持的最新训练数据格式规范。将跳过Rasa开源版本高于您在计算机上安装的版本的训练数据文件。目前，RASA2.x最新的训练数据格式规范是2.0。

例子(Example)

下面是一个简短的示例，它将所有训练数据保存在一个文件中：

version: "2.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

要指定测试故事，需要将它们放入一个单独的文件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

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

| 符号
如以上示例所示，user和examples键后跟|（pipe）符号。在YAML中|表示保留缩进的多行字符串。这有助于在训练示例中保留诸如“，”等特殊符号。

NLU训练数据(NLU Training Data)

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

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

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

• 同义词(Synonyms)

nlu:
- synonym: credit
  examples: |
    - credit card account
    - credit account

• 正则表达式(Regular expressions)

nlu:
- regex: account_number
  examples: |
    - \d{
     10,12}

• 查阅表格(Lookup tables)

nlu:
- lookup: banks
  examples: |
    - JPMC
    - Comerica
    - Bank of America

训练实例(Training Examples)

训练示例按意图(intent)分组，并在examples键下列出。通常，每行列出一个示例，如下所示：

nlu:
- intent: greet
  examples: |
    - hey
    - hi
    - whats up

但是，如果您有自定义NLU组件并且示例需要元数据(metadata)，也可以使用扩展格式：

nlu:
- intent: greet
  examples:
  - text: |
      hi
    metadata:
      sentiment: neutral
  - text: |
      hey there!

元数据(metadata)键可以包含任意key-value 数据，这些数据绑定到一个示例并可由NLU管道中的组件访问。在上面的示例中，情绪元数据可以由管道中的自定义组件用于情绪分析。
您还可以在意图(intent)级别指定此元数据(metadata)：

nlu:
- intent: greet
  metadata:
    sentiment: neutral
  examples:
  - text: |
      hi
  - text: |
      hey there!

在这种情况下，元数据(metadata)键(key)的内容被传递给每个意图示例。
如果要指定检索意图(retrieval intents)，则NLU示例如下所示：

nlu:
- intent: chitchat/ask_name
  examples: |
    - What is your name?
    - May I know your name?
    - What do people call you?
    - Do you have a name for yourself?

- intent: chitchat/ask_weather
  examples: |
    - What's the weather like today?
    - Does it look sunny outside today?
    - Oh, do you mind checking the weather for me please?
    - I like sunny days in Berlin.

所有检索意图都添加了后缀，该后缀标识助手的特定响应键。在上面的示例中，ask_name和ask_weather是后缀。由/分隔符将后缀与检索意图名称分隔。

/的特殊含义
如以上示例所示，/符号被保留为分隔符，用于将检索意图与其关联的响应键分开。确保不要以你的意图的名义使用它。

实体(Entities)

实体(entities)是可以从用户消息中提取的结构化信息片段。
实体(entities)在训练示例中用实体的名称进行注释。除了实体名称之外，还可以使用同义词(synonyms)、角色(roles)或组(groups)来注释实体。
在训练示例中，实体注释如下所示：

nlu:
- intent: check_balance
  examples: |
    - how much do I have on my [savings]("account") account
    - how much money is in my [checking]{
     "entity": "account"} account
    - What's the balance on my [credit card account]{
     "entity":"account","value":"credit"}

注释实体的完整可能语法为：

[<entity-text>]{
     "entity": "", "role": "", "group": "", "value": ""}

在此表示法中，关键字role、group和value是可选的。value字段引用同义词。要了解标签角色(role)和组(group)的用途，请参阅实体角色和组部分。

同义词(Synonyms)

同义词通过将提取的实体映射到提取的文本以外的值来规范化训练数据。可以使用以下格式定义同义词：

nlu:
- synonym: credit
  examples: |
    - credit card account
    - credit account

还可以通过指定实体的值在训练示例中在线定义同义词：

nlu:
- intent: check_balance
  examples: |
    - how much do I have on my [credit card account]{
     "entity": "account", "value": "credit"}
    - how much do I owe on my [credit account]{
     "entity": "account", "value": "credit"}

有关同义词的更多信息，请阅读NLU训练数据。

正则表达式(Regular Expressions)

您可以使用正则表达式来改进使用regexfeaturer和RegexEntityExtractor组件的意图分类和实体提取。
定义正则表达式的格式如下：

nlu:
- regex: account_number
  examples: |
    - \d{
     10,12}

这里的帐号(account_number)是正则表达式的名称。当用作regexfeatureizer的功能时，正则表达式的名称并不重要。使用RegexEntityExtractor时，正则表达式的名称应与要提取的实体的名称匹配。

阅读NLU训练数据，了解更多关于何时以及如何对每个组件使用正则表达式的信息。

查找表(Lookup Tables)

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

nlu:
- lookup: banks
  examples: |
    - JPMC
    - Bank of America

在训练数据中提供查找表时，该表的内容将合并到一个大型正则表达式中。这个正则表达式用于检查每个训练示例，以查看它是否包含查找表中条目的匹配项。
查找表regexes的处理方式与训练数据中直接指定的正则表达式相同，并且可以与RegexFeaturer或RegexEntityExtractor一起使用。查找表的名称应与正则表达式功能名称相同。
阅读NLU训练数据，了解有关使用查找表的更多信息。

会话训练数据(Conversation Training Data)

故事(Stories)和规则(rules)都是用户和会话助手之间对话的表示。它们被用来训练对话管理模式。故事(Stories)被用来训练机器学习模型来识别会话中的模式，并推广到看不见的会话路径。规则(rules)描述了应该始终遵循相同路径并用于训练规则策略(RulePolicy)的小对话片段。

故事(Stories)

故事(Stories)包括：

• story：故事的名字。名称任意，不用于训练；你可以把它作为故事的可读参考。
• metadata：元数据。任意和可选的，不用于训练，你可以用它来存储有关的信息，如故事的作者。
• steps：步骤列表。组成故事的用户消息和操作。

例如：

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

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

• 用户消息，由意图(intent)和实体(entities)表示。
• OR语句，其下包含两个或多个用户消息。
• 机器人的行为(action)。
• 表单(form)。
• 为事件设置了一个插槽。
• checkpoint，把故事和另一个故事联系起来。

用户消息(User Messages)

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

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

例如，要表示句子I want to check my credit balance，其中credit是一个实体：

stories:
- story: story with entities
  steps:
  - intent: account_balance
    entities:
    - account_type: credit
  - action: action_credit_account_balance

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

行为(Actions)

机器人(bot)执行的所有操作行为都用action键指定，后跟操作的名称。在写故事时，你会遇到两种类型的行为：

• 响应(Responses)：由utter_开头，向用户发送特定消息。例如

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

• 自定义操作(Custom actions)：由action_开头，运行任意代码并发送任意数量的消息（或不发送任何消息）。

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

表单(Forms)

表单(Forms)是一种特定类型的自定义操作，它包含在一组所需插槽上循环并向用户请求此信息的逻辑。您可以在域(domain)的forms部分中定义表单(forms)。定义之后，您应该为forms指定happy path作为规则。你应该在故事中加入forms的中断或其他unhappy paths，这样模型就可以推广到看不见的对话序列。作为故事中的一个步骤，表单采用以下格式：

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

action步骤激活forms并开始在所需的槽(slots)上循环。active_loop: restaurant_form步骤表示当前有一个活动forms。与slot_was_set步骤非常类似，form步骤不会将表单设置为活动状态，而是指示它应该已经被激活。active_loop: null步骤表示在执行后续步骤之前，不应激活任何form。
form可以中断并保持活动状态；在这种情况下，中断应该在action:

步骤之后，然后是active_loop:步骤。form的中断(interruption)可能如下所示：

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

槽(Slots)

插槽事件(slot event)在键slot_was_set下指定：具有插槽名称和可选的插槽值。
插槽充当机器人的内存。插槽由实体或自定义操作(custom actions)设置，并由slot_was_set步骤中的故事引用。例如：

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

这意味着故事要求feedback_value槽的当前值为positive，会话才能按指定继续。
是否需要包含slot的值取决于 slot类型 以及该值是否可以或应该影响对话。如果值无关紧要，请仅列出插槽的名称：

stories:
- story: story with a slot
  steps:
  - intent: greet
  - slot_was_set:
    - name
  - action: utter_greet_user_by_name

槽的工作原理
故事(Stories)不会给你设置槽(slot)。槽必须在slot_was_set步骤之前由实体(entity)或自定义操作(custom action)设置。

(Checkpoints)

在故事的开头或结尾使用checkpoint键指定Checkpoints。
Checkpoints是连接故事的方法。它们可以是故事的第一步，也可以是最后一步。如果它们是一个故事中的最后一步，那么在训练模型时，该故事将连接到以同名checkpoint开始的另一个故事。下面是一个以一个checkpoint结束的故事和一个以同一个checkpoint开始的故事的示例：

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

故事开头的checkpoint也可以以设置的插槽为条件，例如：

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

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

OR语句(OR statement)

or步骤是以相同的方式处理多个意图(intents)的方法，而不是为每个意图(intents)编写单独的故事。例如，如果您要求用户确认某事，您可能希望以相同的方式对待“确认(affirm)”和“感谢(thankyou)”意图。带有or步骤的故事将在训练时转换为多个单独的故事。例如，以下故事将在训练时转换为两个故事：

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

就像checkpoints一样，or语句可能很有用。但是如果您使用了很多checkpoints和or语句，则最好重新构造域(domain)和意图(intents)。

不要过度使用
过度使用这些特性（checkpoints和or语句）会减慢训练速度。

规则(Rules)

规则(Rules)列在规则(rules)键下，看起来与故事类似。规则还有一个steps键，其中包含与故事相同的步骤列表。规则还可以包含conversation_started(会话)和conditions(条件)键。这些用于指定规则应适用的条件。
有条件的规则如下所示：

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

有关编写规则的详细信息，请参阅规则。

故事测试集(Test Stories)

测试故事(Test Stories)检查消息的分类是否正确以及行为预测(action predictions)。
测试故事(Test Stories)使用与故事(stories)相同的格式，只是用户消息步骤可以包括user键来指定用户消息的实际文本和实体注释。下面是一个测试故事的示例：

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

端到端训练(End-to-end Training)

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

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

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

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

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

类似地，您可以将bot语句直接放在故事中，方法是使用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!

你也可以有一个混合的端到端的故事：

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方法集成。这意味着您可以将故事与一些由操作(actions)或意图(intents)定义的步骤混合，以及由用户消息或bot响应直接定义的其他步骤。

参考

1. 官方文档