蚂蚁金服MISA：比用户更懂自己的自然语言客服系统

编者按：本文来自机器之心（ID：almosthuman2014），作者：邱陆陆；36氪经授权转载。

当手机取代了钱包，支付宝甚至比现金更常用，与蚂蚁金服的产品端一同忙碌起来的还有公司的服务端。95188 服务热线就是其中之一。

然而当我们谈起客服电话，想到的仍然是传统的按键菜单（「普通话服务请按 1，for English service please press 2」）和在机械而漫长的语音播报里等待的焦躁。「在过去的统计里，只要用户没转接人工，就算作『问题被自助解决了』，其实在我们看来那不叫『解决』，叫『损耗』。」蚂蚁金服的产品运营专家弈客说。秉承着这样的理念，团队开发了 MISA（Machine Intelligence Service Assistant），一个能够通过识别用户的语音中包含的业务需求来直接进行回应的客服系统，他们称之为「37 摄氏度的自助语音交互」。

在金融业务领域，客户服务涉及许多环节，通过人工智能的技术解决客服问题，为广大用户提供高效、个性化的普惠金融服务，成为金融科技领域非常基础、非常具有挑战性的课题。

最近，在蚂蚁金服发起的「ATEC 蚂蚁开发者大赛——人工智能大赛」上，这支团队在初赛就拿出了来自实际应用场景的 10 万对标注问题集，并开放相关资源与专家指导，邀请人工智能开发者来挑战「问题相似度计算」这一客服领域最基础也最核心的任务。

如今，赛事已经集结了来自全球超过两千支队伍报名，并开启了激烈的准确率打榜竞赛。近日机器之心也有幸探访蚂蚁金服，采访了 MISA 团队中的三位核心成员：人工智能部资深算法专家深空（张家兴）、客户服务及权益保障事业部产品运营专家弈客（于浩淼）以及人工智能部算法专家千瞳（崔恒斌），聊了聊如何利用深度学习算法构建能够「未卜先知」的客服系统。以下内容根据采访实录整理，机器之心对内容作了不改变原意的调整。

MISA 的「成长故事」与「近照」

机器之心：开发 MISA 系统的初衷是什么？

弈客：95188 支付宝服务热线是一个典型的 IVR 场景（Interactive Voice Response，互动式语音应答），作为一个语音渠道，它的业务目标很简单，就是「定位用户的问题，匹配相应解答方案」。一开始，它就是一个传统的按键菜单，后来随着蚂蚁金服业务线的日益增长，按键菜单无法满足业务需求，同时语音识别技术也进入了一个基本可以投入应用的阶段，所以从 16 年初开始，我们和算法工程师一起，尝试找新的解决方法。

最初的想法是让用户描述自己的问题与场景，然后将描述与我们的业务与知识进行一次匹配。后来，我们发现单次匹配也很难做到特别精准，因为用户很难在单次描述里给出全部所需要素，所以就尝试以多轮交互的形式，用一个对话系统来帮助用户补全其描述中缺失的部分。

再后来，我们发现与其让用户完全清楚地描述自己的问题，不如我们率先发问。我们做了大量的市场调研，发现如今市面上的客服系统也基本上以「描述与匹配」模式为主，涉及多轮交互的本身就很少，在多轮基础上发展方向也没有那么明确。因此我们就回到了蚂蚁自身。我们就想，能不能基于用户在提问时所积累的行为特征，以「猜问题」的形式让系统率先发起对话，降低用户的使用难度。相比于「你有什么问题？」，「你是不是想问 XXX 问题？」就要容易回答得多，即使用户回答「不是」，我们的问题也会为他接下来的描述提供一个示例。

如今的 95188 语音服务流程

机器之心：现在 MISA 的系统由哪些部分组成？分别完成什么任务？

深空：MISA 的主要模块有猜问题、问题识别、反问交互三个。「猜问题」是蚂蚁金服在客服领域的首创，是一个利用用户可能与本次致电相关的信息，基于深度学习算法框架构建的问题识别模型。「问题识别」是根据用户的描述定位他可能遇到的问题。「反问交互」是在用户给出的信息不全时，利用「要素拆解和补全」的方式帮助问题识别模块圈定范围，降低问题识别的难度，以反问的形式与用户进行交互。

