分享嘉宾：常景冬 腾讯 高级研究员
编辑整理：高同学 中国科学院大学
出品平台：DataFunTalk

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

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

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

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

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

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

• KBQA：基于知识图谱的推理问答
• DeepQA：基于通用文本挖掘的机器阅读理解问答
• IRQA：基于FAQ问答库的检索式问答

01 KBQA

Knowledge-Based QA

1. 什么是KBQA

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

2. 解决方案

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

3. 方案选择

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

① 特点

• 当前用户检索的表达通常比较短，甚至有一些简单的词堆砌，输入两三个词去完成一次检索。
• 搜索里面大部分还是简单的SPO查询，也会有少量的嵌套查询和限定查询，但是量比较少。
• 搜索的长尾化会很严重，也需要去考虑长尾化品类拓展的成本问题。
• 最后最重要就是需要灵活多变，要求强的可解释性，遇到问题时需要批量收敛；搜索的产品形态会比较多样化，面对业务的定制要有更深更灵活的定制需求。

② 结构化推理方案

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

• Query解析：首先AC自动机识别Mention，通过NEL做双实体链指，识别主成分后，通过嵌套模板及基础意图模型进行层次化解析
• 算子引擎：有了成分嵌套解析、结构解析以及意图后，我们就可以生成整个算子执行的过程，生成算子链，递归地执行算子和图引擎交互，做最后的推理；
• 图引擎：基于Neo4j 图引擎和简单正排索引；
• 排序：最后进行打分清洗排序以及业务化的定制，把最终的答案返回给用户。

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的识别，以及结构和意图的解析，接下来就进入到算子的推理执行过程。

结构化推理：算子引擎

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

• 图引擎算子：如查实体、查属性、查关系…
• 计算型算子：如交并计算、年龄计算、计数、排序、取Top…
• 业务型算子：如换算、内容排版、字段选取、字段加工…

上图列举了一些图引擎、计算型、业务型算子，这三部分组合起来，根据整个嵌套解析的过程，以及针对意图的一些定制，生成针对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. 系统性解决方案

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

• QU：包括问答意图的准入，问题类型的分类，强弱无时效的区分，低质Q的语法识别，一些pattern的补充识别，已经一些tagging的过程。
• 召回：主要是基于通搜的top N作为基础召回队列，额外引入百科库召回和IRQA召回；通搜里只有在实体绝对匹配时才会召回百科内容，但是百科里通常在实体不匹配的时候，一些其他的实体内容也可能会挖掘到当前Q的答案，所以这里通过百科Doc+自建Title做双域索引召回；此外自建的FAQ库通过IRQA可以召回直接满足Q的相关Answer，作为潜在答案抽取的补充文档；
• 粗排：很多文章类的内容文本很长，seqlength过长在性能上是不可接受的。这里需要将Doc切分成paragraph，再通过Query-Para的数据形式处理后续流程；同时召回文档数量较多，再进行切分后，候选数量多下游压力较大，无答案比例带来的据识问题更大，需要根据一些相关性的过滤、粗排以及截断，去降低下游服务的计算压力和据识压力。
• 抽取：进入MRC环节的通常就是优质的Query和Paragraph的数据对，这里针对Query-Para做MRC抽取，每个Paragraph都会抽出答案，再对答案进行聚合
• 答案融合：将不同para抽取出的相同答案聚合，形成Q-A-支撑ParaList的三元组，再对三元组生成各种特征
• 答案rank：根据Q-A-ParaList 三元组进行排序，选出Best answer
• summary生成：根据Best answer做最终摘要的生成

① Query理解

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

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

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

• 强时效：对于类似金价、股票价格、天气等，Query本身属于问答意图，但是不适合DQA手段来解决，更适合用一些阿拉丁卡片、一些task型的组件来解决；还有一些和事件关联的，并且跟时间相关的，比如说苹果公司财报、iphone12上市，这些Q和事件强绑定，更适合由实体知识图谱和事件图谱，去由结构化的挖掘跟更新推理解决，而不是通过文本去抽取，一旦文本内容时效滞后，或随着时间的变化，这个答案的支撑会有很大变数；
• 弱时效：对于Query一段时间之内不会变化，至少一大段时间窗之内不会变化；这类Query无需过滤，但是在选择候选文档时，对时间戳做更紧的收敛，以及在最终排序时需要对Doc及Answer时间因子权重进行提权。
• 无时效：如知识类、事实类；这类Q虽然也需要越近的文章越好，但是没有那么强的要求，如果没有近期的文章的话，一些时间戳相对较早的文章也可以，在排序侧Doc及Answer的时间因子权重不需要很重。

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

② Query理解-意图识别

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

• 二阶段预训练：针对问答短Q的模型，对比BERT,RoBERTa,ELECTRA这些优秀的预训练模型，在此基础上做二阶段领域预训练；
• 训练过程优化：在预训练模型基础上，针对训练过程优化，如通过DropPooler来做特征矫正，Layer-wise LR Decay来避免灾难性遗忘等等；
• 样本增强：通过同义样本的标签平移增强数据、通过预测高低边界样本增强数据、错误数据抽检精标做主动学习等；

• 参数对抗：增加参数对抗过程提升模型的鲁棒性，从早期FGM到近期表现较好的SMART，在众多问答相关任务的实验中都取得了不错的指标提升；除了参数的扰动, 也加了一些样本的对抗，比如给Query去加一些有用的干扰词或者无用的干扰词，让它变成正负样本，这样去手动对抗模型。

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

③ MRC抽取

MRC模型侧的优化：

• 预训练模型：阅读理解基于QQ浏览器自研的一套基于搜索领域数据以及点击行为的大规模的预训练模型“摩天”；
• 特征引入：在摩天的基础上，除了引入基础的Query，title，paragraph来做朴素的MRC抽取之外，还引用了QueryType，当做token输入指导模型下游的抽取，比如做跨领域跨类型的混淆抽取，防止问一个人却抽出地点；
• HasAnsTask：出口侧除了传统的Start/End,Span的输出，额外引入HasAns来判定是否有答案的Task，这个信号也会用到下游的答案融合和排序；整个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库进行正排+倒排+语义向量多路召回；
• 匹配：通过语义模型计算相关性打分；
• 排序：通过相关性分数、时间因子、数据来源置信度等信号，做综合排序。

离线系统：

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

• 数据选择：包括社区UGC数据、垂直领域的爬取数据、外部PGC合作数据、腾讯内部垂直领域数据等；同时也包括图文、视频、音频等多种形态的内容；共计亿级别的原始FAQ库；
• 质量管控：通过插件化的质量管理模块，共计40+的插件，如：黄反、死链、答非所问、时效性过滤、口语化识别、结构识别、结构清洗等以及一些规则类的插件；经过一整套的质量管控流程之后，进入到优质FAQ库，流入线上KV库、IR库、EM库做多路召回。

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的处理使用摩天。