以下文章来源于贝壳智搜，作者智搜小贝壳

数据是算法的基础，贝壳智能客服在长期的数据建设中积累了一些让数据建设更加科学合理的方法。

一、背景
二、标准问和相似问
- 2.1 定义
- 2.2 整体生产流程
- 2.3 用法
三、数据挖掘流程
- 3.1 标准问生产流程
- 3.2 相似问生产流程
四、相似问挖掘实践
- 4.1 数据增强--同义词替换
- 4.2 相似度–cos相似度
- 4.3 聚类–KMeans/DBSCAN
- 4.4 k近邻
- 4.5 生成式--seq2seq+attention/SLCVAE
- 4.6 算法对比
五、数据效果预估
六、总结与展望
作者介绍

一、背景

贝壳智能客服主要解决经纪人在业务中遇到的常见的问题，主要场景有闲聊、卡片触发、精准问答、sug、QA问答。对于非寒暄的场景下，QA问答的占比是最大的，有70%以上，而QA问答效果强烈依赖于数据建设。

QA问答的场景所需的模块大致分为数据层、NLU层、召回层和排序层，数据建设为整个流程中的语义召回、匹配、排序提供足够的query和title的匹配对。所以贝壳智能客服的数据建设实际上就是FAQ库的建设。

二、标准问和相似问

2.1 定义

生产足够的query和title的匹配对，主要就是要生产足够的query来和知识title匹配。这里我们把要生产的query分为两类：标准问和相似问。

相似问和标准问具体是什么意思呢，从下面这张图来看：

知识标题是某条知识的官方总结，标准问能从多个角度描述该问题（或将知识拆分成多个内容），相似问是标准问的不同描述方式。简单来说，就是同一角度问法互为相似问，不同角度的问法互为标准问。下面来举个栗子：

图中的知识标题为：“房源验真任务的规则”，但是知识内容包含了，“如何验真”、“验真时效”、“验真进度”三个不同角度问题的答案，当用户问的问题是“验真时效相关”问题时，和“验真时效”标准问的相似度肯定会大于原知识标题，能够得到更好的匹配结果，这就是我们生产标准问的原因。然后有一条标准问并不一定能够训练好模型，如果能够有足够多句子都是来描述验真时效的问题，那么模型学会这个问题和答案匹配的可能性就会越高，这就是我们想要挖掘相似问的原因。所以我们从标准问和相似问生产两个方面来对FAQ库来进行扩充。

2.2 整体生产流程

标准问和相似问的生产依赖人工标注，整个流程依赖问题学习系统来完成。

问题学习系统将我们挖掘的数据经过一定的策略处理过滤后，将数据推送到业务库，业务库根据不同意图分发给对应的标注人员，经过人工标注后，数据回流到样本库中。回流的反馈数据用来优化整个服务，整个过程形成闭环。智能客服的数据建设重点就是如何为标注提效，如何挖掘优质的标准问和相似问（对应蓝框标注的推送策略部分）。标注人员拿到这些推送数据之后，只需要进行简单的判断，就可产生出可用的标准问和相似问。

2.3 用法

标准问和相似问为语义召回、匹配、排序提供足够的数据支持，匹配和排序都是在训练模型的时候增加了query和title的匹配对数量，在语义召回中的使用方式则是对es进行了扩充：

召回与用户query相对应的title_spare(可以是原知识标题、标准问、相似问)，然后进行匹配排序后返回给用户。用法上相似问、标准问、原知识标题是一样的，由于标准问的表述更为规整，当前只展示原标题和标准问。

其中产生的标准问和相似问只有title_spare，需要找到对应的content（即现有的知识内容），其中知识内容和原标题是一起存在的，这里我们把title_spare找到对应原知识标题和content的过程称为挂接。

三、数据挖掘流程

3.1 标准问生产流程

标准问的挖掘流程可以分为三大部分：挖掘可用query并推送、标注人员进行标准问生产、知识库的知识挂接。

标准问的整体挖掘流程从拿到埋点日志开始，选择点踩query、无召回query和有返回知识但是用户没有点击的query（这些query是适合标准问产出，为整个召回排序提效的数据），然后经过分类去除寒暄等意图的query，faiss召回和query相似的现有标准问，然后把query聚类后推送给标注人员。

数据会根据意图推送给不同的标注人员，标注人员会首先判断query是否有效，若是无效query则直接结束标注，有效query会先和现有的标准问进行判断是否匹配，若匹配，则选出正确的，若不匹配，则总结成新标准问。最终获得推送query和对应的标准问。

