本地生活的内容搜索，应该啥样

hzx5 · 2022 年10 月 30 日 03:20

1. 引言

挑战与思路

搜索是大众点评App上用户进行信息查找的最大入口，是连接用户和信息的重要纽带。而用户搜索的方式和场景非常多样，并且由于对接业务种类多，流量差异大，为大众点评搜索（下文简称点评搜索）带来了巨大的挑战，具体体现在如下几个方面：

意图多样：用户查找的信息类型和方式多样。信息类型包括POI、榜单、UGC、攻略、达人等。以找店为例，查找方式包括按距离、按热度、按菜品和按地理位置等多种方式。例如用户按照品牌进行搜索时，大概率是需要寻找距离最近或者常去的某家分店；但用户搜索菜品时，会对菜品推荐人数更加敏感，而距离因素会弱化。
业务多样：不同业务之间，用户的使用频率、选择难度以及业务诉求均不一样。例如家装场景用户使用频次很低，行为非常稀疏，距离因素弱，并且选择周期可能会很长；而美食多为即时消费场景，用户行为数据多，距离敏感。
用户类型多样：不同的用户对价格、距离、口味以及偏好的类目之间差异很大；搜索需要能深度挖掘到用户的各种偏好，实现定制化的“千人千面”的搜索。
LBS的搜索：相比电商和通用搜索，LBS的升维效应极大地增加了搜索场景的复杂性。例如对于旅游用户和常驻地用户来说，前者在搜索美食的时候可能会更加关心当地的知名特色商户，而对于距离相对不敏感。

上述的各项特性，叠加上时间、空间、场景等维度，使得点评搜索面临比通用搜索引擎更加独特的挑战。而解决这些挑战的方法，就需要升级NLP（Natural Language Processing，自然语言处理）技术，进行深度查询理解以及深度评价分析，并依赖知识图谱技术和深度学习技术对搜索架构进行整体升级。在美团NLP中心以及大众点评搜索智能中心两个团队的紧密合作之下，经过短短半年时间，点评搜索核心KPI在高位基础上仍然大幅提升，是过去一年半涨幅的六倍之多，提前半年完成全年目标。

基于知识图谱的搜索架构重塑

美团NLP中心正在构建全世界最大的餐饮娱乐知识图谱——美团大脑（相关信息请参见《美团大脑：知识图谱的建模方法及其应用》）。它充分挖掘关联各个场景数据，用NLP技术让机器“阅读”用户公开评论，理解用户在菜品、价格、服务、环境等方面的喜好，构建人、店、商品、场景之间的知识关联，从而形成一个“知识大脑”[1]。通过将知识图谱信息加入到搜索各个流程中，我们对点评搜索的整体架构进行了升级重塑，图1为点评搜索基于知识图谱搭建的5层搜索架构。本篇文章是“美团大脑”系列文章第二篇（系列首篇文章请参见《美团餐饮娱乐知识图谱——美团大脑揭秘》)，主要介绍点评搜索5层架构中核心排序层的演变过程，文章主要分为如下3个部分：

核心排序从传统机器学习模型到大规模深度学习模型的演进。
搜索场景深度学习排序模型的特征工程实践。
适用于搜索场景的深度学习Listwise排序算法——LambdaDNN。

图1 基于知识图谱的点评搜索5层架构

2. 排序模型探索与实践

搜索排序问题在机器学习领域有一个单独的分支，Learning to Rank（L2R）。主要分类如下:

根据样本生成方法和Loss Function的不同，L2R可以分为Pointwise、Pairwise、Listwise。
按照模型结构划分，可以分为线性排序模型、树模型、深度学习模型，他们之间的组合（GBDT+LR，Deep&Wide等）。

在排序模型方面，点评搜索也经历了业界比较普遍的迭代过程：从早期的线性模型LR，到引入自动二阶交叉特征的FM和FFM，到非线性树模型GBDT和GBDT+LR，到最近全面迁移至大规模深度学习排序模型。下面先简单介绍下传统机器学习模型（LR、FM、GBDT）的应用和优缺点，然后详细介绍深度模型的探索实践过程。

传统机器学习模型

图2 几种传统机器学习模型结构

LR可以视作单层单节点的线性网络结构。模型优点是可解释性强。通常而言，良好的解释性是工业界应用实践比较注重的一个指标，它意味着更好的可控性，同时也能指导工程师去分析问题优化模型。但是LR需要依赖大量的人工特征挖掘投入，有限的特征组合自然无法提供较强的表达能力。
FM可以看做是在LR的基础上增加了一部分二阶交叉项。引入自动的交叉特征有助于减少人工挖掘的投入，同时增加模型的非线性，捕捉更多信息。FM能够自动学习两两特征间的关系，但更高量级的特征交叉仍然无法满足。
GBDT是一个Boosting的模型，通过组合多个弱模型逐步拟合残差得到一个强模型。树模型具有天然的优势，能够很好的挖掘组合高阶统计特征，兼具较优的可解释性。GBDT的主要缺陷是依赖连续型的统计特征，对于高维度稀疏特征、时间序列特征不能很好的处理。

深度神经网络模型

随着业务的发展，在传统模型上取得指标收益变得愈发困难。同时业务的复杂性要求我们引入海量用户历史数据，超大规模知识图谱特征等多维度信息源，以实现精准个性化的排序。因此我们从2018年下半年开始，全力推进L2核心排序层的主模型迁移至深度学习排序模型。深度模型优势体现在如下几个方面：

强大的模型拟合能力：深度学习网络包含多个隐藏层和隐藏结点，配合上非线性的激活函数，理论上可以拟合任何函数，因此十分适用于点评搜索这种复杂的场景。
强大的特征表征和泛化能力：深度学习模型可以处理很多传统模型无法处理的特征。例如深度网络可以直接中从海量训练样本中学习到高维稀疏ID的隐含信息，并通过Embedding的方式去表征；另外对于文本、序列特征以及图像特征，深度网络均有对应的结构或者单元去处理。
自动组合和发现特征的能力：华为提出的DeepFM，以及Google提出的DeepCrossNetwork可以自动进行特征组合，代替大量人工组合特征的工作。

下图是我们基于Google提出的Wide&Deep模型搭建的网络结构[2]。其中Wide部分输入的是LR、GBDT阶段常用的一些细粒度统计特征。通过较长周期统计的高频行为特征，能够提供很好的记忆能力。Deep部分通过深层的神经网络学习Low-Order、高纬度稀疏的Categorical型特征，拟合样本中的长尾部分，发现新的特征组合，提高模型的泛化能力。同时对于文本、头图等传统机器学习模型难以刻画的特征，我们可以通过End-to-End的方式，利用相应的子网络模型进行预处理表示，然后进行融合学习。

图3 Deep&Wide模型结构图

3. 搜索深度排序模型的特征工程实践

深度学习的横空出世，将算法工程师从很多人工挖掘和组合特征的事情中解放出来。甚至有一种论调，专做特征工程的算法工程师可能面临着失业的风险。但是深度学习的自动特征学习目前主要集中体现在CV领域，CV领域的特征数据是图片的像素点——稠密的低阶特征，深度学习通过卷积层这个强力工具，可以自动对低阶特征进行组合和变换，相比之前人工定义的图像特征从效果上来说确实更加显著。在NLP领域因为Transformer的出现，在自动特征挖掘上也有了长足的进步，BERT利用Transformer在多个NLP Task中取得了State-of-The-Art的效果。

但是对于CTR预估和排序学习的领域，目前深度学习尚未在自动特征挖掘上对人工特征工程形成碾压之势，因此人工特征工程依然很重要。当然，深度学习在特征工程上与传统模型的特征工程也存在着一些区别，我们的工作主要集中在如下几个方面。

3.1 特征预处理

特征归一化：深度网络的学习几乎都是基于反向传播，而此类梯度优化的方法对于特征的尺度非常敏感。因此，需要对特征进行归一化或者标准化以促使模型更好的收敛。
特征离散化：工业界一般很少直接使用连续值作为特征，而是将特征离散化后再输入到模型中。一方面因为离散化特征对于异常值具有更好的鲁棒性，其次可以为特征引入非线性的能力。并且，离散化可以更好的进行Embedding，我们主要使用如下两种离散化方法：
- 等频分桶：按样本频率进行等频切分，缺失值可以选择给一个默认桶值或者单独设置分桶。
- 树模型分桶：等频离散化的方式在特征分布特别不均匀的时候效果往往不好。此时可以利用单特征结合Label训练树模型，以树的分叉点做为切分值，相应的叶子节点作为桶号。
特征组合：基于业务场景对基础特征进行组合，形成更丰富的行为表征，为模型提供先验信息，可加速模型的收敛速度。典型示例如下：
- 用户性别与类目之间的交叉特征，能够刻画出不同性别的用户在类目上的偏好差异，比如男性用户可能会较少关注“丽人”相关的商户。
- 时间与类目之间的交叉特征，能够刻画出不同类目商户在时间上的差异，例如，酒吧在夜间会更容易被点击。

3.2 万物皆可Embedding

深度学习最大的魅力在于其强大的特征表征能力，在点评搜索场景下，我们有海量的用户行为数据，有丰富的商户UGC信息以及美团大脑提供的多维度细粒度标签数据。我们利用深度学习将这些信息Embedding到多个向量空间中，通过Embedding去表征用户的个性化偏好和商户的精准画像。同时向量化的Embedding也便于深度模型进一步的泛化、组合以及进行相似度的计算。

3.2.1 用户行为序列的Embedding

用户行为序列（搜索词序列、点击商户序列、筛选行为序列）包含了用户丰富的偏好信息。例如用户筛选了“距离优先”时，我们能够知道当前用户很有可能是一个即时消费的场景，并且对距离较为敏感。行为序列特征一般有如下图所示的三种接入方式:

Pooling：序列Embedding后接入Sum/Average Pooling层。此方式接入成本低，但忽略了行为的时序关系。
RNN：LSTM/GRU接入，利用循环网络进行聚合。此方式能够考虑行为序列的时序关系；代价是增大了模型复杂度，影响线上预测性能。
Attention：序列Embedding后引入Attention机制，表现为加权的Sum Pooling；相比LSTM/GRU计算开销更低[4]。

图4 行为序列特征接入的几种方法

同时，为了突显用户长期偏好和短期偏好对于排序的不同影响，我们按照时间维度对行为序列进行了划分：Session、半小时、一天、一周等粒度，也在线上取得了收益。

3.2.2 用户ID的Embedding

