查看原文
其他

无需等待:电商领域重排模型在线学习可以先于用户反馈

王原 博士 DataFunTalk
2024-09-11

导读 在当前典型工业应用推荐系统 pipeline 中,重排作为最后一个环节,决定最终的推荐结果,因此需要综合考虑多样的业务需求以及复杂物料的融合。经典的在线学习依赖用户反馈,在电商场景,用户完成一次购买决策通常需要几小时甚至几天,这无法避免地限制着在线学习的实时性。本文将介绍一种新型的用于重排的在线学习方法,该方法不强依赖用户反馈,能够确保模型的实时性。该方法由阿里巴巴与中国人民大学共同提出。

今天的介绍会围绕下面四点展开:

1. Background:实时在线学习&重排模型基本概念

2. Formal Introduction:重排的定义&解决方案

3. New Proposal:Learning at Serving Time (简称 LAST)

4. 结语

分享嘉宾|王原博士 阿里巴巴淘天集团 算法专家 

编辑整理|杨昕玥

内容校对|李瑶

出品社区|DataFun


01

Background:实时在线学习&重排模型基本概念

首先介绍一些实时在线学习和重排模型相关的基本概念。

1. 实时在线学习

一般的推荐系统或者机器学习的应用系统,会有天级或者周级的离线训练,训练结束后将模型推上线做线上 serving。实时在线学习指的是,在模型上线后,基于新产生的有效的 sample,实时更新模型的学习过程。主要目的是让模型能够更加快速地捕获数据分布之间的变化,进而做出更优质的推荐。

在电商推荐场景,实时在线学习的意义在于,电商推荐场景的数据分布存在显著周期性变化,或受突发事件影响而发生突变,同时直播电商的兴起也让数据分布更加动态。实时在线学习的解决方案就是不停使用最新的样本训练模型,以便模型快速适应数据分布的变化。

实时在线学习会面临三大挑战:

  • 实时在线学习依赖于用户反馈数据的实时性。比如在电商领域,用户可能需要几个小时至几天才能完成一个购买决策,我们的模型也就不可避免地需要等待几个小时甚至几天。

  • 实时在线学习还需要额外的工程支持。举例来说,一个线上系统至少需要有实时的数据流支持,才有可能做到实时在线学习。

  • 实时在线学习模型的稳定性也受到了更大挑战。

2. 重排模型

重排的概念是由庄涛在 2018 年提出的,图示是一个非常经典的工业级的推荐系统的 pipeline。大致会分为召回、粗排、精排以及重排 4 个步骤。从左到右是一个时间序,每个环节的打分量从大到小。召回处理亿级的数据,粗排万级,精排千级,重排一般是百级甚至不满百级。同时,从左到右打分精准度不断提升。

重排相对前序的模型来说,会显式建模宝贝之间的相互影响,即 context information。例如一瓶饮料以上图中的方式呈现给用户,那么中间那瓶饮料的点击率就会有所提升,因为其尺寸和颜色都明显区别于旁边的两瓶饮料,这就说明 context 会影响用户行为。

重排的建模主要分为两个流派。一是单点打分,即利用 context 信息给候选物品打更加精准的排序分,再按照从高到低的顺序排列,形成最后的推荐序列。二是序列生成,是模型直接输出 candidates 序列,不存在 rank score 的概念。

