一、前言

一般来说，机器人可以跟人对话，机器人说什么是最难的，顶多是人工编写几种规则和模版来回复即可。但是要让机器人理解人的意图，确实非常难的事情。因为语言具有多样性，多义词，一语双关，长短句等，尤其是中文的博大精深。因此机器人需要特别多的数据，也就是模拟人的问法，让机器人理解这些意图特征，理解人的问法，以及人是如何回复别人的问题，这部分内容在Rasa里面称为训练数据。

Rasa使用YAML格式作为一种统一和可扩展的方式来管理所有的训练数据，包括NLU数据、stories数据和rules规则。可以将训练数据拆分为任意数量的YAML文件，每个文件可以包含NLU数据、故事和规则的任意组合。训练数据解析器使用最上层的key确定训练数据类型。

开发者还在寻找 Markdown 数据格式？它在 Rasa 3.0 中被删除，但仍然可以找到markdown NLU data和markdown stories的文档。如果您仍然有 Markdown 格式的训练数据，那么推荐的方法是使用 Rasa 2.x 将您的数据从 Markdown 转换为 YAML。迁移指南解释了如何执行此操作。

1.1 High-Level Structure

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

version
nlu
stories
rules

开发者应该在所有 YAML 训练数据文件中指定版本key。如果开发者未在训练数据文件中指定版本key，Rasa 将假定开发者使用的是已安装的 Rasa 版本支持的最新训练数据格式。Rasa 版本高于开发者机器上安装的版本的训练数据文件将被跳过。目前，Rasa 3.x 的最新训练数据格式规范是 3.1。

1.2 example

这里拿一个样例来说明，nlu、stroies和rules数据都在一个文件中来展现：

version: "3.1"nlu:
- intent: greetexamples: |- Hey- Hi- hey there [Sara](name)- intent: faq/languageexamples: |- What language do you speak?- Do you only handle english?stories:
- story: greet and faqsteps:- intent: greet- action: utter_greet- intent: faq- action: utter_faqrules:
- rule: Greet usersteps:- intent: greet- action: utter_greet

要测试指定stories，需要将它们放入一个单独的文件中，并使用前缀test_：

stories:
- story: greet and ask language
- steps:- user: |heyintent: greet- action: utter_greet- user: |what language do you speakintent: faq/language- action: utter_faq

二、NLU 训练数据

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

按用户意图分组的培训示例

例如带上标注的实体，但是标注信息是可选。

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

同义词

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

正则表达式

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

查表

nlu:
- lookup: banksexamples: |- JPMC- Comerica- Bank of America

2.1 Training Examples（训练数据样例）

train examples按意图分组并列在 examples字段下。通常，开发者会在每一行列出一个示例，如下所示：

nlu:
- intent: greetexamples: |- hey- hi- whats up

但是，如果开发者有自定义 NLU 组件并且需要示例的元数据，也可以使用扩展格式：

nlu:
- intent: greetexamples:- text: |himetadata:sentiment: neutral- text: |hey there!

metadata字段可以包含任意键值数据，这些数据与示例相关联并且可由 NLU 中的组件访问。在上面的示例中，情感元数据可以被管道中的自定义组件用于情感分析。

开发者还可以在意图级别指定此元数据：

nlu:
- intent: greetmetadata:sentiment: neutralexamples:- text: |hi- text: |hey there!

在这案例里，metadata 字段所包含的内容会应用到每一个intent样例中。

如果开发者需要明确检索意图，你的NLU样例可能会跟下面一样：

nlu:
- intent: chitchat/ask_nameexamples: |- What is your name?- May I know your name?- What do people call you?- Do you have a name for yourself?- intent: chitchat/ask_weatherexamples: |- 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.

所有检索意图都添加了一个后缀，用于标识Bot的特定响应字段。在上面的例子中， ask_name 和 ask_weather 是后缀。后缀与检索意图名称由 / 分隔符分隔。

2.2 Entities（实体）

Entities是可以从用户消息中提取到结构化的信息，在训练数据中使用实体名称进行标注。除了实体名称之外，开发者还可以使用同义词、角色或组来标注实体。

在训练数据中，标注的实体样例如下所示：

nlu:
- intent: check_balanceexamples: |- 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": "<entity name>", "role": "<role name>", "group": "<group name>", "value": "<entity synonym>"}

role, group, and value关键词是在标注时是可选的。value 字段的内容可以参考 synonyms。如果你希望理解role 和 group 字段的内容，可以参考entity roles and groups.

2.3 Synonyms（同义词）

同义词将提取的实体映射到提取的文本之外的值。开发者可以使用以下格式定义同义词：

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

开发者还可以直接在训练数据中定义同义词，通过指定value字段来设置同义词：

nlu:
- intent: check_balanceexamples: |- 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 Training Data page.

2.4 Regular Expressions（正则表达式）

开发者可以用正则表达式来提高意图分类和实体抽取的效果，正则表达式主要是用 RegexFeaturizer 和 RegexEntityExtractor 模块。

