0、背景
优化单个目标训练而得的点击率预估模型偏向过重,容易引发bad case(如信息流推荐中单一优化pCTR引起标题党)从整体上拓宽用户从点击到转化漏斗的宽度,而不是单独拓宽某一层满足多业务方需求希望产品对用户的黏性增加,营造良好的用户体验1、方案
考虑一个类似微信看一看的应用场景。推荐系统为用户推荐他们可能感兴趣的内容(内容数据分为图文、视频、新闻、小视频、人工干预等几个大类),用户对这些内容可以进行点击、评论、点赞、转发以及收藏等行为。
整个系统基本遵循召回、粗排、精排的结构。现在召回层从以下几路执行召回之后进入排序层对内容进行排序。现在需要确定一个多目标优化的方案,以同时提升点击、时长、点赞、评论和分享。
召回层的多路召回策略
1.1 多任务联合建模
case:阿里CVR预估模型之ESMM
solution
对点击率、转化率联合建模,并将转化率分解为点击率*点击后转化率,将两个模型在目标输出层进行关联
图转自知乎用户@刺猬,来源链接点这,侵删
advantages
多任务之间可以共享基础的embedding层建模目标明确可弥补转化数据过于稀疏引起的预测不准确
disadvantages
与业务场景强耦合,复用性差
1.2 各任务独立建模
solution
对点击、时长、点赞、评论等目标单独建模,在model serving阶段进行合并
advantages
各指标之间完全解耦,复用性强模型之间独立,可并行训练模型,model training阶段效率大幅提高
disadvantages
未能公用基础的embedding信息多个模型之间意义割裂
1.3 多目标在线融合
solution 对点击、时长、点赞、评论等目标单独建模,在model serving阶段进行合并case:微信"看一看"个性化推荐:排序篇
advantages
融合了多任务联合建模和子任务单独建模,互补优劣
model combination
(离线model training)grid search寻找在离线实验中AUC较为平衡的少量几组方案(在线model serving)离线实验中得到的方案上线进行ABTest
3、重排和多样性
模型迭代:DQN -> DQN+RNN
多样性评估:submoduler -> 多样性加入模型训练时的reward
4、工程挑战
spark-mllib算力瓶颈:自研算法平台PanguX在线serving的内存与性能瓶颈:单次预测无法容纳百亿级别的特征与模型。即使拆分模型,又会遇到网络带宽、版本控制和模型一致性的问题。解决这个问题较为硬核,需要与工程部署团队联合开发。实时特征抽取的性能问题:serving阶段加载实时特征阶段中,大量时间消耗在字符串拼接和hash上,解决方案:数据结构优化,hash算法优化。模型的可扩展性:原来高度耦合的模型拆解为特征抽取、打分算法、模型存储等组件,解耦的同时可以按需组合,独立维护。如果觉得《推荐系统中精排模型的多目标优化》对你有帮助,请点赞、收藏,并留下你的观点哦!