一种更常见的刻画用户偏好的方式，是直接将用户ID经过Embedding后作为特征接入到模型中，但是最后上线的效果却不尽如人意。通过分析用户的行为数据，我们发现相当一部分用户ID的行为数据较为稀疏，导致用户ID的Embedding没有充分收敛，未能充分刻画用户的偏好信息。

Airbnb发表在KDD 2018上的文章为这种问题提供了一种解决思路[9]——利用用户基础画像和行为数据对用户ID进行聚类。Airbnb的主要场景是为旅游用户提供民宿短租服务，一般用户一年旅游的次数在1-2次之间，因此Airbnb的用户行为数据相比点评搜索会更为稀疏一些。

图5 按照用户画像和行为信息聚类

如上图所示，将用户画像特征和行为特征进行离散分桶，拼接特征名和所属桶号，得到的聚类ID为：US_lt1_pn3_pg3_r3_5s4_c2_b1_bd2_bt2_nu3。

我们也采取了类似Airbnb的方案，稀疏性的问题得到了很好的解决，并且这样做还获得了一些额外的收益。大众点评作为一个本地化的生活信息服务平台，大部分用户的行为都集中自己的常驻地，导致用户到达一个新地方时，排序个性化明显不足。通过这种聚类的方式，将异地有相同行为的用户聚集在一起，也能解决一部分跨站的个性化问题。

3.2.3 商户信息Embedding

商户Embedding除了可以直接将商户ID加入模型中之外，美团大脑也利用深度学习技术对UGC进行大量挖掘，对商家的口味、特色等细粒度情感进行充分刻画，例如下图所示的“好停车”、“菜品精致”、“愿意再次光顾”等标签。

图6 美团大脑提供的商家细粒度情感标签

这些信息与单纯的商户星级、点评数相比，刻画的角度更多，粒度也更细。我们将这些标签也进行Embedding并输入到模型中：

直连：将标签特征做Pooling后直接输入模型。这种接入方式适合端到端的学习方式；但受输入层大小限制，只能取Top的标签，容易损失抽象实体信息。
分组直连：类似于直连接入的方式，但是先对标签进行分类，如菜品/风格/口味等类别；每个分类取Top N的实体后进行Pooling生成不同维度的语义向量。与不分组的直连相比，能够保留更多抽象信息。
子模型接入：可以利用DSSM模型，以标签作为商户输入学习商户的Embedding表达。此种方式能够最大化保留标签的抽象信息，但是线上实现和计算成本较高。

3.2.4 加速Embedding特征的收敛

在我们的深度学习排序模型中，除了Embedding特征，也存在大量Query、Shop和用户维度的强记忆特征，能够很快收敛。而Embedding特征是更为稀疏的弱特征，收敛速度较慢，为了加速Embedding特征的收敛，我们尝试了如下几种方案：

低频过滤：针对出现频率较低的特征进行过滤，可以很大程度上减少参数量，避免过拟合。
预训练：利用多类模型对稀疏Embedding特征进行预训练，然后进入模型进行微调：
- 通过无监督模型如Word2vec、Fasttext对用户-商户点击关系建模，生成共现关系下的商户Embedding。
- 利用DSSM等监督模型对Query-商户点击行为建模得到Query和商户的Embedding。
Multi-Task：针对稀疏的Embedding特征，单独设置一个子损失函数，如下图所示。此时Embedding特征的更新依赖两个损失函数的梯度，而子损失函数脱离了对强特征的依赖，可以加快Embedding特征的收敛。

图7 Multi-Task加速Embedding特征收敛

3.3 图片特征

图片在搜索结果页中占据了很大的展示面积，图片质量的好坏会直接影响用户的体验和点击，而点评商户首图来自于商户和用户上传的图片，质量参差不齐。因此，图片特征也是排序模型中较为重要的一类。目前点评搜索主要用了以下几类图片特征：

基础特征：提取图片的亮度、色度饱和度等基础信息，进行特征离散化后得到图片基础特征。
泛化特征：使用ResNet50进行图片特征提取[3]，通过聚类得到图片的泛化特征。
质量特征：使用自研的图片质量模型，提取中间层输出，作为图片质量的Embedding特征。
标签特征：提取图片是否是食物、环境、价目表、Logo等作为图片分类和标签特征。

图8 图片特征接入

4. 适用于搜索场景的深度学习Listwise排序算法：LambdaDNN

4.1 搜索业务指标与模型优化目标的Gap

通常模型的预测目标与业务指标总会存在一些Gap。如果模型的预测目标越贴近业务目标，越能保证模型优化的同时业务指标也能够有相应的提升；反之则会出现模型离线指标提升，但线上关键业务指标提升不明显，甚至出现负向的问题。工业届大部分深度学习排序采用Pointwise的Log Loss作为损失函数，与搜索业务指标有较大的Gap。体现在如下两个方面：

搜索业务常用的指标有QV_CTR或者SSR(Session Success Rate)，更关心的是用户搜索的成功率（有没有发生点击行为）；而Pointwise的Log Loss更多是关注单个Item的点击率。
搜索业务更关心排在页面头部结果的好坏，而Pointwise的方法则对于所有位置的样本一视同仁。

图9 Pointwise和Listwise优化目标的区别

基于上述理由，我们对于深度学习模型的损失函数进行了优化。

4.2 优化目标改进：从Log Loss到NDCG

为了让排序模型的优化目标尽量贴近搜索业务指标，需要按照Query计算损失，且不同位置的样本具有不同的权重。搜索系统常用的指标NDCG(Normalized Discounted Cumulative Gain)相较于Log Loss显然更贴近搜索业务的要求，NDCG计算公式如下：

累加部分为DCG(Discounted Cumulative Gain)表示按照位置折损的收益，对于Query下的结果列表l，函数G表示对应Doc的相关度分值，通常取指数函数，即G(lj)=2lj-1（lj表示的是相关度水平，如{0，1，2}）；函数 η 即位置折损，一般采用 η(j)=1/log(j+1)，Doc与Query的相关度越高且位置越靠前则DCG值会越大。另外，通常我们仅关注排序列表页前k位的效果，Zk 表示 DCG@k 的可能最大值，以此进行归一化处理后得到的就是NDCG@k。

问题在于NDCG是一个处处非平滑的函数，直接以它为目标函数进行优化是不可行的。LambdaRank提供了一种思路：绕过目标函数本身，直接构造一个特殊的梯度，按照梯度的方向修正模型参数，最终能达到拟合NDCG的方法[6]。因此，如果我们能将该梯度通过深度网络进行反向传播，则能训练一个优化NDCG的深度网络，该梯度我们称之为Lambda梯度，通过该梯度构造出的深度学习网络称之为LambdaDNN。

要了解Lambda梯度需要引入LambdaRank。LambdaRank模型是通过Pairwise来构造的，通常将同Query下有点击样本和无点击样本构造成一个样本Pair。模型的基本假设如下式所示，令Pij为同一个Query下Doci相比Docj更相关的概率，其中si和sj分别为Doci和Docj的模型得分：

使用交叉熵为损失函数，令Sij表示样本Pair的真实标记，当Doci比Docj更相关时（即Doci有被用户点击，而Docj没有被点击），有Sij=1，否则为-1；则损失函数可以表示为：

在构造样本Pair时，我们可以始终令i为更相关的文档，此时始终有Sij≡1，代入上式并进行求导，则损失函数的梯度为：

到目前为止，损失函数的计算过程中并未考虑样本所在的位置信息。因此进一步对梯度进行改造，考虑Doci和Docj交换位置时的NDCG值变化，下式即为前述的Lambda梯度。可以证明，通过此种方式构造出来的梯度经过迭代更新，最终可以达到优化NDCG的目的。

Lambda梯度的物理意义如下图所示。其中蓝色表示更相关（用户点击过）的文档，则Lambda梯度更倾向于位置靠上的Doc得到的提升更大（如红色箭头所示）。有了Lambda梯度的计算方法，训练中我们利用深度网络预测同Query下的Doc得分，根据用户实际点击Doc的情况计算Lambda梯度并反向传播回深度网络，则可以得到一个直接预测NDCG的深度网络。

图10 Lambda梯度的物理意义

4.3 LambdaDNN的工程实施

我们利用TensorFlow分布式框架训练LambdaDNN模型。如前文所述，Lambda梯度需要对同Query下的样本进行计算，但是正常情况下所有的样本是随机Shuffle到各个Worker的。因此我们需要对样本进行预处理：

通过QueryId进行Shuffle，将同一个Query的样本聚合在一起，同一个Query的样本打包进一个TFRecord。
由于每次请求Query召回的Doc数不一样，对于可变Size的Query样本在拉取数据进行训练时需要注意，TF会自动补齐Mini-Batch内每个样本大小一致，导致输入数据中存在大量无意义的默认值样本。这里我们提供两点处理方式：

MR过程中对Key进行处理，使得多个Query的样本聚合在一起，然后在训练的时候进行动态切分。
读取到补齐的样本，根据设定的补齐标记获取索引位，去除补齐数据。

图11 Lambda梯度的分布式实现

为了提升训练效率，我们与基础研发平台数据平台中心紧密协同，一起探索并验证了多项优化操作：

将ID类特征的映射等操作一并在预处理中完成，减少多轮Training过程中的重复计算。
将样本转TfRecord，利用RecordDataSet方式读取数据并计算处理，Worker的计算性能大概提升了10倍。
Concat多个Categorical特征，组合成Multi-Hot的Tensor进行一次Embedding_Lookup操作，减少Map操作的同时有助于参数做分片存储计算。
稀疏Tensor在计算梯度以及正则化处理时保留索引值，仅对有数值的部分进行更新操作。
多个PS服务器间进行分片存储大规模Tensor变量，减少Worker同步更新的通讯压力，减少更新阻塞，达到更平滑的梯度更新效果。

整体下来，对于30亿左右的样本量、上亿级别的特征维度，一轮迭代大概在半小时内完成。适当的增加并行计算的资源，可以达到分钟级的训练任务。

4.4 进一步改进优化目标

NDCG的计算公式中，折损的权重是随着位置呈指数变化的。然而实际曝光点击率随位置变化的曲线与NDCG的理论折损值存在着较大的差异。

对于移动端的场景来说，用户在下拉滑动列表进行浏览时，视觉的焦点会随着滑屏、翻页而发生变动。例如用户翻到第二页时，往往会重新聚焦，因此，会发现第二页头部的曝光点击率实际上是高于第一页尾部位置的。我们尝试了两种方案去微调NDCG中的指数位置折损：

