搜狗怎么不显示em(搜狗emoji很少)

导读： 近年来随着搜索、语音交互、智能客服等场景的不断进化，问答技术的应用越来越丰富，本文将会介绍智能问答在QQ浏览器搜索引擎上的相关工作，通过精准、快速满足用户检索意图帮助搜索引擎的智能化升级。

搜索引擎从第一代由人工分类，到文本检索，到后面的整合分析，再到现在第四代智能搜索的概念,通过机器学习算法、NLP等技术来给用户呈现出更加全面，更加及时，更加精细化的结果，包括智能化的文本，以及结构化的知识，以及一些多模态的内容。

搜索场景里的Query需求大概分成几个方面，第一类是导航类的需求，第二类是资源类的需求，第三类是信息类的需求，信息类的需求占的比例会比较大，问答就是信息类需求中的一种。

在整体的搜索需求里，问答可以占到25~30%，如搜实体、搜关系、搜方法、搜因果等都可以通过问答的一些技术手段来满足。

以上是我们的一些业务的问答形态， 包括：普通的图文内容、列表型答案内容、医疗法律等垂类内容、结构化数据内容、事实性短答案等等。

接下来会分三条技术线条，每个线条展开一下重点模块，给大家分享一下这些业务落地的实际过程：

01

KBQA

Knowledge-Based QA

1. 什么是KBQA

知识图谱通过三元组的形式把知识组织成一张知识网络，里面包含着很多的实体关系和属性，当用户问一些结构化的知识的时候，比如说埃菲尔铁塔在哪里，直接通过里面的实体跟属性关系的查询，就可以找到目标答案；以及一些复杂的问题，需要在图谱中通过多条路径推理找到有支撑力的答案。

2. 解决方案

要去完成KBQA这件事情，解决方案有很多，这里列举两个例子，第一个是结构化的推理，基于组合范畴语法、句法依存解析query结构，并将其转换成图引擎的表达式，再做进一步推理；另一种是端到端，基于神经网络，把原始的用户Query，一站式的从文本转换成图引擎表达，然后做查询得出答案；同时也有基于子图挖掘的一些重要的方法等等。但这些方法在不同的场景上的适配也不太一样，比如短文本的场景、长文本的场景以及一些多轮对话的场景。

3. 方案选择

QQ浏览器知识图谱，包含亿级别的实体，几十亿级别的SPO三元组，涵盖了人物，影视，医疗等等十几个大的领域。基于当前图谱现状结合，结合搜索的一些特性，最终选择结构化推理的方案。

① 特点

② 结构化推理方案

结合这些特点，我们最终选择推理化的方案，主要包含四个模块，Query解析，算子引擎，图引擎以及排序：

Query解析：模板挖掘

强的假定：对于问答Query，一条三元组SPO，如果它的主实体Subject出现在了Query里面，并且它的Object出现在了Doc里面，我们假定这个query在说S和O之间的关系。Eg.刘德华的配偶是朱丽倩，如果刘德华出现在Query里，朱丽倩出现在了Doc里面，那我们就假定这个Query在说刘德华和朱丽倩的关系，他的意图就是在问配偶关系。

模板生成：通过这种方式我们能拿到很多这种Query+S+O的数据pair，这个Query即是在描述S和O的关系，这时只需要把Query中的主实体做槽位化，生成一个基础的模板；

噪声：基于这样的强假定会有很多噪声，但是基于搜索的海量数据下，聚合之后再做进一步的简化，把中间的一些通用词mask掉，生成通配，形成最后的模板+意图数据对；通过置信度打分排序后，头部模板质量可以得到控制。

Query解析：层次化模板匹配

简单匹配：“特朗普的大女儿”，“1991年出生是什么星座”，这类Q通过简单模板直接匹配就可以得到槽位和意图

复杂匹配：“爸爸的姐姐的儿子怎么称呼”，这种复杂的嵌套解析也是通过简单模板一层一层递归出来，第一层会匹配到 “[w:*][r:kinship]”，其中通配部分子串为“爸爸的姐姐的儿子”，第二层会匹配到“[w:*][r:son]”, 其中通配部分子串为“爸爸的姐姐”,最后一层会匹配到 “[d:entity-person][r:elder_sister]”。 这里层次化解析之后天然就出现了一个递归嵌套的结构，方便整个算子链的生成以及层次化的执行。

复杂模板：复杂嵌套解析中的模板都是普通模板生成而来，大部分模板既可以做简单Q的直接匹配或者嵌套底层的直接匹配，也可以是通配，做复杂解析中的上层嵌套匹配。

