优酷土豆实时推荐系统架构升级实践

21CTO

资讯 0 4311 2017-03-24 12:00:47

为了进一步优化提升优酷土豆视频相关推荐效果，同时为了减少新推荐算法测试评估的代价，优酷土豆大数据应用团队计划对已有的系统进行改造。本文主要描述相关推荐系统由离线训练、排序往离线训练、在线排序架构迁移过程中的一些内容整理。

背景

优酷土豆拥有亿级别的视频，每日国内外的视频用户会贡献亿级别的视频播放次数，相关的行为数据更加丰富多样。相关推荐系统负责每日给广大用户提供有效高质量的视频推荐内容。说到推荐系统、推荐算法，大家可能会很容易想到Kaggle 比赛，它给广大爱好研究推荐算法的大牛们有了小试牛刀的舞台，同时也推动了业界的相关产品技术形态。
为了进一步优化提升优酷土豆视频相关推荐效果，同时为了减少新推荐算法测试评估的代价，我们组计划对已有的系统进行改造。
本文主要描述相关推荐系统由离线训练、排序往离线训练、在线排序架构迁移过程中的一些内容整理。

新旧系统架构对比

下面这张图主要描述迁移前后两套系统主要处理环节的对比，从图中可以看出只是简单的将离线排序调整到在线环节。但是所涉及的数据整理、存储，接口封装以及在线使用等模块都需要做出相应的调整。

说明：
在线特征，一般是指只能在在线环境下实时计算得到的特征值。在实际系统中还会将这些特征（特征标识及特征值）以日志的方式记录下来，离线进行模型训练时可以得到这些数据。

优缺点

总的来说，新系统架构（在线排序）相比老系统架构（离线排序）有以下一些优点：
1、当尝试对不同的模型进行ABTest时，所需要的额外开发代价极小，不需要额外的存储一份推荐内容（排序后数据）
2、排序数据与具体模型分开，只在使用时，指定具体模型即可完成所推荐内容，使得流量策略调整更加轻量级
3、某些特征只能在线环境下拿到，使得在在线条件下对被候选视频进行一次性排序变成了可能

当然，也会带来一些挑战：
1、对应请求接口需要能够承受更大量级的实时数据请求，比如：被推荐候选视频集合，对应详细特征值，模型对应特征权重数据等
2、在线逻辑模块能够根据请求的中间数据，必须在很短的时间内快速计算得到排序结果
3、概括来说，为了不影响用户体验，对代码及服务性能要求极高。架构接口服务这块是影响整个系统是否能够顺利完成的关键，我们架构组的同学还是非常给力的！

主要经验收获

1. 特征名称处理
不同日期，单个模型进行训练时，可能对应有实际反馈的特征集合会存在差异。模型在训练时会自动对特征进行编码。

老系统每日会同时进行离线训练及排序，最终存储时只有推荐结果及预测的点击概率。新系统只是离线训练，排序会在在线阶段完成，为了将排序环节与具体模型独立开来，我们事先对所有的特征名称进行全局编码（每个特征会有一个唯一的序号）。后续如果有新的特征加入，则给予新的序号。

2. 模型效果评估

在新的推荐算法进行ABTest时，往往需要几天才能看到上线效果。为了提高开发效率，我们会优先在离线阶段进行新算法的效果评估，与对照组相比，确认有提升的情况下，再进行ABTest。经过实际验证，我们的离线评估方案是合理的，与后续ABTest上线后的表现基本一致。

离线评估处理过程大概如下：

1、准备一天数据作为训练数据集，另外一天作为测试数据集
2、分别训练得到对照模型及试验模型的特征权重信息
3、分别计算两组特征权重在测试数据集上的全局AUC表现如果试验组对应全局AUC值优于对照组AUC值，则基本上可以肯定在ABTest阶段，其小流量表现也会优于对照组的小流量表现。

这里的全局AUC其实就是通常所定义的AUC值，不过我们的训练数据集、测试数据集较大，为此专门实现了可用于计算大数据量级的AUC值的方法。

3. 模型权重融合

新系统初步构建完毕后，我们继续进行了小流量的测试。在针对同一模型，不同日期所更新的特征权重，我们发现以一定的方式将不同日期的特征权重进行融合，能够带来一定的收益。这里可以初步解释为，当实现了在线排序逻辑时，对于某一视频而言，对应被推荐的候选视频所对应的特征值可能是历史计算得到的，当日模型特征（权重）更新后，对应的新的特征集合可能不能包含被推荐视频某个特征，因此该特征值无法参与排序计算，从而影响它的排序位置。

极端情况下，可能某一个候选视频对应的特征（值）集合（比较稀疏）与当日更新后的模型特征（权重）集合没有交集，则会严重影响该候选排序结果。

为此，模型特征权重融合的策略，能够一定程度上扩大有效特征集合范围，通过实际小流量测试发现，该方法能够一定程度上提升系统的请求点击效果。

小结

经过两个多月的紧张开发与测试，我们的新系统顺利的上线了。但我们的优化工作才刚刚开始，后续我们会不断的尝试新的方法，期待能够给广大视频用户带来更优质的视听体验。