当前位置：首页 > 法制聚焦 > > 正文

QQ浏览器是如何提升搜索相关性的？环球新消息

2023-01-19 10:07:11 来源：程序员客栈

导言 | 搜索相关性主要指衡量Query和Doc的匹配程度，是信息检索的核心基础任务之一，也是商业搜索引擎的体验优劣最朴素的评价维度之一。本文作者刘杰主要介绍QQ浏览器搜索相关性团队在相关性系统及算法方面的实践经历。值得一提的是，本文会特别分享在QQ浏览器搜索、搜狗搜索两个大型系统融合过程中，在系统融合、算法融合、算法突破方面的实践经验。希望对搜索算法以及相关领域内的同学有帮助。

业务介绍

搜索业务是QQ浏览器的核心功能之一，每天服务于亿万网民的查询检索，为用户提供信息查询服务，区别于一些垂直领域的站内搜索，从索引规模、索引丰富度来看，QQ浏览器的搜索业务可以定位成综合型的全网搜索引擎。具体来说，检索结果的类型，不仅包含传统Web网页、Web图片，也包含新型富媒体形态，例如小程序、微信公众号文章、视频四宫格卡片、智能问答等移动互联网生态下的新型富媒体资源。

(相关资料图)

从相关性的视角看，QQ浏览器的业务场景，既包含传统综合搜索引擎的基本特点，即承接不同群体、不同兴趣、不同地域的海量用户的查询Query。从需求角度来看，QQ浏览器的搜索业务有着大量的用户主动查询，其需求种类、表达形式、结果偏好，存在非常大的差异性，对系统的检索、Query理解、相关性判别有着巨大的挑战；同时，从资源类型角度看，依托集团自有的生态优势，QQ浏览器的搜索场景包含海量的新形态的内容搜索，例如微信公众号文章、企鹅号图文、企鹅号视频，这些资源与传统网页在内容表述、内容形式上与传统网页有着较大的区别，也对相关性算法提出了新的要求。

搜索相关性介绍

1）搜索主体框架

在介绍相关性实践前，首先介绍下系统当前的现状。我们于2021年完成了看点、搜狗两套系统的系统级融合，经过不断地思考、讨论、推演、演化后，整体系统的整体最终演化为如图所示的样子（示意图）。在整个系统融合的过程中，整个团队进行了充分的人员、技术融合，同时也进行了相当长时间的系统改造。系统从逻辑上分为了两大搜索子系统，即主搜子系统和通用垂搜子系统，分别由搜狗系统、看点系统演化而来，同时在系统顶层将两个子系统结果进行进一步融合排序，最终输出检索结果。具体来说分位，分为三个逻辑层次：

第一，融合系统：对自然结果、垂搜特型结果（卡片）进行整页异构排序，包含点击预估、异构多目标排序等阶段，同时也会进行一些业务顶层的轻量重排序或微调。

第二，通用垂搜子系统：垂搜检索系统由看点搜索系统演化而来，主要用于对接入对高速迭代、快速部署有很高要求，与通用检索逻辑有较大差别的业务。整体系统的特点是部署便捷、快速，这套系统从设计之初就充分考虑了多业务快速接入的场景，目前承接的主要是特型形态的结果。

第三，主搜子系统：对十亿级规模的索引库中，对用户的Query进行检索，一般会经历召回、精排两个重要阶段。主要的Doc形态是传统Web网页、Web图片、H5形态网页等，这套系统的特点为，业务形态、效果相对稳定、持续，问题类型有相对的共性，适合算法处于稳定器的业务，主要的难点在于满足用户的中长尾需求。

2）算法架构

搜索算法的计算流程，大致可以分为召回和排序两大逻辑部分。从算法处理的Doc规模来看，在工业界的一般算法架构，都是类似金字塔型的漏斗结构（QQ浏览器目前的主搜子系统、垂搜子系统，虽然定位不同，但都遵照了上述模式）：单个Query会从海量的索引中，检索出一个初始Doc集合，然后经过系统的几个重要的Ranking阶段，逐步对上一个阶段的Doc集合进行筛选，最终筛序出系统认为最好的N条结果。具体来说，如图所示可以分为：

第一，召回层：包含文本检索和向量检索两部分，文本检索会按照Query的核心词进行语法树构建，由倒排系统进行Doc归并、截断产出文本召回集合。向量检索部分利用深度模型将Query、Doc映射到隐空间，在线利用向量检索引擎召回与Query相似的N条结果，相比倒排检索能够充分利用PLM对Query和Doc的表示进行学习，实现近似一段式检索，相比传统的召回+粗排的二段式检索有更好的效果。