Query解析：模型预测

模板匹配的问题：模板的问题在于，即使量再大，它的泛化性还是不够，对于一些表达的变化或长尾化的Q，当前体系下的模板可以解决搜索KBQA里面需求的90%，需要泛化性的模型来兜住剩下10%的用户表达；

意图识别模型：首先识别Query中的Mention，然后将实体转化为槽位，原始Q变为槽位化的模板表达，如“[d:entity-person]的老婆是谁”，将这部分当前做Q1，再将实体槽位对应的候选意图当做Q2，做HRRNN的表示型匹配模型。一般这样简单表示型模型的匹配就可以兜住大部分剩余Query意图解析。有了上面Mention的识别，以及结构和意图的解析，接下来就进入到算子的推理执行过程。

结构化推理：算子引擎

这里可以讲算子分为三部分：

上图列举了一些图引擎、计算型、业务型算子，这三部分组合起来，根据整个嵌套解析的过程，以及针对意图的一些定制，生成针对Q的算子链；根据算子链的依赖关系，递归执行，取得最终的答案。

Eg. 爸爸的姐姐的儿子怎么称呼：对应算子链如上图所示， 爸爸是一个称谓实体，第一步先经过图引擎算子找到“爸爸”的姐姐这个目标实体，作为算子结果再去向上层执行；第二步根据当前实体找到“儿子”目标实体，再替换掉这个结果；最后顶层执行找到它的称谓；

总结：KBQA流程基本如上，以模板挖掘，模板匹配和解析为主，以模型的意图兜底为辅，再结合一些业务的定制化，综合去解决搜索里面可以通过结构化推理解决的问题。但是搜索中大部分还是非结构化查询，这些非结构化的Q还是要依靠DQA或者IRQA去解决。

02

DeepQA

Machine Reading Comprehension

1. 特点

DQA的数据来源非常简单，基于普通的网页文本就可以针对不同的Query抽取出不同的答案；另外适配的场景也比较多，不止在搜索场景，一些语音交互场景以及商品客服场景等等，都可以用DQA的方式做内容抽取。

2. 难点

难点一：QueryDoc理解；搜索中问答Query会比较杂，比较乱，中长尾分布严重，同时召回的Doc也是众多来源；

难点二：据识；抽取是整个DQA的核心，很多Query的候选Doc中没有正确答案或者无法解答， 且无答案比例比有答案比例高很多；一旦没有足够的支撑情况下出了答案，通常是一个bad case ；MRC模型经常会过召回一些答案，需要将这些答案据识掉，避免错误曝光；

难点三：答案选择；同一个Query下，会有很多的文档，每个文档也会抽出不同的答案来，最后需要在这些答案中进行选择，同时生成对应摘要；

3. 系统性解决方案

整个系统依据这些问题以及搜索场景的特性， 分为以下流程：

① Query理解

搜索里面25~30%是问答的Q，还有70%+是非问题的Q；对不适合DQA抽取Q的据识，以及一些必要的标签化是QU侧主要面临的问题，下面介绍下意图识别、时效性、分类标签这三部分的一些做法：

意图识别： 对于一些严重的是缺乏主成分的Query、无问题意图的Query、语意不清、计算类、寻址类等问题，需要模型判别据识掉；最终流入到下游系统的仅保留问题意图清晰、且适合DQA抽取的Query；

时效性识别： 这里将时效问题分为强弱无三类：

Type识别： Query类型区分了三十个类别，如时间、地点、人物等；分类标签有助于下游抽取模型避免抽取混淆，比如问一个人物，避免结果抽出一段描述或一个地点，给下游模型当作信号；同时也可以针对类别区分下游任务，如时间、地点、人物、实体等为短答案，定义类、观点类为长答案，步骤方法为列表答案等；

② Query理解-意图识别

在以上问题定义下，列举Query意图识别的模型优化过程：

如上图的优化路径显示，随着优化的不断进行，效果提升还是比较明显。

③ MRC抽取

MRC模型侧的优化：

MRC数据侧的优化：

MRC样本的构造成本非常高，远监督或弱监督方式构造出来的数据质量问题会导致天花板很低，人工精标数据生产成本特别高，所以在前期版本，尝试去引入外部数据来做一阶段抽取范式的学习，再迁移到自有数据上做二阶段的精标和微调，适配具体场景。

