Kdd

阿里巴巴2022年KDD上发表一篇论文，介绍“瀑布流”推荐产品如何智能地选定请求时机的问题。这篇论文之前作为淘宝端智能的一项成果在知乎发布过，详见这篇文章。今年算是正式在KDD发表论文了。 阅读过程中我也一直将论文的方法和我们所做的类似的项目做对比，结论是思路是一致的，并不落后，但这篇论文的手段更加丰富，资源投入也更多，值得我们参考和学习。 背景 论文一开始先介绍什么事“瀑布流”推荐，这对于国内的移动用户而言司空见惯，就是无限下拉无限刷新推荐结果的产品交互形式，国内一般也叫feed信息流。所以需要解决的一个问题是分页请求时机的问题，就是确定在什么时机向后端发送新的推荐请求。一般是每浏览n个item后(也叫一刷)发起后端推荐请求。如果n变小，请求的频度增加，则后端服务请求的压力增加，而且很多用户本来也没有购买或者点击意愿，新增的推荐请求返回的结果也没有转换为最终的业务收益，最终白白浪费了算力。相反，如果n变大，请求的频度减少，则用户反馈延迟较长，用户实时的意愿（例如点击，购买转化等行为）没能及时反馈到后端，导致下一刷展现的还是之前缓存的推荐结果，体验较差而且不能提升产品收益。作者以淘宝App首页推荐为例，统计了每一刷的推荐结果CTR的变化情况，如下图所示： 可以明显看出每一刷头几条结果都是点击率很高，但后续衰减也是非常明显的。而且每次一刷更新点击率都有一次迅速提升，原因是新的一刷捕捉到了用户最新的兴趣点，但之后又回归到衰减。 问题和解决方案 因此，如何确定什么时机发起下次刷新是这篇论文需要解决的问题，作者给该解决方案定义了一个名词：IRSD（Intelligent Request Strategy Design），还大言不惭的说据他们所知，这是第一个在瀑布流推荐产品中研究IRSD的论文。 作者提出该问题主要有如下几点挑战： 捕捉用户兴趣点动态变化是一个难点，因为用户兴趣点是隐式变化的 不能同时观测到用户增加或者不增加下一刷请求，本质上这是一个反事实现象，所以uplift预估存在巨大的挑战。 这一点非常赞同，和我们遇到的难题类似， 不同策略其实无法在一个用户中同时存在，这也是反事实模型需要解决的问题 如何平衡新增下一刷请求的收益和带来的额外资源消耗非常有挑战性，尤其是用户数一直在动态变化 这一点和我们遇到的问题类似，如何保持QPS在系统可承载的范围内，同时拿到额外的业务收益，这也是效果-算力之间平衡的难题 为了解决以上调整，他们提出了一种新的范式，即基于Uplift算法的端智能请求框架（Uplift-based On-edge Smart Request Framework (AdaRequest)）。该框架部署在端上，这样可以更极致实时地收集和分析用户行为。该框架由如下几部分组成：用户行为理解模型（CUBE），反事实请求奖励估计（CREST），动态请求规划（DRP）。其中： CUBE挖掘用户稀疏的实时行为序列，长期行为序列，以及购买交互序列。通过比较用户实时意图和历史兴趣，CUBE可以评估出用户兴趣点是否有变化 CREST目标是对treatment和control组的用户分别建模，通过因果推断（causal inference）预估出增益（uplift）。 DRP动态选择新增请求的比例，用来选取最大化的请求奖励和资源消耗之比，在有限的资源约束前提下最大化请求奖励。 最终这套AdaRequest在手机淘宝的猜你喜欢页面（也就是首页推荐）落地，和固定增加请求比例对比，有GMV提升3%的额外收益。 总的来说，论文定义并调研了瀑布流推荐场景下的IRSD问题，同时提出了AdaRequest范式解决IRSD问题。同时通过在线和离线实验量化证明了AdaRequest的有效性。 问题定义 接下来论文介绍了实现的方法。首先定义问题，从形式上IRSD问题定义如下： 其中S函数代表用户的正向反馈，F函数代表决策结果(1代表请求，0代表不请求)，\(c_i^X\)代表第i个上下文环境，\(u_i^X\)代表第i个用户，\(b_i^u\)代表第i个用户的历史行为，\(X_i\)代表第i刷。R代表新增请求的资源消耗函数。因此第一个公式代表在各种上下文环境、用户、历史行为、刷次中获取的总收益大小。第二个公式代表总资源消耗约束在theta阈值以内。优化目标是找到最优的算法F，使得在满足资源消耗约束条件下，最大化业务收益。 AdaRequest框架 接下来终于一窥AdaRequest方案的整体框架，如下图所示： 虽然CUBE，CREST，DRP三大组件看起来很高级的样子，其实核心在左边的流程图中： 首先在端上实时采集用户行为，第二步CUBE将用户行为转变为用户意图变化情况，转化方式实现采用了一个神经网络来解决，产出用户浏览历史匹配度，用户当前session点击历史匹配度，用户长期点击历史匹配度，以及候选推荐item的embedding向量。第三步CREST将第二步的输出作为输入，再加上用户以及上下文特征向量，可以预估出新增请求的奖励uplift，最终交给DRP来决策是否发起新增请求。 DRP将动态选择一部分高性价比的时机发起新的请求。如果决策新增一次推荐请求，端则向后端发起请求，上传用户实时行为，后端则重新分析用户意图，返回更新的推荐item，更好地匹配用户最新的兴趣点。 因此，该论文所采用的特征体系有： 用户特征F(user) 候选item特征F(cands) 用户细粒度的历史行为特征： 用户的浏览历史F(exp) 用户当前session的点击行为F(sclk) 用户长期点击行为F(clk) 粗粒度的当前session的上下文特征F(context) 在这个特征组中，F(sclk)和F(clk)分别代表了用户实时和长期的兴趣点。F(exp)代表了上次请求曝光后用户不喜欢的item，原因是负向反馈也是一种有价值的信号。F(context)代表用户在当前session中的推荐满意程度，例如浏览的深度。论文还很贴心的把所有特征列表附在论文附录。 CUBE CUBE组件的目标是从用户实时行为中找出用户意图是否发生变化。由于推荐候选item是由后端服务根据用户历史兴趣推荐选择的，CUBE将结合用户行为，将用户刚刚交互过的item和推荐候选的item进行匹配。如果这两者不是非常匹配，意味着当前候选item并不满足用户当前意图，进一步则意味着用户意图发生了变化，因此此时如果新增一次推荐请求，能收获显著的购买uplift。 具体来说，CUBE将F(exp), F(sclk), F(clk)和F(cands)作为输入，针对特征特点做细粒度的建模。具体来说，F(sclk)特征分为用户行为序列F(sclk_beh)和item序列特征F(sclk_item)，分别通过两个GRU encoder输出向量并拼接在一起。F(exp)和F(clk)类似处理，而F(cands)采用一个GRU encoding编码，并通过mean-pooling操作做fusion融合。 最终，整个模型采用attention作为将候选item和用户以及交互行为序列匹配的算子。F(cand_emb)作为attention的query输入，用于匹配候选item是否满足用户实时意图。以F(sclk)为例，第i个item是否匹配用户意图的attention评分函数如下公式所示： 可见alpha_i即当前item的匹配率在所有匹配率中的softmax归一化值。输出向量M(sclk)定义如下： 可见M(sclk)即每个item的F(sclk_embs)的加权和，代表了当前候选item是否匹配用户实时意图的程度。 上述的Match函数代表匹配分，代表推荐候选集和用户实时交互的item序列之间的相似程度，即attetion匹配函数。论文实际采用的是内积函数作为匹配函数的实现。M(exp)和M(clk)也是类似方法产出，结果的分布代表了候选item是否匹配用户不喜欢的item以及用户长期感兴趣的item。 CREST CREST模块用于预估新增一个额外的推荐请求带来的uplift收益。由于用户无法同时存在有和没有新增推荐请求的状态，因此无法反事实地观察到收益uplift的真实值groundtruth。 为了解决这个问题，作者采用两个独立的预估网络，Control Net用于预估如果没有额外的请求，购买率是多少。以及Uplift Net，用于预估如果有额外的请求，额外的增益uplift是多少。Control Net和Uplift Net加一起，可以预估出如果有额外的请求，那么购买率是多少。 为了训练这两个预估网络，论文将实验用户随机分为两组用于数据收集：control组没有额外请求，而treatment组随机发起额外请求。Control Net用control组的数据训练，而Uplift Net用control组以及treatment组的数据训练。 预估的时候，只有Uplift Net需要运行，来预估出请求reward，作为决策此次额外请求是否需要触发的基础依据。 用因果推断causality的语言来描述，CREST就是用于对新增额外请求实现CATE，描述如下： Y(0)代表没有新增请求，Y(1)代表有新增请求，CATE代表对于一个新增请求所获得的uplift值。...