双11专栏 | EdgeRec：电商信息流的端上推荐系统

双十一期间，我们业务完成了全面上云，云计算的发展保障了大促期间业务的稳定运行，承接了巨量的流量。在过去的这十年里，依托于大数据，云计算取得了非常耀眼的发展。随着云计算的发展，也面临着一些问题：互联网应用每天面临的大量请求，以及日益普遍的大规模神经网络在线部署，对云端计算产生巨大压力；随着5G的普及和带宽的增加，云端同时面临着巨大的存储压力；对一些实时性要求比较高的应用来说，与云端巨大的通信开销也是交互和体验瓶颈；同时云端“中心化”的计算模式也会带来运维成本和故障风险。

近几年，终端设备的计算与存储能力的快速发展，智能手机的性能成为主要卖点，各种CPU、GPU的快速迭代，内存越来越大，为计算带来了新的空间，端侧的工作不再只是。相对于云计算，端计算的优势在于下面四点：

1. 数据本地化，解决云端存储及隐私问题；

2. 计算本地化，解决云端计算过载问题；

3. 低通信成本，解决交互和体验问题；

4. 去中心化计算，故障规避与极致个性化。

实际上，端计算与云计算不是割裂的。在云计算时代，端侧主要负责信息的收集与展现，云侧负责大规模的计算与存储；在端计算能力逐渐丰富的今天，端侧的计算和存储能力也被利用起来，更多的端云联动能力被挖掘出来。比如，拍立淘将类目检测和物品检测能力放到端上，而将图片-商品召回、排序能力则放到云上；在谷歌输入法Gboard上，智能手机会根据用户的实时反馈首先更新用户个性化模型，并将更新信息回传云侧，云侧则会根据所有用户的反馈，聚合成新的统一输入法排序模型下发给每个用户，完成模型的迭代。结合端侧能力，提升互联网服务的质量与消耗，端云联动的能力越来越多的体现出来。

本文将介绍在我们电商首页部署的端上推荐系统EdgeRec，以及我们在端上推荐系统中的算法实践（部分已发表CIKM2020论文[1]）。第2部分将介绍我们搭建的端上推荐系统EdgeRec整体架构，第3部分将介绍端上重排的问题与端上行为序列建模的算法方案，第4部分将介绍端上智能请求的背景问题与算法实践，第5部分将介绍我们在千人千模算法问题上的探索与算法实践。目前，EdgeRec日常为淘宝首页信息流带来13%的GMV提升。

目前，信息流是业界搜索推荐产品的主流形式，其展现信息丰富、可持续交互的特性，使得包括我们电商首页瀑布流、我们电商搜索瀑布流、美团瀑布流、抖音全屏页等，都使用信息流作为主要推荐方式。当然，信息流推荐系统也面临着一些痛点，阻碍信息流的进一步优化。

• 痛点1：用户实时感知弱 / 决策慢

信息流推荐基于“分页请求”机制，仅在分页附近有调整机会。受限于资源消耗和用户体验，一般分页不会特别小。带来问题有：1. 分页过程中无法实时调整策略；2. 实时的意图获取和策略的调整次数太少。

用户的实时行为感知弱：上行数据延迟高：依靠端上实时上报日志->服务端实时解析->推荐系统实时查询的链路，回传延迟一般在10s-1min。

• 痛点2：云端存储和计算瓶颈

以我们电商平台首页信息流场景为例，日常2w+ QPS，大促峰值10w+ QPS，巨大的在线infer压力导致日常超时的情况时有发生，而大促期间也会面临降级；另外，一般需要存储60天的样本，云端面临巨大存储和训练资源消耗。

• 痛点3：“千人一模”的局限性

目前的推荐模型使用统一的模型，而“千人千面”源自于特征的个性化；高活用户主导全局推荐结果，20%的用户贡献了80%的训练数据；而每个用户数据分布并非IID，使用同一模型拟合并非最优。（图片引用自[2]）。