第二，粗排层：粗排层使用计算复杂度相对低的方式进行特征捕捉，基本上分为三类：第一类为相关性类特征，文本相关性、语义相关性，其中语义相关性受限于这个位置的算力，主要采用双塔结构，将Query、Doc表示为向量，用点积或者半交互得到。第二类为Query、Doc的静态特征，例如Query的一些长度、频次、Doc质量、Doc发布时间等。第三类特征为统计类特征，例如历史窗口下的用户行为数据。

第三，精排层：对粗排层输入的Doc集合进行更精细化的区分，按照搜索多目标来，精排层要对Doc以下几个维度进行综合判断，例如相关性、时效性、质量权威性、点击预估等几个维度进行综合考量。

相关性计算的位置：按照上述介绍的算法架构，QQ浏览器的搜索相关性计算主要分为粗排相关性、精排相关性两部分，其中粗排相关性用于在万级别->百级别这个筛选阶段，算法大部分使用基于倒排的文本匹配特征，同时加上双塔结构的语义特征，在计算复杂度相比精排更轻量；精排相关性，主要用于百级别->个级别的筛选，算法相比粗排，利用了Doc的正排数据，建模方式更精细和计算复杂度也相对更高，本文在算法实践方面，会偏向于介绍团队在精算阶段的经验。

3）评估体系

搜索相关性的评估，主要分为离线和在线评估。离线评估主要看重PNR以及DCG的指标变化，在线评估上主要看重interleaving实验以及人工的GSB评估。下面将详介绍几种评估指标的计算方式：

第一种，PNR：Positive-Negative Ratio是一种pairwise的评估手段，用来评估搜索相关性效果。它的物理含义是在一个排序列表中的结果按照query划分，对每个query下的结果进行两两组pair，计算正序pair的数量/逆序pair的数量。值越大说明整个排序列表中正序的比例越多。

第二种，DCG：Discounted Cumulative Gain是一种listwise的评估手段。它的物理含义是整个排序相关性，并且越靠前的item收益越高。

其中r(i)代表相关性label。一般而言K选择1或者3。

第三种，interleaving：Interleaving是一种在线评估用户点击偏好的实验。它是将两个排序列表的结果交织在一起曝光给用户，并记录用户最总的点击偏好。整体的感知增益计算逻辑:

其中wins代表用户最总点击了A列表结果，ties代表持平，loss则代表落败。

则代表感知增益胜出，反之则代表落败。

第四种，GSB：Good vs Same vs Bad 是一种采用专家评估的手段。标注专家会对左右两边的排序列表进行评估，一边是来自基线线上，一边是来自试验组线上。对于标注专家而言，他不清楚那边的结果是试验组产生的，然后对这两个排序列表进行打分，Good or Same or Bad。最后统计统计整体的GSB指标：

(Good-Bad)/(Good + Same +Bad)。

相关性精算的系统演进

搜狗搜索作为一款历经迭代18年的搜索产品，在数据积累、技术打磨、系统成熟度方面有很强的先天优势。QQ浏览器·搜索是搜索行业较为年轻的新人，在架构选型、技术代际、历史债务方面有很强的后发优势。为了兼顾两家之长，在系统融合的过程中，团队的首要目标就是充分融合两套系统的特有优势。以相关性视角来看，我们大致经历了以下几个改造时期

1）1.0时代，群雄割据->三国争霸

从相关性的视角看，面临最大的难题是两套系统相关性得分不可比的问题。具体来说：

标准差异：两套系统的相关性判定标准、标注方法不同，从根本上不可比。

建模差异：两个系统对于多目标（相关性、时效性、点击、权威性）的建模方式存在较大差异：主搜系统以End-To-End思路解决搜索多目标的问题，具体来说使用GBDT作为融合模型，所有子特征一并送入融合模型，我们后继称之为「大一统」模型。垂搜系统对多目标进行了进一步的拆解，尽量将同一个维度的特征系列汇聚形成高级特征，以相关性为例，垂搜的会存在一个单独的基础相关性精算阶段，输出相关性高级特征，再将高级特征替换所有的子特征的方式进入融合排序，我们后继称之为「抽象高级特征」。

对比思考：从系统设计上看，「大一统」VS「抽象高级特征」，是两种完全不同的思路，前者更符合机器学习的理念，暴露更多的子特征细节能够提供更多的信息；后者的思路，对目标进行了高度抽象，具有更好的可解释性。从表面看似乎没有明显的优劣可言，但从工业实践经验看，这里还是有较强的实践结论的。

