Gavin老师Transformer直播课感悟 - 基于Transformer的Rasa之去掉对话系统的Intent剖析(二)

        本文继续围绕工业级业务对话平台和框架Rasa来从多个角度解析为何Rasa要在业务对话机器人实现中去掉intent，即意图识别相关的内容。

三、关于Rasa提出的去掉intent机制的剖析                                        

      从通常对业务对话机器人的理解来说，去掉intent是不可思议的，这里会讨论一些不适合使用intent的经典场景。我们可以把对话看做是由intent，action，state等元素构成的一个事件流（Event Streaming），从工业实践角度来看，这些元素的背后都有非常复杂的实现细节，譬如关于状态的维护，同一个用户基于不同的业务与系统进行交互的状态如何维护，能否及时更新状态，以及对话系统重启前后的状态的维护等都是很复杂的细节。

      不可否认intents对于开始创建对话系统是有帮助的，然而随着对话机器人变得越来越复杂，譬如任务处理面临的多意图联合或者耦合的情况，那么从分类的角度讲，对不同意图的confidence就会降低，从机器学习的角度讲，对话系统在判断下一步动作时就会举棋不定或者就直接进入异常处理流程。是时候考虑如何绕过通过把每一个对话内容映射到一个intent的方式带来的一些限制。Intents具有以下特点：

-是僵硬的，intent本身并不具有伸缩性或者适应性

-是有局限的，理论上不可能表达所有的意图

-与上下文无关的，无论采用何种机器学习模型，包括Transformer在内，在NLU的部分是不具有上下文的，只是把用户输入的信息根据自己的一套编码规则生成representations，然后和intent进行匹配

Rasa通过使用forms，retrieval actions，multi-intent（多意图在对话中的使用也比较常见，譬如用户的一句对话隐含了多个任务）来逐步移除这些限制。这样的一些特征模糊了一个intent本身的定义，在未来intents不应再是对话系统的一个瓶颈。

1. 关于“inform” intent解析

        如果使用Rasa forms（类似于表单的数据结构），那么可能依赖于inform这样一个intent，对于识别下一个action并没有什么帮助。引入forms的目的在于提供一种清晰的方式来把业务逻辑整合进对话引擎，而这些业务逻辑是提前就知道的，所以不需要从用户对话数据里学习。一个form仅包含了业务逻辑，譬如一个用户要求一个退款操作，那么就会触发一个退款form，要求用户提供一些信息如订单号和要求退款的理由等。对于这样的场景，系统的一个有用的响应是提供用户的订单号信息，订单号属于一个entity，但是没有一个有意义的intent来与之对应，所以倾向于使用inform标签，但是实际上是没有意义的，因为inform不会在entity “order_number”所提供的信息之外再添加其它的信息。幸运的是，通过使用form_entity这个方法来映射这个slot，即使在无法使用intent进行分类的情况下也可以使这个form正常工作。对于上面这个例子来说，传统经典的做法是先从用户信息里提取出entity，然后基于entity相关的intent来触发action，再根据状态信息产生最后的response，对于基于语义级别的intent来说，通常应该是由entities和另外的一些信息共同构成，而不是像上面这种直接给entity加上一个inform所表示的intent。

     2.  Retrieval intents并不是真正的intents

        Retrieval actions把所有的FAQ相关问题组合在一起对应到一个intent，这种做法就模糊了关于一个intent的原有的定义。Retrieval actions把所有的无状态交互信息拆解为一个intent和一个对应的action，所谓无状态交互是指这些intents总是会接收到相同的response，譬如FAQ问题的回答。从对话的角度来说，这是一种有效的简化方式，即针对所有的FAQ这类的交互都是一样的（就是说选择response是不需要考虑上下文的，仅仅针对问题来和答案做简单匹配处理）。使用单个intent来对应所有的无状态交互可以让对话领域变得更简单，从而只需要较少的训练场景(stories)。

        但是从使用retrieval action的角度讲，在未来可以取消intent的使用，之所以可以使用retrieval action这种方式，是因为Rasa训练了一个retrieval模型用于处理response的选取，如以下对话示例所示：

Intent分类器和对话策略把所有这些交互都看做是一个intent “faq”和一个action “respond_faq”，只有retrieval模型能够知道问题之间的差异。

    3. 多意图(multi-intents)

        关于多意图，重要的是应该只在对话机器人要求处理这样的逻辑的情况下才考虑使用multi-intents。过度使用multi-intents会使对话系统变得过于复杂，所以建议只在必要的时候才使用来确保用户与系统的对话过程是自然的。用户在一句话里表达多个事情是常见的，譬如下面这个例子：

通过设计，Rasa只会根据在训练数据中至少出现过一次的内容来预测multi intents。这遵循了这样的设计准则，即现实的对话比假设的东西更重要。这里有几种有效的方式来处理多意图的输入信息：

-对多意图中的一个意图采取忽略的方式，而只关注另一个意图（需要采用什么方法来处理？）

-需要同时对这些意图进行响应（这会涉及到一个先后顺序的问题）

-这些意图彼此冲突而需要对话机器人向用户进行澄清

此外，在没有看到用户与系统交互的数据的情况下，我们是无法知道哪些是正确的。

    4. 关于无法定义的intents

        有些intents是无法定义的，这是由于专业知识的局限性，业务对话系统接触的客户是有限的，同时建模能力是有限的。下面列出的这些假设是不成立的：

-假设在建立业务对话系统时就已知道用户想要做的所有的任何类别的事情

-假设获得的数据代表了所有的情况来训练模型

-假设对领域的认识永远是最好的

此外，由于语言的限制，也存在无法表达意图的情况，譬如下面这个例子：

类似元对话（meta-conversation）这样的表达，很难去发明一个intent来对应上面的信息，从另一方面说，可以考虑通过使用response模板来挑选出一个比较通用的但是看起质量较好的response来应对。

    5. 为何intent看起不错但是要取消它

        在引导对话机器人方面使用定义好的一套intents确实是一种很有效的方式，这种方式就是把人类对话所表现出来的无限的空间压缩为有限的buckets（指有限的intents集合），从而使对话机器人在知道如何进行响应时变得比较容易。然而随着对话机器人复杂程度的增加，譬如对于用户来说，提供一个好的response是很容易的事，但是对于对话机器人来说，要使用这样一套表现僵硬的intents就会变得越来越困难。基于这样的场景，seq2seq的模型（通常说的end2end不等同于seq2seq，Transformer就是seq2seq的模型，Rasa也是基于Transformer的）也许并不是一个好的选择，而通过大规模预训练模型做迁移学习也不是一个好的方式。对于基于业务的对话系统来说，模型应该具有能产生确定性的结果的能力并且是可测试的。