本文介绍进入Rasa助手的不同类型的训练数据,以及训练数据的结构。
Rasa开源使用YAML
作为一种统一的、可扩展的方式来管理所有训练数据,包括NLU数据、故事和规则。
您可以将训练数据拆分到任意数量的YAML
文件上,每个文件都可以包含NLU数据、故事和规则的任意组合。训练数据解析器使用top level keys
确定培训数据类型。
domain
使用与培训数据相同的YAML
格式,也可以跨多个文件拆分或合并在一个文件中。domain
包括响应(responses
)和表单(forms
)的定义。有关如何格式化domain
文件的信息,请参阅域文档。
传统格式
开源Rasa1.x数据格式?它们现在已被弃用,但您仍然可以找到有关markdown格式的NLU数据和markdown格式的故事数据的文档。
每个文件可以包含一个或多个具有相应训练数据的键(keys
)。一个文件可以包含多个键(keys
),但每个键在一个文件中只能出现一次。可用键(keys
)包括:
version
nlu
stories
rules
您应该在所有YAML
训练数据文件中指定版本键(keys
)。如果未在训练数据文件中指定版本键(keys
),Rasa将假定您使用的是已安装的Rasa开源版本支持的最新训练数据格式规范。将跳过Rasa开源版本高于您在计算机上安装的版本的训练数据文件。目前,RASA2.x最新的训练数据格式规范是2.0。
下面是一个简短的示例,它将所有训练数据保存在一个文件中:
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训练数据由按意图(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
)在训练示例中用实体的名称进行注释。除了实体名称之外,还可以使用同义词(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
)的用途,请参阅实体角色和组部分。
同义词通过将提取的实体映射到提取的文本以外的值来规范化训练数据。可以使用以下格式定义同义词:
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训练数据。
您可以使用正则表达式来改进使用regexfeaturer
和RegexEntityExtractor
组件的意图分类和实体提取。
定义正则表达式的格式如下:
nlu:
- regex: account_number
examples: |
- \d{
10,12}
这里的帐号(account_number
)是正则表达式的名称。当用作regexfeatureizer
的功能时,正则表达式的名称并不重要。使用RegexEntityExtractor
时,正则表达式的名称应与要提取的实体的名称匹配。
阅读NLU训练数据,了解更多关于何时以及如何对每个组件使用正则表达式的信息。
查找表是用于生成不区分大小写的正则表达式模式的单词列表。格式如下:
nlu:
- lookup: banks
examples: |
- JPMC
- Bank of America
在训练数据中提供查找表时,该表的内容将合并到一个大型正则表达式中。这个正则表达式用于检查每个训练示例,以查看它是否包含查找表中条目的匹配项。
查找表regexes
的处理方式与训练数据中直接指定的正则表达式相同,并且可以与RegexFeaturer
或RegexEntityExtractor
一起使用。查找表的名称应与正则表达式功能名称相同。
阅读NLU训练数据,了解有关使用查找表的更多信息。
故事(Stories
)和规则(rules
)都是用户和会话助手之间对话的表示。它们被用来训练对话管理模式。故事(Stories
)被用来训练机器学习模型来识别会话中的模式,并推广到看不见的会话路径。规则(rules
)描述了应该始终遵循相同路径并用于训练规则策略(RulePolicy
)的小对话片段。
故事(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
)表示。action
)。form
)。checkpoint
,把故事和另一个故事联系起来。所有用户消息都是以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
属性更改此行为)。
机器人(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
)是一种特定类型的自定义操作,它包含在一组所需插槽上循环并向用户请求此信息的逻辑。您可以在域(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: