文末福利~

推荐系统的逻辑框架

先来简单梳理下推荐系统的作用和意义。

用户的角度：推荐系统解决的是在‘信息过载的情况下’，用户如何获得感兴趣信息（或者说是对自己有用的信息）的问题，特别是在互联网这种拥有海量信息的场景下，推荐系统会更多地利用用户的各类历史信息‘猜测’其可能喜欢的内容。

公司的角度：推荐系统解决产品能够最大限度地吸引用户、留存用户、增加用户黏性、提高用户转化率的问题，从而达到公司商业目标连续增长的目的。当然，不同的业务模式的公司的优化目标是不同的：如视频类公司更注重用户观看时长，电商类公司更注重用户的购买转化率，新闻类公司更注重用户的点击率。

从上面可以看出，推荐系统要处理的核心问题就是如何更好地利用商品和人的信息来实现公司与用户的双赢。

就‘信息’来讲，可以根据所属大体划分为三部分，分别是物品信息，用户信息和场景信息。物品信息只是一个统称，在不同的场景中也会有不同的叫法，比如在商品推荐中可以称为‘商品信息’，在视频推荐中可以称为‘视频信息’，在新闻推荐中可以称为‘新闻信息’等等。用户信息通常包含和用户更加相关的信息，如人口属性、历史行为、关系网络等等，这些信息往往可以推测出‘人’的兴趣点。

场景信息一般指的是时间、地点等一些环境信息，常常也被称为‘上下文信息’。

在我们获得‘用户信息’，‘物品信息’，‘场景信息’后，就可以将推荐系统解决的问题定义为以下形式：对于用户 U（user），在特定场景下 C（context）下，针对海量的物品，构建一个函数 f (U, I, C)，预测用户对特定候选物品 I（item）的喜好程度，再根据喜好程度对所有候选物品进行排序，生成推荐列表的问题。

这样我们就可以大致得到如下图所示的推荐系统逻辑框架。

推荐系统的技术架构

不论是数据处理，还是模型训练，都需要各种各样的计算，常常我们看一些文章的时候，总是会谈到离线计算，近线计算，在线计算等，因此想要了解推荐系统的技术架构，就需要对这几种不同的计算方式有一定的了解，直接来上张图。

从上图中可以看到，从上至下依次为离线（offline），近线（nearline），在线（online）三部分。

离线（offline）

存储离线数据，利用大数据查询工具进行数据查询和处理，离线模型训练。离线部分对于数据数量和算法复杂度的限制较少，以批量方式完成数据处理，但是数据处理的实时性非常差，无法做到数据和模型的及时更新。

近线（near line）

基于数据消息队列，利用一些流计算平台进行数据的准实时处理。它居于离线和在线之间，既可以以分钟级别甚至秒级的延时来准实时地处理数据，也有一定的数据批量处理能力。

在线（online）

online部分的主要任务是进行用户请求的实时处理，模型的在线服务。在线部分需要更快地响应最近的事件和用户交互，因此对于延迟的要求比较苛刻，一般都要求在100ms以内完成所有处理，这会限制所用算法的复杂性和可处理的数据量。

常用的技术栈： HDFS(离线)+Spark(离线)+Flink(在线+近线)+Redis(在线+近线)，从离线到在线，数据的实时性从上到下依次增强，而数据规模和处理能力从上到下依次减弱。

推荐系统的技术架构图如下。

推荐系统的数据部分

在推荐系统的技术架构中，数据部分主要负责收集和处理用户信息、物品信息，场景信息。而海量信息是需要大数据平台来处理的。根据实时性的强弱排序：依次为‘客户端及服务器端实时数据处理’，‘流处理平台准实时数据处理’，'大数据平台离线数据处理’。而在实时性由强到弱递减的同时，三种平台的海量数据处理能力则由弱到强。当然，一个成熟的推荐系统的数据流系统会将三者取长补短，配合使用。

推荐系统的模型部分

推荐系统的模型部分是推荐系统的核心，也是主体，模型结构一般由‘召回层’,‘排序层’和‘补充策略与算法层’（重排序）组成。

‘召回层’一般利用高效的召回规则、算法或简单的模型，快速从海量的候选集中召回用户可能感兴趣的物品。

‘排序层’利用排序模型对初筛的候选集进行精排序。

‘补充策略与算法层’也被称为‘重排序层’，可以在将推荐列表返回用户之前，为兼顾结果的‘多样性’，‘流行度’，‘新鲜度’等指标，结合一些补充的策略和算法对推荐列表进行一定的调整，最终形成用户可见的推荐列表。

模型训练根据训练环境的不同，分为离线训练和在线更新两部分，其中，离线训练的特点是可以利用全量样本和特征，使模型逼近全局最优点，而在线更新则可以准实时地‘消化’新的数据样本，更快地反映新的数据变化趋势，满足模型实时性的需求。

模型性能预估：离线指标 AUC/Recall/RMSE等，而在线评估则是AB Testing，它是用于衡量某值算法上线后带来的真实收益情况（这里的收益可以是CTR/CVR/ecpm等），从而让我们知道某个算法是否和离线预估表现的一致，是否值得上线替代老版本的算法。

常用算法框架：TensorFlow/Keras，Spark MLlib，在数据采集上，可以采用Flink；在离线批量计上，可以采用历久弥新的Spark；在底层数据存储上，可以采用HDFS；在存储(U,I,C)的近线在线特征时，可以采用Redis。

将上面推荐系统的技术架构进一步细化的话，可得到如下图所示的技术架构。

AB Testing的流程

假设我们要上线A算法通过了我们的离线预估，准备上线来与线上正在跑的B算法battle一下。

通常的AB Testing流程是：

在线上的流量池中，切出一部分流量来给A算法（该流量为实验组）同时为了方便对，会切出等量的流量来给B算法（该流量为对照组），让这两个算法分别在各自的流量中运行一段时间，看看最终在线CTR/CVR等商业指标的表现情况如何。

其中的流量则指的是用户，同时在实验期间：实验组有且仅能看到A算法效果；控制组有且仅能看到B算法效果，因此AB Testing环节的精髓便在于，怎么”公平“的切分流量。即让两个流量组的用户分布均匀，不会存在实验组用户和控制组用户区分性太大，因为区分性太大流量就有偏了，做出来的实验效果自然不可信。比如实验组美国的用户占比为80%，而控制组的用户美国的用户的10%就是一个分流非常差的结果。

AB Testing的意义在于：离线评估无法完全消除模型过拟合的影响，因此，得出的离线评估结果无法完全替代线上评估结果。一般来讲，离线评估往往不会 考虑线上环境的延迟、数据丢失、标签数据缺失等情况。因此，离线评估的结果 是理想工程环境下的结果。线上系统的某些商业指标在离线评估中无法计算。离线评估一般是针对 模型本身进行评估，而与模型相关的其他指标，特别是商业指标，往往无法直接获得。比如，上线了新的推荐算法，离线评估往往关注的是ROC曲线、P-R曲线等 的改进而线上评估可以全面了解该推荐算法带来的用户点击率、留存时长、PV 访问量等的变化。这些都要由A/B测试来进行全面的评估。

七月在线宠粉礼

↓↓↓单推荐方向课程15个小课1分起购，更有ML、DL、CV、NLP等精品课1分秒！↓↓↓
移步→http://julyedu.com 抢购

已帮助超200人达成升职加薪愿望的【推荐高级小班】课，也有钜惠福利，了解详情→https://www.julyedu.com/employment/rs13