Gavin老师Transformer直播课感悟 - 基于Transformer的Rasa之Retrieval Model剖析(一)

一、概述

        本文围绕工业级业务对话平台和框架Rasa来介绍其内部机制。基于最新的3.x版本提出用一个图来统一所有组件的概念，无论是语言理解（NLU），还是语言处理，语言生成等都是这个图中的组件，从而模糊了NLP不同组件之间的界限。这些组件之间存在依赖关系，也会有通信和相互交互，如下面图中，DIET分类器需要依赖特征提取器(CountVectorFeaturizer)，而特征提取器需要依赖Tokenizer，左侧蓝色背景框的部分是NLU，包括intents，entities和slots，对它们使用了有状态的计算(stateful computations)。而右侧黄色背景框部分是基于NLU的对话策略部分。

二、Rasa assistants集成了response retrieval模型

        在Rasa的1.3.0版本里引入了NLU组件“Retrieval Action”和“ResponseSelector”。通过组合使用这些组件使处理特定的对话元素如small talk，闲聊内容，常见问题（FAQ）和其它的一些与业务处理对话无关的单轮对话变得更加容易。但是这种方式与之前Rasa使用intents的方式不一样了，这样做的主要目的是通过retrieval模型可以在单轮对话场景下从可选的response集合中选取一个最合适的response。所谓单轮对话就是一问一答，跟对话上下文无关。譬如下面这个例子，当用户向对话机器人提问关于python版本的问题时，机器人应该总是给出同样的回答，而与之前的对话历史信息无关（Single turn interaction）：

Rasa会把所有的与常见问题相关的intents都当做是一个retrieval intent（把这类问题分为一个组），然后通过称为“respond_ask_faq”的action来提供对应的response。这样就可以用同样的方式使用单个retrieval action来处理所有的跟FAQ相关的对话信息，这个过程与这些对话问题所具有的特定的intent无关，所以从对话机器人的角度看只有一个intent存在，而只有retrieval模型能够感受到每个问题的差异，从候选responses里把相关度最高的response提取出来返回给用户。然而在Rasa 1.3.0之前的版本里，对于用户输入的每个问题，都会进行intent的识别，那么1.3.0的做法实际上是破坏了意图识别的完整性。

由于intent和response之间的匹配不依赖对话历史，所以不存在通过像Transformer这样的方式来预测response。另外由于把所有用户的不同问题都归为一个intent，就必须建立一个retrieval模型来区分这些问题，并且针对不同的问题给出合适的response。

1. 监督式response selector

        引入了新的NLU组件“ResponseSelector”，它的工作机制如下：

-收集每个用户问题和答案(candidate response)的词汇特征

-通过把词汇的token传入神经网络，分别对问题和答案部分的embedded representation进行计算

-使用一个相似函数来计算问题embedding和答案embedding的相关度

-最大化问题和答案正确配对的相似度，最小化问题和答案错误配对的相似度（MLE）

-在推理时根据用户问题和所有答案进行相似度计算，选择得分最高的作为系统给出的答案

这个过程类似另一个组件“EmbeddingIntentClassifier”，主要差别是intent被response的实际内容所替代。在使用组件“ResponseSelector”之前，还需要使用tokenizer，featurizer，intent classifier对用户输入信息进行处理。相关配置信息如下：

  2. Retrieval Intents

        如下面的例子所示，在配置文件里设定了两个intents：ask_faq/python_version和ask_faq/languages。Intent classifier会把这些intents组合为单个intent：ask_faq，只有组件“ResponseSelector”会关注ask_faq/python_version和ask_faq/languages之间的差异。

   3. Response Phrases

        Response的实际内容是训练数据的一部分，所以不会存在于domain文件里，这是基于retrieval actions的response和基于机器人的response之间的一个重要的差异。由于是基于用户输入内容来直接选择response，那response选择可以看做是端到端的对话机器人训练的一步。这里使用的response格式有点类似曾经用于“end-to-end evaluation”的story的格式：

  4. Retrieval Actions

        Rasa使用一套命名规则来匹配retrieval intents的名称和正确的retrieval action，如ask_faq和respond_ask_faq，前缀respond被用于识别它是一个retrieval action。Retrieval action需要被添加到domain文件里。有两种方式来触发retrieval action：

-如果采取respond完成后总是监听下一个用户话语的方式，那么在domain文件里使用“MappingPolicy”来映射retrieval intents 到相应的actions：

-如果需要采取特定的follow up actions，如问用户是否想要继续对话等，可以像其它actions那样把“respond_ask_faq”这个action包含在stories里面，如下图所示：

配置文件示例：

  5. 关于ResponseSelector更多的用法

        Rasa允许有多个retrieval intents和相应的多个retrieval actions，有以下两种实现方式：

1. 建立一个共享的retrieval模型，基于跨所有的retrieval intents的用户对话和系统response配对进行训练，这种情况下，不需要在ResponseSelector的配置里定义参数retrieval-intent。
2. 为每个retrieval intent建立一个特定的retrieval模型，每个模型只基于对应的retrieval intent的用户对话和系统response配对进行训练，所以在NLU配置里，ResponseSelector的数量应该和训练数据里retrieval intents的数量一致。在每个ResponseSelector的配置里使用参数retrieval_intent来定义相应的retrieval intent：

是否需要采用共享或者单独的retrieval模型是由具体运用场景来决定的，如果基于一个特殊retrieval intent的对话内容是与特定领域高度相关的，如FAQ相关的问题，那么使用来自于闲聊数据训练的retrieval模型没有多大作用，特定的模型如果使用与共享模型不同的参数集，效果可能会更好。另外如果采用更平衡的样本对于训练效果也有改善。