答案支撑片段假定： 如上图所示，对于Query+Paragraph+Answer三元组数据，将Para本身分成三部分：第一部分即答案片段本身；第二部分在答案周边的一定窗口内定义为支撑片段；在答案窗口的远端，将其定义为非支撑片段；MRC本身就是在学习文本对答案的支撑程度，远端的文本对它的支撑会比较弱；

增强方式： 在上述假定下 ① 把答案片段的实体切换成同类型的实体，仍然当成一个正样本，这样虽然置换了答案，但是它上下文的支撑没有变，它的类型也没有变；②把支撑片段去掉，换成其他的相近片段，变成一个负样本；③ 把非支撑片段替换成其他的相近的一些文字表达，当做正样本；

上述列举的三种增强方式，让模型学习到上下文语义的支撑性以及答案本身的类别及类型信息，而不是答案本身的文本信息；除此之外， 还会对一些错误样本进行主动学习，以及边界样本增强，一些相近Q的增强，最终也取得了比较好的效果。

④ 答案融合与排序

MRC侧本身的据识在负样本比例很大的情况下效果很弱，所以对于整个系统的据识，大部分都有后置rank部分来承担，这个环节可以拿到答案支撑片段的数量，支信号的强度，从而拿到每个答案在多文档下的支撑度，且最后的环节做据识，对准确率的提升也是直接能折射到业务侧，效果的折算更加直接。

每一个Query都会切分成多个Paragraph，每个Paragraph会抽出多个答案，在这些答案之间，先按照答案的文本做第一步的聚合，变成一个答案外加多个支撑para的答案组；

基于这样的答案组，采集各类特征：①baseweight类的特征，比如字表征的一些特征，紧密度特征、termweight加权特征等 ② MRC直出的一些特征，如NaProb、Top1AnswerProb等；③一些聚合类特征，如答案数量，答案重叠度特征等；④语义匹配类特征，如QT相关性和QP相关性等；基于上述特征融合成最终打分，做rank取best的同时，通过阈值做最后阶段的据识处理。

基于摩天的预训练模型、领域二阶段预训练、数据增强、模型对抗、特征提取融合排序等手段，在GLUE榜单的CMRC分榜上也取得了top 1的效果。

03

IRQA

Information Retrieval QA

IRQA跟DQA的区别比较大的是DQA是靠自然文本抽取，IRQA是依靠全网已有的一些QA内容：比如典型的综合类社区问答内容，以UGC为主，且各大社区体量非常大，包括百度知道、搜狗问问、爱问、悟空等；另外一类是近些年各大垂直类的站点崛起的比较快，有很多PGC专家生产的数据也越来越多且质量很高。

面对网络上的海量QA数据，直接用来构建FAQ库会有很大的质量问题，尤其是UGC的社区数据中，质量参差不齐，答非所问、时效性老旧、黄反政反、结构性杂乱等等需要进一步筛选和处理。

1. 系统方案

在线系统：

离线系统：

相对在线测，离线侧的FAQ库构建会显得比较重。

2. 相关性计算

语义相关性模块经历多个版本迭代，从最开始的手工特征+机器学习模型，演进到后续的表示型模型、交互型模型，再到最新的预训练模型；下面对方案进行简单的列举：

手工特征+XGB： 最早版本基于XGB字面量的特征进行匹配，33维的手工特征加上词嵌入embedding的向量特征，灌入XGB模型；效果在保准确的情况下会丢很多召回，且对Query的文字表达非常敏感，表达稍微变化一下就无法解决。

交互型模型： 第二版交互型模型，通过word和char双维度的输入解决oov问题；通过BiLSTM进行编码；通过BiMPM这种多维度attention进行信息交互；通过类似ESIM的思想对两个最终句向量做多种运算后融合，进行最终特征层面的增强；最后通过MLP取得最终score；相对XGB取得了很大的提升，但是在高准情况下召回仍然不足。

预训练模型： 问答领域的短Q虽然属于搜索子集，但是特性比较明显，做领域预训练效果明显，最后的模型选择用ELECTRA加上领域的预训练；此外配合上一些训练过程的优化、参数对抗等取得了当前最优效果； 这里对抗不只是反梯度的参数对抗，还有一些Query文本上的对抗，也能提升当前模型的拟合能力和打分的稳定性。

3. 大模型加速

搜索每天都会面临近十亿级别的流量，QPS也是万级别，面临庞大的搜索体量压力，在现役预训练模型的基础上，要对模型进行加速，这里我们做了一个二阶段的蒸馏加速：

