在智能客服的业务场景中，对于用户频繁会问到的业务知识类问题的自动解答（以下简称为FAQ）是一个非常关键的需求，可以说是智能客服最为核心的用户场景，可以最为显著地降低人工客服的数量与成本。
比如10086的在线智能客服，用户提问“如何查询话费”，那系统可以自动给出一个对应的知识“请您向10086号码发送‘HF’短信，即可查询当前话费”，而不再需要耗费高成本的人力来做解答。
本文要讨论的就是对于这么一个特殊场景的算法方案在落地时候的一些考虑。也许有人会觉得，这个不都是很成熟的句子相似性建模的问题吗？有啥好讨论的。那我也有一个疑惑，为什么不是QA相关度建模，而是Q与Q的相似性建模呢？
关于Sentence similarity（STS）和QA相关度的课题其实在学术界已经是一个很老的课题了，前人都有大量的研究，但都只关心课题本身。而这些研究最终是否会被某一个具体的工业需求场景所需要和采用，却也是另外一个值得思考的事情。
作为准备战斗在业务一线的算法工程师，我觉得对于算法本身的理解深度和调优的技能固然重要，而对于一些实际的场景，如何考虑商业需求的实质与潜在变化，并为其寻找和落地一个准确率和速度兼顾，且能稳步支持需求变更的技术方案也是尤其重要的能力。
FAQ 需求剖析
不多说，我们进一步来看一下什么是FAQ。基本上来说，就是用户使用智能客服系统，提问了一个业务知识的问题，系统需要在知识库里找到最合适的那一个答案，且一般来说，知识库都是人工事先编辑好的。
那看上去这个需求非常明确，就是一个QA任务，问题是如何对这个QA任务建模和实现？QA技术发展到今天，涉及范围已经很广了，有阅读理解QA，知识图谱问答QA，数据分析QA，个人助手QA等等...每一种的领域和方法都不太一样，那FAQ的QA和他们有什么不一样的地方呢？
个人拙见：
1. 在这个场景中，知识的域是垂直封闭的
，并不是开放的，只取决于开发这个智能客服的公司或者个人的需要支持的业务范围是多大。2. 由于是垂直领域，知识的变化并不会过于频繁，且知识库其实一般都是一个已经编辑好的库，一般由问题与答案这样的pair对组成，而不是那种很复杂的图结构或者关联表结构。如“如何查询话费”与“请您向10086号码发送 ‘HF’短信，即可查询当前话费”这样的一个文本pair对
构成。一般来说pair对的数量都是几十到几百几千不等，不会特别大。3. 回答相对简单，不需要太多的推理和解析，只需要知道是知识库里的哪一个回答即可，某种程度上可以看做是一个匹配问题甚至是分类问题
。
方案选择
在了解了具体的一些需求之后，我们就可以发现，在这个场景中并不需要上很复杂的semantic parsing技术，也不需要上如各种SQuAD里的复杂算法，感觉就是一个经典的检索和搜索问题。去候选里搜索出哪个是最合适作为回复的即可。那问题又来了，拿什么作为搜索的对象呢？
一种方案是拿输入Query 与候选的所有Answer 去做匹配，去找哪一个最合适。 而另一种方案是就是拿输入Query与历史语料库里的Query去找哪一个最相似，然后把找到的query对应的Answer取出即可。
两种方案看上去都有一定的可行性，但是经过我实际的调研发现，工业界普遍采用的都是第二种基于问题相似性的方案。
调研例子如下：
以上技术和数据的例子都发生在2018年，说明这个已经成为了现实的FAQ场景里的技术方向了，且久经实际使用的考验，只是具体实现的差别罢了。
那为什么最终这种方案会成为FAQ的主流解决方案呢？我也这个问题进行一定的探索与思考，也请教了一些做这方面的前辈，再加上我自己的一些理解，写下了这篇文章。
选择问题相似度方案的原因
以下进入正题，我们来仔细讨论为什么问题与问题的相似性建模会成为FAQ领域的主流方案。
原因1：语义空间
问题和问题的语义空间是一致的，而问题与回答的语义空间可能是不一致的。这个很好理解，问题都是用户方说的自然语言，其说话的出发点和形式是一样的，所以其学习的空间也是同一个空间。而回答基本都是公司的产品经理、业务运营、客服经理等等制订和编辑的，所以在语义空间上就与用户的问题有着明显的不同。而这个语义空间的不一致性会极大影响算法的选择与学习。
举例来说，如果是深度学习，句子相似度典型算法中以两侧向量相似度为目标和损失函数的孪生网络算法（Siamese network系列）就需要两边的语义空间一样，两边抽取特征的网络结构和参数也是共享的。而其他任务的匹配算法，如推理SLI任务往往就不是参数共享的，且往往需要额外的一个交互映射层来完成两边句子表示的语义映射关系。我的理解是这个额外的语义映射关系也会加大学习的难度。
另一方面如果是传统手工特征，那么句法树的解析出的中心节点是否相同，两句子的编辑距离大小，两句子的关键词overlap情况，这些特征在相似问题判断时会有更好的体现，且具有很高的可解释性（比如编辑距离越小，越可能是同一个意思）。而QA Match 在特征抽取上就会受限很多。
还需要考虑的一点是，极端情况下，问题的回答甚至不是文本形式的，而是其他多媒体形式的，比如一个产品的安装操作视频，中国和欧美的标准尺码表格或者是一张带标注的全国地图。那这种情况，就更难以去对问题和回答就行直接建模匹配。
原因2：语料的稳定性
用户的问题虽然形式和说法各有不一，千奇百怪，但是其整体分布上是一个稳定的状态。而回答却会随着业务的发展和国家政策的更改不断发生变化。即QA数据本身，A就会发生变化，而Q却不会发生太大变化。
可能会有人不理解我对于“变化”和“稳定”的定义。我们的目标是对于用户的问题都能给出一个合适的回复。那么什么叫做合适呢？一种理解是相关性，即问题和回复是有高度的关联性的。而另一种理解只要是在当前这个时间点上根据实际业务需要的最好的回复即可。基于这个背景，我们重新理解一下“变化”和“稳定”。
用户的问题，如“现在买电动车可以直接上牌吗？”，即使变成了“我明天来买特斯拉，是不是牌照问题直接解决”，从某种角度上看依然还是一个很稳定的同义关系。而回答就很可能不是这样了，会随着客服和运营的脑子一热或者业务政策本身的变化而发生非常剧烈的变化。
举个例子，比如买车的用户几年前问“现在买电动车可以直接上牌吗？”，当时的标准回答是“纯电动车在北京市目前可以上牌，只要买车时办理即可。” 过了几年回答就变成“现在部分符合国家相关标准的可以直接上牌，如***车型，不符合的需要摇号”。而时过境迁，现在回答就成”现在都不能直接上牌，建议您先排队摇号，可以先来看一看中意车型，等中了再来购买“。甚至极端情况下，该答案变成了“该问题较为复杂，请咨询人工客服，电话为400XXXXXXX”。
所以我们可以看到回答的变化而引来的难题。算法本质是在做一个拟合操作，而数据的变化越多，对模型算法的学习就越不利，所以你完全无法预估回答变化之后，整体的效果变化走向。
原因3：业务回答与算法模型的解耦
这一点可以说是上述第二点的扩展，把问题与回答分离，只对问题建模，可以将算法模型的学习与业务方编辑的答案充分解耦，让不同问题与回答之间的映射比较随意可控。
如上面买电动车的例子所说，如果只是对用户的输入进行相似性建模，那么不管客服运营方如何配置要回复的答案，都不会影响系统的匹配效果，可以做到实时的答案更新和替换。如下的例子更可以直观反映情况：
原先的业务逻辑配置情况如下：
某次政策大幅度变动之后的业务逻辑配置情况：
这里我们可以直观地看到，如果采用QA匹配的策略，那么在新业务配置下，其语义匹配的关系已完全乱了。而如果使用QQ相似性建模的策略，依然不影响，只需要把问题对应的答案指针修改到新的位置即可。
原因4：新问题发现与去重
FAQ的系统在构建好后，并不会是一成不变的，因为公司的业务需要也还是在不断发生变化和增长，用户会有新的频繁需要询问的问题，或者其实有些问题跟已有的问题其实是一致的，或者历史上配置的问题其实是不必要的。
那这个时候就需要对系统进行迭代，比如做新问题的发现与重复问题去重。而想做这个的话，最需要的就是要学习对问题本身如何去表示。而问题与问题相似度建模的方法，明显要比问题与回答相关度建模的方法更直观一些。
这里引用了一张蚂蚁金服举办比赛时，其专家对于赛题的解读，提到了一个完整的智能客服标准问题生产体系里，会有一个对问题进行聚类挖掘闭环的过程。而如何聚类，那显然就需要对问题的充分表示，无论这个表示是基于手工特征的，还是分布式的表示。
原因5： 上线运行速度
一个工业系统在在上线时必须要考虑的一个问题是这个系统的并发和延时情况是怎么样的。
如果使用QA Match的话，如果FAQ语料库的候选很大，即A有很多的话，那么在线上预测的时候，就会存在一个问题，进来的问题需要和那么多的A分别去做Match，（假设有1000条A，那么就需要执行QA Match模型1000次）虽然可以使用Batch机制来批量match，但始终整体的计算资源消耗和计算速度是比较大的。
而如果使用问题与问题相似的思路，那么就可以提前把历史文本语料索引在Elastic search这样的搜索引擎中，或者可以把相似模型对于问题的建模稠密向量用Faiss或者annoy工具索引起来。当来了一个新问题的时候，就通过索引去搜索召回出历史语料中比较粗粒度的最相似TopK（这个时候TopK就可以降低到10或者20）问题即可，然后再用精细化的耗时的复杂语义模型去进一步匹配，就可以节约很多的计算资源和提高速度。
这里引用了一张百度的AnyQ框架的方案说明，里面就设计了这个粗粒度的相似召回模块。所以说用相似的思路做，可以借鉴很多搜索上的一些优化思路和方法，先做召回，后排序。而用QA Match的思路做，在召回阶段，难度就比较高。
原因6：预训练
这个原因就属于我拍脑袋想的了。问题相似的方案，其实可以利用很多外部语料进行预训练，如百度知道里有个百度提供的类似问题推荐（还是可以相信一下百度的NLP实力的）。一般来说，合理的预训练会提高一些自己的具体任务的效果。
而QA Match里的A，往往是定制化的，跟业务高度相关，所以并没有办法很好的获得太多外部语料。
总 结
我从性能，扩展性，效果等方面分析了我个人关于智能客服领域的FAQ QA任务的具体技术方案的一些思考和整理。
虽然思考的是FAQ任务在方案选择上的一些事情，但我认为在调研和落地其他NLP任务的时候同样也需要类似的一种能力和实践。
联系客服