由于一条标准问，对应的不同城市的知识会有不同，比如同样是问“业绩分配比例”，可能北京的业绩分配结果和天津的不同，所以标准问需要查找和挂接所有城市的知识，挂接完成后标准问就和一条知识一样被存储在知识库中。

3.2 相似问生产流程

相似问的整体挖掘流程和标准问类似，也是从拿到埋点日志开始，选择点击标准问的query，同样经过分类去除寒暄等意图的query，判断query和标准问的相似度是否较高，若足够高，达到设定的阈值则进行推送。

标注人员只需要判断，query和标准问是否是在问同一问题，若是，query是否需要改写为更为完整通用的句子，然后把改写后或者直接可用的相似问推入线上知识库即可。

由于日志中的标准问已经挂接了知识，产出的相似问不需要在进行知识挂接，且标注人员只需要对现有query进行修改，标注简单。相似问和标准问相比产出快、产量高。

四、相似问挖掘实践

下面来具体介绍一下，相似问挖掘中我们所尝试的各种算法以及效果。

相似问挖掘中所尝试的模块主要有在召回层使用数据增强的同义词替换，聚类、knn和生成式方法，以及排序层的相似度排序。

4.1 数据增强–同义词替换

同义词替换所需的数据有标准问和同义词组，其中同义词又可分为行业同义词（知识生产人员积累）和日常同义词（算法挖掘+人工筛选）。

替换方式分为简单同义词和同义词组两种，简单同义词是标准问进行分词后替换，若为同义词组的话，则直接替换不需分词。

行业同义替换后效果如下图所示（std表示标准问，替换的同义词用”[ ]”标出），其中“核销、下架、无效”为同义词，“查询、查看、查找”为同义词，行业同义词是人工积累获得，替换后可直接使用，不需要人工过滤。

日常同义词质量没有行业同义词高，替换后query需人工过滤。如下图中“哪里、在哪儿”是同义词，标准问“签后报单的入口在哪里？”替换为“签后报单的入口在在哪儿? ”，是不通顺的。但日常同义词数据量大，当其他相似问挖掘方法产出有限时，同义词替换可作为兜底数据。

4.2 相似度–cos相似度

计算用户query和点击的标准问之间的相似度，若query和标准问的相似度足够高，则把该query作为标准问的相似问。这里我们使用的是cos相似度，阈值设置为0.6，如下图可知，标准问为“VR带看没有声音怎么办？”点击这条标准问的query有“vr来电不响 ”、“vr带看没声音 ”、“为什么我的小被vr讲房没有声音呢”，和标准问的相似度都达到了0.6以上，经过人工判断，可知，只有“vr带看没声音”和原标准问的意思相同，是原标准问的相似问。而第二个例子，由于query“vr讲房稿在那里 ”应该是“vr讲房稿在哪里 ”，所以是标准问“VR讲房的模板是什么？”的相似问，但需修改错别字。

4.3 聚类–KMeans/DBSCAN

聚类算法用到用户query和标准问，做法是将query和标准问映射到同一空间一起进行聚类，根据聚类结果，将每个类中的query作为该聚类中的标准问的相似问。

尝试的具体算法有KMeans聚类（k=80，数据量1k+），聚类效果为每个聚类的query个数较均衡，但聚类后query意图分散，图中可以看出聚类label=2时，query包含有离职、转店、审核等意图。

处理KMeans聚类还尝试了DBSCAN聚类，DBSCAN聚类是基于密度的距离，不需要设置聚类个数，但是需要设置类内最大距离，这里希望聚在一起的query意图足够相近，设置类内最大距离较小，导致每个聚类的query个数相差较大，聚类个数有1k+，大多为单点，但同一类内的query意图分散，图中可以看出聚类label=1时，query包含有手机号、房源录入、400电话、贝壳币等意图。

4.4 k近邻

用到的数据是用户query（圆圈表示）和标注标准问的query（菱形表示），将标注标准问的query和用户query映射到同一空间，查看离用户query最近的k个query所对应的标准问类别，若用户query周围大于的k/2的query都对应同一标准问，则用户query也作为该标准问的相似问。

knn所用数据为用户query和标注标准问的query，根据数据量的大小、k值大小分别进行对比实验。

测评1和测评3说明数据从2500增加到6w时，准确率从0.567增加到0.786（绿框），测评3和4说明了k值从5减到3时准确率从0.732增加到0.786（黄框）。

实验还尝试了在数据量一定时，分别使用k=3标注query和k=5标注query，且只有两者标注一致时才作为标签使用，发现标注的query的标签为对应标准问的准确率为0.838，可知叠加不同k值下的效果进行标注时效果较好（蓝框）。

