加购率是怎么算的,加购率是怎么算的啊.

导读:严选是网易旗下受新中产喜爱的电商品牌,覆盖居家生活、服饰鞋包、美食酒水、个护清洁、母婴亲子、运动户外、数码家电等品类。严选站内业务包括核心入口页、活动页、商详页,还有其他小流量的场景。目前这些场景都已经实现了个性化推荐算法的覆盖,严选电商推荐场景中算法建模面临多目标平衡、多场景数据如何共用等问题的挑战,针对这些挑战,本次主要分享跨域多目标在严选推荐算法中的实践。

加购率是怎么算的,加购率是怎么算的啊.

全文目录:

  • 背景介绍
  • 多目标建模及演进
  • 长期价值探索
  • 多场景建模的实践

其中 Part2 围绕严选业务,介绍如何多目标建模,以及进一步演进至跨域多目标建模的具体做法;Part3 主要分享在推荐业务中长期价值的探索;Part4 则集中在多场景建模,并结合某业务场景的实践进行细粒度讲解。


分享嘉宾|强小辉/陈自强 网易严选 推荐算法工程师

编辑整理|李润顺 知乎

出品平台|DataFunTalk


01

背景介绍

加购率是怎么算的,加购率是怎么算的啊.

推荐系统的总体流程可以分成四块,主要是召回、粗排、精排、重排。其中精排会承载很多业务模块的业务指标,在不同业务模块,关注的业务指标有所不同。对于某一些业务指标,存在转化数据比较稀疏,以及冷启动的问题。另外,我们在与业务方的交流中发现,他们关注的一些业务指标与算法目标不直接相关,需要我们去做一些长期价值的探索。

严选精排算法演进过程,开始是基于深度学习的 CTR 单目标建模,然后在此基础上增加了基于用户行为序列进行建模,接着衍生到多目标建模,最后是跨域多目标建模。

02

多目标建模及优化

1. 样本特征

近年来,多目标建模是业界排序建模的主流方式,而业务数据和特征工程决定了模型的上限。

加购率是怎么算的,加购率是怎么算的啊.

在多目标建模中,我们选取用户的点击与转化行为为正样本,根据 Skip-Above 原则,选取曝光未点击的样本作为负样本。此外,在样本构造中还会注意以下几个优化点:

  • 头部的热门商品可能存在过曝光,需要对这种 Top 流量的商品做降采样。
  • 短时间之内会存在同一商品的多次曝光,需要在时间窗口对样本进行聚合,保留点击样本、剔除曝光未点击样本。
  • 虚假曝光,第一种是用户在刷 Feed 流浏览时,快速滑跃或无意识的快速浏览时的曝光;第二种是由于页面布局的影响,导致卡片头部一定比例在页面加载时默认曝光。这两种曝光实际上并没有对用户产生心智影响,因此,需要定制规则去噪。
  • 假正样本,主要包含用户的误点以及点进去之后快速回退的操作,用户并没有对商品产生兴趣,这类正样本也需要特殊处理。

特征工程方面,我们将其分为四类:数值特征、类别特征、序列特征和 Embedding。各类特征处理方式如下

  • 数值特征的处理,对连续特征进行归一化,或者采用 RankGauss[1](Rank 预处理保留数据排序信息,并转化为高斯分布);然后进行分桶,再计算 Embedding 。
  • 类别特征,通过哈希映射,对于频率出现过低的一些类别做过滤,同时保留一个默认和异常处理的坑位,再计算 Embedding。
  • 序列特征,把用户行为交互序列中的每个元素进行embedding,再做attention 或者 Pooling 操作。
  • Embedding 特征,主要是商品侧的表征特征,基于一个预训练模型得到的Embedding 作为模型中对应的商品侧表征的初始化权重;为处理值域过大的情况,可以做 Normalize 操作。

2. 模型结构迭代

加购率是怎么算的,加购率是怎么算的啊.

目前业界主流的多目标建模的网络结构是 MMOE[2]PLE[3] 两种,我们也分别迭代了这两种结构。MMOE 是基于专家网络和门控做多任务学习的框架,它的特点是每个任务有单独的门控网络,同时在底部共享几个专家网络,通过不同的门控网络去控制专家网络对于不同任务的权重贡献。PLE 是在 MMOE 的基础上更加细粒度化,在专家网络共享的同时,还给每个任务单独提供独有的专家网络。这个独有的网络会去强化每一个任务的权重学习,能够有效地避免在 MMOE 中可能由于某些任务的训练占主导地位,带偏小任务的问题;也可以让不同任务的专家,通过集成方式,进行权重交互。