第一阶段通过TinyBert层次化蒸馏的方法降低模型层数和参数量，降到两层之后再通过FastBert早出策略进行二阶段加速。最终发现很多简单的Q可以在一层的时候就早出出去，并且效果折损很小；

整体用ELECTRA + TinyBERT + FastBERT后效率可以在原ELECTRA基础上提升23倍， 效果折损可以控制在一个点以内。

整个的IRQA这里只介绍相关性计算这一块，其他的比如一些质量控制、意图的准入、时效性识别等在任务目标、数据处理上不一样，但是在模型选型优化角度上是很通用的，包括预训练模型的使用：Query级别的任务用我们自己领域的预训练模型，Doc级别的就用摩天。

04一些思考

上面介绍了KBQA、DQA、IRQA三个部分，也说一下团队对这些线条的一些思考：

首先IRQA对内容生态的依赖非常重，尤其是互联网里面的UGC数据使用到后期会有很强的瓶颈，包括质量和量级，更好的数据其实是PGC生产的垂直领域数据；对于垂直PGC站点来说，生产一些垂直领域的优质数据，希望借此吸引流量，同时对于搜索来说，缺乏这种特别优质的问答内容。所以这有一个非常强的结合点：垂直领域的站点以搜索的top1和问答为出口，通过内容供给合作甚至是定向生产作为SEO的结合，同时搜索以优质内容为依托，解决用户检索需求的同时满足站点生产商的流量诉求；现在一些搜索引擎也有这样的开放平台，来让这些垂类的站点来介入生产合作。其实我们这边也有一些尝试，后面也会加强这方面的探索。

第二方面就是DQA答案的事实性支撑会有些匮乏，经常会发现通过几篇文章里都抽出相同的答案，但其实答案是错的，这也和内容库的重复有关，互联网上有很多重复的内容，一旦重复的内容出现了错误就会很麻烦；另外KB里面又有一个“完备性”的问题，数据的不完备导致会出现漏召或错召；所以这里也有可能是去结合一下，通过KB的事实关联去解决DQA的支撑问题，通过DQA解决KB的完备性问题，二者结合做互补；所以后面也可能会去探索一些DQA跟KB的联合。

05

问答环节

Q：字面特征，XGB的标签是怎么来的？

A：DQA有BaseWeight的一些特征，其实是借鉴通搜粗排的一些特征，粗排会通过Query、title和Doc的一些字面打一些共现、紧密度、termweight类特征；XGB的特征也是类似的，计算各种维度的共现，一些子序列，各种基于向量的距离，以及文本的编辑距离等等。

Q：Query的时效性判定是怎么做的？标签是什么？

A：问答的Query时效的标签是一个三分类问题，做法和后面会有点类似，在我们自己的领域训练模型上做三类别分类，同时结合一些策略，因为有一些比较强的特征，比较明显的词，比如说股票价格这些东西直接就可以做识别和过滤，剩下的就是模型普通三分类，基于领域训练，没有什么特别的。最主要的是做完划分之后，强弱无标签要怎么使用，强类别直接过滤，弱类别圈定文档时间戳，同时对源数据做更高频次的更新抓取，同时在排序层对时间因子特征的权重进行放大。

Q：人工特征33维是怎么和embedding结合起来？

A：XGB匹配模型采用433维特征，400维里面分200维的Question句向量和200维的Query句向量，另外33维为手工特征，也包含了对两个句向量的各种距离计算。使用上，直接平铺灌入XGB就好。

Q：MRC上用了比赛用的预训练模型，在IR上用了另外一个预训练模型，这两个模型哪个强？有什么区别？

A：比赛的MRC以及我们自己的MRC是用搜索大规模预训练模型“摩天“， 摩天是在搜索场景上做的预训练，DQA的召回文档也是搜索的，摩天在当前DQA系统上会比普通的预训练模型好很多。我们自己做的那些做领域预训练，是针对Query的，因为问答的文档跟搜索通搜是差不多的，但是它的Query也是通搜的一个子集，虽然是子集，但差异化会很大，特性会很明显。对于Q级别的任务使用我们自己领域预训练BERT或者ELECTRA，对于Doc的处理使用摩天。

今天的分享就到这里，谢谢大家。

分享嘉宾：

分享嘉宾：常景冬 腾讯 高级研究员

编辑整理：高同学 中国科学院大学

出品平台：DataFunTalk

本文链接：https://www.24zzc.com/news/169348731827063.html