但是测评1-5都是对训练集进行测试，测评6为对测试集进行测试，发现数据量6w时，训练集的准确率为0.732，测试集的准确率为0.599，可知模型对新数据的判断效果不佳（红圈），但是随着数据量的增长，knn效果会有所提升，后期数据积累到一定水平时，该方法还存在尝试的价值。

4.5 生成式–seq2seq+attention/SLCVAE

生成式算法需要的训练数据为标准问和标注标准问的query，以标准问为输入，对应的query为输出，训练GEN模型。预测则是输入标准问，以生成的新query作为相似问。

这里采用了两种生成式模型，seq2seq+attention和SLCVAE模型。

seq2seq+attention是在seq2seq的基础上，添加attention（注意力），当前的输入与目标状态越相似，那么在当前的输入的权重就会越大，说明当前的输出越依赖于当前的输入。

我们在统计了模型训练30轮、40轮、50轮之后的结果发现，生成的query会有字重复现象，停止较慢，且生成的query质量不高的现象。

然后尝试了阿里在19年提出的SLCVAE模型，说起SLCVAE模型要先从AE（AutoEncoder）模型开始，它就是简单的encoder、decoder，encoder输出的中间向量是确定的，为了增加输出的多样性，出现了VAE(Variational AutoEncoder)，即学习输入的均值和方差采样得到中间向量，来保证解码的多样性。

而SLCVAE（Self Labeling Conditional Variational Auto Encoder）模型则是添加了输出作为Conditional来限制生成的结果，并且添加Labeling phase，解码共用相同的参数网络。

SLCVAE的最终的效果如下：pred0、pred1、pred3、pred4都是原训练集里存在的数据，只有pred2是新生成的query。可以看出生成的query会有“照搬”训练集的情况出现，生成的query质量尚可但数量少。尝试增加数据量（37w+），”照搬”情况依然存在，调整参数增加输出的多样性，query质量下降。

4.6 算法对比

最后关于相似问的各种算法实践，进行了3个方面的对比：

挖掘难度：同义词替换>聚类、knn、生成式> 相似度

从挖掘难度上看，同义词替换难度最大，相似度的方式难度最小，原因是同义词替换需要依赖同义词，同义词的积累和总结是一个长期的过程。而聚类、knn、生成式方法，则需要标准问和标注标准问的数据，而相似度挖掘只需要标准问即可。

数据产量：日常同义词>相似度>行业同义词

数据产量上来说，由于聚类、knn、生成式方法产出效果不好，没有进行测评。剩下的日常同义词占比最大，相似度挖掘是以日志为基础，能够持续挖掘数量也很多，行业同义词由于数量较少，所以产出有限。

数据质量：行业同义词>日常同义词>相似度>聚类、knn、生成式

虽然行业同义词产量少，但是数据质量是最高的，因为它是纯人工积累的，然后是日常同义词，之后是相似度，最后是聚类、knn和生成式方法。

五、数据效果预估

我们了解了标准问和相似问的挖掘算法和流程，但是有一个问题没有解决，就是该怎么预估达到想要的指标所需的数据量？

这里我们做了一个量化标准问与匹配率之间关系的实验。

将现有标准问分成几等份依次添加到知识库中，记录库中标准问数量和匹配率的变化，可以得到拟合函数，来预测得到理想匹配率所需的标准问数量。

如右图所示，希望达到query和title的匹配率为90%时，所需要的标准问为24w+，由于是指数型的拟合曲线，希望达到query和title的匹配率为96%时，所需要的标准问数据量接近翻了一倍，需要41w多。有了这些标准问数量的预测数据，标准问的生产人员会对生产的目标更为清晰，能够更好的理解数据对于指标有多大的影响。

然后经过一段时间的标准问和相似问的积累，又统计了一下当前的匹配率，重新进行了拟合，图中红线为最新拟合结果，蓝色为第一次的拟合结果，横轴为标准问数量，纵轴为匹配率。可知，在相同标准问数量下，第二次预测的匹配率比之前的要高，但整个走势是相同的。当前统计的匹配率为58.6%，所需标准问和相似问的总量为1.26w左右，比预期的1.95w要少不少，说明先前的预估和实际效果之间的差距还是比较明显的，但走势一致，足以说明数据和效果指标之间存在指数关系。

六、总结与展望