总结下来，分页推荐系统感知/决策慢、资源消耗固定的问题，根本原因是用户意图的变化与推荐系统的请求时机和商品展现时机不匹配。端上是请求的发起者和商品展现的终端，对用户行为有最实时的感知能力，因此，我们希望将请求决策和展现决策这两项最接近用户的任务放到端上，利用端智能的能力，进行进一步的优化。基于这个思想，在我们电商首页信息流推荐里建设了端上推荐系统EdgeRec，通过端上重排能力做展现决策，通过端上动态请求能力做请求决策，整体提升推荐系统的实时感知和实时反馈的能力。

▐  端上推荐系统介绍

为了实现EdgeRec端上推荐系统，我们依赖了许多淘系的基础服务，其中包括：

1. MNN：淘系自研轻量级端侧推理引擎 。为算法的脚本、模型和工具库提供运行环境。https://github.com/alibaba/MNN

2. BehaviX：淘系全域端上用户数据中心。端侧用户数据与特征中心，定义一套方便算法使用的数据标准，提供行为本地标准化处理，为算法提供了行为、特征、样本的通用基础数据源。

3. BehaviR：淘系端上智能调度框架。串联前台交互、用户感知、用户触达。对用户的实时行为调用端侧算法模型预测意图，进行本地重排、智能刷新等实时决策 。

• 服务端决策延迟

  
  

  目前，信息流推荐的分页普遍较长。以我们电商首页信息流为例，采用50一分页的分页机制，一屏展示约4个商品，用户需要划十几屏后才能发起新的请求，看到下一页的商品。长分页导致用户在刚分页时点击了某个商品之后，直到下一分页，服务端才能根据该行为下发用户可能感兴趣的相关商品。从上文不同坑位的点击率曲线可以看出，在分页刚开始时点击率最高，然后由于决策滞后，点击率逐渐下降，知道下一次分页请求决策时，点击率才回升。

• 服务端感知不及时、不完整

  
  

  服务端对用户行为的感知依赖于行为记录、行为上报和行为解析，整体链路包含了以下问题：

  
  

1. 感知不及时：服务端想要获取用户的行为，需要等待行为从用户手机端上报到服务端，然后服务端对行为加以解析，这些时间延迟导致用户的实时意图无法及时被服务端感知，在大促期间由于流量压力，这种延迟更为明显。

2. 感知不完整：目前的搜索、推荐、广告算法模型如DIN、BST等，主要特征包括以商品为粒度的曝光序列、点击序列、收藏序列、加购序列、购买序列等序列。而算法模型的进一步升级需要描述某一种行为的“强与弱”。以“商品点击序列”这个行为为例，从细节来看，为了描述一次商品点击的强弱，我们需要详情页的细节行为来描述用户对这次“商品点击”的意图强弱，比如详情页各区块停留时长、各控件点击等；从上下文来看，我们需要这次点击的来源场景信息、APP来访等信息，通过上下文信息来描述一次商品点击的用户意图。而端上是对用户意图进行感知的最实时的位置。

   
   

在端上重排模型中，对于用户全域行为的序列建模分为encoder和decoder两个部分，前者整体建模用户状态，可用于重排、混排和智能请求等，后者则基于重排候选商品逐一进行点击率预估，最后将排序结果展示给用户。下面分别介绍这两个模块。细节内容见我们在CIKM2020上发表的论文[1]。

RNN-based encoder。端上重排的曝光序列、点击序列等多个行为序列，首先会分别使用GRU模块进行encode，保留每一个state得到encode之后的各个序列。

Attention-based decoder。排序模型中行为序列decoder常用的target attention模型，会使用目标候选商品与行为序列中的商品计算相关性，然后对序列进行加权。目前attention-based decoder基于对各个序列进行建模时，存在两个问题：

