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

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

背景

优酷土豆拥有亿级别的视频，每日国内外的视频用户会贡献亿级别的视频播放次数，相关的行为数据更加丰富多样。相关推荐系统负责每日给广大用户提供有效高质量的视频推荐内容。说到推荐系统、推荐算法，大家可能会很容易想到Kaggle 比赛，它给广大爱好研究推荐算法的大牛们有了小试牛刀的舞台，同时也推动了业界的相关产品技术形态。

为了进一步优化提升优酷土豆视频相关推荐效果，同时为了减少新推荐算法测试评估的代价，我们组计划对已有的系统进行改造。

本文主要描述相关推荐系统由离线训练、排序往离线训练、在线排序架构迁移过程中的一些内容整理。

新旧系统架构对比

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

说明：

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

优缺点

总的来说，新系统架构（在线排序）相比老系统架构（离线排序）有以下一些优点：

• 当尝试对不同的模型进行ABTest时，所需要的额外开发代价极小，不需要额外的存储一份推荐内容（排序后数据）

• 排序数据与具体模型分开，只在使用时，指定具体模型即可完成所推荐内容，使得流量策略调整更加轻量级

• 某些特征只能在线环境下拿到，使得在在线条件下对被候选视频进行一次性排序变成了可能

当然，也会带来一些挑战：

• 对应请求接口需要能够承受更大量级的实时数据请求，比如：被推荐候选视频集合，对应详细特征值，模型对应特征权重数据等

• 在线逻辑模块能够根据请求的中间数据，必须在很短的时间内快速计算得到排序结果

• 概要来说，为了不影响用户体验，对代码及服务性能要求极高。架构接口服务这块是影响整个系统是否能够顺利完成的关键，我们架构组的同学还是非常给力的！

主要经验收获

1. 特征名称处理

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

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

2. 模型效果评估

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

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

• 准备一天数据作为训练数据集，另外一天作为测试数据集

• 分别训练得到对照模型及试验模型的特征权重信息

• 分别计算两组特征权重在测试数据集上的全局AUC表现

如果试验组对应全局AUC值优于对照组AUC值，则基本上可以肯定在ABTest阶段，其小流量表现也会优于对照组的小流量表现。这里的全局AUC其实就是通常所定义的AUC值，不过我们的训练数据集、测试数据集较大，为此专门实现了可用于计算大数据量级的AUC值的方法。

3. 模型权重融合

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

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

小结

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

出自：21cto

版权申明：内容来源网络，版权归原创者所有。除非无法确认，我们都会标明作者及出处，如有侵权烦请告知，我们会立即删除并表示歉意。谢谢。

-END-