3. 位置偏差与 Debias

上面介绍了数据特征处理和使用基础的多目标网络结构进行建模,在此基础上,会根据实际业务场景的问题进行优化。

第一个问题是位置偏差,位置偏差是指推荐 Feed 流场景下用户倾向点击/交互曝光位置靠前的物品,这个信息蕴含在正样本里,可能会导致建模存在偏差。如下图左上角是对某个业务模块做的位置偏差分析,横轴是时间,纵轴是曝光点击率。可以看到随着坑位的逐渐往下,曝光点击率逐渐下降。基于带位置偏差的数据进行模型训练,会形成一个循环反馈,模型去学习这种趋势,然后做预测推荐,会导致位置偏差在不断地放大,从而导致整体的推荐流量生态出现问题,比如部分商品过曝光。

加购率是怎么算的,加购率是怎么算的啊.

存在的位置偏差需要做 Debias 的操作。我们做 Debias 的方式是在 MMOE 多任务的基础上,加一个消偏模块整体结构如上图右边部分,输入是常见的几类特征(用户侧、商品侧、情境上下文,行为交互序列特征)。经过特征预处理后,输入到 Embedding 层,然后会进入 MMOE 主网络。同时会构建一个 Debais 辅助网络,输入主要是 Bias 相关的特征(比如商品曝光的坑位、设备的型号、用户的身份等可能影响到展示位置的特征),经过浅层网络后得到bias 的学习表征。然后把这个结果与多任务主网络学出来的 CTR 结果直接相加,再经过一层激活函数得到最终 CTR 预测结果,CVR 网络无任何操作。Debais 辅助网络的浅层部分,会加上 Dropout,主要是为了防止模型学习结果过于依赖浅层网络的特征,保证模型的鲁棒性。

多任务模型 Debias 优化上线 AB 后,人均点击数+4.95%、曝光点击率+1.70%。需要说明的是,Debias 优化需要根据具体业务特点做判断,我们的场景 AB 刚上线前几天,会对某些业务指标产生非正向收益,因为 Debias 会对热门做打压,对长尾的商品进行扶持,这可能会影响销售额。Debias 优化,本质上是从整体业务生态或者长期收益的角度考虑问题,在短期内能承载一部分收益下降的前提下,可以推全放量,它会带动整体推荐流量生态向良性、健康的方向发展。

4. 多目标 Loss 优化

此外,在 CTR 跟 CVR 目的基础上根据业务方的需求增加更多的目标,包括加购、评论商品、查看促销信息、分享、收藏等。有些目标如收藏、分享的转化数据相对会比较稀疏,这些任务与 CTR、CVR 样本比较丰富的任务一起训练时,由于样本过于稀疏,会导致训练不够充分,被带偏。

加购率是怎么算的,加购率是怎么算的啊.

针对转化目标比较稀疏,训练不充分的问题。我们会考虑在损失函数上引入 Focal Loss[4] 替换交叉熵函数。如上图中的 FL(p, y),Focal Loss 在交叉熵基础上,增加了 P 和 Gamma 两个参数,P 就是模型预测样本是否为正样本的概率。看损失函数第一项,对于正样本,P 的预测接近 1 时,1-p 的 Gamma 次方会更加接近于 0,那么很容易区分的那部分正样本,损失会下降非常明显;P 的预测接近 0 时,损失无太大变化。对负样本的处理与正样本同理。Focal Loss 目的是让 Loss 去关注/聚焦比较难以区分样本信息,Gamma 参数是去调节聚集程度。还可以再引入一个类别权重参数A lpha,去解决正负样本不平衡的问题。比如 Alpha 定义为正负样本比,增强正样本的损失影响。

另外,多个子任务一起训练时可能存在某个子任务被带偏的情况,即跷跷板(Seesaw Phenomenon)效应。我们尝试使用 Gradnorm[5] 梯度归一化来控制 WI 的权重。梯度归一的目标是让不同的任务的 Loss 梯度量级更加接近,同时还可以让不同任务的学习速率也更加接近。通过这两个点优化 WI 权重,让各个任务的学些更加平衡。上图右下角两张图是 CTR、CVR 训练速度的展示。红线是它原有的训练速度,蓝线是经过 Gradnorm 调整之后的,可以看到调整之后,训练的速度接近 1 左右,不会出现速度训练过快或过慢的情况。