1. 每种序列行为内都存在多种细节行为，如曝光行为序列中的曝光时长、曝光次数、滚动速度和点击行为序列中的点击来源、各区块点击情况、各区块曝光时长等，这些细节信息如果只是简单的concat到行为商品信息中，无法被充分建模

2. 行为序列之间割裂严重，多个序列通常在分别建模之后才在MLP阶段进行隐式交互，没有充分利用到行为与行为之间的关系。

针对以上的两个问题，我们设计了行为内的细节行为Reliable attention建模以及行为之间的序列对抗建模。整体模型架构如下图所示，Reliable attention建模以及行为之间的序列对抗建模，将在后面进行分别介绍。

• 行为细节建模——Reliable attention

Target attention加权方式在计算权重时只考虑到商品与商品之间的关系，没有考虑到用户在该行为中发生的行为细节。因此，我们首先实验通过noninvasive attention引入细节行为，证明了细节行为的有效性。进一步地，基于行为细节对行为的可信度刻画，我们提出了Reliable attention，对序列进行可信度加权，取得了更优的效果。下面具体介绍这两个模型

Noninvasive attention

noninvasive attention论文[3]中指出，序列建模最终输出的是基于item的兴趣序列的表示，如果将side information混入到item表示中，则会对序列建模带来噪声，使得side information的收益被消减。而noninvasive（非入侵）的方式则是根据混杂了side info的item 表示来计算相似性/相关性，再用于对纯净的item representation进行加权处理，从而做到不污染序列item表示又考虑side information带来的收益。下图1表示了invasive attention与noninvasive attention两种方式的对比。

Reliable attention

Noninvasive attention的缺点在于该方法需要在序列decoder前加入一层self attention进行进一步的encode，计算消耗较大，而由于目标候选商品缺乏后验细节行为，所以直接将目标候选商品作为noninvasive attention query用于target attention decode则会出现映射空间不一致的问题。同时，item信息和细节信息fusion之后，由于部分细节信息特征空值率较高，projection输出易受item信息主导。拆分开来计算可以保证不会细节加权和item相似度计算不会互相干扰。因此我们设计了multihead reliable attention的方式，使用行为细节直接在target attention阶段进行序列可信度加权，优化target attention结果。下图2展示了reliable attention模块的计算细节。

• 多序列建模——序列对抗建模

目前的排序模型中为了全面建模用户的行为信息，常常使用多个行为建模从各方面建模用户，如电商排序模型中的曝光序列、点击序列、加购序列、购买序列等，行为与行为之间显然存在许多关联，因此多个序列之间的交互对于用户的兴趣建模十分重要。目前多序列建模中常见的建模方式为：

1. 隐式交互。各个序列分别独立建模，然后将结果进行拼接，在最后的MLP阶段再进行隐式交互。

2. Cross attention建模。以曝光序列和点击序列为例，在attention中，曝光行为序列作为query，点击行为序列作为key和value，得到曝光行为序列对点击行为序列的attention结果，再调换一下得到点击行为序列对曝光行为序列的attention结果，最后再将这两个结果进行拼接。

以上第一种隐式交互建模方式对于多序列的建模较弱，而cross attention的方式只是选择当前曝光序列与当前点击序列彼此之间相近的部分，如果当前的曝光序列与当前的点击序列关联性不强，则难以有效挖掘曝光序列中的点击成分、挖掘点击序列中的负反馈成分。

因此，我们设计了一种序列对抗的方式，来挖掘出行为之间内在的联系，从而寻找当前曝光序列当中有哪些行为是真正的负反馈，而哪些行为与点击有更相近的关系，相应地，在点击序列中寻找哪些行为是有效点击，哪些行为是无效点击。

具体地，以点击行为序列对曝光行为序列进行对抗建模为例，对抗模块（Adversarial block）网络结构如下图所示：

其中，Pool操作表示使用mean pooling将序列信息进行聚合；Split操作表示把点击行为序列中分割为不重叠的部分。Discriminator使用的是MLP，Discriminator将输入的两个向量进行concat，并输出两个向量来自同种行为序列的概率。