根据实际曝光点击率拟合折损曲线：根据实际统计到的曝光点击率数据，拟合公式替代NDCG中的指数折损公式，绘制的曲线如图12所示。
计算Position Bias作为位置折损：Position Bias在业界有较多的讨论，其中[7][8]将用户点击商户的过程分为观察和点击两个步骤：a.用户需要首先看到该商户，而看到商户的概率取决于所在的位置；b.看到商户后点击商户的概率只与商户的相关性有关。步骤a计算的概率即为Position Bias，这块内容可以讨论的东西很多，这里不再详述。

图12 真实位置折损与理论折损的差别

经过上述对NDCG计算改造训练出的LambdaDNN模型，相较Base树模型和Pointwise DNN模型，在业务指标上有了非常显著的提升。

图13 LambdaDNN离线NDCG指标与线上PvCtr效果对比

4.5 Lambda深度排序框架

Lambda梯度除了与DNN网络相结合外，事实上可以与绝大部分常见的网络结构相结合。为了进一步学习到更多交叉特征，我们在LambdaDNN的基础上分别尝试了LambdaDeepFM和LambdaDCN网络；其中DCN网络是一种加入Cross的并行网络结构，交叉的网络每一层的输出特征与第一层的原始输入特征进行显性的两两交叉，相当于每一层学习特征交叉的映射去拟合层之间的残差。

图14 DCN模型结构

离线的对比实验表明，Lambda梯度与DCN网络结合之后充分发挥了DCN网络的特点，简洁的多项式交叉设计有效地提升模型的训练效果。NDCG指标对比效果如下图所示：

图15 Lambda Loss与DCN网络结果的效果

5. 深度学习排序诊断系统

深度学习排序模型虽然给业务指标带来了大幅度的提升，但由于深度学习模型的“黑盒属性”导致了巨大的解释性成本，也给搜索业务带来了一些问题：

日常搜索Bad Case无法快速响应：搜索业务日常需要应对大量来自于用户、业务和老板们的“灵魂拷问”，“为何这个排序是这样的”，“为什么这家商户质量跟我差不多，但是会排在我的前面”。刚切换到深度学习排序模型的时候，我们对于这样的问题显得手足无措，需要花费大量的时间去定位问题。
无法从Bad Case中学习总结规律持续优化：如果不明白为什么排序模型会得出一个很坏的排序结果，自然也无法定位模型到底出了什么问题，也就无法根据Bad Case总结规律，从而确定模型和特征将来的优化方向。
模型和特征是否充分学习无从得知：新挖掘一些特征之后，通常我们会根据离线评测指标是否有提升决定特征是否上线。但是，即使一个有提升的特征，我们也无法知道这个特征是否性能足够好。例如，模型拟合的距离特征，会不会在特定的距离段出现距离越远反而打分越高的情况。

这些问题都会潜在带来一些用户无法理解的排序结果。我们需要对深度排序模型清晰地诊断并解释。

关于机器学习模型的可解释性研究，业界已经有了一些探索。Lime(Local Interpretable Model-Agnostic Explanations)是其中的一种，如下图所示：通过对单个样本的特征生成扰动产生近邻样本，观察模型的预测行为。根据这些扰动的数据点距离原始数据的距离分配权重，基于它们学习得到一个可解释的模型和预测结果[5]。举个例子，如果需要解释一个情感分类模型是如何预测“我讨厌这部电影”为负面情感的，我们通过丢掉部分词或者乱序构造一些样本预测情感，最终会发现，决定“我讨厌这部电影”为负面情感的是因为“讨厌”这个词。

图16 Lime解释器的工作原理

基于Lime解释器的思想，我们开发了一套深度模型解释器工具——雅典娜系统。目前雅典娜系统支持两种工作模式，Pairwise和Listwise模式：

Pairwise模式用来解释同一个列表中两个结果之间的相对排序。通过对样本的特征进行重新赋值或者替换等操作，观察样本打分和排序位次的变化趋势，诊断出当前样本排序是否符合预期。如下图所示，通过右侧的特征位次面板可以快速诊断出为什么“南京大牌档”的排序比“金时代顺风港湾”要更靠前。第一行的特征位次信息显示，若将“金时代顺风港湾”的1.3km的距离特征用“南京大牌档”的0.2km的距离特征进行替换，排序位次将上升10位；由此得出，“南京大牌档”排在前面的决定性因素是因为距离近。
Listwise模式与Lime的工作模式基本类似，通过整个列表的样本生成扰动样本，训练线性分类器模型输出特征重要度，从而达到对模型进行解释的目的。

图17 深度学习排序诊断系统：雅典娜

6. 总结与展望

2018年下半年，点评搜索完成了从树模型到大规模深度学习排序模型的全面升级。团队在深度学习特征工程、模型结构、优化目标以及工程实践上都进行了一些探索，在核心指标上取得了较为显著的收益。当然，未来依然有不少可以探索的点。

在特征层面，大量知识图谱提供的标签信息尚未充分挖掘。从使用方式上看，简单以文本标签的形式接入，损失了知识图谱的结构信息，因此，Graph Embedding也是未来需要尝试的方向。同时团队也会利用BERT在Query和商户文本的深层语义表达上做一些工作。

模型结构层面，目前线上依然以全连接的DNN网络结构为主，但DNN网络结构在低秩数据的学习上不如DeepFM和DCN。目前LambdaDeepFM和LambdaDCN在离线上已经取得了收益，未来会在网络结构上做进一步优化。

在模型优化目标上，Lambda Loss计算损失的时候，只会考虑Query内部有点击和无点击的样本对，大量无点击的Query被丢弃，同时，同一个用户短时间内在不同Query下的行为也包含着一些信息可以利用。因此，目前团队正在探索综合考虑Log Loss和Lambda Loss的模型，通过Multi-Task和按照不同维度Shuffle样本让模型充分学习，目前我们已经在线下取得了一些收益。

最后，近期Google开源的TF Ranking提出的Groupwise模型也对我们有一些启发。目前绝大部分的Listwise方法只是体现在模型训练阶段，在打分预测阶段依然是Pointwise的，即只会考虑当前商户相关的特征，而不会考虑列表上下文的结果，未来我们也会在这个方向上进行一些探索。

参考资料

作者简介

非易，2016年加入美团点评，高级算法工程师，目前主要负责点评搜索核心排序层的研发工作。
祝升，2016年加入美团点评，高级算法工程师，目前负责点评搜索核心排序层的研发工作。
汤彪，2013年加入美团点评，高级算法专家，点评平台搜索技术负责人，致力于深层次查询理解和大规模深度学习排序的技术落地。
张弓，2012年加入美团点评，美团点评研究员。目前主要负责点评搜索业务演进，及集团搜索公共服务平台建设。
仲远，博士，美团AI平台部NLP中心负责人，点评搜索智能中心负责人。在国际顶级学术会议发表论文30余篇，获得ICDE 2015最佳论文奖，并是ACL 2016 Tutorial “Understanding Short Texts”主讲人，出版学术专著3部，获得美国专利5项。此前，博士曾担任微软亚洲研究院主管研究员，以及美国Facebook公司Research Scientist。曾负责微软研究院知识图谱、对话机器人项目和Facebook产品级NLP Service。

hzx5 · 2022 年10 月 30 日 03:24

1. 背景

点评搜索是大众点评App的核心入口之一，用户通过搜索来满足不同场景下对生活服务类商户的找店需求。搜索的长期目标是持续优化搜索体验，提升用户的搜索满意度，这需要我们理解用户搜索意图，准确衡量搜索词与商户之间的相关程度，尽可能展示相关商户并将更相关的商户排序靠前。因此，搜索词与商户的相关性计算是点评搜索的重要环节。

大众点评搜索场景面临的相关性问题复杂多样，用户的搜索词比较多样，例如搜索商户名、菜品、地址、类目以及它们之间的各种复杂组合，同时商户也有多种类型的信息，包括商户名、地址信息、团单信息、菜品信息以及其他各种设施和标签信息等，导致Query与商户的匹配模式异常复杂，容易滋生出各种各样的相关性问题。具体来说，可以分为如下几种类型：

文本误匹配：在搜索时，为保证更多商户被检索和曝光，Query可能会被拆分成更细粒度的词进行检索，因此会带来Query错误匹配到商户不同字段的问题，如图1(a)所示的用户搜“生蚝火锅”应该想找汤底中包含生蚝的火锅，而“生蚝”和“火锅”分别匹配到商户的两个不同菜品。
语义偏移：Query与商户字面匹配，但商户与Query的主要意图在语义上不相关，如“奶茶”-“黑糖珍珠奶茶包”，如图1(b)所示。
类目偏移：Query与商户字面匹配且语义相关，但主营类目与用户需求不符，例如用户搜索“水果”时一家提供“果盘”的KTV商户明显与用户的需求不相关。

(a) 文本误匹配示例

(b) 语义偏移示例

图1 点评搜索相关性问题示例

基于字面匹配的相关性方法无法有效应对上述问题，为了解决搜索列表中的各类不符合用户意图的不相关问题，需要更准确地刻画搜索词与商户的深度语义相关性。本文在基于美团海量业务语料训练的MT-BERT预训练模型的基础上，在大众点评搜索场景下优化Query与商户（POI，对应通用搜索引擎中的Doc）的深度语义相关性模型，并将Query与POI的相关性信息应用在搜索链路各环节。

本文将从搜索相关性现有技术综述、点评搜索相关性计算方案、应用实战、总结与展望四个方面对点评搜索相关性技术进行介绍。其中点评搜索相关性计算章节将介绍我们如何解决商户输入信息构造、使模型适配点评搜索相关性计算及模型上线的性能优化等三项主要挑战，应用实战章节将介绍点评搜索相关性模型的离线及线上效果。

2. 搜索相关性现有技术

搜索相关性旨在计算Query和返回Doc之间的相关程度，也就是判断Doc中的内容是否满足用户Query的需求，对应NLP中的语义匹配任务（Semantic Matching）。在大众点评的搜索场景下，搜索相关性就是计算用户Query和商户POI之间的相关程度。

文本匹配方法：早期的文本匹配任务仅考虑了Query与Doc的字面匹配程度，通过TF-IDF、BM25等基于Term的匹配特征来计算相关性。字面匹配相关性线上计算效率较高，但基于Term的关键词匹配泛化性能较差，缺少语义和词序信息，且无法处理一词多义或者多词一义的问题，因此漏匹配和误匹配现象严重。