重排的复杂性主要体现在 context 中包含着的巨大可能性。比如,手淘猜你喜欢和关注信息流,一方面是混合着各种物料(比如说直播、视频、图文、宝贝)的复杂信息流。另一方面,在这样的场景中,除了需要提高点击,提高停留时长这些指标之外,还有很多的实际的业务目标要去完成,比如说打散、流控等等。在我们以前的工作中,已经介绍了如何将两者有机融合进重排模型中。这部分可以参看 paper(https://arxiv.org/abs/2306.05118) 和去年在 DataFun 的公开课(全名“融合复杂目标且支持实时调控的重排模型在淘宝流式推荐场景的应用”)。

02

Formal Introduction:重排的定义&解决方案

1. 重排学习问题定义

重排位于整个推荐系统 pipeline 的最末端。上图中以一个三排二的 case 解释了重排问题的定义:当前有三个宝贝候选来到了重排阶段,要求输出的序列长度为 2,三排二共可能有 6 种序列,这 6 种序列分别对应了用户/平台/商家的反馈(用笑脸表示)。

为了后文理解方便,我们在三排二的 case 上聚焦于用户反馈单一指标。

在这样的情况下,重排的问题就可以由一个 arg max reward 公式定义(如上图中所示),寻找最优序列。这个序列给到用户后可以拿到更好的 feedback。Reward function 会同时考虑商家和平台的诉求,在这里简化为 feedback 越多 reward 越大。在这一例子中,重排的目标就是寻找 L3

注-数学 notation: ①序列=L;②用户反馈=y

2. 解决方案

在完成问题定义后,我们逐一破解 3 个落地时遇到的实际问题。

问题 1:线上预估时,需要考虑到 response time 的限制。

解决方案 1:我们使用 one shot solution,调用序列生成模型 generator。这意味着在给定一个 u 和 c 的情况下,通过调用 generator,就直接输出 arg max reward 的结果,从而节省 response time。

问题 2:实际拿到的用户反馈只有一个序列的反馈结果(红色笑脸标),虽然这条序列大概率来说是一条不错的序列,但也大概率不是最优的那条序列。

解决方案 2:解法来自新角色的引入,也就是 evaluator 评估器。评估器会给其他可能的序列预测用户 feedback(蓝色笑脸标)。Evaluator 的有效性已经得到验证,具体的建模思路和评估参见去年的 paper 和 DataFun 大会分享。(同上)

在有了 evaluator 后,我们的训练过程就转化为了通过调整 θ(Generator 的参数)来实现在给定 u 和 c 的情况下,拿到 evaluator 最大化分数。

问题 3:真实线上环境无法用刚刚展示的穷举法,原因在于真实环境比三排二可能性多得多,候选序列组合基本是百万~亿级别的。

解决方案 3:流程是用 Actor/Generator 生成序列,用 Evaluator/Simulator 评估序列。如果评估出来 reward 大,那么 Actor/Generator 就调大生成当前序列的概率;如果 reward 小,那么 Actor/Generator 就降低生成当前训练的概率。

基本逻辑是预先训练 Evaluator/Simulator 模型。值得一提的是,在给定了 evaluation 之后,actor 的训练是无需直接的用户反馈的。所以在线上不需要等待用户的 feedback,就可以训练更新 actor。

03

New ProposalLearning at Serving Time (简称 LAST)

1. 基础架构

经典的在线学习的过程(左边)是在初始模型 deployed model θ 的基础上等待第一批带着用户反馈的样本 Sample 1 with feedback 准备好后,学习并更新模型至 deployed model θ1,但在等待样本的过程中已经等了用户的购买决策的几个小时。以此类推模型逐步更新至 θ2

而 LAST 学习的特点在于,在线上模型还是 θ2 的情况下,当收到线上新请求 request 1 w/o feedback 的这一瞬间,我们会尝试从 θ2 的基础上去寻找一个偏移量 Δθ1,从而尝试优化对 request 1 的推荐结果。而这个对于当次请求优化的偏移量 Δθ1 仅仅只是针对当次请求,在模型吐出结果后就被丢弃,不会回流到 deployed model 中。以上推理需要模型更新在 serving 的一瞬间完成,也就是 learning at serving time。

2. LAST 核心逻辑

接下来讲解 LAST 中的核心,新请求来时需要更新的 Δθ 是如何来的?

Δθ 同一来源于最优化问题(第三行)。在拿到 U0 和 C0 之后,我们会尝试寻找一个 Δθ 使得 evaluate 分数增大。跟 θ 优化的核心区别是在于优化针对的范围的不同,θ 是对任意可行的 U 和 C 都希望拿到最优的结果,为全局最优化;而 Δθ 只为当前请求的 U0 和 C0 去计算最优结果,只为这一次请求最优化。

3. LAST 方案对比传统学习的亮点

  • LAST 更新无需等待用户反馈,在请求到达的一瞬间就可以更新模型。

  • LAST 的优化针对的是当前请求的预估效果,源自于模型针对每一次请求时,模型都可以有针对当前请求局部的优化。

  • LAST 定制程度高,有望实现千人千模,源自于 LAST 的优化在全局最优基础上再加于局部最优。

  • LAST 不会影响已上线的模型,可以作为可插拔的插件使用,源自于 LAST 的 Δθ 是及抛的优化。

  • LAST 不依赖线上工程支持。

4. LAST 算法

LAST 设计了两个版本,第一个是串行的版本,在给定一个 u 和 C 的情况下,首先调用 generator 打出一条序列,然后 evaluator 评估序列,再基于评估结果调高/低当前序列生成的概率,重新尝试打一个新的序列,然后再访问 evaluator 评估结果,循环往复。但串行版本的问题还是反馈时间。在此基础上,我们提出了并行的版本。并行版本从 gradient exploration 模块出发,它会输出各种的 Δθ 的可能性,来自于调大/小当前序列生成的概率,配合各种步长生成。然后 generator 在尝试各种的可能性之后,产生各种的序列,每个序列去访问 evaluator,最终我们从当中选 evaluator 分数最高的那一个 item 序列透出。

5. LAST 实验结果

考虑到经典模型非 Evaluator-based 的对比公平性,第一个离线评估中用 NDCG,明显看到最下方的两个 generator-evaluator 的多序列方法效果最好,其中 LAST 最优。

考虑到 NDCG 受头部效应的影响不够接近于真实的预估水平评估,第二个离线评估中用 evaluator 去对比各个模型,还是能明显看到 LAST 最优,对比最强的 baseline 有 1 个多点的提升。

实际线上实验在淘宝关注信息流场景。实验结果发现是能在点击数不变的情况下,带来两个点级别的成交笔数的提升。

04

结语

LAST 工作是由阿里巴巴与人民大学合作完成的,成员包括来自阿里巴巴的王原(分享者)、李志宇、温子敬、林泉,其中王原和李志宇是同等贡献程度;还有来自人民大学的张昌硕、陈思睿、张骁老师和徐君老师。

最后分享一些招聘信息。

关于团队:我们是来自淘宝算法技术商家平台算法团队,负责手淘商家私域产品,包括店铺/详情/关注/消息相关的算法。我们通过对海量数据的分析和学习,帮助亿万用户在商家私域高效的买和逛,辅助千万级的商家运营客户。同时我们是也是一支注重技术创新,乐于分享的团队,不少成果已经整理发表在了 AAAI 等相关国际顶会上。我们这里有海量的数据,充足的计算资源,丰富的应用场景等你来挑战。

欢迎感兴趣的同学通过邮件(tieyi.lq@taobao.com)及上图中的二维码联系我们。
以上就是本次分享的内容,谢谢大家。


分享嘉宾

INTRODUCTION


王原博士

阿里巴巴淘天集团

算法专家

博士,美国纽约大学,18 年毕业加入阿里巴巴,先后负责淘宝“关注”信息流和日销超 10 亿元的私域商品搜索推荐算法。

活动推荐

往期推荐


Data+AI 一体架构的产品创新

数据产品方法论:踩坑与超越!

Apache Paimon 实时湖仓存储底座

LLM+RAG:大模型在金融场景的落地探索

95% 向量资源节省,火山引擎云搜索 RAG 技术体系演进

天穹数仓自治能力在大模型时代的新实践

推荐系统融合排序的多目标寻优技术

GenAI时代的实时数据分析:Apache Pinot与向量索引技术探秘

金融,大模型落地的关键场景!

打造 LLMOps 时代 Prompt 数据驱动引擎


点个在看你最好看

SPRING HAS ARRIVED

继续滑动看下一个
DataFunTalk
向上滑动看下一个

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存