下面揭晓一下结论，从工业系统设计的角度看，更倾向于「抽象高级特征」这种方案，而非「大一统」的方式。理由有以下几点：

第一点，可解释性：工业算法系统的首要考虑就是如何支撑算法持续、高效迭代。在多目标导向下，「大一统」方式下子特征规模已经达到了100维以上，逆序的问题归因相比「高级特征」来讲，归因难度大、问题会更分。这个模式也间接鼓励算法同学去新增能够带来指标提升的新特征，而不是去迭代已有的特征。

第二点，业务需求：「大一统」方式下，一旦脱离该阶段的多目标排序后，后继的更High-Level的融合场景即失去判断相关性的载体，无法对相关性维度进行比较。更High-Level的融合不得不将必要的子特征继续向上传递，往往看到某些子特征从最底层一路透传到最顶层，对子特征的可比性、覆盖率、迭代维护成本都要很大的要求

第三点，特征管理：High-Level的业务同学大量使用子特征也会造成管理混乱，一旦某些子特征在后继的业务中使用，该特征迭代就与其在后继业务中的形成了耦合，例如比较常见的通过某个特征MagicNumber进行过滤，很有可能的情况是，特征迭代时也要去调整该MagicNumber。所以，以相关性为例，使用具有物理含义的统一「高级特征」会大大减少子特征的管理问题。

改进方式：我们在垂搜子系统、主搜系统按照同样的设计思路，抽象了一个基础相关性计算阶段，这个阶段的目标是单目标的相关性，即不考察Doc的质量、时效性等。这一阶段会接管所有刻化相关性目标的特征，通过相关性模型，输出相关性高级特征。同时，相关性高级特征，会经过Probility Calibration算法将score转化为是否相关的概率（对齐标准、档位，跨系统可比），同时具有较好的分布稳定性、跨Query可比性，即具有物理含义的相关性得分。应用视角上看，分为两部分，即交给融合排序模型，替换一批刻化相关性的子特征，另外一部分是直接用于High-Level的场景，例如某些业务会将相关性大于某个阈值的Doc进行过滤或者提权。

演进总结：首先，我们明确了标准。主要的业务场景对齐了相关性标准，特别是每个档位物理含义。其次，具有物理含义的相关性得分：对相关性特征进行归纳和融合，通过Probility Calibration算法对得分进行相关概率校准，在ranking任务能力尚可的情况下，能够保证跨Query、跨业务可比，同时从特征管理的角度看，也从特征割据的时代进入了三足鼎立的时代。

2）2.0时代，统一复用

1.0阶段我们通过校准算法、相关性标准统一，输出了具有一定的物理含义相关性得分，可以基本做到子特征保持差异的情况下，基本实现跨业务可比的问题。此时，虽然校准可以解决系统内部的实现上的差异问题，但团队面临更核心问题是系统的近一步融合问题，具体来说：

第一，算法融合：如果说「大一统」「高级特征」两种模式的统一是系统级方法论的对齐，那么「相关性算法融合」角度，则需要进一步将执行细节对齐。如何最大化算法能力，兼两家之长，是最基本的融合初衷。

第二，人效问题：系统细节的差异，算法角度看，在内部的模型、特征体系、数据结构、代码库，全部是完全不同的。维护两套大型复杂系统，分别投入则必须要面对人力折半的问题，背后的压力是可想而知的。

在上述背景下，22年重新对两套系统进行了整合，力图用统一的一套相关性服务，服务于主搜索系统和垂搜系统。这里介绍下我们其中一项重要的重构，重新设计构建了相关性精算服务，统一了主搜系统和垂搜系统的相关性能力，做到90%代码级别的复用。

相关性精算服务：新的相关性精算服务，定位于精算旁路系统，为搜索精排阶段提供高级相关性得分，服务内部可以高速并行获取Doc正排，进行精细化的相关性特征计算、GPU计算、模型预测等。算法统一，一套代码，90%的特征属于通用基础匹配，10%特征根据场景差异，对该业务的独有问题进行独立刻化。具体来看，新的服务相比之前提供的能力包括：

调研实验效率：新的相关性精算服务，调研实验周期由周级下降为天级，背后的效率提升，主要是由于模块位置带来的调研环境搭建成本上的区别。在以前的系统，相关性大部分非GPU类的特征，均在召回层实现，这样带来的问题是，由于召回层的架构大部分都是分布式系统，调研成本相比精算模块需要更多的机器成本，这也造成了该阶段的调研需要团队共用1-2套调研环境，调研&实验成本将会大大增加。