传统语义匹配模型：为弥补字面匹配的缺陷，语义匹配模型被提出以更好地理解Query与Doc的语义相关性。传统的语义匹配模型主要包括基于隐式空间的匹配：将Query和Doc都映射到同一个空间的向量，再用向量距离或相似度作为匹配分，如Partial Least Square（PLS）[1]；以及基于翻译模型的匹配：将Doc映射到Query空间后进行匹配或计算Doc翻译成Query的概率[2]。

随着深度学习和预训练模型的发展，深度语义匹配模型也被业界广泛应用。深度语义匹配模型从实现方法上分为基于表示（Representation-based）的方法及基于交互（Interaction-based）的方法。预训练模型作为自然语言处理领域的有效方法，也被广泛使用在语义匹配任务中。

(a) 基于表示的多域相关性模型

(b) 基于交互的相关性模型

图2 深度语义匹配相关性模型

基于表示的深度语义匹配模型：基于表示的方法分别学习Query及Doc的语义向量表示，再基于两个向量计算相似度。微软的DSSM模型[3]提出了经典的双塔结构的文本匹配模型，即分别使用相互独立的两个网络构建Query和Doc的向量表示，用余弦相似度衡量两个向量的相关程度。微软Bing搜索的NRM[4]针对Doc表征问题，除了基础的Doc标题和内容，还考虑了其他多源信息（每类信息被称为一个域Field），如外链、用户点击过的Query等，考虑一个Doc中有多个Field，每个Field内又有多个实例（Instance），每个Instance对应一个文本，如一个Query词。模型首先学习Instance向量，将所有Instance的表示向量聚合起来就得到一个Field的表示向量，将多个Field的表示向量聚合起来得到最终Doc的向量。SentenceBERT[5]将预训练模型BERT引入到双塔的Query和Doc的编码层，采用不同的Pooling方式获取双塔的句向量，通过点乘、拼接等方式对Query和Doc进行交互。

大众点评的搜索相关性早期模型就借鉴了NRM和SentenceBERT的思想，采用了图2(a)所示的基于表示的多域相关性模型结构，基于表示的方法可以将POI的向量提前计算并存入缓存，线上只需计算Query向量与POI向量的交互部分，因此在线上使用时计算速度较快。

基于交互的深度语义匹配模型：基于交互的方法不直接学习Query和Doc的语义表示向量，而是在底层输入阶段就让Query和Doc进行交互，建立一些基础的匹配信号，再将基础匹配信号融合成一个匹配分。ESIM[6]是预训练模型引入之前被业界广泛使用的经典模型，首先对Query和Doc进行编码得到初始向量，再用Attention机制进行交互加权后与初始向量进行拼接，最终分类得到相关性得分。

引入预训练模型BERT进行交互计算时，通常将Query和Doc拼接作为BERT句间关系任务的输入，通过MLP网络得到最终的相关性得分[7]，如图2(b)所示。CEDR[8]在BERT句间关系任务获得Query和Doc向量之后，对Query和Doc向量进行拆分，进一步计算Query与Doc的余弦相似矩阵。美团搜索团队[9]将基于交互的方法引入美团搜索相关性模型中，引入商户品类信息进行预训练，并引入实体识别任务进行多任务学习。美团到店搜索广告团队[10]提出了将基于交互的模型蒸馏到基于表示的模型上的方法，实现双塔模型的虚拟交互，在保证性能的同时增加Query与POI的交互。

3. 点评搜索相关性计算

基于表示的模型重在表示POI的全局特征，缺乏线上Query与POI的匹配信息，基于交互的方法可以弥补基于表示方法的不足，增强Query和POI的交互，提升模型表达能力，同时，鉴于预训练模型在文本语义匹配任务上的强劲表现，点评搜索相关性计算确定了基于美团预训练模型MT-BERT[11]的交互式方案。将基于预训练模型的交互式BERT应用在点评搜索场景的相关性任务中时，仍存在诸多挑战：

如何更好地构造POI侧模型输入信息：Doc侧模型输入信息的构造是相关性模型中的重要环节。在通用网页搜索引擎中，Doc的网页标题对相关性的判断极为重要，但在点评搜索场景下，POI信息具有字段多、信息复杂的特点，不存在能提供类似“网页标题”信息量的字段，每个商户都通过商户名、类目、地址、团单、商户标签等多种结构化信息来表达。在计算相关性分数时，大量多源商户信息无法全部输入到模型中，而仅使用商户名和类目等基础信息又会因为信息缺失无法达到满意的效果，因此如何更好地构造具有丰富信息量的POI侧模型输入是我们要解决的首要问题。
如何优化模型来更好地适配点评搜索相关性计算：大众点评搜索场景中的文本信息与通用的预训练模型语料信息有一定差异，例如通用语义场景下“开心”和“高兴”同义，但在点评搜索的场景下“开心烧烤”和“高兴烧烤”却是两家完全不同的品牌。同时，Query和POI的相关性判定逻辑与通用NLP场景的语义匹配任务也不完全相同，Query和POI的匹配模式非常复杂，当Query匹配到POI的不同字段时，相关性的判定结果也有所不同，例如Query“水果”匹配到“水果店”商户类目时相关性较高，而命中KTV的“水果拼盘”标签时则相关性较弱。因此，相比通用的基于交互的BERT句间关系语义匹配任务，相关性计算还需要关注Query和POI两部分之间的具体匹配情况。如何优化模型来适配点评搜索的场景，并能处理复杂多样的相关性判断逻辑，尽可能地解决各种不相关问题，是我们面临的主要挑战；
如何解决预训练相关性模型的在线性能瓶颈：基于表示的模型虽计算速度较快但表达能力有限，基于交互的模型可以增强Query和POI的交互从而提升模型效果，但在线上使用时存在较大的性能瓶颈。因此，在线上使用12层BERT的基于交互的模型时，如何在保证模型计算效果的同时保证整个计算链路的性能，使其在线上稳定高效运行，是相关性计算线上应用的最后一道关卡。

经过不断探索与尝试，我们针对POI侧的复杂多源信息，构造了适配点评搜索场景的POI文本摘要；为了让模型更好地适配点评搜索相关性计算，采用了两阶段训练的方法，并根据相关性计算的特点改造了模型结构；最后，通过优化计算流程、引入缓存等措施，成功降低了模型实时计算和整体应用链路的耗时，满足了线上实时计算BERT的性能要求。

3.1 如何更好地构造POI侧模型输入信息

在判定Query与POI的相关程度时，POI侧有十几个参与计算的字段，某些字段下的内容特别多（例如一个商户可能有上百个推荐菜），因此需要找到合适的方式抽取并组织POI侧信息，输入到相关性模型中。通用搜索引擎（如百度），或常见垂类搜索引擎（如淘宝），其Doc的网页标题或商品标题信息量丰富，通常是相关性判定过程中Doc侧模型输入的主要内容。

如图3(a)所示，在通用搜索引擎中，通过搜索结果的标题可以一眼看出对应网站的关键信息及是否与Query相关，而在图3(b)的搜索结果中，仅通过商户名字段无法得到充足的商户信息，需要结合商户类目（奶茶果汁）、用户推荐菜品（奥利奥利奶茶）、标签（网红店）、地址（武林广场）多个字段才能判断该商户与Query“武林广场网红奶茶”的相关性。

(a) 通用搜索引擎搜索结果示例

(b) 大众点评App搜索结果示例

图3 通用搜索引擎与大众点评搜索结果对比

标签抽取是业界比较通用的抽取主题信息的途径，因此我们首先尝试了通过商户标签来构造POI侧模型输入的方法，根据商户的评论、基础信息、菜品、商户对应的头部搜索点击词等抽取出具有代表性的商户关键词来作为商户标签。在线上使用时，将已抽取的商户标签，及商户名和类目基础信息一起作为模型的POI侧输入信息，与Query进行交互计算。然而，商户标签对商户信息的覆盖仍不够全面，例如用户搜索菜品“鸡蛋羹”时，某个距用户很近的韩式料理店有鸡蛋羹售卖，但该店的招牌菜、头部点击词等均与“鸡蛋羹”无关，导致该店所抽取的标签词也与“鸡蛋羹”相关性较低，因此模型会将该店判断为不相关，从而对用户体验带来伤害。

为了获取最全面的POI表征，一种方案是不抽取关键词，直接将商户的所有字段拼接到模型输入中，但是这种方式会因为模型输入长度过长而严重影响线上性能，且大量冗余信息也会影响模型表现。

为构造更具信息量的POI侧信息作为模型输入，我们提出了POI匹配字段摘要抽取的方法，即结合线上Query的匹配情况实时抽取POI的匹配字段文本，并构造匹配字段摘要作为POI侧模型输入信息。POI匹配字段摘要抽取流程如图4所示，我们基于一些文本相似度特征，将与Query最相关且最具信息量的文本字段提取出来，并融合字段类型信息构建成匹配字段摘要。线上使用时，将已抽取的POI匹配字段摘要、商户名及类目基础信息一起作为POI侧模型输入。

图4 POI匹配字段摘要抽取流程

在确定POI侧模型输入信息后，我们采用BERT句间关系任务，先用MT-BERT对Query侧和POI侧匹配字段摘要信息进行编码，然后使用池化后的句向量计算相关分。采用POI匹配字段摘要的方案构造POI侧模型输入信息后，配合样本迭代，相比基于标签的方法，模型的效果有了极大的提升。

3.2 如何优化模型来更好地适配点评搜索相关性计算

让模型更好地适配点评搜索相关性计算任务包含两层含义：大众点评搜索场景下的文本信息与MT-BERT预训练模型使用的语料在分布上存在着一定的差异；预训练模型的句间关系任务与Query和POI的相关性任务也略有不同，需要对模型结构进行改造。经过不断探索，我们采用基于领域数据的两阶段训练方案，结合训练样本构造，使预训练模型更适配点评搜索场景的相关性任务；并提出了基于多相似矩阵的深度交互相关性模型，加强Query和POI的交互，提升模型对复杂的Query和POI信息的表达能力，优化相关性计算效果。

3.2.1 基于领域数据的两阶段训练

为了有效利用海量用户点击数据，并使预训练模型MT-BERT更适配点评搜索相关性任务，我们借鉴百度搜索相关性[12]的思想，引入多阶段训练方法，采用用户点击和负采样数据进行第一阶段领域适配的预训练（Continual Domain-Adaptive Pre-training），采用人工标注数据进行第二阶段训练（Fine-Tune），模型结构如下图5所示：

