智能客服领域任务驱动型多轮对话框架的应用实践

    自然语言处理（NLP）是人工智能其中的一个方向，甚至可以说是人工智能的终极难题。因为NLP是感知层面的，相对于认知智能会有更大的难度。当前应用最广的是智能客服机器人领域。通常来说，人机对话领域的问题包括开放领域闲聊，问答和任务驱动型多轮对话。

    本文就智能客服领域的实践，来聊一聊任务驱动型多轮对话框架在智能客服领域的应用和设计思路。

1.定义

    此处的任务型多轮对话指的是以完成任务为目的，通过和用户的多轮对话收集相关信息，决定流程的流转或部分依赖条件的确认，然后根据预设给出答案或调用外部系统完成任务。

    通常这种场景下，用户是带着明确的目的来的，希望是得到特定的信息或者服务，然而有可能一次性表达不清楚所有信息，于是就需要通过多轮对话来实现。同样的，在和用户的交互中，机器人通过询问、澄清、让用户确认等方式引导用户，让对话能够保持在相对规范的框架内，提高多轮对话的完成率。

2.主要应用场景

    对于任务型的多轮对话，主要目的是在于信息的收集和决策，通常信息收集通过NER（命名实体识别）或配合调用外部的数据系统来实现，通常这里的信息收集被称作填槽，待收集的信息类型被称作槽位。

    而在实际的应用场景中，多轮对话的框架并不局限于具体的任务型操作，如买火车篇等。下面详细地聊一下任务型多轮对话的框架在各种场景中的应用。

（1）标准问答关键信息的区分

    针对某些过于相近的标准问题，但是答案不一样的场景，如果完全依赖于问题识别或意图识别模型进行区分，准确率可能会很低。

例如需要区分：

“我晚还款了1天怎么办”和“我晚还款了4天怎么办”

因为部分信用卡存在3天的还款延期服务，所以这两个问题对应的答案是不一样的。

    解决这类问题，可以通过将两个问题在模型中先合并成一类问题，然后通过NER（命名实体识别）提取出句子中的关键信息（时间），然后按照预设的规则进行对比，从而可以区分出这两个问题。

而如果当用户的表述中未包含需要提取的信息，则可以通过下面一点问题澄清的方式来实现。

（2）问题澄清

    对于部分过于相近的标准问题，没有包含明确的命名实体来区分，可以通过多轮对话的框架让用户澄清。

例如对于问题：

“我要怎么上课”

用户有可能是学生，也可能是老师，这个问题其实对应到两个不同的问题：

“学生怎么上课”和“老师怎么上课”。

这种场景下可以用问题澄清，直接追问用户：

请问您是学生还是老师？

当用户给出相应的答案之后再进行接下来的流程。

    以及对于问题：“我的还钱信息” ，有可能对应到“我应该还多少钱”和“我已经还了多少钱”，也可以通过问题澄清来解决。

（3）任务办理和信息查询

    这是当前多轮对话应用最广泛的领域，例如订机票，订酒店，查询等。通过和用户的对话来填槽，并调用外部系统完成操作。

    例如订机票需要提供出发地，目的地，出发时间，和座位级别集中信息，当机器人收集完这些槽位信息之后，会形成框架式的数据结构去请求外部接口完成操作。

    信息查询类类似，对话中可能包含部分限制条件，例如根据时间、地点金额区间等来查询自己的消费情况。

3.词槽

    关于词槽，也是有很多内容可以聊的。

    填槽是任务型多轮对话的核心，通过自然语言处理的技术解析出用户对话中的关键信息来进行决策。

（1）必填槽位和非必填槽位

    并不是所有预设的槽位都必须要填满才能够进行接下来的流程，有部分槽位可以有默认值，默认值可以来自于上下文，预设和外部接口。

（2）NER和槽位审核

    NER做的是从句子中抽出相关格式的关键信息，例如时间，地点。NER通常是通过正则加上训练模型的方式来实现的，其中对于同一个命名实体说法的扩展是实践过程中需要关注的因素。

    而槽位审核指的是当前的多轮对话中，槽位本身的限制要求，例如，只能填入当年的时间，只能填入用户已经开通账户名称。而槽位本身往往依赖于外部系统。

（3）固定槽位和动态槽位

    这里的固定和动态指的是槽位的审核机制的确定性和动态性。其中固定槽位指的是有些槽位对提取到的信息没有严格的限制，或是有固定规则的。例如可以填入所有收集到的金额信息，或可以填入预设的时间范围。

    动态槽位指的是槽位的审核机制依赖于外部的系统，例如用户画像，账户信息等。举个例子，当用户表达了注销信用卡的意图的时候，需要根据用户账户下已开通的卡，来确定填槽信息。

4.其他注意问题

（1）异常场景

    对话过程中，会存在一些异常场景，包括用户答非所问，用户要求退出场景，或连续几轮解析失败等，此类问题需要提前考虑处理的方法。包括流程的处理和兜底回复。

（2）对话框架的灵活性

a.非当前节点询问信息的解析

    人机对话的交互方式和传统GUI的主要差别就在于不确定性。用户可能不按照套路出牌。

例如订酒店的场景中：

当前节点上机器人问用户：请提供入住人数。

但是用户直接说：2个人住3天。

机器人这时候一定要能够解析出人数和天数两个信息。

所以，其实在多轮对话的框架下也未必一定要进行多轮的对话，如果一句话能够包含所有必须提取的槽位信息，则可能只需要一轮。

b.信息的修改

    在多轮对话的流程结束之前，当前节点需要允许修改之前节点收集到的信息。

例如订飞机票的场景中，

U1：我要订飞机票

B1：请问您的出发地是哪里？

U2：上海虹桥机场

B2：请问您的目的地是哪里？

U3：算了，从浦东机场走吧，到深圳。

    U3轮机器人提取到了出发机场：上海浦东国际机场，则需要替换掉之前槽位提取到的上海虹桥机场。