端上智能在快手上下滑推荐取得APP时长+1%的应用实践

1.背景

1.1.端上智能

端上智能是相对于云计算人工智能应用(如推荐、搜索)的概念：如工业界成熟的推荐系统方案，几乎都是通过云计算的算力，在海量候选集中搜索用户感兴趣的 Feed，并通过复杂的精排模型(百亿至千亿级参数规模)将排序 Top 的 Feeds 列表发送给智能手机终端。智能手机终端在这个过程中，只是对云端下发的 Feeds 列表进行渲染，收集用户反馈进行上报，并没有执行推荐算法。所有 AI 算法全都部署在云端，智能手机通过网络请求才能获得云端 AI 计算的结果。

近些年智能手机等终端设备的算力有了显著提升，这些算力足以支持一些中等规模的 DNN 模型进行推理与训练，一些原本只能在云端运行的 AI 模块，可以部署在智能手机终端上，从而使得智能手机终端，在不依赖云端的情况下，也可以进行独立的 AI 计算。

目前业内，手淘猜你喜欢在端上智能落地方面已有实践，并取得较为显著收益(EdgeRec[1, 2], 双十一 ipv+10%, gmv+5%)。

1.2.上下滑推荐

上下滑推荐，相对于传统的 Feeds 流推荐，不再向用户展示 Feeds 封面列表，每一屏直接展示一个 Feeds 详情页内容，用户不能预知接下去展示的 Feeds(见图一)。

图一: 封面瀑布流与上下滑

对于上下滑这种推荐形式，很自然的想到，每一屏消费一个视频时，用户都会产生显式/隐式的反馈，推荐系统根据这些实时反馈可以及时修正用户偏好，下一屏即向用户推荐更好的作品。

遗憾的是，上下滑的推荐形式并不支持手机终端每屏都请求云端重新生成一个推荐结果。客户端每次请求服务端，实际会下发 PageSize(PageSize >> 1)个 Feeds，等用户浏览完下发的 PageSize 个 Feeds 后，才会继续触发服务端推荐系统，重新计算并下发 PageSize 个 Feeds(见图二)。

图二: 上下滑分页请求

这是因为：

1.客户端请求服务端天然存在显著的边界耗时成本(网络>100ms)，请求服务端频率存在极限，用户快速滑动时极易卡顿。

2.减小 PageSize 会增加客户端对服务端的请求 qps，从而增加服务端的计算压力。

综上所述，目前基于云计算架构的推荐系统，不能实时响应用户的反馈修正推荐结果，已经难以满足上下滑推荐这种高频交互式推荐产品。

1.3. KIR: 上下滑推荐+端上智能

上下滑推荐这种全新的产品形式，使我们面临一个高频交互的推荐场景，暴露了云计算架构推荐系统的缺陷。我们基于端上智能技术设计并实现了 KIR(Kwai Instant Recommend)框架，使得智能手机终端具备 DNN 推理能力，用户每浏览一个 Feed，就能触发终端对未展示的候选 Feeds 集合进行重排序，实时修正用户偏好，向用户推荐更好的 Feed。

相对于 EdgeRec[1, 2]的工作，我们面临一个极高的 Baseline，服务端 PageSize 已在客户端流畅滑动与服务端请求压力允许的情况下，调整至一个极小值，使得端上智能即时推荐的潜在收益空间被压缩，对端上智能推荐系统与模型设计提出了更高的要求。另外，上下滑推荐作为一个高频交互的推荐场景，对即时推荐的需求也超过交互行为较稀疏的封面瀑布流推荐模式，端上智能是更适合上下滑推荐场景的技术。

图三: KIR 推荐流程

KIR 上线后，对用户互动指标有非常显著的收益，更是取得了 APP 时长+1%的显著提升。

2.KIR 实时排序

2.1 系统架构

图四: KIR 系统架构

因为端上的计算资源受限，无法存储完整的超大规模参数模型，我们因此将训练的模型参数拆分成了 Dense Network 与 Sparse Feature Embedding 分别部署用于 DNN 计算推理：

1.DenseNetwork 被转化成 tflite 格式，存储在 K-CDN(KUAISHOU Content Delivery Network)上，供客户端启动时一次性拉取，载入 DNN 推理引擎(Tensorflow Lite)。DenseNetwork 参数较少，可持久存储在客户端本地。

2.SparseFeatureEmbedding 存储在服务端 EmbeddingServer 中，在推荐引擎下发 FeedList 时，会从 EmbeddingServer 获取当次下发结果 Rank 推理所需的部分 SparseFeatureEmbedding，与 FeedList 一同下发至客户端，在客户端与 DenseNetwork 合并，进行 Rank 推理。SparseFeatureEmbedding 全量极大(上亿系数参数)，并且实时更新，因此需要存储在服务端。

2.2 推荐机制