在序列对抗中，输入Discriminator的两个向量只能包含行为的item信息，不能包含细节行为的具体embedding信息，因此Selector使用的是Reliable attention，其中Query来自点击行为序列聚合后的结果，而Key和Value都来自曝光行为序列。该模块期望通过Selector选出曝光行为序列当中接近点击成分的信息，而Discriminator负责鉴别两个不同的序列是否属于同一种序列。对抗模块计算出ptrue和pfake之后，对抗loss为：

双十一期间，端上重排给我们电商首页信息流带来11%的GMV提升、12%的成交笔数提升。在端上重排模型进行端上行为序列建模优化的实验对比为

从上表对比可以看出，在端上重排模型中加入Noninvasive attention建模细节行为，离线AUC提升较为微弱。使用Reliable attention建模细节行为，离线AUC提升为0.0011。在Reliable attention的基础上，加入序列对抗建模，离线AUC提升从0.0011变成0.0021。上线后成交笔数提升2%，GMV提升2%。

在信息流推荐中，分页请求机制极为常见，一方面受限于网络带宽，为了减小延迟优化用户体验，另一方面为了能够留下调整推荐内容的空间，针对用户的推荐内容会被分批推送到端上。但考虑到QPS压力，一般分页的长度固定，而且不会特别小，这就带来一些问题：

1. 推荐内容更新的时机与用户意图变更的时机无法匹配。如图1所示，用户的兴趣意图和目标商品随用户浏览而变化，但分页请求导致端上商品池更新时机固定，云端的推荐内容排序无法实时的对用户需求意图改变做出反馈。

2. 无法实时的对用户意图进行检测。只有实时的用户行为特征才能反映用户当下的需求。每次分页请求后，服务端可以拿到用户的行为意图特征，并基于此进行召回排序。但由于分页请求时机固定，加上网络的带宽和延迟，用户的实时行为中大量全域细节行为无法上传，导致云端推荐模型对用户意图的推测出现偏差。

3. 无法动态分配请求资源，导致大量无效请求，而且无法实时调节QPS压力。如下图，在分页请求的基础上，在每一个分页中以不同概率随机插入动态请求，随着概率的上升，用户的购买率也随之上升。由此可见更多的请求能够带来更好的推荐，导致更多的购买。由于不同用户兴趣意图变更时机不同，不同时刻对不同用户施加一次请求的产生的价值也不同，非个性化的统一分页请求会导致大量请求资源的浪费，线上效果提升与资源分配不匹配。

端上是请求的发起者和推荐内容展示终端，对用户行为有最实时的感知处理能力，因此我们希望通过端上智能请求来做个性化请求决策，提升推荐系统的实时感知和实时反馈的能力，同时预估请求价值，合理分配请求资源。

端上智能请求会检测用户在端上检测用户兴趣意图的变化，通过请求价值预估得到在当下给该用户施加请求产生价值大小，再通过请求动态规划算法来做出是否请求的决策，让请求产生真正的线上收益。如下图所示。

双11期间，在我们电商首页信息流推荐场景中，端上重排结合智能请求算法和请求价值预估模型，相比只结合动态请求规则(每页固定增加一次请求)，线上成交金额提升超过3%，说明智能请求能够实时感知用户兴趣变化，在更好的时机更新端上商品池，为用户带来更好的推荐，促使购买行为的发生。

▐  请求价值预估Request Uplift

请求价值预估模型会分别预测不施加智能请求下用户的购买预估和对应的购买率，以及购买增益，也就是请求价值预估，并同时推断出施加智能请求下用户的购买预估和对应的购买率。就是对

的预估，而与成正相关，所以我们会直接用来作为请求决策的依据。