定义正则表达式的格式如下：

 nlu:
- regex: account_numberexamples: |- \d{10,12}
- intent: informexamples: |- my account number is [1234567891](account_number)- This is my account number [1234567891](account_number)

account_number是正则表达式的名称。当用作特征RegexFeaturizer时，正则表达式的名称无关紧要。使用RegexEntityExtractor时，正则表达式的名称应与Bot要提取的实体名称对应上。

如果需要了解更多关于正则表达式的信息，可以去这里 NLU Training Data page.

2.5 Lookup Tables（查找表）

查找表用于生成不区分大小写的正则表达式列表。它们可以与使用正则表达式的方式相同，与pipeline中的regexfeatureizer和RegexEntityExtractor组件结合使用。可以使用查找表来帮助提取具有已知可能值集的实体。保持开发者的查找表尽可能具体。例如，要提取国家名称，可以添加世界上所有国家的查找表。其实这个地方就是添加词库的功能。

nlu:
- lookup: banksexamples: |- JPMC- Comerica- Bank of America

三、Conversation Training Data（对话数据）

stories和 rules都是用户和对话助手之间的对话流程表示，主要是用于训练对话管理模型。stories用于训练机器学习模型来识别对话中的模式并推广到看不见的对话路径。 rules描述了bot需要始终遵循相同路径的原则以及训练 RulePolicy规则策略。

3.1 Stories（故事）

stories通常由以下几个部分组成：

story: 故事的名称。该名称是任意的，不用于训练；开发者可以将其用作故事的可读参考，方便统计和说明。
metadata: 任意且可选，不用于训练，您可以使用它来存储有关故事的相关信息，例如作者。
steps列表: 组成故事的用户消息和操作。

样例如下：

stories:
- story: Greet the usermetadata:author: Somebodykey: valuesteps:# list of steps- intent: greet- action: utter_greet

每一个step可以是以下之一构成：

用户消息，主要是由意图和实体组成。
语句，在其下包含两个或多个用户消息。
机器人动作。
表单。
槽位事件。
checkpoint（检查点），它将故事与另一个故事联系起来。

User Messages

所有用户消息都可以用 intent 字段和 entities 字段来指定，这个字段是可选的。

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

用户消息遵循的格式如下：

stories:
- story: user message structuresteps:- intent: intent_name  # Requiredentities:  # Optional- entity_name: entity_value- action: action_name

在样例“I want to check my credit balance”中，“credit”就是一个entities。训练数据中包含的实体也很重要，因为policy会根据意图和实体的组合来学习预测下一个动作（但是，开发者也可以使用use_entities属性更改此行为）。

Actions

Bot执行的所有动作都使用action字段来指定，后面跟动作名称。在编写故事时，一般会有两种类型的操作：

1.响应。由"utter_"开始，并且返回的是具体的消息。例如：

stories:
- story: story with a responsesteps:- intent: greet- action: utter_greet

2.自定义动作。由“action_”开头，运行任意代码并发送任意数量的消息（或不发送）。例如：

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

Forms

Forms是一种特定类型的自定义动作，它包含循环遍历一组必需的槽位以及向用户询问此信息的逻辑。开发者在Domain中来定义一个表单。Forms一旦定义，开发者应该作为规则指定表单的路径。开发者应该在故事中包括形式中断或其他“不确定的路径”，以便模型可以预测看不见的对话序列。表单作为动作中的一个步骤，通常采用以下格式：

stories:
- story: story with a formsteps:- 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步骤激活表单并开始遍历所需的槽位。 active_loop: restaurant_form 步骤表示当前有一个action表单。与 slot_was_set 步骤非常相似，表单步骤不会将表单设置为活动状态，而是指示它应该已经被激活。同样，active_loop: null 步骤表示在执行后续步骤之前不应激活任何表单。

表单可以被中断并保持活动状态；在这种情况下，中断应该发生在 action: <form to activate> 步骤之后，然后是 active_loop: <active form> 步骤。表格的中断可能如下所示：

stories:
- story: interrupted foodsteps:- intent: request_restaurant- action: restaurant_form- intent: chitchat- action: utter_chitchat- active_loop: restaurant_form- active_loop: null- action: utter_slots_values

Slots

槽位事件在 slot_was_set 字段下指定：带有槽位名称和可选的槽位值。槽位充当机器人的内存，根据domain中指定的槽位映射，由默认 action_extract_slots 字段设置，或由自定义action设置。它们在 slot_was_set 步骤中被故事引用。例如：

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

这意味着stories要求 feedback_value 的当前值为positive，以便对话按指定继续进行。

是否需要包含槽位的值取决于插槽类型以及该值是否可以或应该影响对话。如果该值无关紧要，例如文本插槽，您可以仅列出插槽的名称：

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

Checkpoints

检查点由 checkpoint 字段指定，在故事的开头或结尾。