算力能力：相关性分布式计算，最重要的贡献是能够让系统的计算条数变的更多，这种思路在GPU并行技术出现以前是非常有效的设计，将相关性计算放到召回层不仅能够最大限度的利用分布式架构，同时也节省了Doc正排在HighLevel获取的存储和带宽，这部分正排数据往往是召回层必须的可以兼顾复用。但最近几年随着深度学习、GPU并行加速技术在搜索系统重越来越多的应用，业务越来越需要重型计算，这样的重型计算是召回层的算力远远无法满足的，召回层的相关性计算只有基于倒排的特征，更关心是否命中、命中距离，缺少对未命中词与query的关系刻化。

算法独立性：相比之前最大的区别是，新的相关性精算服务，与召回层解耦。从基础数据结构、特包括Query信息、Doc正排，进行重构对齐，传导至特征设计、实现，也能够相应的进行统一。最终做到算法统一，一套代码，90%的特征属于通用基础匹配，10%特征根据场景差异，对该业务的独有问题进行独立刻化。

搜索相关性技术实践

1）相关性标准

QQ浏览器搜索下的相关性标准，主要用于基础相关性样本的标注，为了能精细化的表达是否相关这一概率，我们将相关、不相关这个二分类任务，拓展到了五档分类，能够提供更多的监督信息。同时，每一档的物理含义，在不同的业务下，尽量保持对等。例如，搜用搜索场景、视频搜索场景下，同一档位的Doc需要具有对等的相关程度，即应具备同一等级的相关性。这样做的好处是，在High-Level场景下，当分类能力尚可的情况下，通过Probility Calibration可以对不同的业务下的doc进行得分的比较，但仍可以对相关性内部特征的实现保留一定的差异性，对系统非常友好。

2）相关性的技术架构3）深度语义匹配实践QQ浏览器搜索相关性的困难与挑战

QQ浏览器的搜索业务每天服务于亿万网民的查询检索，因为业务场景偏向于综合搜索业务，每天的用户的查询表达都呈现海量量级，在这个场景下的用户Query天然的具备很强的长尾效应，对搜索相关性的匹配能力提出了巨大的挑战。

深度语义的现状

为了解决一词多义等模糊表达的问题，QQ浏览器的搜索相关性场景，进行了大量的语义匹配工作实践。随着深度学习技术的兴起，基于预训练语言模型的方法，特别是基于BERT模型的语义匹配，目前是我们工作的主要研究方向。当前系统按照表达方式来看，主要包括基于表示的匹配方法（Representation-based）和基于交互的匹配方法（Interaction-based）。

基于表示的匹配方法：使用深度模型分别学习Query和Doc的Embbeding，在线通过cosine计算Query和Doc相似度来作为语义匹配分数。计算框架上，借鉴百度的SimNet双塔结构，由于在线计算相对交互式模型更友好，目前普遍应用于粗排语义相关性的计算。

基于交互的匹配方法：将Query和Doc（Title）拼接后输入给BERT模型，经过N层Transformer Block后，将CLS Token的Embbeding接入下游相关性任务，由于交互式普遍需要比较高的计算复杂度，一般用于QQ浏览器的精排阶段。

QQ浏览器搜索相关性深度语义实践相关性Ranking Loss：目前我们的相关性标注标准共分为五个档位，最直接的建模方式，其实是进行N=5的N分类任务，即使用Pointwise的方式建模。搜索场景下，我们其实并不关心分类能力的好坏，而更关心不同样本之前的偏序关系，例如对于同一个Query的两个相关结果DocA和DocB，Pointwise模型只能判断出两者都与Query相关，无法区分DocA和DocB相关性程度。因此搜索领域的任务，更多更广泛的建模思路是将其视为一个文档排序场景，广泛使用Leaning To Rank思想进行业务场景建模。

Pairwise 方法通过考虑两两文档之间的相关对顺序来进行排序，相比 Pointwise 方法有明显改善，因此我们对BERT模型的Fine-tuning任务，也进行了RankingLoss的针对性改进。Pairwise Loss下的训练框架，任务输入的单条样本为三元组的形式，在多档标注下，我们对于同一Query的多个候选Doc，选择任意一个高档位Doc和一个低档位Doc组合成三元组作为输入样本。

