Gavin老师Transformer直播课感悟 - 基于Transformer的Rasa 3.x 内核解密之对话策略Policy完整源码详解(二十)

        本文继续围绕工业级业务对话平台和框架Rasa的对话策略Policy完整源码进行解析。

一、关于对话策略Policy架构与完整源码解析

1. Policy架构与内部工作机制剖析

        Rasa提供了几种policies：

-MemoizationPolicy：继承自Policy

-RulePolicy：继承自MemoizationPolicy

-TEDPolicy：继承自Policy

-UnexpecTEDIntentPolicy：继承自TEDPolicy

        可以看出，这些policies的公共父类是Policy，了解policy的内部工作机制对于如何有效地在对话机器人中使用这些policies是非常重要的。对于RulePolicy来说，我们可以看下Rasa提供的moodbot的样例，任意时候只要符合下面定义的intents，那么就会采取对应的actions，这些actions都是定义在domain配置文件里的：

在基于机器学习时，需要参考stories的内容，在下面的例子里我们可以看到针对happy path和unhappy path出现的intents以及各自对应的actions：

        之所以要定义这些policies，是因为在实际对话中会有不同的场景，需要针对具体的场景来应用合适的policy。这些policies是基于优先级来进行操作的，假定在标准的设置里，那么RulePolicy的优先级最高，如果场景适合使用RulePolicy来很好地匹配action时就使用它，如果RulePolicy不可用，那么通过回退机制(fallback)交给MemoizationPolicy来处理，MemoizationPolicy会根据已有的训练数据stories来判断当前对话场景是否与之匹配，如果能很好匹配则运用这个policy来预测next action，如果不能则继续回退到TEDPolicy来处理，即采用机器学习的方法来尝试预测next action。具体参考下图所示流程：

通过下面样例来看下机器人moodbot是如何运用policies的，在config.yml文件里可以看到关于policies的配置：

当使用debug模式运行样例时，可以看到输出信息里每个action所使用的policy，”action_listen” 表示系统等待用户输入的状态，对话里加入了happy path和unhappy path的处理：

上面的例子只使用了MemoizationPolicy和RulePolicy，为了触发TEDPolicy的使用，在下面的例子里触发了表示deny的intent（用户说”no”），这个时候没有任何的rules和stories可以用来预测，所以需要使用TEDPolicy来预测next action，但是由于没有类似这种非期望场景的训练数据可用（指没有可用的stories），从而导致TEDPolicy得到的confidence很低：

为了更好地处理这种场景，从配置文件方面做了改进：

如果没有任何policy可用于做出基于一定confidence的预测，那么对于RulePolicy来说可以启用回退机制和设置threshold（不让TEDPolicy进行实际预测），并且在domain文件里配置相应的fallback被触发后的action（一般是要求用户重新输入信息以澄清意图），这样得到的运行效果如下：

所以基于实际对话中可能会出现的各种场景，需要混合使用各种policies来进行处理。而从训练数据stories的角度讲，实际上是不可能包括所有的对话场景的。我们可以改进训练数据以便让TED模型能够更好地进行预测和进行推理，而在基于特定的单轮对话的场景下，使用rules可以简化对话处理和进行更直接的控制。

Rules并不能解决一切！从设计来说，应该只基于简短的对话场景来编写rules，从而防止制造一个不可维护的“状态机”，rules并不能替换训练数据stories，而是提供了一种处理对话的方式。

Rules最佳实践包括：

-控制回退行为：你可以把rules同一个Rasa提供的FallbackClassifier组合起来使用，也可以定制自己的这类组件

-单轮对话：如果可以很容易定义正确的action，即使没有很好的stories，也可以使用rules，这是一种非常方便的工具

-Forms：需要收集用户信息时使用form，这时你可以使用rules来定制form如何初始化，提交或者不激活等

  2.  Policy与GraphComponent

        Policy会导入Event，它用于描述对话中使用的events以及这些events如何影响对话状态，event是在用户与对话机器人的对话过程中所发生的一切的不可改变的表示，通过event来通知对话状态跟踪器在event发生时应该如何更新状态。

导入GraphComponent, ExecutionContext，在Rasa 3.x的架构中，把任何组件都抽象为graph components：

导入MessageContainerForCoreFeaturization，它以key-value的方式来存储来自这些属性的messages：`ACTION_NAME`, `ACTION_TEXT`, `TEXT`, or `INTENT`。

导入SingleStateFeaturizer，这个类用来把对话状态转换为机器学习的格式，它的子类可以定义如何把对话状态转换为一个字典来映射一个attribute和它所对应的features（即vectors）：

导入这些常量：ENTITIES, INTENT, TEXT, ACTION_TEXT, ACTION_NAME，它们都定义在一个常量文件里，方便进行管理和更新：

Policy继承自GraphComponent，GraphComponent定义了关于组件依赖关系的方法以及依赖包的方法：

下面的初始化方法用来构建一个policy对象，譬如是否需要根据policy的类型创建featurizer，设置优先级，model storage和resource等：

   3.  SupportedData完整源码详解

   SupportedData是一个枚举类，定义了三种类型：

-ML_DATA：只支持机器学习的训练数据stories

-RULE_DATA：只支持rules

-ML_AND_RULE_DATA：同时支持stories和rules

下面方法返回基于给定policy的对话状态跟踪器时，会根据支持数据类型进行相应的判断处理：

在Policy中会调用supported_data这个方法，返回SupportedData：