图5 基于点击及人工标注数据的两阶段训练模型结构

基于点击数据的第一阶段训练

引入点击数据作为第一阶段训练任务的直接原因是在点评搜索场景下存在着一些特有的问题，例如“开心”和“高兴”两个词在通用场景下是几乎完全同义的词，但是在点评搜索的场景下“开心烧烤”和“高兴烧烤”却是两家完全不同的品牌商户，因此点击数据的引入能够帮助模型学习到搜索场景下的一些特有知识。但是直接将点击样本用于相关性判断会存在较大噪声，因为用户点击某个商户可能是由于排序较为靠前导致的误点击，而未点击某个商户也可能仅仅是因为商户距离较远，而并不是因为相关性问题，因此我们引入了多种特征和规则来提高训练样本自动标注的准确率。

在构造样本时，通过统计是否点击、点击位次、最大点击商户距用户的距离等特征筛选候选样本，将曝光点击率大于一定阈值的Query-POI对作为正例，并根据业务特点对不同类型商户调整不同的阈值。在负例的构造上，Skip-Above采样策略将位于点击商户之前且点击率小于阈值的商户才做为负样本。此外，随机负采样的方式可以为训练样本补充简单负例，但考虑随机负采样时也会引入一些噪声数据，因此我们利用人工设计的规则对训练数据进行降噪：当Query的类目意图与POI的类目体系较为一致时或者与POI名高度匹配时，则将其从负样本中剔除。

基于人工标注数据的第二阶段训练

经过第一阶段训练后，考虑到无法完全清除掉点击数据中的噪音，以及相关性任务的特点，因此需要引入基于人工标注样本的第二阶段训练来对模型进行纠偏。除了随机采样一部分数据交给人工去标注外，为了尽可能提升模型的能力，我们通过难例挖掘和对比样本增强方式生产大量高价值样本交给人工去标注。具体如下：

1）难例挖掘

特定类型样本挖掘：通过设计一种基于Query和POI的特征和两者的匹配情况来刻画BadCase类型的方法，自动化从候选数据集中筛选出特定BadCase类型的样本进行送标。
用户点击过但线上旧版模型判定为不相关的：该方法可以挖掘出当前线上模型预测错误及语义接近的用户难以区分的难例。
边缘采样：通过边缘采样的方式挖掘具有较高不确定性的样本，如抽取模型预测得分在阈值附近的样本。
模型或人工识别困难的样本：用当前模型预测训练集，将模型预测结果与标注标签不一致的样本，及人工标注标签有冲突的样本类型重新送标。

2）对比样本增强：借鉴对比学习的思想，为一些高度匹配的样本生成对比样本进行数据增强，并进行人工标注确保样本标签的准确率。通过对比样本之间的差异，模型可以关注到真正有用的信息，同时提升对同义词的泛化能力，从而得到更好的效果。

针对菜品词较容易出现的跨菜品匹配的相关性问题（例如搜“鹅肝汉堡”匹配到售卖“牛肉汉堡”和“鹅肝寿司”的商家），分别用菜品的各个子成分与推荐菜字段进行匹配，生产大量对比样本，加强模型对于跨菜品匹配问题的识别能力。
针对菜品词命中推荐菜前缀的问题，通过改造完全匹配到推荐菜的情况（搜“榴莲蛋糕”匹配到售卖“榴莲蛋糕”的商家），仅保留搜索词中的前缀，构造出匹配推荐菜前缀的对比样本（搜”榴莲”和售卖”榴莲蛋糕”的商家），使模型能更好的区分匹配推荐菜前缀时的情况。

图6 对比样本增强示例

以跨菜品匹配的相关性问题为例，如上图6所示，同样是Query拆开后与商户的多个推荐菜字段匹配的情况，Query“榴莲蛋糕”与推荐菜“榴莲千层、黑森林蛋糕”是相关的，但Query“鹅肝汉堡”与“铁板鹅肝、芝士牛肉汉堡”是不相关的，为了增强模型对这类高度匹配但结果相反的Case的识别能力，我们构造了“榴莲蛋糕”与“榴莲千层”、“鹅肝汉堡”与“铁板鹅肝”这两组对比样本，去掉了与Query在文本上匹配但对模型判断没有帮助的信息，让模型学到真正决定是否相关的关键信息，同时提升模型对“蛋糕”和“千层”这类同义词的泛化能力。类似地，其他类型的难例同样可以用这种样本增强方式来提升效果。

3.2.2 基于多相似矩阵的深度交互模型

BERT句间关系是一个通用的NLP任务，用于判断两个句子的关系，而相关性任务是计算Query和POI的相关程度。在计算过程中，句间关系任务不仅计算Query与POI的交互，还计算Query内部和POI内部的交互，而相关性计算更关注Query与POI的交互。此外，在模型迭代过程中，我们发现部分类型的困难BadCase对模型的表达能力有更高要求，例如文本高度匹配但不相关的类型。因此，为进一步提升模型对复杂的Query和POI在相关性任务上的计算效果，我们对第二阶段训练中的BERT句间关系任务进行改造，提出了基于多相似矩阵的深度交互模型，通过引入多相似矩阵来对Query和POI进行深度交互，引入indicator矩阵以更好地解决困难BadCase问题，模型结构如下图7所示：

图7 基于多相似矩阵的深度交互相关性模型

受CEDR[8]的启发，我们将经过MT-BERT编码后的Query和POI向量进行拆分，用于显式地计算两部分的深度交互关系，将Query和POI拆分并进行深度交互，一方面可以专门用于学习Query与POI的相关程度，另一方面，增加的参数量可以提升模型的拟合能力。

参考MatchPyramid[13]模型，深度交互相关性模型计算了四种不同的Query-Doc相似矩阵并进行融合，包括Indicator、Dot-product、余弦距离及欧氏距离，并与POI部分的输出进行Attention加权。其中Indicator矩阵用来描述Query与POI的Token是否一致，计算方式如下：

Indicator矩阵可以较好地刻画Query和POI的匹配关系，该矩阵的引入主要考虑到判定Query和POI相关程度时的一个难点：有时即使文本高度匹配，两者也不相关。基于交互的BERT模型结构更容易将文本匹配程度高的Query和POI判定为相关，但是在点评搜索场景中，有些难例却未必如此。比如“豆汁”和“绿豆汁”虽然高度匹配，但并不相关。“猫空”和“猫的天空之城”虽然是拆开匹配，但因为前者是后者的缩写而相关。因此，将不同的文本匹配情况通过Indicator矩阵直接输入给模型，让模型显式地接收“包含”、“拆开匹配”等文本匹配情况，在帮助模型提升对难例判别能力的同时，也不会影响大部分正常的Case的表现。

基于多相似矩阵的深度交互相关性模型将Query和POI拆分后计算相似矩阵，相当于让模型对Query和POI进行显式交互，使模型更加适配相关性任务。多个相似矩阵则增加了模型对Query和POI相关程度计算的表征能力，而Indicator矩阵则是针对相关性任务中复杂的文本匹配情况做的特殊设计，让模型对不相关结果的判断更加准确。

3.3 如何解决预训练相关性模型的在线性能瓶颈

将相关性计算部署在线上时，现有方案通常会采用知识蒸馏的双塔结构[10,14]以保证线上计算效率，但此种处理方式或多或少对于模型的效果是有损的。点评搜索相关性计算为保证模型效果，在线上使用了基于交互的12层BERT预训练相关性模型，需要对每个Query下的数百个POI经过12层BERT的模型预测。为保证线上计算效率，我们从模型实时计算流程和应用链路两个角度出发，通过引入缓存机制、模型预测加速、引入前置黄金规则层、将相关性计算与核心排序并行化等措施优化相关性模型在线上部署时的性能瓶颈，使得12层基于交互的BERT相关性模型在线上稳定高效运行，保证可以支持数百个商户和Query间的相关性计算。

3.3.1 相关性模型计算流程性能优化

图8 相关性模型线上计算流程图

点评搜索相关性模型的线上计算流程如图8所示，通过缓存机制及TF-Serving模型预测加速来优化模型实时计算的性能。

为有效利用计算资源，模型线上部署引入缓存机制，将高频Query的相关性得分写入缓存。后续调用时会优先读取缓存，若命中缓存则直接输出打分，未命中缓存的则进行线上实时计算。缓存机制大大节省了计算资源，有效缓解在线计算的性能压力。

对未命中缓存的Query，将其处理为Query侧模型输入，通过图4所述的流程获取每个POI的匹配字段摘要，并处理为POI侧模型输入格式，再调用线上相关性模型输出相关分。相关性模型部署在TF-Serving上，在模型预测时，采用美团机器学习平台的模型优化工具ART框架（基于Faster-Transformer[15]改进）进行加速，在保证精度的同时极大地提高了模型预测速度。

3.3.2 应用链路性能优化

图9 相关性模型在点评搜索链路中的应用

相关性模型在搜索链路中的应用如上图9所示，通过引入前置黄金规则、将相关性计算与核心排序层并行化来优化整体搜索链路中的性能。

为了进一步对相关性调用链路加速，我们引入了前置黄金规则对Query分流，对部分Query通过规则直接输出相关分，从而缓解模型计算压力。在黄金规则层中利用文本匹配特征对Query和POI进行判断，例如，若搜索词跟商户名完全一致，则通过黄金规则层直接输出“相关”的判定，而无需通过相关性模型计算相关分。

在整体计算链路中，相关性计算过程与核心排序层进行并发操作，以保证相关性计算对搜索链路的整体耗时基本无影响。在应用层，相关性计算被用在搜索链路的召回和排序等多个环节。为降低搜索列表的首屏不相关商户占比，我们将相关分引入到LTR多目标融合排序中进行列表页排序，并采用多路召回融合策略，利用相关性模型的结果，仅将补充召回路中的相关商户融合到列表中。

4. 应用实战

4.1 离线效果

为精准反映模型迭代的离线效果，我们通过多轮人工标注方式构造了一批Benchmark，考虑到当前线上实际使用时主要目标为降低BadCase指标，即对不相关商户的准确识别，我们采用负例的准确率、召回率、F1值作为衡量指标。经过两阶段训练、样本构造及模型迭代带来的收益如下表1所示：

表1 点评搜索相关性模型迭代离线指标

