Rasa教程系列-Core-1-Stories

Rasa Core 核心的对话引擎。先来介绍下训练数据的格式。Rasa stories 是一种用来训练Rasa的对话管理模型的数据形式。一个story 是用户和人工智能助手之间对话的表示，被转换为特定的格式，其中用户输入表示为相应的意图(和必要的实体)，而助手的响应表示为相应的action名称。Rasa Core对话系统的一个训练示例称为一个story。

注意：
可以将story分散到多个文件中，并指定包含该文件的文件夹路径。这些stories将被视为一个大文件的一部分。

1. 格式

一个Story示例如下：

## greet + location/price + cuisine + num people    <!-- name of the story - just for debugging -->
* greet
   - action_ask_howcanhelp
* inform{"location": "rome", "price": "cheap"}  <!-- user utterance, in format intent{entities} -->
   - action_on_it
   - action_ask_cuisine
* inform{"cuisine": "spanish"}
   - action_ask_numpeople        <!-- action that the bot should execute -->
* inform{"people": "six"}
   - action_ack_dosearch

1.1 Story的组成

• story以两个##作为起始，如##story_03248462开始。可以将story命名为任何自己喜欢的名字，但是为它们提供描述性的名称对于调试非常有用!
• story以新行作为结尾，新的story仍然以##作为起始
• user发出的信息是以*起始的行，意图形式{"entity1": "value", "entity2": "value"}。
• 机器人执行的actions以-作为起始，随着跟随的是action的名字
• 执行action之后会立即返回events。比如当一个action返回SlotSet event，那么可以写成slot{"slot_name": "value"}

用户信息

当写stories时，没有必要处理用户发消息中特殊的内容。而是利用NLU管道的输出，它允许你使用意图和实体的组合来将用户可能发送的消息映射到相同的内容。这里引入实体也是很重要的，因为用来预测下一个行为的策略是基于意图和实体的组合。（可以使用use_entities属性改变这个设定）。

动作 Actions

撰写stories时，会有两种类型的actions：utterances 和 自定义 actions。utterances 是机器人可以回应的硬编码信息。而自定义 actions 涉及正在执行的自定义代码。

机器人执行的所有action(包括 utterances 和自定义actions)都是以-开头的行，后面跟着action的名称。所有的utterances都必须以前缀utter_开头，并且必须匹配域中定义的模板的名称。

对于自定义 actions，action 名称是从自定义actions类中name方法返回的字符串。虽然对自定义 actions 的命名没有限制(与utterances不同)，但是这里的最佳实践是在名称前面加上action_。

事件Events

Events比如设置插槽或激活/停用表单等必须作为story的一部分显式地写出来。当自定义 Actions 已经是story的一部分时，必须单独包含自定义Actions返回的事件可能看起来有些多余。然而，由于Rasa在训练中不能确定这一事实，所以这一步是必要的。更多关于events的内容可以阅读这里

Slot Events

Slot events写为如下方式：- slot{"slot_name": "value"}。如果此槽设置在自定义Actions中，则它将被写入自定义Actions事件之后的行中。如果自定义Actions将槽值重置为None，那么相应的事件将是-slot{“slot_name”:null}

Form Events

在处理stories时，需要记住三种事件：

• 表单动作事件(form action event)，比如- restaurant_form。这类事件在第一次出现一个表单之前被使用，并且当表单已经激活后，会恢复这个表单行为(form action)。
• 表单激活事件(form activation event )，比如- form{"name":"restaurant_form"}。这类事件在第一次form action even之后被调用。
• 表单失活事件( form deactivation event ),比如- form{"name":null}，用来使表单失活。

注意：
为了避免忘记添加事件，推荐编写这些stories的方法是使用交互式学习。

Checkpoints 和 OR statements

Checkpoints(检查点)和OR statements(或语句)都应该谨慎使用。通常有一种更好的方法：可以通过使用表单和/或检索 actions 来实现想要的结果。

Checkpoints

可以使用>checkpoints来模块化和简化训练数据。Checkpoints可能有用，但不要滥用。使用大量Checkpoints会使示例stories很难理解。Checkpoints的使用场景：如果一个 story block(故事块)在不同的story中经常重复。但是没有Checkpoints的stories更容易读和写。下面是一个包含Checkpoints的示例(注意，可以一次附加多个Checkpoints)：

## first story
* greet
   - action_ask_user_question
> check_asked_question

## user affirms question
> check_asked_question
* affirm
  - action_handle_affirmation
> check_handled_affirmation

## user denies question
> check_asked_question
* deny
  - action_handle_denial
> check_handled_denial

## user leaves
> check_handled_denial
> check_handled_affirmation
* goodbye
  - utter_goodbye

注意：
与常规的stories不同，checkpoints 并不局限于从用户输入开始。只要checkpoints 被插入到主要stories的正确位置，第一个事件可以是一个action，也可以是一个utterance。

OR statements

另一种缩短stories的方法，或者用同一种方法处理多个意图的方法，是使用OR语句。例如，如果要求用户确认某事，并且希望以相同的方式对待affirm和thankyou意图。以下story将在训练时转换为两个stories：

## story
...
  - utter_ask_confirm
* affirm OR thankyou
  - action_handle_affirmation

就像 Checkpoints 和 OR语句一样，它们可能很有用，但是如果使用了大量Checkpoints和 OR语句，那么最好重新构造域和/或意图。总之，慎用二者。

端-端的Story评估

端到端story格式是一种将NLU和Core训练数据合并到单个文件中进行评估的格式。可以在这里了解更多。