优酷土豆实时推荐系统架构升级实践
背景
优酷土豆拥有亿级别的视频,每日国内外的视频用户会贡献亿级别的视频播放次数,相关的行为数据更加丰富多样。相关推荐系统负责每日给广大用户提供有效高质量的视频推荐内容。说到推荐系统、推荐算法,大家可能会很容易想到Kaggle 比赛,它给广大爱好研究推荐算法的大牛们有了小试牛刀的舞台,同时也推动了业界的相关产品技术形态。
为了进一步优化提升优酷土豆视频相关推荐效果,同时为了减少新推荐算法测试评估的代价,我们组计划对已有的系统进行改造。
本文主要描述相关推荐系统由离线训练、排序往离线训练、在线排序架构迁移过程中的一些内容整理。
新旧系统架构对比
下面这张图主要描述迁移前后两套系统主要处理环节的对比,从图中可以看出只是简单的将离线排序调整到在线环节。但是所涉及的数据整理、存储,接口封装以及在线使用等模块都需要做出相应的调整。
说明:
在线特征,一般是指只能在在线环境下实时计算得到的特征值。在实际系统中还会将这些特征(特征标识及特征值)以日志的方式记录下来,离线进行模型训练时可以得到这些数据。
优缺点
总的来说,新系统架构(在线排序)相比老系统架构(离线排序)有以下一些优点:
当尝试对不同的模型进行ABTest时,所需要的额外开发代价极小,不需要额外的存储一份推荐内容(排序后数据)
排序数据与具体模型分开,只在使用时,指定具体模型即可完成所推荐内容,使得流量策略调整更加轻量级
某些特征只能在线环境下拿到,使得在在线条件下对被候选视频进行一次性排序变成了可能
当然,也会带来一些挑战:
对应请求接口需要能够承受更大量级的实时数据请求,比如:被推荐候选视频集合,对应详细特征值,模型对应特征权重数据等
在线逻辑模块能够根据请求的中间数据,必须在很短的时间内快速计算得到排序结果
概要来说,为了不影响用户体验,对代码及服务性能要求极高。架构接口服务这块是影响整个系统是否能够顺利完成的关键,我们架构组的同学还是非常给力的!
主要经验收获
1. 特征名称处理
不同日期,单个模型进行训练时,可能对应有实际反馈的特征集合会存在差异。模型在训练时会自动对特征进行编码。
老系统每日会同时进行离线训练及排序,最终存储时只有推荐结果及预测的点击概率。新系统只是离线训练,排序会在在线阶段完成,为了将排序环节与具体模型独立开来,我们事先对所有的特征名称进行全局编码(每个特征会有一个唯一的序号)。后续如果有新的特征加入,则给予新的序号。
2. 模型效果评估
在新的推荐算法进行ABTest时,往往需要几天才能看到上线效果。为了提高开发效率,我们会优先在离线阶段进行新算法的效果评估,与对照组相比,确认有提升的情况下,再进行ABTest。经过实际验证,我们的离线评估方案是合理的,与后续ABTest上线后的表现基本一致。
离线评估处理过程大概如下:
准备一天数据作为训练数据集,另外一天作为测试数据集
分别训练得到对照模型及试验模型的特征权重信息
分别计算两组特征权重在测试数据集上的全局AUC表现
如果试验组对应全局AUC值优于对照组AUC值,则基本上可以肯定在ABTest阶段,其小流量表现也会优于对照组的小流量表现。这里的全局AUC其实就是通常所定义的AUC值,不过我们的训练数据集、测试数据集较大,为此专门实现了可用于计算大数据量级的AUC值的方法。
3. 模型权重融合
新系统初步构建完毕后,我们继续进行了小流量的测试。在针对同一模型,不同日期所更新的特征权重,我们发现以一定的方式将不同日期的特征权重进行融合,能够带来一定的收益。这里可以初步解释为,当实现了在线排序逻辑时,对于某一视频而言,对应被推荐的候选视频所对应的特征值可能是历史计算得到的,当日模型特征(权重)更新后,对应的新的特征集合可能不能包含被推荐视频某个特征,因此该特征值无法参与排序计算,从而影响它的排序位置。极端情况下,可能某一个候选视频对应的特征(值)集合(比较稀疏)与当日更新后的模型特征(权重)集合没有交集,则会严重影响该候选排序结果。
为此,模型特征权重融合的策略,能够一定程度上扩大有效特征集合范围,通过实际小流量测试发现,该方法能够一定程度上提升系统的请求点击效果。
小结
经过两个多月的紧张开发与测试,我们的新系统顺利的上线了。但我们的优化工作才刚刚开始,后续我们会不断的尝试新的方法,期待能够给广大视频用户带来更优质的视听体验。
出自:21cto
版权申明:内容来源网络,版权归原创者所有。除非无法确认,我们都会标明作者及出处,如有侵权烦请告知,我们会立即删除并表示歉意。谢谢。
-END-
如果觉得《优酷土豆实时推荐系统架构升级实践》对你有帮助,请点赞、收藏,并留下你的观点哦!