初始方法（Base）采用Query拼接POI匹配字段摘要信息的BERT句对分类任务，Query侧模型输入采用用户输入的原始Query，POI侧采用商户名、商户类目及匹配字段摘要文本拼接方式。引入基于点击数据的两阶段训练后，负例F1指标相比Base方法提升1.84%，通过引入对比样本、难例样本持续迭代训练样本并配合第二阶段的模型输入构造，负例F1相比Base显著提升10.35%，引入基于多相似矩阵的深度交互方法后，负例F1相比Base提升11.14%。模型在Benchmark上的整体指标也达到了AUC为0.96，F1为0.97的高值。

4.2 线上效果

为有效衡量用户搜索满意度，点评搜索每天对线上实际流量进行抽样并人工标注，采用列表页首屏BadCase率作为相关性模型效果评估的核心指标。相关性模型上线后，点评搜索的月平均BadCase率指标相比上线前显著下降了2.9pp（Percentage Point，百分比绝对点），并在后续几周BadCase率指标稳定在低点附近，同时，搜索列表页的NDCG指标稳定提升2pp。可以看出相关性模型可以有效识别不相关商户，显著降低了搜索的首屏不相关性问题占比，从而提升了用户的搜索体验。

下图10列举了部分线上BadCase解决示例，小标题是该示例对应的Query，左边为应用了相关性模型的实验组，右边为对照组。图10(a)中当搜索词为“佩姐”时，相关性模型将商户核心词包含“佩姐”的商户“佩姐名品”判断为相关，并将用户可能想找但输错的高质目标商户“珮姐老火锅”也判断为相关，同时，通过引入地址字段标识，将地址中位于“珮姐”旁边的商户判断为不相关；图10(b)中用户通过Query“柚子日料自助”想找一家名为“柚子”的日料自助店，相关性模型将拆词匹配到有柚子相关商品售卖的日料自助店“竹若金枪鱼”正确判断为不相关并将其排序靠后，保证展示在靠前的均为更符合用户主要需求的商户。

(a) 佩姐

(b) 柚子日料自助

图10 线上BadCase解决示例

5. 总结与展望

本文介绍了大众点评搜索相关性模型的技术方案及应用实战。为了更好地构造商户侧模型输入信息，我们引入了实时抽取商户匹配字段摘要文本的方法来构造商户表征作为模型输入；为了优化模型来更好地适配点评搜索相关性计算，使用了两阶段训练的方式，采用基于点击和人工标注数据的两阶段训练方案来有效利用大众点评的海量用户点击数据，并根据相关性计算的特点提出了基于多相似矩阵的深度交互结构，进一步提升相关性模型的效果；为缓解相关性模型的线上计算压力，在线上部署时引入缓存机制和TF-Serving预测加速，引入黄金规则层对Query分流，将相关性计算与核心排序层并行化，从而满足了线上实时计算BERT的性能要求。通过将相关性模型应用在搜索链路各环节，显著降低了不相关问题占比，有效改善了用户的搜索体验。

目前，点评搜索相关性模型在模型表现及线上应用上仍有提升空间，在模型结构方面，我们将探索更多领域先验知识的引入方式，例如识别Query中实体类型的多任务学习、融入外部知识优化模型的输入等；在实际应用方面，将进一步细化为更多档位，以满足用户对于精细化找店的需求。我们还会尝试将相关性的能力应用到非商户模块中，优化整个搜索列表的搜索体验。

6. 参考文献

[1] Rosipal R, Krämer N. Overview and recent advances in partial least squares[C]//International Statistical and Optimization Perspectives Workshop” Subspace, Latent Structure and Feature Selection”. Springer, Berlin, Heidelberg, 2005: 34-51.
[2] Gao J, He X, Nie J Y. Clickthrough-based translation models for web search: from word models to phrase models[C]//Proceedings of the 19th ACM international conference on Information and knowledge management. 2010: 1139-1148.
[3] Huang P S, He X, Gao J, et al. Learning deep structured semantic models for web search using clickthrough data[C]//Proceedings of the 22nd ACM international conference on Information & Knowledge Management. 2013: 2333-2338.
[4] Zamani, H., Mitra, B., Song, X., Craswell, N., & Tiwary, S. (2018, February). Neural ranking models with multiple document fields. In Proceedings of the eleventh ACM international conference on web search and data mining(WSDM) (pp. 700-708).
[5] Reimers N, Gurevych I. Sentence-bert: Sentence embeddings using siamese bert-networks[J]. arXiv preprint arXiv:1908.10084, 2019.
[6] Chen Q, Zhu X, Ling Z H, et al. Enhanced LSTM for Natural Language Inference[C]//Proceedings of the 55th Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers). 2017: 1657-1668.
[7] Nogueira R, Yang W, Cho K, et al. Multi-stage document ranking with bert[J]. arXiv preprint arXiv:1910.14424, 2019.
[8] MacAvaney S, Yates A, Cohan A, et al. CEDR: Contextualized embeddings for document ranking[C]//Proceedings of the 42nd International ACM SIGIR Conference on Research and Development in Information Retrieval. 2019: 1101-1104.
[9] 李勇, 佳昊等. BERT在美团搜索核心排序的探索和实践.
[10] 邵雯, 杨扬等. 预训练技术在美团到店搜索广告中的应用.
[11] 杨扬, 佳昊等. 美团BERT的探索和实践.
[12] Zou L, Zhang S, Cai H, et al. Pre-trained language model based ranking in Baidu search[C]//Proceedings of the 27th ACM SIGKDD Conference on Knowledge Discovery & Data Mining. 2021: 4014-4022.
[13] Pang L, Lan Y, Guo J, et al. Text matching as image recognition[C]//Proceedings of the AAAI Conference on Artificial Intelligence. 2016, 30(1).
[14] 阿里文娱深度语义搜索相关性探索. https://mp.weixin.qq.com/s/1aNd3dxwjCKUJACSq1uF-Q.
[15] Faster Transformer. DeepLearningExamples/FasterTransformer at master · NVIDIA/DeepLearningExamples · GitHub.

7. 本文作者

校娅 * 、沈元 * 、朱迪、汤彪、张弓等，均来自美团/点评事业部搜索技术中心。

本文共同一作。

hzx5 · 2022 年10 月 30 日 03:32

1 引言

随着大数据、人工智能等信息技术的快速发展，云计算已经无法满足特定场景对数据隐私、高实时性的要求。借鉴边缘计算的思想，在终端部署 AI 能力逐渐步入大众的视野，“端智能”的概念应运而生。相比于传统的云计算，在智能手机等终端部署运行 AI 模块有以下几个方面的优势：首先，数据本地化可以缓解云存储的压力，也有利于用户数据的隐私保护；其次，计算的本地化可以缓解云计算过载问题；最后，端智能减少了和云端系统的请求通信成本，可以更好地利用用户在端上的交互，提供更加实时、个性化的服务体验。

在端智能的应用方面，国内外各大科技公司已经走在了前列。Google 提出了 Recommendation Android App 的概念，根据用户兴趣进行内容推荐；Apple 的 Face ID 识别、Siri 智能助手等一些我们熟知的产品，也都是端智能典型的应用代表。阿里巴巴、快手、字节跳动等企业也在各自的应用场景上进行了端智能的落地，并推出相应的端上模型推理框架。比如，快手上线的短视频特效拍摄、智能识物等功能。另外，在搜索推荐场景下也有一些实践，其中，手机淘宝“猜你喜欢”在端上部署了智能推荐系统，取得较为显著收益（EdgeRec[1]，双十一 IPV 提升 10%+，GMV 提升 5%+）。快手上下滑推荐场景也应用了端上重排的方案，并取得App时长提升了 1%+ 的效果。

搜索是大众点评 App 连接用户与商家的重要渠道，越来越多的用户在不同场景下都会通过搜索来获取自己想要的服务。理解用户的搜索意图，将用户最想要结果排在靠前的位置，是搜索引擎最核心的步骤。为了进一步优化搜索个性化的排序能力，提升用户体验，搜索技术中心进行了在端上部署深度个性化模型的探索实践。本文主要介绍了端智能重排在大众点评 App 上的实践经验，文章主要分为以下三个部分：第一部分主要分析端智能重排要解决的问题和整体流程；第二部分会介绍端上重排序算法部分的探索实践过程；第三部分将介绍端上重排系统的架构设计以及部署优化，最后是总结与展望。

2 排序系统进阶：为什么需要端上重排

2.1 云端排序痛点

我们以一次完整的搜索行为，来看一下整个前后端执行的过程。如图 1 所示，用户在手机端搜索入口发起检索请求后，触发云端服务器执行，包括查询理解、多路召回、模型排序与展示信息合并等处理，最终返回给客户端进行渲染呈现给用户。

图1 搜索执行链路示意图

由于整个系统的每秒查询数（QPS）的限制，以及前后端请求通信、传输包体影响，通常会采用分页请求机制。这种客户端分页请求，云端服务检索排序返回给用户最终展示列表的 Client-Server 架构，对于大众点评 LBS 场景、类推荐的搜索产品来说，存在以下两个问题：

① 列表结果排序更新延迟

分页请求限制会导致排序结果的更新不及时。在下一个分页请求之前，用户的任何行为都无法对当前页内的搜索排序结果产生任何影响。以大众点评搜索结果页为例，一次请求返回 25 个结果到客户端，每屏展示约 3~4 个，那么用户需要滑动 6~8 屏左右，才能触发新的分页请求到云端获取下一页结果（以美食频道列表页为例，有 20% 以上的搜索浏览超过一页结果）。云端的排序系统无法及时感知用户的兴趣变化，并调整已下发到客户端的结果顺序。

图2 分页浏览决策示意图

② 实时反馈信号感知延迟

一般来说，实时反馈信号会通过 Storm、Flink 等流处理平台，将日志流以 Mini-batch 的方式计算后，存入 KV 特征数据库供搜索系统模型使用。这种方式往往会有分钟级的特征延迟，因为需要对反馈数据进行解析处理，当涉及到更多、更复杂的反馈数据时，这种延迟表现会更加明显。而实时反馈反映着用户的实时偏好，对于搜索排序的优化有着十分重要的意义。

2.2 端智能重排流程和优势

为了解决分页结果排序调整决策延迟，更及时地建模用户实时的兴趣偏好变化，我们在端上建设了重排序的系统架构，使得客户端具备深度模型推理能力，该方案具有以下几个方面的优势：

支持页内重排，对用户反馈作出实时决策：不再受限于云端的分页请求更新机制，具备进行本地重排、智能刷新等实时决策的功能。
无延时感知用户实时偏好：无需通过云端的计算平台处理，不存在反馈信号感知延迟问题。
更好的保护用户隐私：大数据时代数据隐私问题越来越受到用户的关注，大众点评 App 也在积极响应监管部门在个人信息保护方面的执行条例，升级个人隐私保护功能，在端上排序可以做到相关数据存放在客户端，更好地保护用户的隐私。

