目录
故事(Stories
)是一种训练数据,用于训练助手的对话管理模型。故事(Stories
)可以用来训练模型,这些模型可以推广到未发现的对话路径。
格式(Format)
故事(Stories
)是用户和人工智能助理之间对话的一种表现形式,转换成一种特定的格式,其中用户输入表示为意图(必要时表示为实体),而助理的响应和行为表示为行为名称。
以下是Rasa故事格式的对话示例:
stories:
- story: collect restaurant booking info # story的名字-只是为了调试
steps:
- intent: greet # 没有实体的用户消息
- action: utter_ask_howcanhelp
- intent: inform # 带有实体的用户消息
entities:
- location: "rome"
- price: "cheap"
- action: utter_on_it # bot应该执行的行为
- action: utter_ask_cuisine
- intent: inform
entities:
- cuisine: "spanish"
- action: utter_ask_num_people
User Messages
在编写故事时,您不必处理用户发送的消息的具体内容。相反,您可以利用NLU管道的输出表示相同的内容,因为它允许您仅使用意图和实体的组合来引用用户可以发送的所有可能的消息。
在这里包含实体也很重要,因为策略(policies
)学习是基于意图和实体的组合来预测下一个操作(但是,您可以使用use_entities
属性更改此行为)。
Actions
bot执行的所有行为(包括响应)都列在stories
中的action
键下。
您可以将来自domain
的响应作为一个操作,方法是将其列为故事中的一个响应。类似地,您可以通过从domain
中的action
列表中包含自定义操作的名称来指示故事应该调用自定义操作。
Events
在训练期间,开源Rasa不调用action server
。这意味着助手的对话管理模型不知道自定义操作将返回哪些事件。
因此,诸如设置槽(slot
)或激活/停用form
之类的事件必须作为故事的一部分显式地写出。有关更多信息,请参阅事件文档。
Slot Events
Slot events
写在故事的slot_was_set
下面。如果此插槽是在自定义操作中设置的,请在自定义操作调用之后立即添加slot_was_set
事件。如果自定义操作将slot
值重置为None
,则相应的事件如下所示:
stories:
- story: set slot to none
steps:
# ... other story steps
- action: my_custom_action
- slot_was_set:
- my_slot: null
Form Events
在故事(Stories
)处理Form
时,有三种事件需要牢记在心。
form action event
(例如,- action: restaurant_form
)在第一次启动form
时开始使用,并且在form
已处于活动状态期间重启form
操作时也使用。form activation event
(例如,- active_loop: restaurant_form
)就在第一个form action event
之后使用。form deactivation event
(例如,- active_loop: null
),用于停用form
。
写Form Stories
为了避开忘记添加事件的陷阱,建议使用交互式学习来编写这些故事。
Checkpoints and OR statements
如果使用Checkpoints
和OR
语句,请谨慎使用。通常有更好的方法来实现您想要的,比如,使用Rules或ResponseSelector。
Checkpoints
您可以使用检查点(Checkpoints
)来模块化和简化培训数据。检查点可能有用,但不要过度使用它们。使用大量的检查点可以很快让你的例子故事变得难以理解,并且会减慢训练的速度。
以下是包含检查点(Checkpoints
)的故事示例:
stories:
- story: beginning of flow
steps:
- intent: greet
- action: action_ask_user_question
- checkpoint: check_asked_question
- story: handle user affirm
steps:
- checkpoint: check_asked_question
- intent: affirm
- action: action_handle_affirmation
- checkpoint: check_flow_finished
- story: handle user deny
steps:
- checkpoint: check_asked_question
- intent: deny
- action: action_handle_denial
- checkpoint: check_flow_finished
- story: finish flow
steps:
- checkpoint: check_flow_finished
- intent: goodbye
- action: utter_goodbye
注意
与常规故事不同,检查点并不局限于从用户输入开始。只要检查点插入到主故事中的正确位置,第一个事件就可以是自定义操作或响应。
Or Statements
写短篇故事(stories
)的另一种方法,或者用同样的方法处理多个意图,就是使用or
语句。例如,如果您要求用户确认某个内容,并且您希望以相同的方式处理affirm
和thankyou
意图。以下故事将在训练时转换为两个故事:
stories:
- story:
steps:
# ... previous steps
- action: utter_ask_confirm
- or:
- intent: affirm
- intent: thankyou
- action: action_handle_affirmation
or
语句可能很有用,但是如果您使用了很多,那么最好重新构造domain
和/或意图(intents
)。过度使用会减缓训练速度。
Test Conversation Format
测试会话格式是一种将NLU数据和故事合并到一个文件中进行评估的格式。在测试助手中阅读有关此格式的更多信息。
仅测试
此格式仅用于测试,不能用于训练。
End-to-end Training
通过端到端的训练,您不必处理由NLU管道提取的消息的特定意图,也不必处理domain
文件中单独的utter_
响应。相反,您可以将用户消息和/或bot响应的文本直接包含在您的故事中。有关如何编写端到端故事的详细说明,请参见训练数据格式。
您可以将端到端格式的训练数据与指定了intents
和actions
的带标签的训练数据混合:故事可以包含由intents/actions
定义的某些步骤,以及由用户或bot语句直接定义的其他步骤。
我们称之为端到端训练,因为策略可以使用和预测实际文本。对于端到端用户输入,将忽略由NLU管道分类的意图和提取的实体。
只有Rule Policy
和TED Policy
允许端到端训练。
RulePolicy
在预测期间使用简单的字符串匹配。也就是说,基于用户文本的规则只有在规则中的用户文本字符串和预测期间的输入相同时才会匹配。TEDPolicy
通过附加的神经网络传递用户文本,以创建文本的隐藏表示。为了获得强大的性能,您需要提供足够的训练故事,以便为任何端到端对话转换捕获各种用户文本。
Rasa策略为了训练下一句话的选择。与创建utter_
响应的唯一区别是TEDPolicy
如何将“bot”语句特性化。对于utter_
操作,TEDPolicy
只看到操作的名称,而如果使用bot
键提供实际的语句,TEDPolicy
将根据NLU配置将其特征化为文本输入。如果在稍有不同的情况下出现类似的话语,这会有所帮助。然而,这也会让事情变得更难学,因为不同的话语有相似的文本,这使得TEDPolicy
更容易混淆这些话语。
端到端训练在TEDPolicy
中需要更多的参数。因此,训练一个端到端的模型可能需要大量的计算资源,这取决于你的故事中有多少个端到端的转折点。