多目标损失优化,引入 Focal Loss 和 GradNorm 控制损失权重后,整体上线 AB 实验,CTR +6.92%,CTCVR+5.87%,都有显著提升。

5. 跨域多目标建模

在我们的业务中,会涉及到很多场景,比如新客、新品页面,用户的行为数据会比较稀疏,还有新上线的业务模块,刚上线数据非常少,处于冷启状态。那么在这些场景下,如何能够让模型学习得更好呢?那就需要考虑多场景的跨域建模。引入多场景的好处在于,首先让模型先意识到场景之间的差异性,建模拟合映射由 P(y|x) -> P(y|x, d),输入增加了场景信息(Domain)。另外小样本的场景,能够通过对样本更加丰富/比较成熟模块的场景共性的刻画和迁移学习,让模型对小场景也能够取得更好的效果。

加购率是怎么算的,加购率是怎么算的啊.

跨域多目标算法的整体网络结构,如上图。

底层输入特征(包括用户侧、商品侧、上下文情境、行为序列特征),经过特征预处理进入 Embedding 层,然后进 MMOE 层进行多任务的信息抽取。网络右边部分是一个辅助网络,把域/不同场景/Domain Field 相关的特征输入,然后经过一个 Domain Tower 得到对应场景的抽象特征。然后将场景的抽象特征与多任务的输出表征共同输入到 STAR 网络层(参考阿里 STAR 文章[6]),STAR 的拓扑结构里包含两种塔:共享 Share塔、表征不同场景的 Domain塔。Share塔主要去学习场景的一些共性信息,Domain 塔去学习各个不同场景对应的独特信息,之后对两边塔的权重进 Element相乘后得到的结果,作为每个场景的权重,最终得到每个场景下不同任务的输出。

这个优化上线后,在主场景和小样本场景上取得的效果有些差异,小样本场景下的提升更加明显,曝光转化率和曝光点击率有 10.8% 和 3.5% 的相对提升。主场景下,本身数据比较丰富,效果提升没有那么显著,曝光转化率和曝光点击率分别有 2.2% 和 0.81% 的提升。

03

长期价值探索

此外,我们还做了一些提升长期价值的探索工作,分别是多业务混排和用户留存优化。我们有很多业务模块,除了向用户透出商品卡片,还需要拓出场景化的如榜单、清单卡片、活动卡片等,这些信息在同一个模块展示,如何做到个性化的页面布局,需要做混排策略,我们基于汤普森采样算法[7],根据线上用户的实时行为交互,做 Reward 反馈,这个反馈对每个用户去拟合 Beta 分布,在 Beta 分布上算用户对三种卡片的点击概率。如果用户刚点击过很多场景化卡片,可能后续会推更多场景化卡片。但场景化或者活动性卡片,对于我们的业务价值可能不如商品卡片那么高, 如何判断混排这个动作到底有没有价值,需要去做比较长时间周期(1个月以上)的 AB 实验 ,观察单个模块和全站数据表现,如果全站 UV 价值和全站加购率提升,那混排就是有价值的。

加购率是怎么算的,加购率是怎么算的啊.

用户留存优化,是指关注用户在一些模块当中有停留且有后续的行为,而不是仅关注短期产生的价值,比如我们希望在签到或者其他模块,能够通过留存来增加后期的用户价值收益,那就需要考虑如何通过主动干预来来提留存。如上图,通过数据分析可以看到用户交互 Session 长度与 3 日留存率会显著正相关(Session 长度 6-20),所以,可考虑优化用户交互 Session 长度。具体做法是在多目标建模中增加户交互的 Session 长度目标。这块我们建模优化之后得到的 AB 结论是,在首猜场景下,曝光点击率跟 3 日留存率会有一定的提升。这里也是需要我们做价值上的判断和取舍,看是否能够接受短期损失,比如说某个模块在 1 到 3 天之内部分用户未回访,但是 3 日内还没有返回,到第三天或者第四天才进行回访和留存,之后才产生价值。这个过程可能会产生一些业务价值的波动,但时间周期拉长,会看到整体的收益比短期能覆盖的范围更大。

04

多场景建模实践

1. 什么是多场景建模?

