intro
问题:given context, user, return item list,
目标是用户的留存,时长
如何解决:直接建模留存是困难的,影响因素不明确;改成对直接的目标建模,ctr,cvr;
发展历程:
- 模型能力的提高,(auc,uauc,rigloss,预估更准确)
- 另一方面在考虑如果优化留存:探索/利用,item 冷启动,多样性,多目标融合,
- 还有一些工程问题,在线系统要求的高吞吐低延迟(大量kv存储)、模型online learning (训练数据,机器学习平台)
解决方案&要点细节:
- 召回/粗排/排序
- 冷启动
- 多样性,模型和规则:判断什么是正确的方法,模型可以对什么建模,如果基于某目的不追求全局最优,才会加规则,比如打压低龄/低俗
模型视角:模型结构,特征工程,训练数据,训练,预估,(系统,不属于我的部分)
排序
从规则到机器学习,个性化排序,ctr模型;
模型演化:lr -> fm/ffm -> dnn -> wide&deep / deep fm, 多塔结构
object != ctr,标题党/引诱评论/... badcase,多目标做到极致(~20),分别建模,融合,(早期有label reweight方法,引入有人为规则,损失模型预估label可解释性,没有推广);
ctr -> ctr * staytime / cvr -> multi object + unitility
1)模型结构
ctr 为例
模型
lr:模型能力依赖特征工程(session/profile/recent-item,dense+sparse,bias:style/time/model/),问题是交叉特征稀疏性
fmm:embeding 可以共享,记住历史行为;预估高效,相比lr 性能提升很大
+nn:nn :nn, 其实也不深 3层,->1024 -> 128
更多算力更好的效果,边际收益,roi 机器/收益
2)多目标融合- cvr模型
问题:cvr label 更稀疏(正例 5% -> 0.01%),简单实用ctr相同的模型,训练数据更少,可能不收敛
下采样效果无损,也不会提高,可以加快训练速度;cvr模型通常过滤click!=1的样本,假设全样本和点击后样本分布一致,训练数据更小,模型更小,加快速度,使用impr做负例没有收益;
最新的方案是,multitask,共享参数/数据 增加泛化能力,避免互相干扰,几种尝试:
- share id embeding / fm prod / bottom nn,要求目标一致
- mmoe,底部nn完全共享 * gate,
- tutor/student, 共享给student但是student的loss 不要回传给tutor;totuor可以很简单 但是能看到更多的数据;不限制任何模型结构,通用思路
- trick: 直接取大模型的user embeding 做特征,应用于小场景,不考虑数据泄漏等,效果就是有提升;
(模型过多的还会带来工程问题:模型裁剪,减少冗余特征/减少embeding,这里没有细看)
3)多目标融合 - 超参
对整体的价值需要仔细评估,推荐系统很复杂,可能存在aa效应,pgc/ugc,内容生产/消费,
一定以留存为最终判断;多目标存在兑换关系,需要经验+信仰;
如何做准指标很有学问,以数据驱动,相信统计,置信度/置信区间,指标敏感
如何融合(不同目标的值域不同,没有直接目标,调整便利性,超参数可解释性)
- \sum ( bias + beta * score)^alpha, 最大值影响
- \prod (bias + beta * score)^alpha,最小值影响
离线自动搜索超参数 todo:
在线自动搜参数
原始都是手动做online abtest实验,效率比较低,不可能对大量超参调整, black-box optimal problem,
grid search, random search, bayesian opt, pso...; 探索性的决定搜索参数
google vizier,模仿开源实现,
另一方面,离线调优算法,契合推荐场景用uauc衡量,准确性更好,来源不清晰;
冷启动
user 冷启动:泛化特征有效,user_id 没有作用,偏向全局热,没有个性化;online learning 下快速反馈,不需要做什么额外工作,系统自然就可以完成 | 少打扰/广告
item 冷启动:item_id,如何和热门内容排序出来,需要被优待,
目标是保量成功率+不同vv分层占比 + 减少impr 影响(线上ab实验监控消费测指标);
工程问题较多,count要准确,避免超保,推荐流量很大;
方法的几个阶段:
随机:随机挑选一个
boost :
精细化多阶段:差异阈值、 pid 动态控制boost、低 vv boost
todo:
损失更精细,
保量对系统影响,消费测/作者侧,
基于关注关系/内容理解,
召回
问题:从item亿量级挑出几千个候选,耗时 ~100ms;性能要求高,个性化、多样性,和排序模型场景有差异;
演化:
- 各式各样的热度/topic倒排,item-based 协同过滤(缺点,更新慢,冷启动,相似度衡量、稀疏、准确性低),已经被模型击败,再也不要在召回规则上浪费时间;
- 模型方法:model embeding + tree serving,
背景:
简言之,2016左右,排序模型从lr->fm/ffm,性能提升巨大;
lr (w' * x, sigmoid loss) 模型简单,拟合能力依赖特征工程,sparse id 特征空间巨大,dense feature, dense-id combine 过于稀疏,比如user_id-topic,dense-dense 还是有用的,已经能做ctr预估了;
fm && ffm,特征对应隐向量/embeding,然后内积,w' x + \sum \sum v_i * v_j,和推荐场景很match,item id有大量展现,有协同能力,user_id有记忆能力;
从ffm到召回:
user_id, item_id的fm,或者以user, item, context 3 field-fm,都可以改写成内积的形式,可以完美的应用在召回场景:ffm模型得到embeding向量,每次请求从item list里面取内积最大的top k;
关键:从诞生到成功
- 模型训练样本选择,以ctr为例,如果impr 做负例,clic做正例,效果不好,第一版上线是真实正例 + 负例从正例池随机采样,原因:select sample bias,impr 负例也是优秀的,只从impr数据train,无法在广大的候选中 挑出top,需要对广大候选有判断能力;打压热门,增加个性化,也存疑。后来演化为20%真实负例 + 80%随机采样,真实负例可以增加模型拟合能力;
- 工程实现:预先load item embeding,构建fast ball tree 加速query approximate top-k nearest neighbor;
更多发散:
- req user_id 置0,减少个性化,增加全局热,用作新用户冷启动;
- ball tree实际上对item做聚类,可以做有意思的工作; req user_id 置item_id,召回结果是相似item,使得动作反馈更及时,比如点赞了美女视频会立刻召回多个美女;
- user/context/group 简单做是对特征做sum pooling,可以由embeding+nn 产生;
- 多路召回,一个模型不能搞定搞定所有,类似排序的多目标;
业界
- dnn for youtube recommend,架构+技术类似;
- alibaba tdm,提高模型性能,复杂模型,头条没有测出效果;
Q:
- ball tree/ fast ball tree,手写一遍,体会他的好处,以及是否有其他数据结构,覆盖率?
- embeding,上面解释来自推荐系统的ffm,其实nn也可以;了解下在nlp 有更多应用,word2vec 的negative sample技巧,避免求softmax更新太多项,采样负例只更新这一部分。
- 如何离线评估召回性能,