端智能重排在大众点评搜索和美食频道页上线后，均取得显著效果，其中搜索流量点击率提升了 25BP（基点），美食频道页点击率提升了 43BP，Query平均点击数提升 0.29%。

图3 端智能重排流程示意图

3 端上重排序算法探索与实践

重排序任务在搜索、推荐领域已有不少研究工作和落地实践，核心解决的问题是从 N 个结果候选中，生成 Top-K 个结果的排列。具体到端上的重排序场景，我们要做的主要工作是：根据用户对前面排序结果的反馈行为，生成候选商户上下文的排列，使得列表页整体的搜索点击率达到最优。下面将详细介绍，针对端上重排序场景，我们在特征工程、实时反馈序列建模以及模型结构做的一些探索与实践。

3.1 特征工程

在端上建设特征工程的思路和云端搜索排序系统基本一致，User/Item/Query/Contextual 各个维度的基础、交叉特征可以快速复用到端上，当然需要考虑传输和存储优化，以及端、云特征系统的一致性，做到端云“无感”的开发部署，这部分内容会在后面架构&部署优化章节详细介绍。除此以外，还有一部分端上特色的用户实时反馈信号，包括更多细粒度的交互行为等，这些特征也是前文所分析的端上实时反馈决策优势的关键信号。

表1 特征体系

具体来说，在端上建设的重排模型特征体系如表 1 所示，主要包括以下几个方面：

基础特征，典型的用户/商户/Query/Context 侧特征，以及双侧的交叉特征等。
偏置特征，主要包括后端返回的排序位置，终端设备上存在的一些大小等视觉上的偏置。
用户的实时反馈特征，这部分是整个端上重排特征体系的重要组成部分，包括：

用户直接的交互行为序列（曝光、点击等）。
行为关联特征，比如点击进入商户详情页内的停留、交互等相关行为。

3.2 用户反馈行为序列建模

对于用户反馈序列的建模，业界有非常多的算法方案，比如我们所熟知的 DIN（Deep Interest Network[10]）、DIEN（Deep Interest Evolved Network[11]）以及基于 Transformer 的 BST（Behavior Sequence Transformer[12]）等等。端上排序场景里，对于用户反馈行为序列的应用会很大程度影响到算法的效果。因此，我们也在这个方面进行了一些探索。

引入深度反馈网络

在云端的精排模型优化工作中，我们一般只考虑用户和商户显式的“正反馈”行为（包括点击、下单等），隐式的曝光未点击“负反馈”信号则少有引入，因为长短期的历史行为中，此类曝光未点击行为非常多，相比于点击信号噪音很大。对于端上来说，这种实时的曝光“负反馈”信号也很重要。比如，对于同一品牌的某类商户实时多次曝光后，该品牌商户的点击率会呈明显的下降趋势。

由于实时反馈序列中曝光未点击的隐式负反馈信号占了较大的比例，作为一个整体序列进行建模，对稀疏的正反馈信号存在较大的主导影响。阿里巴巴在淘宝首页信息流推荐场景下也提出了一种基于对抗的方式，来挖掘曝光、点击行为序列之间的联系，从而寻找当前曝光序列当中有哪些行为是真正的负反馈，而哪些行为与点击有更相近的关系。微信团队提出了深度反馈网络 DFN[4]，通过引入正负反馈信号的交互作用关系，进行一定程度的去噪、纠偏。

首先，基于 DFN 的优化思路，我们对反馈序列进行拆分，生成正负反馈序列，利用 Transformer 进行正负反馈信号的 Cross Attention 交互作用。具体来说，以曝光序列和点击序列为例，曝光行为序列作为 Query，点击行为序列作为 Key 和 Value，得到曝光行为序列对点击行为序列的 Attention 结果。同理，再调换一下得到点击行为序列对曝光行为序列的 Attention 结果。考虑到正反馈信号的稀疏性，当仅有负反馈序列时，会计算得到一些平均的无关噪音权重。因此，我们参考[7]的做法，在负反馈序列中引入全零的向量，来消除这种潜在的噪音。具体模型结构如下图 4 所示：

图4 正负反馈交叉 Attention 结构图

提升负反馈信号的信噪比

初版模型在美食频道列表页上线后，相比 Base 取得 0.1% 的稳定提升，但是和离线的收益对比还有一些差距，不太符合我们的预期。经过消融实验分析发现，主要原因是负反馈信号中存在大量噪音，而噪音产生的根源是因为部分曝光商户的点击行为可能发生在特征收集的时刻之后。因此，为了提高负反馈信号的信噪比，我们对于负反馈信号的曝光时间进行了限制，长时间曝光但未点击的商户更有可能是真实负反馈信号。如下图 5 所示，更长的停留可以关联到更稳定的反馈信号，线上效果更优。

图5 停留时长-点击率效果对比

多视角的正负反馈序列交叉建模

在初版正负反馈序列模型的基础上继续迭代，我们关注到在调整 Transformer 中 Multi-Head 的数目时，并没有预期的增量收益，相比仅使用一个 Head 指标无明显变化。经过分析，我们怀疑这种通过随机初始化的生成的多头表征，很大程度上只是单纯参数量上的扩充。

另外，在大众点评搜索场景下，同 Query 下商户列表整体的相关度比较高，尤其对页内的结果来说，同质度更高。差异性主要体现在比如价格、距离、环境、口味等细粒度的表征上面。因此，我们设计了一种多视角的正负反馈序列交叉建模方式 Multi-View FeedBack Attention Network (MVFAN)，来强化曝光、点击行为在这些感知度更高的维度上的交互作用。具体网络结构如下图 6 所示：

图6 Multi-View FeedBack Attention Network 结构图

用户行为序列按反馈类型切分为点击正反馈和曝光未点负反馈，序列除了 shopid 本身，还补充了更多泛化的属性信息（包括类目、价格等），以及上下文相关的特征（比如经纬度、距离）。这些序列 Embedding 后叠加，形成最终正负反馈序列的表征。接下来会使用多级的 Transformer 进行编码，输入多个维度的信号去解码，激活用户在不同商户维度上的偏好：

使用待排商户ID作为Q，对实时反馈行为进行激活，表达用户隐形的多样性兴趣。
使用商户更多表现粒度的属性信息作为Q，激活得到注意力权重，提升用户在这些更显式感知的商户表征上的兴趣表达。
使用当前搜索上下文相关的信号作为Q，激活得到注意力权重，增强实时反馈行为对于不同上下文环境的自适应地表达。

$Q = [x_s, x_c, …, xd] \in \Re^{K\times d{model}}，，K = V = x_s \oplus x_c \oplus … \oplus x_d$ 表示各种反馈序列（shop_id/category/distance/position等）相加，作为 Transformer 的输入，Multi-View 的注意力结构可以由以下公式表示：

MultiHead(Q,K,V)=Concat(head1,head2,…,headh)WOMultiHead(Q,K,V)=Concat(head1,head2,…,headh)WO

headi=Attention(QiWQi,KWKi,VWVi)headi=Attention(QiWQi,KWiK,VWiV)

Attention(Qi,K,V)=softmax(QiKTdk−−√)VAttention(Qi,K,V)=softmax(QiKTdk)V

通过消融对比实验发现，相比于随机初始化的 Multi-Head Attention，这种显式使用多种商户上下文特征的 Transformer 激活方式效果更显著。

Match&Aggregate 序列特征

对于端上的用户实时反馈特征，除了各种常用的基于 Attention 的序列建模方式，还有一种采用显式交叉的兴趣提取方式。如图 7 所示，相比于一般基于 Embedding 内积计算“Soft”权重的 Attention 建模，它可以理解为一种“Hard”的 Attention 方式，提取的形式包括：Hit（是否命中）、Frequency（命中多少次）、Step（间隔多久）等等，除了单变量序列的交叉，还可以组合多个变量进行交叉，来提升行为描述的粒度和区分度。

图7 Attention、Match&Aggregate 序列特征提取对比图

这种基于先验知识引入的反馈序列交叉特征，可以一定程度上避免“Soft” Attention 方式引入的一些噪音信息，同时也具有更好的可解释性。比如，用户在搜索“火锅”时，没有选择附近的商户，而点击了常住地附近的历史偏好商户，这种场景下存在明显的信号说明用户提前决策的意图。这时，加入一些显式的强交叉特征（例如，待排商户距实时点击商户的距离等）就能非常好的捕捉这种意图，从而把距离远但和用户意图更匹配的相关商户排上来。在大众点评搜索的场景下，我们基于该方式引入了大量的先验交叉特征，也取得了较为显著的效果。

3.3 重排模型设计

关于重排序的研究，目前业界也有不少相关的工作，包括：基于贪心策略优化多目标的 MMR(Maximal Marginal Relevance) [8]，直接建模上下文作用关系的 Context-aware List-wise Model[2,3] 以及基于强化学习的方案[9]等。在搜索端智能重排场景上，我们采用了基于 Context-aware List-wise 的模型进行构建，通过建模精排模型生成的 Top-N 个物品上下文之间的互相影响关系，来生成 Top-K 结果。整体模型结构如下图 8 所示，主要包括端云联动的训练方案，以此来引入更多云端的交互表征；以及基于 Transformer 的上下文关系建模，下面将分别进行介绍。

图8 整体模型结构图

端云联合训练

一般来说，云端的重排序模型基本都复用精排层的特征，并在此基础上加入精排输出的位置或者模型分。大众点评搜索精排模型经过长期的迭代更新，已经建设了大量的基础、场景相关特征，以及建模了包括点击、访购等多个联合目标，这些大规模维度的特征和多目标优化在端上直接复用存在巨大的计算开销、存储&传输压力。而仅使用云端模型位置或者预估分输出，则不可避免的会损失掉很多端云特征的交叉表达能力。同时，对于到端云两侧的模型迭代、更新，还会存在较大的维护成本。

因此，我们采用端云联合训练的方式把大量的云端特征交叉信号，以及多目标高阶表征引入到端上使用。如图 9 所示，云端的模型训练收敛后，加入到端上重排任务继续 Fine-tune 更新。需要注意的是：