检查点是将故事连接在一起的方法。它们可以是故事的第一步或最后一步。 如果它们是故事中的最后一步，那么在训练模型时，该故事将与以同名检查点开始的其他故事相关联。这是一个以检查点结尾的故事示例，以及以相同检查点开始的故事示例：

stories:
- story: story_with_a_checkpoint_1steps:- intent: greet- action: utter_greet- checkpoint: greet_checkpoint- story: story_with_a_checkpoint_2steps:- checkpoint: greet_checkpoint- intent: book_flight- action: action_book_flight

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

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

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

3.2 Rules（规则）

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

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

rules:
- rule: Only say `hey` when the user provided a namecondition:- slot_was_set:- user_provided_name: truesteps:- intent: greet- action: utter_greet

如果需要了解更多关于rules的信息，可以到这里Rules.

四、Test Stories（测试stories）

test stories检查用户消息是否被正确分类以及动作预测。test stories使用与故事相同的格式，除了用户消息步骤可以包括user指定用户消息的实际文本和标注实体。这是一个测试故事的例子

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

开发者可以通过执行以下命令来进行测试：

rasa test

如果还需了解更多关于测试的信息，可以到这里Testing Your Assistant.

五、End-to-end Training（端到端训练）

通过端到端训练，开发者必处理 NLU pipline提取的特定意图。相反，开发者可以使用user字段将用户消息的文本直接放在故事中。

这些端到端的用户消息遵循以下格式：

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

此外，开发者可以添加可被TED Policy 提取的实体标签。实体标签的语法与 NLU 训练数据中的相同。例如，以下故事包含用户话语 I can always go for sushi。通过使用 NLU 训练数据 [sushi](cuisine) 中的语法，开发者可以将寿司标记为 cuisine 类型的实体。

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

同样，开发者可以将机器人话语直接放在stories中，方法是使用bot字段，然后使用开发者希望机器人说出的文本。

只有bot字段的故事可能如下所示：

stories:
- story: story with an end-to-end responsesteps:- intent: greetentities:- name: Ivan- bot: Hello, a person with a name!

开发者也可以有一个混合的端到端的story：

stories:
- story: full end-to-end storysteps:- intent: greetentities:- 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 方法完全集成。这意味着开发者可以混合stories，其中一些步骤由操作或意图定义，而其他步骤由用户消息或机器人响应直接定义。

六、参考文献

Training Data Format

Introduction to Rasa Open Source & Rasa Pro

（十三）RASA 训练数据

章节四：RASA 训练数据介绍相关推荐

章节七：RASA NLU组件介绍--意图分类器和实体提取器
目录一.前言二.意图分类器 2.1 MitieIntentClassifier 2.2 LogisticRegressionClassifier 2.3 SklearnIntentClassifi ...
章节六：RASA NLU组件介绍--特征生成器
目录一.前言二.特征生成器 MitieFeaturizer SpacyFeaturizer ConveRTFeaturizer LanguageModelFeaturizer RegexFeatu ...
章节五：RASA NLU组件介绍--语言模型和分词器
这里写目录标题一.前言二.语言模型组件 1.MitieNLP 2.SpacyNLP 三.分词器 1.WhitespaceTokenizer 2.JiebaTokenizer 3.MitieTo ...
还在为图像训练数据少发愁吗？那是因为你还不会这几招
点击左上方蓝字关注我们如果要把深度学习开发过程中几个环节按重要程度排个序的话,相信准备训练数据肯定能排在前几位.要知道一个模型网络被编写出来后,也只是一坨代码而已,和智能基本不沾边,它只有通过学习大 ...
knockoutjs ajax分页,KnockoutJS 3.X API 第四章之数据控制流foreach绑定
foreach绑定 foreach绑定主要用于循环展示监控数组属性中的每一个元素,一般用于table标签中假设你有一个监控属性数组,每当您添加,删除或重新排序数组项时,绑定将有效地更新UI的DOM- ...
【深度学习】翻译：60分钟入门PyTorch（四）——训练一个分类器
前言原文翻译自:Deep Learning with PyTorch: A 60 Minute Blitz 翻译:林不清(https://www.zhihu.com/people/lu-guo-92 ...
#章节四：input()函数
章节四:input()函数目录章节四:input()函数 1. input()函数 1.1 input()函数的使用 1.2 input()函数结果的赋值 1.3 input()函数的数据类型 1 ...
神经网络如何训练数据,神经网络常用训练方法
gpu构架为什么更适合发展神经网络因为神经网络这种大范围多任务的简单运算来说,正好符合GPU这种多核架构,比如你CPU20核心,同时处理20个任务.但是神经网络可能有20000个任务(比喻). 但最 ...
训练数据不够怎么造？yolo5 最有用的trick 之数据增强详解
在深度学习领域,模型参数量往往数以百万计,因此要训练一个鲁棒的模型往往需要大量的数据,与此同时,我们还可以利用各种数据增强的手段来增加模型训练数据的多样性,令模型尽可能适应不同的场景,防止过拟合的发生 ...

章节四：RASA 训练数据介绍