智能客服从最初只有数据同步，把司南（知识生产方）的知识通过数据流落入到智能客服的es。然后到有标准问的挖掘，逐渐形成问题学习系统，能够使整个标注流程系统化管理，再到之后通过标准问和同义词的积累，进行相似问的挖掘，最终挖掘得到的标准问和相似问，和原知识一样写入到了es，形成了一整套知识库扩充的系统和方法。

目前为止标准问的产量大概是25条query可以总结出一条标准问，标准问总积累量是8千多，标准问最初通过聚类60w数据，产出的标准问仅3千多，虽然当时的和当前标准标准的有一些变化，但是整体来说，标准问的产出还是有很高提升的。

相似问的产出比例大概在30%-40%之间，总量在1.4w+，且相似问上线前后一周的AB实验的ctr指标有了近5%的提升（数量6K+），充分反映了数据对整体服务效果的影响。

贝壳智能客服的数据建设最终希望能够产出一个工具，当用户输入一条query，我们可以提供和这条query相似的query ，比如我们现存的标准问相似问，或者同义词替换生成的query，以及生成模型生成的query等，整个工具的结构也是遵循之前的以数据为基础，进行召回排序后输出。

毫无疑问数据是效果的基础，当算法达到一定水平的时候数据建设将会成为效果提升的关键步骤。但数据收益不是那么显而易见的，它是一个比较持久的过程，但是我们相信做好数据建设这个基础，智能客服一定能在未来收到可观的收益。

作者介绍

黄钰瑶，2019年毕业于华中科技大学，毕业后加入贝壳找房语言智能部，主要从事NLP及智能客服相关工作。

贝壳智能客服中的数据建设相关推荐

深度文本匹配在智能客服中的应用
参加2018 AI开发者大会,请点击↑↑↑ 作者 | 云知声目录一. 深度文本匹配的简介 1. 文本匹配的价值 2. 深度文本匹配的优势 3. 深度文本匹配的发展路线二. 智能客服的简介 1. ...
瓜子IM智能客服系统的数据架构设计（整理自现场演讲）
本文由ITPub根据封宇在[第十届中国系统架构师大会(SACC2018)]现场演讲内容整理而成. 1.引言瓜子业务重线下,用户网上看车.预约到店.成交等许多环节都发生在线下.瓜子IM智能客服系统的目 ...
基于深度学习的聊天机器人在网易严选智能客服中的应用
目录业务概要模型构建 KBQA模块 - NER模型语聊模块 - 生成模型模型部署总结作者业务概要随着自然语言处理技术的发展,智能客服作为电商领域内重要的业务场景,近年来受到的重视日益增 ...
太强了！美团智能客服核心技术与实践，这差距不止一点点！
客服是在用户服务体验不完美的情况下,尽可能帮助体验顺畅进行下去的一种解决办法,是问题发生后的一种兜底方案.而智能客服能让大部分简单的问题得以快速自助解决,让复杂问题有机会被人工高效解决.在用户服务的全 ...
2020最新智能客服|聊天机器人算法、架构及应用分享
智能客服(聊天机器人)是在大规模知识处理基础上发展起来的一项面向行业应用的,适用大规模知识处理.自然语言理解.知识管理.自动问答系统.推理等等技术行业,智能客服不仅为企业提供了细粒度知识管理技术,还为 ...
行业内关于智能客服、聊天机器人的应用和架构、算法分享和介绍
更多精品内容及源码,尽在"源码大数据" 阿里巴巴小蜜阿里小蜜新一代智能对话开发平台技术解析阿里小蜜:知识结构化推动智能客服升级阿里云小蜜对话机器人背后的核心算法大中台.小 ...
美团智能客服核心技术与实践
客服是在用户服务体验不完美的情况下,尽可能帮助体验顺畅进行下去的一种解决办法,是问题发生后的一种兜底方案.而智能客服能让大部分简单的问题得以快速自助解决,让复杂问题有机会被人工高效解决. 在用户服务的 ...
2023中国智能客服领域最具商业合作价值企业盘点
‍数据智能产业创新服务媒体 --聚焦数智 · 改变商业随着科技的飞速发展,人工智能已经逐渐渗透到我们生活的方方面面.在这个波澜壮阔的时代背景下,智能客服作为人工智能与现代服务业的跨界融合,正以一种前 ...
智能客服“听不懂人话”？消费者很“闹心”
智能客服与人工客服并非互相取代的关系.人工客服不能缺位,应通过人机协同更好地回应消费者诉求.在金融消费领域,建议与资金安全等密切相关的业务能够设置人工服务"一键转接"或者" ...

贝壳智能客服中的数据建设

目录