QQ浏览器搜索相关性技术演进
17位高级专家共同打造，涉及15个领域，133个体系框架，1000个细分知识点！
关注公众号"大话数智"，免费下载这份《数据智能知识地图》
前言： 搜索相关性主要指衡量 Query 和 Doc 的匹配程度，是信息检索的核心基础任务之一，也是商业搜索引擎的体验优劣最朴素的评价维度之一。
本文主要介绍 QQ 浏览器搜索相关性团队，在相关性系统、算法方面的实践经历，特别是在 QQ 浏览器·搜索、搜狗搜索两个大型系统融合过程中，在系统融合、算法融合、算法突破方面的一些实践经验，希望对搜索算法、以及相关领域内的同学有所帮助及启发。
全文目录：
- 业务介绍
- 搜索相关性介绍
- 相关性精算的系统演进
- 搜索相关性技术实践
- 小结与思考
分享嘉宾｜刘杰 腾讯QQ浏览器 应用研究员
内容来源｜作者投稿
出品社区｜DataFun
01/业务介绍
搜索业务是QQ浏览器的核心功能之一，每天服务于亿万网民的查询检索，为用户提供信息查询服务，区别于一些垂直领域的站内搜索，从索引规模、索引丰富度来看，QQ浏览器的搜索业务可以定位成综合型的全网搜索引擎。
具体来说，检索结果的类型，不仅包含传统Web网页、Web图片，也包含新型富媒体形态，例如小程序、微信公众号文章、视频四宫格卡片、智能问答等移动互联网生态下的新型富媒体资源。
从相关性的视角看，QQ浏览器的业务场景，既包含传统综合搜索引擎的基本特点，即承接不同群体、不同兴趣、不同地域的海量用户的查询Query。
从需求角度来看，QQ浏览器的搜索业务有着大量的用户主动查询，其需求种类、表达形式、结果偏好，存在非常大的差异性，对系统的检索、Query理解、相关性判别有着巨大的挑战。
同时，从资源类型角度看，依托集团自有的生态优势，QQ浏览器的搜索场景包含海量的新形态的内容搜索，例如微信公众号文章、企鹅号图文、企鹅号视频，这些资源与传统网页在内容表述、内容形式上与传统网页有着较大的区别，也对相关性算法提出了新的要求。
--
02/搜索相关性介绍
1. 搜索主体框架
在介绍相关性实践前，首先介绍下系统当前的现状，我们于2021年完成了QQ浏览器·搜索、搜狗两套系统的系统级融合，经过不断地思考、讨论、推演、演化后，整体系统的整体最终演化为如图所示的样子（示意图）。
在整个系统融合的过程中，整个团队进行了充分的人员、技术融合，同时也进行了相当长时间的系统改造。系统从逻辑上分为了两大搜索子系统，即主搜子系统和通用垂搜子系统，分别由搜狗系统、QQ浏览器·搜索系统演化而来，同时在系统顶层将两个子系统结果进行进一步融合排序，最终输出检索结果。具体来说，分为三个逻辑层次：
- 融合系统：对自然结果、垂搜特型结果（卡片）进行整页异构排序，包含点击预估、异构多目标排序等阶段，同时也会进行一些业务顶层的轻量重排序。
- 通用垂搜子系统：垂搜检索系统由QQ浏览器·搜索系统演化而来，主要用于对高速迭代、快速部署有很高要求、与通用检索逻辑有较大差别的业务。整体系统的特点是部署便捷、快速，这套系统从设计之初就充分考虑了多业务快速接入的场景，目前承接的主要是特型形态的结果。
- 主搜子系统：对用户的Query进行检索，一般会经历召回、精排两个重要阶段。索引内容的主要形态是传统Web网页、Web图片、H5形态网页等，系统的特点是业务形态、效果都相对稳定、持续，问题类型有相对的共性，适合算法处于稳定期的业务，主要的难点在于满足用户的中长尾需求。
2. 算法架构
搜索算法的计算流程，大致可以分为召回和排序两大逻辑部分。
从算法处理的Doc规模来看，在工业界的一般算法架构，都是类似金字塔型的漏斗结构（目前主搜子系统、垂搜子系统，虽然定位不同，但都遵照了上述模式）：单个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实验以及第三方评估员的Side By Side评估。下面将详介绍几种评估指标的计算方式：
- PNR：Positive-Negative Ratio是一种pairwise的评估手段，用来评估搜索相关性效果。它的物理含义是，在一个排序列表中，按照query划分，对每个query下的结果进行两两组pair，计算正序pair的数量/逆序pair的数量。值越大说明整个排序列表中正序的比例越多。
- DCG：Discounted Cumulative Gain是一种listwise的评估手段。它的物理含义是整个排序相关性，并且越靠前的item收益越高。，其中r(i)代表相关性label。
- Interleaving：Interleaving是一种在线评估用户点击偏好的实验。它是将两个排序列表的结果交织在一起曝光给用户，并记录用户最终的点击偏好。整体的感知增益计算逻辑：，其中，AB分别代表了用户点击了实验组和对照的结果，wins代表用户最终点击了实验组的结果，ties代表持平，loss则代表点击了对照组的结果。△AB>0则代表感知增益胜出，反之则代表落败。
- Side By Side评估：一种专家评估手段，标注专家会对实验组、对照组两边的排序列表进行评估，且标注专家并不知道两边分别来自哪组策略，标注过程中会记录相同一批Query下的两端效果对比，结论分位三类，即Good、Same、Bad。最后统计统计整体的Side By Side指标：(Good-Bad)/(Good + Same +Bad)。
--
03/相关性精算的系统演进
搜狗搜索作为一款历经迭代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算法对得分进行相关概率校准，能够保证跨Query、跨业务可比，同时从特征管理的角度看，也从特征割据的时代进入了三足鼎立的时代。
2. 2.0时代，统一复用
1.0阶段我们通过校准算法、相关性标准统一，输出了具有一定的物理含义的相关性得分，可以基本做到子特征保持差异的情况下实现跨业务可比的问题。此时，虽然校准可以解决系统内部的实现上的差异问题，但团队面临更核心问题是系统的近一步融合问题，具体来说：
算法融合： 如果说「大一统」「高级特征」两种模式的统一是系统级方法论的对齐，那么**「相关性算法融合」**角度，则需要近一步将执行细节对齐。如何最大化算法能力，兼两家之长，是最基本的融合初衷。
**人效问题：**系统细节的差异，算法角度看，在内部的模型、特征体系、数据结构、代码库，全部是完全不同的。维护两套大型复杂系统，分别投入则必须要面对人力折半的问题，背后的压力是可想而知的。
在上述背景下，22年我们重新对两套系统进行了整合，力图用统一的一套相关性服务，服务于主搜索系统和垂搜系统。这里介绍下我们其中一项重要的重构，重新设计构建了相关性精算服务，统一了主搜系统和垂搜系统的相关性能力，做到90%代码级别的复用。
相关性精算服务：新的相关性精算服务，定位于精算旁路系统，为搜索精排阶段提供高级相关性得分，服务内部可以高速并行获取Doc正排，进行精细化的相关性特征计算、GPU计算、模型预测等。算法统一，一套代码，90%的特征属于通用基础匹配，10%特征根据场景差异，对该业务的独有问题进行独立刻化。具体来看，新的服务相比之前提供的能力包括：
调研实验效率：新的相关性精算服务，调研实验周期由周级下降为天级，背后的效率提升，主要是由于「分布式部署」变成「单节点」部署带来的。在以前的系统，相关性大部分非GPU类的特征，均在召回层实现，这样带来的问题是，由于召回层的架构大部分都是分布式系统，调研成本相比精算模块需要更多的机器成本，这也造成了该阶段的调研需要团队共用1-2套调研环境，调研&实验成本将会大大增加。
算力能力：相关性分布式计算，最重要的贡献是能够让系统的计算条数变的更多，这种思路在GPU并行技术出现以前是非常有效的设计，将相关性计算放到召回层不仅能够最大限度的利用分布式架构，同时也节省了Doc正排在HighLevel获取的存储和带宽，这部分正排数据往往是召回层必须的，优势是可以兼顾复用。但最近几年随着深度学习、GPU并行加速技术在搜索系统越来越多的应用，业务越来越需要重型计算，这样的重型计算是召回层的算力远远无法满足的。
算法独立性：相比之前最大的区别是，新的相关性精算服务，能够与召回层解耦。我们将基础数据结构、特征计算、服务接口等，进行了重构对齐，最终做到与两套子系统的上下游独立，以实现算法统一。最终的效果是，一套代码，90%的特征属于通用基础匹配，10%特征根据场景差异，对该业务的独有问题进行差异性刻化。
--
04/搜索相关性技术实践
1. 相关性标准
QQ浏览器搜索下的相关性标准，主要用于基础相关性样本的标注，为了能精细化的表达是否相关这一概率，我们将相关、不相关这个二分类任务，拓展到了五档分类，能够提供更多的监督信息。同时，每一档的物理含义，在不同的业务下，尽量保持对等。例如，通用搜索场景、视频搜索场景下，同一档位的Doc需要具有对等的相关程度，即应具备同一等级的相关性。这样做的好处是，在High-Level场景下，通过Probility Calibration可以对不同的业务下的相关性模型得分映射到同一个体系下而获得全局可比性，同时不同业务下的相关性内部特征的实现能够保留一定的差异性，对系统非常友好。
2. 相关性的技术架构
3. 深度语义匹配实践
（1）QQ浏览器搜索相关性的困难与挑战
QQ浏览器的搜索业务每天服务于亿万网民的查询检索，因为业务场景偏向于综合搜索业务，每天的用户的查询表达都有海量量级，在这个场景下的用户Query天然的具有很强的长尾效应，对搜索相关性的匹配能力提出了巨大的挑战。
（2）深度语义的现状
为了解决一词多义等模糊表达的问题，QQ浏览器的搜索相关性场景，进行了大量的语义匹配工作实践。随着深度学习技术的兴起，基于预训练语言模型的方法，特别是基于BERT模型的语义匹配，目前是我们工作的主要研究方向。当前系统按照表达方式来看，主要包括基于表示的匹配方法（Representation-based）和基于交互的匹配方法（Interaction-based）。
基于表示的匹配方法：使用深度模型分别学习Query和Doc的Embbeding，在线通过cosine计算Query和Doc相似度来作为语义匹配分数。计算框架上，使用了经典的双塔结构，由于这种结构相对交互式模型的在线计算成本更低，目前普遍应用于粗排语义相关性的计算。
基于交互的匹配方法：将Query和Doc拼接后输入给BERT模型，经过N层Transformer Block后，将CLS Token的Embbeding接入下游相关性任务，由于交互式普遍需要比较高的计算复杂度，一般用于QQ浏览器的精排阶段。
（3）QQ浏览器搜索相关性深度语义实践
- 相关性Ranking Loss
目前我们的相关性标注标准共分为五个档位，最直接的建模方式，其实是进行N=5的N分类任务，即使用Pointwise的方式建模。
搜索场景下，我们其实并不关心分类能力的好坏，而更关心不同样本之间的偏序关系，例如对于同一个Query的两个相关结果DocA和DocB，Pointwise模型只能判断出两者与Query相关性是否处于同一个分类等级，但为同一档位时却无法区分DocA和DocB相关性程度。
因此搜索领域的任务，更多更广泛的建模思路是将其视为一个文档排序场景，广泛使用Leaning To Rank思想进行业务场景建模。其中比较典型的方法是Pairwise 方法，通过考虑两两文档之间的相关对顺序来进行排序，相比 Pointwise 方法对上述场景有明显优势。因此我们对深度语义模型的Fine-tuning任务，也进行了RankingLoss的针对性改进。Pairwise Loss下的训练框架，任务输入的单条样本为三元组的形式，在多档标注下，我们对于同一Query的多个候选Doc，选择任意一个高档位Doc和一个低档位Doc组合成三元组作为输入样本。
- 深度语义特征的物理含义
Ranking Loss的问题：相关性是搜索排序的基础能力，在整个计算流程的视角看，相关性计算不是最后一个阶段，所以当相关性内部子特征的目标如果直接使用RankingLoss，要特别注意与上下游的配合应用，特别要关注单特征的RankingLoss持续减少，是否与整体任务的提升一致。
同时，RankLoss由于不具有全局的物理含义，即不同Query下的DocA和DocB的得分是不具有可比性的，这直接导致了其作为特征值应用到下游模型时，如果我们使用决策树这种基于全局分裂增益来计算分裂阈值的模型，则会由于局部分布与全局分布的差异导致局部精度有一定的损失。
搜索系统，一般为了追求可解释性，往往会将高级特征通过一些解释性较强的模型进行融合。
以相关性高级特征的产出过程为例，我们在产出整体的相关性得分时，会使用例如XGB模型对相关性N维子特征进行最终的打分预测。如果此时放大这个打分过程，当执行到某一个决策树时，会按照当前决策树的特征分裂值判断走左子树还是右子树，这个分裂值会要求该特征在全部Query下都按照此分裂点判断，这里如果当前的特征完全使用Ranking Loss会导致在不同Query下得分不可比，因此由于该特征的分布差异与全局分裂值的冲突，在最终预测相关性高级特征时，其准确率在一部分Query下会有一定的精度损失。
实践中我们对语义特征的ranking loss，也同时进行了一部分pointwise loss结合，目的是希望单特征得分的分布尽量在全局有一定的可比性，帮助相关性模型整体的PNR提升。由图所示：
（1）当单特征持续以PairwiseLoss训练，随着训练步数的增加，单特征PNR是持续上升的，但相关性模型整体的PNR并不是线性上升的。
（2）此时，观察单特征ECE（Expected Calibration Error 期望标定误差）, ECE反应了单特征实际概率分布与输出分布差，当单特征的ECE较高时，相关性模型整体的PNR在此处下降，体现了分布差异带来的精度损失。
（3）如果将单特征变成Pairwise+PointwiseLoss，发现随着训练过程的进行，模型ECE持续下降，而且ECE显著比Pairwise方式低。此时，虽然单特征PNR微弱上升，但相关性整体的PNR能够上升，且最终高于单纯使用Pairwise的方式。
- 领域自适应
最近几年的NLP领域，预训练方向可以称得上AI方向的掌上明珠，从模型的参数规模、预训练方法、多语言多模态等几个方向持续发展，不断地刷新着领域Benchmark。在搜索领域下，如何将预训练语言模型，与搜索语料更好的结合，是我们团队一直在探索的方向。
在实践过程中，我们发现通用预训练的语料，与搜索场景的任务，依然存在不小的gap，所以一个比较朴素的思想是，是否可以将搜索领域的自有数据进行领域迁移。在实际的实验中，我们发现将搜索领域的语料，在基础预训练模型后，继续进行post-pretrain，能够有效的提升业务效果，对下游任务的提升也比较显著。
4. 相关性语义匹配增强实践
（1）深度语义匹配的鲁棒性问题
在NLP领域，预训练语言模型（Pretrained Language Model）已经在很多任务上取得了显著的成绩，PLM搭配领域Finetune也同时在工业界成为解决搜索、推荐等领域的标准范式。
在搜索相关性业务中，行业内在2019年开始，就已将神经网络模型全面转为基于Transformer结构的模型结构上来。区别于传统的字面匹配，语言模型能够有效解决Term模糊匹配的问题，但大力出奇迹的同时，也引入了很多核心词缺失等问题。例如，基于预训练语言模型，"二手车"和"二手摩托车"会判定为比较匹配，但实际上二者明显不同。如何解决此类鲁棒性问题是搜索语义匹配要解决的核心问题。
（2）什么是相关性匹配（RelevanceMatching）
搜索业务下的核心词缺失问题，我们认为传统的预训练方向并不能提供一个统一的解决方案，因为该问题属于搜索领域的特型问题，我们在实际工作中发现，搜索场景下很多形态的问题，与NLP的SemanticMatching任务的差异还是比较明显的，例如短Query和长Title的匹配等。为了强化搜索相关性的鲁棒性，我们引入了Relevance Matching的概念和对应的建模方式，二者的区别，具体来说：
Relevance Matching：注重关键词的精确匹配，相应的需要考虑核心词的识别、命中形态识别，一般需要关注query的重要性以及提取匹配信号。
Semantic Matching：一般情况下，两个片段的文本通常具有一定语法结构，和准确的单词匹配相比，注重句法结构是否匹配，Term间是否相似，任务的核心是建模Term、Phrase、Sentence间的相似关系。
（3）相关性匹配的相关工作
早期的做法：
在Transformer结构广泛应用以前，行业内早期提出过Relevance Matching的概念，主要工作大多是通过对Query和Doc的文本建立匹配矩阵，矩阵中的每一个元素是对应位置的Term相似度，然后再通过对匹配矩阵的命中Pattern进行提取，具体来说：
- MatchPyramid（中科院 2016 AAAI），构建了基于字面匹配或Embedding匹配，构建Query-Document匹配矩阵，命中提取使用CNN + Dynamic Pooling + MLP完成。
- DRMM (2016 中科院 CIKM)，提出了一个交互匹配模型结构，Query中的每一个Term分别与Doc中的所有的Term交互，将相似度离散到直方图上，通过MLP以及Q中的Term Gating Network产出得分。
- K-NRM (2017 SIGIR) ，主要贡献在于提出了RBF Kernel的Pooling方式，与之前最大的不同是，Embedding使用随机初始化并端到端训练的方式，总参数量达到了约5000w（绝大部分来自Embedding层）实验效果显著优于DRMM，其中端到端训练Embedding带来了最大幅度的提升，Kernel Pooling相比基线的pooling方式能带来小幅提升。
- PACRR (2017 EMNLP)，主要创新点是在对每一个Query Term完成Pooling后，使用LSTM建模整体的Query-Coverage，LSTM的输出直接作为最终的score。
Bert以后的做法：
大部分从预训练语言模型的角度，在MASK机制、外部知识引入、参数规模等角度进行研究，也取得了显著的效果提升。但在搜索相关性业务上，大部分交互式的应用方式，是将Query和Title完全拼接后输入Bert，最后在输出层基于CLS这个特殊Token的Embbeding做领域任务。
目前我们了解到的是，除了CEDR这个工作外，很少有直接使用非CLS以外的Token的模型架构。这里可能对Transformer比较熟悉的同学会觉得，每一个Transformer Block内部架构其实会天然的对两两Term进行Attention计算，形成多头AttentionMap，与Relevance Matching中的Matrix的设计思路几乎一致，是否还有必要继续再手动进行一次MatrixMatching的计算。对此我们在22年通过一系列实践，证明Relevance Matching的重要意义。
（4）相关性匹配增强
为了兼顾SemanticMatching和RelevanceMatching两者的能力，我们提出了HybridMratrixMatching模型，提升模型在精确匹配和语义泛化匹配两方面的综合能力。具体优化点为：
- Query-Title匹配矩阵建模
隐式匹配矩阵构造：基于BERT产出的最后一层的Token Embedding，通过Token间的Cosine作为Similarity，构造Query-Title语义匹配矩阵。
显式文本匹配矩阵构造：基于Query与Title分词后的词粒度命中信息，构造Q-T精确匹配矩阵，并进一步打平映射到与BERT输入信息相同的Token粒度。
- 语义匹配与文本匹配信息融合
CNN汇聚两种匹配矩阵信息：在模型输出层，对隐式和显式匹配矩阵拼接产出N个|Q|x|T|匹配矩阵 ，通过CNN + Weighted Sum Pooling的方式来捕捉隐式匹配Matrix和Term显式匹配Matrix相结合的命中pattern，产出匹配矩阵特征向量。
最终得分融合：将匹配矩阵侧产出的特征向量与BERT CLS特征向量拼接，融合产出最终的模型得分。
（5）实验&效果
为了能够验证Hybrid MratrixMatching模型在搜索场景下的匹配能力，我们对模型进行了离线和在线两方面的效果验证。
- 离线实验
我们对新模型进行了消融实验分析，其中几个比较重要的实验结论为：
（1）隐式MatchingMatrix结构，单独进行下游任务预测时，测试集的PNR、NDCG等指标几乎与只用CLS进行下游任务相同。进一步对比CLS侧代表的SemanticMatching能力与隐式匹配矩阵代表的RelevanceMatching能力，观察到两者在测试集上的局部表现有较大不同，二者联合会有一定的互补性。这里互补收益的来源，我们认为是通过人工将Token间的相似度组成隐式匹配矩阵，相比CLS内部的AttentionMap，能够更好的捕捉Token粒度的精确命中Pattern，特别是已有较多工作证明Transformer较高层的AttentionMap更倾向于捕捉高级语义关系而非字词级别的关系。
（2）Hybrid结构整体做下游任务，即隐式Matrix+CNN后与CLS拼接融合后，整体去做相关性任务，在PNR、NDCG指标上看，相对只用CLS进行下游任务，相对提升大约1.8% 。
（3）外部Matrix的引入，包括多层显示匹配矩阵，能够继续为模型整体的提升带来2.3%的提升。外部匹配Matrix带来的额外信息能够带来效果提升，也证明了精确匹配能力在搜索这个任务中的考核占比是比较高的，将外部精确匹配信号的引入，能够帮助模型强化这部分能力。
- 在线实验
Hybrid MratrixMatching模型目前已在搜索相关性场景下全量部署，实验期间我们通过ABTest系统和Interleaving系统对实验组效果进行观察，其中Interleaving感知相关性指标在实验期间显著正向，这也与模型升级对精确匹配、核心词命中能力提升等预期比较吻合。
第三方评估团队的SideBySide评估显示，由专家标注员对实验组和对照组进行Good、Same、Bad打分，最终随机Query下的送评结果显示，有比较显著的变好趋势。线上效果的变化，如图中的例子来看，模型能够更好的捕捉核心词的命中，对应语义飘移、抗噪声鲁邦性方面都有一定的缓解。
5. 蒸馏技术优化
（1）大模型蒸馏的问题
搜索相关性，特别是精排阶段的相关性，工业界面临的核心挑战是，业务效果与部署成本的TradeOff。
为了能够及时响应海量的用户请求，工业界往往会采用模型蒸馏等手段来最大程度的提升效果。
具体来说，模型蒸馏一般指将教师网络学习到的能力迁移学习到学生网络上来，使学生的能力能够与教师相当，这里往往学生模型为小模型，在参数规模、部署成本、响应速度远小于教师模型。在这个流程中，为了近一步提升学生网络的效果，最直接的方法是提升教师模型的能力，但通常来说，提升教师模型的主要手段，往往需要参数规模的提升，但教师网络参数规模的提升往往不一定意味着学生网络的精度提升，如何以最佳性价比提升学生网络的性能，是值得进一步研究的。
（2）为什么大模型不一定是一个好老师
尽管参数规模更大的教师模型，一般情况下，都能够显著提升教师网络的任务表现，但在知识蒸馏的流程中，大量实验发现，从工程性价比的角度看，更大参数规模的教师网络不一定是好的老师，这具体表现在随着教师网络的参数增加，教师网络在特定任务下的精度对应增加，但由于师生参数、能力差异过大造成的蒸馏损失，导致学生网络的精度并没有跟随增加，这意味着参数增加付出的成本，并没有带来业务收益。甚至会出现，一个不合适的教师网络，在知识蒸馏中会导致学生网络的能力下降。这背后的原因，大致有有两个：
任务差异性：相比有标签的监督任务，老师模型的Soft Label虽然带来更多的信息增益，但简单的学生可能没有足够的能力去模仿教师网络的行为或输出。
教师模型的Overfident问题：随着教师对任务确定性增加，从而使其logits(软目标)不那么soft，这也许会削弱了通过学习软目标实现的知识迁移。
所以，在工业系统在线成本的硬性约束下，特别是近几年预训练语言模型逐渐往更大的参数规模发展的行业趋势下，尽量减少教师网络和学生网络的蒸馏损失差，是非常有意义的工作。
（3）多步蒸馏流程
实际实践过程中，我们受到CV领域相关工作的启发，在知识蒸馏中引入Teacher Assistant（助教网络）来帮助解决上述提到的教师网络和学生网络的蒸馏损失，并且我们验证了Teacher Assistant模型的引入在搜索相关性业务上有着切实的效果增益。在经过多个版本的迭代后，我们将这个过程逐步演化为一个多步蒸馏流程。
多步蒸馏流程，相比传统的知识蒸馏流程相比，主要的升级点：
引入助教模型（TA）：
传统的知识蒸馏指，将教师网络的能力通过迁移学习的方式蒸馏到学生模型。我们在这个过程中会引入TA模型，大致的好处有3点：
（1）TA的参数规模与教师网络的参数规模更为接近，例如TA可以依然是一个大尺寸的模型，可以是介于教师网络和学生网络中间量级的参数规模，能够减少由于能力差异带来的蒸馏损失。
（2）TA模型可以不止一个，通过Teacher->TA1-> TA2 -> TAX... -> Student这样的流程，可以通过多步蒸馏的方式，进一步避免教师模型和学生模型因为参数规模、Layer间的差异较大带来蒸馏损失。
（3）TA如果与教师模型的参数规模、结构比较接近，蒸馏损失会更小，甚至出现蒸馏后比教师模型能力更强的现象，这个现象可以通过自蒸馏的收益来解释。
综合上述3点，我们认为TA的引入之所以能够减少蒸馏损失，背后主要是由于多步蒸馏在数据域广度、Soft标签学习、抗过拟合、多步知识蒸馏背后的Dark Knowledge获取等几个方面带来的收益。
TA蒸馏Student：
在这一步可以理解为传统的知识蒸馏过程，可以将TA看做教师模型，通过SoftLabel进行标准的知识蒸馏过程。其中也会采用多语料阶段蒸馏，每一个阶段分别是业务场景用到的主要目标语料，例如点击语料、相关性语料等。
（4）多步蒸馏方法实验效果
- 离线实验
离线阶段，我们主要将多步蒸馏和传统蒸馏方式进行了对比，主要的消融实验结论为：
（1）引入TA模型的个数，目前在我们的任务上验证，多个TA相比单个TA，会有增益，但也同时会增加离线调研的成本，目前基于我们教师模型和学生模型的尺寸，同时考虑离线成本，当前只引入一个TA。
（2）TA引入能够帮助学生模型在最终任务上带来精度的提升，相比传统教师模型直接蒸馏Student，大致有5%的提升。
- 在线实验
多步蒸馏方法目前已经比较广泛的在QQ浏览器搜索相关性场景应用，在我们实验过程中，在线数据方面，在线指标取得了显著的业务收益，通过ABTest系统观测，大盘的CTR、有点率均有约1~2%的相对提升。在效果的第三方人工评估环节，专家评估员的Side By Side人工效果对比结果，随机Query下也有比较显著变好趋势。
--
05/小结与思考
搜索相关性方向，是一个充满了技术挑战的硬核方向，无数网民的检索需求、五花八门的查询表达、越来越新颖的内容模态，全部对系统的相关性计算能力提出了极其艰巨的挑战。目前QQ浏览器搜索相关性团队的小伙伴们，在搜狗并入腾讯的大背景下，逐步将两套系统的优势合并，完成大量的技术重构、技术债务清理，逐步形成了一个高可用的大型相关性计算系统。接下来，我们将继续在搜索相关性领域持续投入，结合工业界、学术界在NLP领域、AI领域等最前沿的技术突破，为提升业务效果不断努力。
今天的分享就到这里，谢谢大家。
分享嘉宾
刘杰
腾讯QQ浏览器搜索技术中心 应用研究员
现任腾讯QQ浏览器搜索技术中心相关性技术Leader，主要从事NLP算法研究，负责搜索相关性Query分析方向、相关性匹配等方向。
DataFun新媒体矩阵
关于DataFun
专注于大数据、人工智能技术应用的分享与交流。发起于2017年，在北京、上海、深圳、杭州等城市举办超过100+线下和100+线上沙龙、论坛及峰会，已邀请超过2000位专家和学者参与分享。其公众号 DataFunTalk 累计生产原创文章900+，百万+阅读，近16万精准粉丝。