下面结合严选某业务场景,细粒度介绍多场景建模的具体实践和应用。业务定义上,根据业务场景我们将业务分为核心场景和通用推荐场景。核心场景包括核心入口页猜你喜欢、购物车、个人页等,它的特点是流量大,位置显著,数据丰富,会承担一些核心的业务指标。其他的中小流量场景,统称为通用推荐场景,特点是流量少、数据稀疏,但模块数量很庞大、场景非常丰富。接下来主要针对通用推荐场景介绍多场景建模的思路。

加购率是怎么算的,加购率是怎么算的啊.

关于多场景的定性,不同的用户群体(新客、老客)、不同客户端(iOS 、安卓)、App 中的不同模块,因为他们的商品展示形式或对用户心智影响等有一些显著差异,只要在数据上有明显的差异,都可视为多场景的一个子场景。

加购率是怎么算的,加购率是怎么算的啊.

关于多场景建模,没有确切的定义,与学术上迁移学习和跨域推荐比较接近。在实际建模方案落地中,主要考虑如何捕获场景间的共性,同时保留各个场景的数据本身的特点。机器学习有个基础假设,训练数据要服从独立同分布,实际上各场景的训练数据的分布存在显著差异。

2. 为什么多场景建模?

加购率是怎么算的,加购率是怎么算的啊.

如上左图,是我们之前采取的方案,在通用推荐场景下,多个场景采用同样的推荐算法。最早期采用同一套 CF 算法,后来切换成向量算法,在后来浅层深度模型。这会存在问题,把所有场景的数据混合在一起去训练模型,完全没有考虑到各个场景之间存在的数据差异性,模型训练方向会被大流量场景的数据带偏,导致推荐效果是一个的中庸的效果,即各个场景下都不是最优的。

另外一种极端做法,如上右图是针对每个场景,都建立一个模型,这样做的问题是小场景或新接入场景的数据比较稀,少量的样本很难训练出比较好的模型。同时维护成本非常高,迭代不方便。

3. 如何进行多场景建模?

加购率是怎么算的,加购率是怎么算的啊.

我们从特征工程入手,先构造一些场景的特征,在输入层直接拼接到现有模型中,但实际效果并不理想。因为最底层加入的这些场景信息特征,经过多层抽象网络很难传递到末端,被模型学习到。通过分析各场景商品的 CTR 分布,有较明显的差异,因此场景信息有很强的先验知识如上右图可以通过一个偏置网络,类似位置消偏,认为不同场景数据分布的差异性是由该场景偏差导致的,偏置网络的输出层加回主网络。这个简单的做法,只在在一些场景上有一定效果,大部分没效果。原因是仅仅依赖偏置网络进行纠偏,对不同场景的特征分布差异,没有进行很好的捕获。

加购率是怎么算的,加购率是怎么算的啊.

在此基础上,套用 MMOE 多任务框架进行多场景建模。顶层的每个塔对应一个场景,各个场景的特征数量和语义是保持一致的,如果某个场景有独特的特征,其他场景下特征用缺省值代替,MMOE 里用多个专家网络来隐式地学习场景间的差异和共性。但也有个问题,模型训练中,每个场景数据只单独更新对应塔权重,这样会导致某些小场景学不好,效果不大。另一方面场景特征信息,也没有得到显示的表达。基于这两方面考虑,在 MMOE 基础上增加了一个模块,首先在顶层增加 1 个共享塔,我们认为即使某个场景做预测时,其他场景也会对这个场景的预测起到贡献,此外接到顶层有个权重生成自网络,类似门控矩阵形式,最终该场景的预测是由所有场景的加权结果,这能够缓解小场景学不好的问题。由于场景数量较多导致 PLE 模型过于复杂,并可能带来的延时问题,未尝试。

加购率是怎么算的,加购率是怎么算的啊.

在实践中参考的另一个解决方案是阿里的 STAR 星型结构模型,底层是特征共享层,往上 BatchNorm 的时候,区分场景分别进行,顶层不同的场景分别对应一个塔,同时有一个共享的中心塔。最终每个场景的输出结果是由场景塔和中心塔相乘得到的,参数更新方式是共享的参数是由所有场景的样本数据同时更新,场景参数只能由特定场景的样本去更新。但这个方案也存在场景特征信息无法显示表达的问题,因为底层的特征空间是共享的。为了解决这个问题,它的做法是把场景特征过一个偏置网络,把场景信息的信息直接传递到输出层,类似方案一。