机器之心： 除了用户转为文本的语音输入外，MISA 的系统还会接收哪些输入？如何分类？

深空：我们将输入分为因子、轨迹、文本三类。因子是由业务方定义的、具有明确含义的特征，例如：过去 24 小时是否有还款行为、过去 24 小时是否发生过转账行为等。因子大约有数百个。轨迹是用户最近的 120 个「行为」组成的时间序列，其中一个行为指对远程服务器发生一次请求。行为的种类超过一万种。文本是用户的描述以文本形式表达；在「猜问题」环节，文本指用户的历史描述，在正常的「问题识别」环节，文本即把本次电话里用户对问题的语音描述转换成文本。文本是一个长度各不相同，甚至可能空缺的输入。

机器之心：作为一个以识别为主要目的的系统，MISA 会将用户的问题匹配到多少种类型里？如何给出应答？

弈客：需要匹配的问题类型的具体数字随着业务上线与下线会有浮动，规模大约在「数千」这个量级。

大框架上，应答可以分为三类。第一类，如果用户的问题很简单，能用一两句话说清楚，我们就以播报的形式输出。比如之前余额宝一个业务的产品方案进行了调整，从不限转入金额到每天最多只能转入两万。这时候当用户转入出错前来咨询，我们就会以播报形式把业务调整通知给用户。第二类，如果方案需要用户在某一个产品页面进行操作与交互，我们就会把相应页面在用户的 app 里拉起来。用户挂掉电话打开 app，就能看到解决方案页面的推送，点开就可以完成操作了。最后一类，我们判断相对复杂的问题，就转接人工小二处理。

机器之心：一位用户平均需要与系统进行多少轮对话能够定位到自己的问题呢？

弈客：一开始系统能力还没有那么强的时候，我们把最多对话轮数设置为 4 轮，如果 4 轮对话之后用户的问题仍然没有得到解决，就转交人工客服。通过不断的优化，现在用户的平均对话轮数不超过两轮，大概在 1.8-1.9 左右。

客服系统是怎样炼成的：模型选择、评估与优化

机器之心：在处理自然语言文本时，用到了哪些深度学习模型？

千瞳：我们首先用自己预训练的词向量对文本进行表示，然后分别用到了卷积神经网络（CNN）和以 LSTM 为基本单位的循环神经网络（RNN）对文本进行处理。

卷积神经网络中，模型对由词向量组成的文本做一维单层卷积与池化，形成一个向量，RNN 则把文本视为一个序列，处理后也得到一个向量，最后，将两个向量相加，得到一个代表本段文本的新向量，然后与代表因子和轨迹的向量加在一起，进行分类。

机器之心：为什么同时采用 CNN 和 RNN？

千瞳：两种模型提取特征的能力不同。CNN 的能力在于提取关键词。RNN 更善于捕捉序列关系。

机器之心：分类模型与问题识别模块的关系是？

千瞳：问题识别模型是由多个子模型+融合模型的形式组织的。分类模型只是其中一种子模型，除此之外，还有搜索、意图树等多个结构化子模型。不同模型的输出格式也各不相同，分类模型返回不同类别的可能性打分，而意图树可能只返回某一个最可能的类别。在子模型各自进行问题识别后，我们会通过一个 GBDT 的模型，对前四个模型的结果进行融合。在融合模型阶段，我们取每一个模型的 top1 输出，根据标注数据来选择输出可能性最高的那个模型的结果。

机器之心：反问交互是如何实现的？

弈客：如今一百通电话里，有三十通会率先通过猜问题的形式对用户进行发问。如果没有猜中，就要思考如何在较短的轮数内摸清用户的需求。用户的大多数问题都能够以「业务、框架、类型」三要素方式进行拆分。例如「花呗不能还款」，「花呗」就是涉及的业务，问题的核心动词「还款」就是框架，「失败」是导致用户提问的诉求类型。有超过一千个用户问题都可以被拆解成三要素的形式，其中包括一百多类业务、不到一百类框架和不超过十种问题类型。