深度语义特征的校准问题——Ranking Loss的问题：相关性是搜索排序的基础能力，在整个计算流程的视角看，相关性计算不是最后一个阶段，所以当相关性内部子特征的目标如果直接使用RankingLoss，要特别注意与上下游的配合应用，特别要关注单特征的RankingLoss持续减少，是否与整体任务的提升一致。同时，RankLoss由于不具有全局的物理含义，即不同Query下的DocA和DocB的得分是不具有可比性，这直接导致了其作为特征值应用到下游模型时，如果我们使用例如决策树这种基于全局分裂增益来划分阈值的模型，会有一定的损失。

搜索系统一般为了追求可解释性，往往会将高级特征通过一些解释性较强的模型进行融合。以相关性高级特征的产出过程为例，我们在产出整体的相关性得分时，会使用例如XGB模型对相关性N维子特征进行最终的打分预测，如果此时放大这个打分过程，即当训练好的决策树进行最终模型预测时，当执行到某一个决策树时，会按照特征分裂值判断走左子树还是右子树，这个分裂值就要求该特征在全部Query下都按照此分裂点判断，这里如果当前的特征值域在不同Query下差异很大，在个别Query下的打分准确率一定会大打折扣。

实践中我们对语义特征的ranking loss，也同时进行了一部分pointwise loss结合，目的是希望单特征得分的分布尽量在全局有一定的可比性，即对其进行一定Calibration能够帮助相关性模型整体的PNR提升。由图所示，当单特征持续以PairwiseLoss训练，随着训练步数的增加，单特征PNR是持续上升的，但其放入相关性模型后，整体的PNR并不是线性上升的，此时观察单特征ECE（Expected Calibration Error 期望标定误差）有较大波动。如果将单特征变成Pairwise+PointwiseLoss，发现随着训练过程的进行，模型ECE持续下降，单特征PNR微弱上升，且相关性整体的PNR能够上升，且最终高于单纯使用Pairwise的方式。

领域自适应：最近几年的NLP领域，预训练方向可以称得上AI方向的掌上明珠，从模型的参数规模、预训练的方法、多语言多模态等几个方向持续发展，不断地刷新着领域Benchmark。预训练通过自监督学习，从大规模数据中获得与具体任务无关的预训练模型。那么，在搜索领域下，如何将预训练语言模型，与搜索语料更好的结合，是我们团队一直在探索的方向。

在实践过程中，我们发现通用预训练的语料，与搜索场景的任务，依然存在不小的gap，所以一个比较朴素的思想是，是否可以将搜索领域的自有数据进行预训练任务。在实际的实验中，我们发现将搜索领域的语料，在基础预训练模型后，继续进行post-pretrain，能够有效的提升业务效果，对下游任务的提升，最大可以大致9%。

4）相关性语义匹配增强实践深度语义匹配的鲁棒性问题

在NLP领域，预训练语言模型（Pretrained Language Model）已经在很多任务上取得了显著的成绩，PLM搭配领域Finetune也同时在工业界成为解决搜索、推荐等领域的标准范式。在搜索相关性业务中，行业内在2019年开始，就已将神经网络模型全面转为基于Transformer结构的模型结构上来。区别于传统的字面匹配，语言模型能够有效解决Term模糊匹配的问题，但大力出奇迹的同时，也引入了很多核心词缺失等问题。例如，基于预训练语言模型，“二手车”和“二手摩托车”会判定为比较匹配，但实际上二者明显不同。如何解决此类鲁棒性问题，是预训练语言模型下的语义匹配要解决的核心问题。

什么是相关性匹配（RelevanceMatching）

搜索业务下的核心词缺失问题，我们认为传统的预训练方向并不能提供一个统一的解决方案，因为该问题属于搜索领域的特型问题，我们在实际工作中发现，搜索场景下很多形态的问题，与NLP的SemanticMatching任务的差异还是比较明显的，例如短Query和长Title的匹配。对此，我们更倾向于通过对特型问题独立建模和处理，为了强化搜索相关性的鲁棒性，提出了Relevance Matching的概念和对应的建模方式，二者的区别，具体来说：

Relevance Matching：注重关键词的精确匹配，相应的需要考虑核心词的识别、多种维度的要求。(一般需要关注query的重要性以及提取匹配信号，同时形态上Q比较短)

Semantic Matching：注重Term间的相似关系，建模Term、Phrase、Sentence间的相似关系。(偏向query，title表达是不是相似，同时认为query和title的重要性一样)

相似度匹配信号 Similarity matching signals：和准确的单词匹配相比，捕获单词、短语和句子的语义相关性/相似性更重要。语义结构 Compositional meanings：语义匹配的文本通过是具有一定语法结构的，使用语义结构的含义会非常有效。全局匹配 Global matching requirement：语义匹配通常将文本的两个片段作为一个整体来推理它们之间的语义关系。