KIR 仍然兼容云端推荐系统，终端每次获取服务端一个 Batch 的 Feeds，以此作为端上推荐的推荐候选池。KIR 端上推理引擎，实际是一个对推荐候选池进行排序的模块。对于上下滑推荐来说，KIR 不需要进行 list 推荐，无需考虑 list 间多样性，将排序简化为 NextOne 推荐，只需选出候选池中最好的作品，作为用户下一滑推荐，只需保证整体 session 的多样性即可。候选池中的 Feeds 不会全部展示，在触发一定的 TTL(TIME TO LIVE)淘汰机制后，便会全部清除，终端重新请求云端获取新的候选集。

2.3 算法模型

在快手极速版/精选模式等短视频上下滑场景中，因为用户无法预知接下来的 Feed 结果，所以用户对于已展示视频的反馈行为将会帮助我们更好的捕捉用户的实时兴趣变化。因此在 KIR 特征体系中，除了一般意义的用户侧与视频侧的类目特征与统计特征外，用户的实时反馈特征是重要的组成部分；这不仅包括点赞/关注/转发等直接交互行为，对于部分交互较少的用户，KIR 也可以通过完播/短播/长播等特征抽象用户的隐式反馈；此外，由于快手服务端精排模型已经较好的建模用户对于视频的点赞率/关注率/转发率等数十个目标，在终端再次对这些目标建模会带来巨大的计算开销，所以复用这部分服务端预估值作为特征会是一个更好的选择；同时，用户的实时网络环境，视频预加载进度都会直接影响用户浏览体验，因此在 KIR 特征体系中也需要考虑这部分特征；总体而言，KIR 系统的特征体系包括以下几个方面: (1) 用户特征 ，主要包括点赞数等统计特征以及用户侧序列特征等; (2) 视频特征，主要包括类目特征等; (3) 用户实时反馈特征; (4) 视频服务端预估特征; (5) 用户设备特征，主要包括设备网络状况/解码方式等;

表一: KIR 特征体系

受到以 Transformer 结构为代表的用户序列建模在工业届大量落地的启发，KIR 重排序模型在 DeepFM 模型基础上，同样使用 Mult-Head Self-Attention 结构构建高阶特征，探寻最优的下一刷视频；为了显示的引入时序特征，KIR 重排序模型同样加入了时间戳特征以及 Index 特征。基于 KIR 的特征体系，特别是每个视频不仅有 ID 类的类目属性特征，还包括服务端的预估特征，因此用户的实时反馈行为也应该对这两类特征分开建模，对于视频的 ID 类特征，用户的实时反馈体现在用户对于不同 ID 特征的偏好，而对于视频的服务端预估特征而言，用户的实时反馈可以理解为对预估值的一种修正；因此 KIR 模型通过两组独立 Transformer 结构分别抽象用户反馈对于这两部分特征的表征，并将他们 Concat 起来进入最后的 MLP 网络。

图五. KIR 模型结构

在快手极速版/精选场景中，用户的交互行为以及观看时长都是衡量产品生态的重要纬度，因此 KIR 通过多目标的加权 LogLoss 来权衡不同纬度之间的关系；相比与传统的 Feed 流的推荐方式，上下滑场景中将没有传统意义上负样本，因此在对时长类目标的建模中，我们通过拷贝正样本的方式实在对于目标的无偏估计。损失函数如下所示：

3. 效果收益

对于排序问题，业界常用的评价指标包括 AUC/WAUC/NDCG 等，结合 KIR 使用加权 LogLoss 的多目标的建模方式，我们采用 WAUC 作为离线的评价标准。相比服务端最终的排序 score，KIR 通过建模用户实时反馈行为，离线指标分别在观看时长(+3.01pp)，点赞(+2.26pp)，关注(3.25pp)等多个目标均取得了显著的提升；在 KIR 系统上线之后，用户交互指标上有显著提升，并且对 APP 时长有 1%的收益。

图六. KIR 系统线上表现

KIR 实时重排序的初衷在于捕获用户对于短视频的实时反馈，并有效的修正用户实时的兴趣变化，为用户实时推荐更适合的 Feeds，对于已经有过实时点赞/关注/进入作者页行为等反馈行为的用户，相比使用服务端直接的推荐结果，KIR 实时重排序能够进一步提升用户在各项指标上的消费体验。

4.总结

用户与上下滑推荐场景的互动频率，远高于传统的推荐场景，推荐系统需要拥有快速反馈的能力，基于云计算的推荐系统无法满足这样的需求。

KIR 完美解决了这一痛点，是端上智能在推荐系统上一次成功的实践。同时 KIR 也从上下滑推荐拓展到了封面瀑布流推荐的模式，其具备了使用用户在封面瀑布流行为与上下滑详情页行为这些异构序列特征进行推荐的能力。

未来，我们将继续优化 KIR 算法模型，使其更精准捕捉用户实时反馈，触发更准确的推荐，为用户实时推荐更好的作品。

同时我们将引入更实时的探索机制与流失建模，在满足用户精准推荐的前提下，使用户尽可能多的获得更新颖多样的内容体验，向用户展示更为全面的快手作品，并以此机制沉淀新用户对快手作品的反馈数据，完善云端的用户兴趣画像，促使新用户转化为快手的活跃用户。

欢迎有感兴趣于端上智能、快手短视频推荐的同学加入我们的团队，简历地址

hongliyin@kuaishou.com, zhaoyifan05@kuaishou.com