因为搜索精排层使用的是 ListWise 的 LambdaLoss，模型输出的预估分仅有相对的大小意思，不能表示商户的点击率预估范围，无法进行全局的绝对值使用。故仅采用网络的最后一层输出接入。
仅接入最后一层的 Dense 输出，大大损失了云端特征与端上特征的交叉能力，因此，需要通过特征选择方式，选取头部特征加入到云端进行使用。

图9 端云联合训练模型结构图

重排商户上下文建模

商户上下文重排建模结构参考 PRM[3]，结合端上应用场景做了一些调整，具体结构如下图 10 所示：

图10 重排算法模型结构图

主要由以下几个部分构成：

商户特征向量 X ：由前文所述的各方面特征（User/Shop 单、双侧统计交叉特征、反馈序列编码特征，以及云端融合输出的特征）经过全连接映射后的输出进行表示。该输出已包含位置信息，所以后续的 Transformer 输入不需要再增加位置编码。
输入层需要进过 Query Dynamic Partition 处理，切分为每个 Query 单元的上下文商户序列，再输入到 Transformer 层进行编码。
Transformer 编码层：通过 Multi-Head Self-Attention 编码商户上下文关系。

优化目标

在搜索场景下，我们关注的还是用户搜索的成功率（有没有发生点击行为），不同于推荐、广告场景往往基于全局性损失预估 item 的点击率，搜索业务更关心排在页面头部结果的好坏，靠前位置排序需要优先考虑。因此，在重排提升用户搜索点击率目标的建模中，我们采用了 ListWise 的 LambdaLoss，梯度更新中引入 DeltaNDCG 值来强化头部位置的影响。详细推论和计算实现过程参见大众点评搜索基于知识图谱的深度学习排序实践。

$$C = \frac{1}{2}(1 - S{ij})\sigma(s_i - s_j) + log(1 + e^{-\sigma (s_i-sj)})

\lambda{ij} = \frac{\partial C(s_i - s_j)}{\partial s_i} = \frac{-\sigma}{1 + e^{\sigma (s_i-s_j)}}| \Delta _{NDCG}|$$

3.4 多场景应用效果

综合上述特征&模型优化举措，相关的离线实验指标效果对比如表 2 所示：

表2 实验迭代指标对比数据表

端智能重排序在点评主搜和美食频道列表页上线 AB 实验，核心业务指标 QV_CTR 均在高位基础上取得显著提升。如图 11 所示，上半部分，主搜列表页 QV_CTR 提升 0.25%，美食频道列表页 QV_CTR 提升 0.43%，分端表现稳定正向。另外，从下半部分分位置的点击率对比曲线，可以看出，端上重排能够一定程度上缓解固定分页请求的点击衰减效果，尤其在靠后的几屏展示上都有比较显著的提升。

图11 线上 AB 实验 QV_CTR 指标效果 & 分位置点击率对比

4 系统架构与部署优化

不同于云端的大规模深度模型上线，几百 GB，甚至上 T 的模型都可以通过扩充机器分片加载的分布式方案部署使用。终端设备的计算和存储能力虽然有了显著提升，可以支持一定规模的深度模型进行推理，但相对来说，端上的存储资源是非常受限的，毕竟 App 整体的大小最多不过几百 MB。

因此，除了前面提到的在特征选择、触发决策控制上对效果与性能进行权衡外，我们还在模型部署、压缩上做了进一步优化，并对能耗等各方面指标进行详细的评估。另外，为了更高效地迭代端上的模型，包括进一步挖掘用户实时的兴趣偏好特征，自研了一套和云端系统流程一致的“端无感”模型训练、预估框架，下面会逐步展开介绍。

4.1 系统架构

整体的端智能重排系统架构，包括和云端的搜索排序系统联合部署方案如图 12 所示。具体来说，主要有以下三大模块来支持端上重排系统的实现：

智能触发方案模块，针对业务设计的各类触发事件，执行端上智能模块的调度。例如，用户点击商户行为触发执行本地重排。
端上重排服务模块，执行构建特征数据，并调用端侧推理引擎运行重排模型，进行打分输出。其中：
- 特征处理部分，是搜索技术中心针对搜/推/广算法场景，专项设计的一套方便算法使用的通用特征算子处理服务。支持对客户端、云端的各种类型数据，使用轻量、简便的表达式构建特征。
- 端侧推理引擎部分，是终端研发中心输出的统一模型管理框架，支持各类端上轻量级推理引擎部署，以及模型的动态下发控制等。
Native 重排处理逻辑部分，主要进行重排输出后的结果回插，刷新控制处理。

图12 端智能重排系统架构

4.2 端上大规模深度模型部署优化

Sparse Embedding 与 Dense 网络拆分部署

因为端上的计算资源受限，无法存储完整的超大规模参数模型，因此，基于最直观的思路，我们将离线训练的模型参数拆分成了 Dense 网络与大规模 ID 特征的 Embedding Table 分别部署：

主 Dense 网络以及一些较小的 Query/Contextual 特征、Shop 基础属性特征等输入层结构，转化成 MNN 格式，存储在美团资源管理平台上，供客户端启动时一次性拉取，存储在客户端本地。
大规模的 ID 特征 Embedding Table 部分（占整体网络参数量的 80%），存储在云端的 TF-Servering 服务中，在客户端发起搜索请求时，会从 Serving 服务中获取当前页商户结果所对应的 Embedding 特征，与商户结果列表一同下返回到客户端，与客户端构建的其余特征一起 Concat 后，输入到推理引擎进行打分重排。

模型压缩

经过上一步拆分处理，模型大小可以控制在 10MB 以内，为了进一步减少模型在手机端的空间占用，以及功耗/性能影响，我们采用了美团视觉智能部提供的压缩方案。该方案针对现有的神经网络模型压缩技术没有考虑要契合部署的端智能设备、压缩后的模型往往不能适配特定的设备、输出结果对齐度差等问题，设计了能更好用于移动端上部署的神经网络压缩工具，更好地在端上推理框架上发挥了性能。

压缩优化后从下面的测试对比数据可以看到，模型大小进一步减小到 1MB 以内，同时精度损失在十万分位差距。采用 Sysdiagnose 进行耗电分析，开启推理功能，重复动作：从首页搜索“火锅/五角场”，进入搜索列表页进行首次重排推理，滑动列表再次计算后，退出页面（测试时间为 10 分钟，间隔 20 秒采用一次），相关的能耗指标均无显著的变化。

图13 模型压缩数据、能耗相关指标对比

4.3 端智能模型训练预估平台

不同于云端的排序算法实验流程，已经有成熟、完善的训练预估平台支持，特征&模型上线非常便捷、高效。客户端的实验流程前期存在非常大的迭代效率问题，比如模型的上线流程繁琐，包括模型结构的分离、转换&验证以及发布依赖大量的人工操作，跟多个内部平台的流转、对接；另外特征迭代效率低下，需要客户端协同开发相应的特征加工逻辑，存在较大的逻辑一致性风险，而且还会存在分端的实现差异等问题。

基于此，美团的前后端工程合力推进开发、设计了一套适配客户端的 Augur 特征处理框架，将端上的模型发布和特征处理与一站式实验平台（Poker）、统一预估框架（Augur）进行打通，为进一步的算法迭代实验奠定了良好的基础，后续搜索技术中心团队也会向大家介绍面向端智能算法应用的一站式模型训练预估平台，敬请期待。

图14 端智能模型训练预估框架图

5 总结与展望

端智能重排序是大众点评搜索在边缘计算方向的一次探索实践，并且在核心指标上取得了较为显著的效果。通过利用端上计算的能力，更高效地捕捉用户的实时兴趣偏好，弥补云端服务决策延迟、用户反馈信息获取延迟等问题。及时调整未曝光候选结果的顺序，把更符合用户意图的商户排上来，从而带来更好的用户搜索触达体验。同时，我们对前后端训练、部署预估框架进行了升级，为后续进一步快速迭代实验奠定了良好的基础。

大众点评搜索技术中心团队会持续进行端智能技术在各个业务场景中的落地，未来可以探索优化的方向还包括：

基于联邦学习模式，进一步在保证数据隐私安全及合法合规的基础上，迭代端云联合的智能搜索排序模型。
建模更精确、多样的触发控制策略，对于端上实时用户意图感知的决策模块，当前的控制策略还比较简单。后续我们会考虑结合 Query 上下文，用户反馈信号等特征输出更灵活的预判信号，同时请求云端，获取更多符合用户当前意图的候选结果。
继续优化重排序模型，包括实时反馈序列建模算法，探索对于隐式负反馈信号更鲁棒的编码表达方式等。
思考端上更丰富、灵活的应用场景，比如模型的个性化定制，做到“千人千模”的极致个性化体验。

作者简介

祝升、刘哲、汤彪、嘉炜、凯元、杨乐、洪晨、曼曼、华林、孝峰、张弓，来自美团/大众点评事业部/搜索技术中心。

逸然、朱敏，来自美团平台/搜索与NLP部/工程研发中心。

参考资料

[1] Yu Gong, Ziwen Jiang, et al. “EdgeRec: Recommender System on Edge in Mobile Taobao” arXiv preprint arXiv:2005.08416 (2020). [2] Qingyao Ai, Keping Bi, et al. “Learning a Deep Listwise Context Model for Ranking Refinement” arXiv preprint arXiv:1804.05936 (2018). [3] Changhua Pei, Yi Zhang, et al. “Personalized Re-ranking for Recommendation” arXiv preprint arXiv:1904.06813 (2019). [4] Ruobing Xie, Cheng Ling, et al. “Deep Feedback Network for Recommendation” (IJCAI-2020). [5] 非易、祝升等. 大众点评搜索基于知识图谱的深度学习排序实践. [6] 肖垚、家琪等. Transformer 在美团搜索排序中的实践. [7] Qingyao Ai, Daniel N Hill, et al. “A zero attention model for personalized product search” arXiv preprint arXiv:1908.11322 (2019). [8] Teo CH, Nassif H, et al. “Adaptive, Personalized Diversity for Visual Discovery” (RecSys-2016). [9] Eugene Ie, Vihan Jain, et al. “SLATEQ - A Tractable Decomposition for Reinforcement Learning with Recommendation Sets” (IJCAI-19). [10] Zhou, Guorui, et al. “Deep interest network for click-through rate prediction.” (SIGKDD-2018). [11] Zhou, Guorui, et al. “Deep interest evolution network for click-through rate prediction.” (AAAI-2019). [12] Chen, Qiwei, et al. “Behavior Sequence Transformer for E-commerce Recommendation in Alibaba.” arXiv preprint arXiv:1905.06874 (2019).