三要素拆分方式的方式能够帮助快速缩小识别范围。用户在描述中，可能不能一次把三要素都描述清楚，但是如果给出了某部分要素，比如用户说「我要还款」，就给出了框架「还款」和类型「如何」，这时我们就可以就缺失的「业务」要素进行反问，比如，「您是要进行花呗还款、借呗还款还是信用卡还款？」

千瞳：从技术的角度上来讲，我们在构建了语义要素库之后，是可以实现 zero-shot 的问题识别的。即，不需要见到特定的要素组合的训练样本，只要在其他训练样本中见过单独的要素在其他场景下出现，一样可以识别这个要素组合，对应到相应问题。

另外，我们也构建了多任务学习的框架。三要素识别任务的目标是非常类似的，都可以看做是多分类问题。多任务学习让不同任务间的数据可以共享。虽然每一个单独的任务都有足够的数据，但是不同任务间目标会让特征提取各有侧重，提高模型效果。相比单模型，识别准确率可以提升 7 个百分点。

机器之心：如何评估匹配的精确程度？这些评估是否会反过来影响模型的优化？

千瞳：匹配的评估指标有多个层级，第一个是 CTR（Click Through Rate），比如在「猜问题」阶段，用户会确认系统猜的是不是他的问题。第二个是分流的准确率，如果分配到人工还有小二派单准确率，最后是问题解决率。

至于用户的评估如何影响模型优化，一言以蔽之，用户的反馈就是模型的训练数据，系统自己能形成一个闭环迭代体系。MISA 的大部分模型一周迭代两次。

关于比赛：客服领域里的相似度计算

机器之心：比赛中的「判断两句话是否为同义句」任务和利用分类法进行问题识别任务之间的关系是什么？

深空：当我们拿到一个用户的自然语言问句，想判断它是知识库里的哪一类问题时，通常有两种做法：一是做分类，也就是上面讲到的问题识别；还有一种做法就是判断同义句，给出每一类问题的几条例句后，当一个新的问句出现，就计算新问句与每一条例句之间的相似度。

相比于识别，同义句是一类相对昂贵但具有重大意义的做法。对于许多拿不到丰富数据的场景来说，训练分类器变得不可能，而搜集例句、计算相似度相较之下更为可行和合适。

基于相似度计算的分类算法对于数据的需求要灵活得多，可以根据数据的情况分层次安排：有的方法可以不需要训练数据，基于规则来做；有的方法可以基于领域无关的、有公开语料的通用数据进行训练；当然，如果提供领域相关的数据，可以让相似度计算得更好，就像我们这次提供的数据这样。

从工程的角度来讲，这种一开始对训练数据依赖较小的办法，有利于工程师按部就班把一个问题解决掉。

机器之心：选择判断同义句作为本次大赛赛题的原因都有哪些？

深空：第一，在将用户的问句分类的场景下，相似度计算是一种基础而实用的做法。在客服领域里，大多数应用场景仍然是缺少数据的。第二，问题的相似度计算在其他场景下也有广泛的应用，例如，在「挖掘用户常见问题」任务里，就要对用户问句进行聚类，将每一类常见问题归为一类。聚类的基础就是计算每两个问句之间的相似度。还有许多其他类似的应用。总而言之，相似度计算是客服大领域中非常基础、非常核心的一个问题。

这次比赛的重点就是鼓励选手找到好的相似度计算方法。本次我们在初赛就提供了 10 万条数据。作为对比，现在的相似度计算比赛中最大的公开数据集大概在 1 万条左右。但是我们不强制选手使用提供的数据，完全不基于数据或者引入外部数据的做法都是被允许的，希望选手们不拘一格，找到最好的相似度计算方法。

机器之心：是否会考虑将比赛中出现的做法投入到实际生产中？

千瞳：这是肯定的。蚂蚁的业务发展非常快，因此在设计算法的过程中会遇到很多现实的问题：比如用户描述口语化、描述多样性、纠错以长句问题等等，都需要相似度计算方法去解决，我们自己也在进行大量相似度计算方面的探索，希望能够和选手们一起，找到最合适的方法。