加购率是怎么算的,加购率是怎么算的啊.

最后的方案还是以 MMOE 为基础,底层特征共享,MMOE 专家网络结构自动选择场景间共享信息,同时针对每个场景考虑特征来源,上图中右上角为各场景的输出结构,由 MMOE 专家网络和底层的场景特征信息直接传递,并行输入。左侧场景 MLP 参数私有,右侧 MLP 参数共享。

加购率是怎么算的,加购率是怎么算的啊.

接下来看下在通用推荐场景中的落地情况,上图中列举了 10 个场景,其中 Mix 和 Single 分别表示用混合场景和单场景数据去训练模型,Multi 代表多场景建模。从 AUC 结果可以看到,如果场景数据量比较充足的情况下(#1),单场景数据训练的 AUC 高于混合场景数据训练,同时和多场景建模是 AUC 基本持平。对于小场景(#9),数据稀疏,单场景数据训练效果不好。线上效果是在某些场景 pCTR 有 5%-10% 的提升。

05

Q&A环节

Q1:电商的新客行为较为稀疏,在搜索推荐领域冷启动问题非常有挑战的,我们有什么针对性的一些举措?

A1:对新客老客做区分,把新客单独拉出来,作为一个单独的链路,从召回到排序到重排单独做模型和策略。

Q2:场景较多时,我们如何既能够复用,同时不用维护太多的模型?

A2:我们的通用推荐场景,也是有这样两个问题,就是小流量场景比较多,就是单独维护的话可能人力资源就很浪费,然后统一的效果你又不能做到非常完美。所以这个时候就是可以尝试一下采用多场景联合建模的一个思路去解决。

Q3:提升用户留存,增加 Session 交互长度目标这块,我理解的 Session 交互长度是个 Listwise 的概念,怎么把Label打到 Pointwise 的单个商品上呢?

A3:Session 交互长度 Label 是指用户交互当前商品后,在该 Session 内的剩余长度,本质上是引导用户进行更多的交互,从而提升留存。

Q4:多场景建模这里,多场景与多目标的关系没太理解,底层的 MMOE 是针对场景,然后在场景 Tower 里面多目标,还是说多场景是单目标的呢?

A4:多场景建模是可以结合多目标任务的。Part4 分享的主要是多场景的 CTR 建模,底层 MMoE 是针对场景的。在跨域多目标建模中,则使用 MMOE 学习多目标信息,类交叉拓扑网络(如star结构)学习多场景的异同。

参考文献

[1] RankGauss:https://zhuanlan.zhihu.com/p/330333894

[2] MMOE:https://dl.acm.org/doi/pdf/10.1145/3219819.3220007

[3] PLE:https://dl.acm.org/doi/10.1145/3383313.3412236

[4] Focal Loss:https://zhuanlan.zhihu.com/p/49981234

[5] GradNorm:https://arxiv.org/abs/1711.02257

[6] 阿里 STAR 模型:https://arxiv.org/abs/2101.11427

[7] 汤普森采样:https://zhuanlan.zhihu.com/p/84338172

今天的分享就到这里,谢谢大家。


|分享嘉宾|

加购率是怎么算的,加购率是怎么算的啊.

强小辉|网易严选 推荐算法工程师

2020 年加入严选人工智能部,致力于严选推荐业务的算法迭代,主要负责精排算法相关工作。

加购率是怎么算的,加购率是怎么算的啊.

陈自强|网易严选 推荐算法工程师

2019 年加入严选人工智能部,致力于严选推荐业务的算法迭代,主要负责召回与粗排算法相关工作。


|DataFun新媒体矩阵|

加购率是怎么算的,加购率是怎么算的啊.


|关于DataFun|

专注于大数据、人工智能技术应用的分享与交流。发起于2017年,在北京、上海、深圳、杭州等城市举办超过100+线下和100+线上沙龙、论坛及峰会,已邀请超过2000位专家和学者参与分享。其公众号 DataFunTalk 累计生产原创文章800+,百万+阅读,15万+精准粉丝。

创业项目群,学习操作 18个小项目,添加 微信:jjs406  备注:小项目

本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至 924072740@qq.com 举报,一经查实,本站将立刻删除。
如若转载,请注明出处:https://www.xmfxquan.com/7805.html