模型上分为两部分，第一部分中与端上重排模型一样需要进行行为序列建模，一方面，使用embedding table和user state模型预先处理用户在端上的行为特征，得到包括用户曝光商品特征序列，用户历史点击商品特征序列和用户实时点击商品特征序列(指本次session内的点击商品特征)，这三种特征。这三种特征代表了用户潜在的兴趣意图和购买倾向。另一方面，通过将待重排商品池中的商品序列编码成特征序列。

在后续的模型中，我们通过attention等操作来挖掘出重排商品池中的商品序列和用户潜在兴趣的匹配程度，当匹配程度较小，说明若此时增加一次智能请求，能带来的增益将较大。首先，我们通过self-attention和均值操作将融合编码成。之后把作为query，把同时作为key和value，通过multi-head attention，并用求和操作将其融合编码成，以此来代表商品池中的商品和用户兴趣的匹配程度。之后，将会和上端上场景下的实时上下文并在一起，来作为模型第二部分的输入。

在模型第二部分中，模型第一部分的输出会被输出入到两个分支control net和uplift net中，分别用来预测不施加智能请求下用户的购买预估和智能请求价值预估，并以此来计算出对应的，和。这里，我们简单的用2个MLP来作为control net和uplift net。

模型第二部分输出的和会和对应的control组和treatment组的数据中的label来计算control loss和treatment loss，最终的loss就是该两个loss的加权和。这里我们用cross entropy来作为loss函数。最终线上部署时，我们仅部署Uplift Logits的通路部分模型，通过Uplift值来决定请求。

▐  离线指标与线上效果

我们把模型做出是否请求的决策之后坑内是否发生购买行为作为Label。control组，treatment组和总体的AUC作为离线指标。

“千人千面”是过去几年搜推广业务增长的关键点，如何个性化信息检索结果成为了算法的工作重点，给搜推广业务带来了巨大的业务增长。目前，“千人千面”是源自特征层面的个性化，比如普遍使用的用户历史行为特征、用户长短期统计等，而模型都是使用统一的大模型。同时，用户的行为数据会从客户端传回服务端，然后在云端训练统一的推荐模型。大模型的方式，能够很好的表达Item-to-Item、User-to-User的相关关系，在保持个性化的能力下提升模型的泛化性。

然而，这种千人一模的方式，也带来了推荐公平性的问题。目前大部分场景里，20%的高活用户贡献了80%的训练样本，这也导致了模型会更加偏向于高活用户的习惯进行推荐，从下面图中曲线可以看出，日均PV较低的用户其模型打分准度（GAUC）也较低。另外，千人一模的方式，也会有数据隐私保护的问题。因此，我们希望能为每个用户提供其个性化模型，以达到极致的个性化。

1. 长期训练不稳定：如下图2，随着个人数据的多次训练，逐渐过拟合于用户本人局部数据，导致用户-用户的协同过滤信息缺失，最终auc反而会变差。

2. 用户行为不稳定：如下图3，取第N天大模型每个人用户表征层的输出值平均值，拼成一个向量做聚类，通过Kmeans算法聚成两个类别，并通过PCA降维到两维，可视化成红色和蓝色两类。而当使用第2天蓝色部分用户的数据，继续通过该模型输出用户表征层输出值时，却发现表现为黄色部分。即不同天之间用户的行为有很大的变化。

▐  MetaFusion个性化模型融合算法

为了解决以上提出的两个问题，我们提出了MetaFusion框架和相应的算法，其中框架如下图所示：

EdgeRec建设的三年内，每一年都有新进展，双十一GMV提升从19年的+5%，到20年的+8%，到今年的+13%，每年都展现了其巨大的增长空间，成为推荐系统中不可或缺的系统。截至目前，端上推荐系统体系的潜力做了一定兑现。接下来，端智能需要与云上算法做端云算法间的协同，端上发挥其信息量大、信息实时的优势，云端发挥其候选存储空间更大的优点，通过端云协同提升业务效果。

小编根据不同技术方向和内容主题，对“双11”的相关技术文章进行分类（内容如下），不定期推送，敬请期待。