推荐系统从入门到 Spark 案例实践

课程介绍

随着移动互联网的高速发展，互联网所承载的信息呈爆炸式增长，而我们所能接触的信息量也急速增长，并且随着移动互联网的进一步发展，用户时间高度碎片化，如何在最短的时间内，快速抓住用户焦点、提升产品粘性、提升用户体验成了重中之重。

而设计合理的推荐系统恰巧能很好地解决当前的难题，进行用户个性化的捕获、提升信息触达的精度、缩短用户与所需信息之间的路径、提升用户的体验。

所以，推荐系统已经成为了在线视频、电商、在线音乐、内容资讯等各个领域的标配，无论是技术人员还是产品经理，掌握以及了解推荐系统的知识体系已经成为了一个迫切的需求。

本课程的核心思路在于如何从零构建一个完整的推荐系统，并且将会以容易理解的陈述方式，来讲解推荐系统的需求背景、涉及到的一些基础知识、常用的算法策略、工程架构、涉及到的产品思维以及评估体系等。整个课程内容都在围绕如何构建以及认识推荐系统这么一个常见的产品形态为准，期间还会结合 Spark 工程案例进行深入讲解，理论与实践结合，帮助大家快速提升。

作者介绍

黄崇远，毕业于哈工大，6 年多大数据以及互联网从业经验。目前为 SEE 小电铺大数据主管，负责公司整个数据团队建设以及数据服务体系搭建。大数据原创公号『数据虫巢』（ID：blogchong），在大数据架构、大数据应用挖掘、数据产品化以及大数据团队建设等方面有一定的积累。

课程内容

导读：推荐系统正成为所有领域的一种标配

为什么推荐系统越来越大行其道

近段时间团队在扩建算法小组，其中至关重要的岗位就是推荐算法工程师，然而历经一两个月的招聘后，却发现一个事实，推荐算法工程师太难招了。

要么根本就约不过来，要么就是手里握着好几个 Offer 骑驴找马不亦乐乎，又或者是给人家发了 Offer，人家根本就不 care。

是的，推荐算法工程师，又或者说算法工程师已经成了一个香馍馍，进一步看招聘市场不难发现，各家都在抢算法以及推荐算法相关的人才。自己随便做的一个 App，如果没有个性化推荐的智能元素，似乎已经拿不出手，不好意思说出去。

这确实是事实，推荐系统已变得越来越大行其道。

人们的耐心正在逐渐降低

随着移动互联网的进一步发展，从各种各样的渠道不难发现，人们的注意力正在不断的从 PC 端往移动端迁移。

而我们知道，对于移动端，人们的使用时间是高度碎片化的，这与我们移动端的使用场景有关，这就意味着，对于任何 App 或者相关的应用，很难维持用户长时间集中在应用中。

除此之外，虽然中国的基础技术建设方面依然落后于美国等发达国家，但是据传闻中国的互联网应用已经走在了世界的前列，美国很多公司已经在复制中国互联网企业模式。换种角度说，在国内，各类应用的开发已经到了“丧心病狂”的地步了，即你会发现各个领域，应用的同质化已经非常严重。

上述的两个重大原因，会让用户在单一的应用中，其停留的时间以及注意力将会越来越少。这也就是为何说，人们的耐心正在逐渐降低。

每个 App 或者说应用都面临着一个问题，那就是如何在最短的时间内抓住用户的焦点，来提升用户的体验。

面临海量信息选择困难症，如何快速为用户筛选有效以及有用信息成为了首要解决的问题，于是，能够理解用户以及用于替代海量信息平铺陈列的推荐模式成为了潮流。

信息获取的两种机制

具体聊推荐系统之前，我们先来了解一下获取信息的两种基本机制，第一是主动获取，第二是被动获取。

主动获取信息很容易理解，我们是抱着很明显的目的去执行，即在获取信息之前对于将要获取的信息已经有了比较明确的定义，在我们去触达的时候，会有比较明确的思路，以及对于即将要获取的信息所付出的成本也有一定的心理预期。

主动获取信息

对于信息主动获取的方式，最典型的有两种，一个是搜索，另一个是导航。

对于搜索，想必大家能最快想到的就是国产大百度，其次便是搜索界一霸谷歌。百度和谷歌通过解决用户的信息主动检索问题，便能成就一个产业，所以对于信息主动获取的需求是很巨大的。

对于另一个主动信息获取的方式，即导航。在门户时代，门户网站的分门别类的各色频道，以及频道下对应的各级菜单其实就是一种导航，再到目前国内遥遥领先世界的电子商务领域，其各色平台，少不了的就是类目导航。

导航提供的是一种通用的目录结构，人们通过对信息的认知，再结合通用的树状结构，逐步检索到自己需要的信息。

同样，通过导航获取信息的方式也需要花费巨大操作成本（与搜索相比），但在主动需求的平衡中，这种成本的支出是可预期的。

被动获取信息

但是很遗憾，大部分的场景下，至少过半的用户并不是抱着很明确的目的去使用的，通常是一种随意看看、随便逛逛的心态，这就意味着被动信息获取的场景我们同样需要去满足。

虽然用户是随便看看、随便逛逛，但作为被逛的主体方可不能带着这种心态，我们必须在用户的随便行为中，把用户给牢牢吸引住，不然就不知不觉地给逛走了。

这就涉及到了被动信息获取机制中的推荐系统。对于用户来说，推荐是一种被动的行为，主体方意图通过推荐的方式将最吸引用户或者说用户最可能感兴趣的东西被动呈现给用户。

通过推荐的方式，缩短用户与其潜在需求信息的路径，从而提升用户的体验、提升用户的粘性。

搜索有大百度、大谷歌，但也不要小看推荐系统这种模式的魅力。除了各色各样非典型非代表性的推荐案例，这两年来今日头条就是依靠推荐引擎起家的，硬生生成为了信息分发领域里的一霸，包括我们的大百度也在玩命地在其搜索 App 中或者应用中做个性化的信息流，意图切分一份蛋糕。

除此之外，微信生态中的朋友圈广告，实际上也是一个典型的推荐案例。微信通过对于推荐以及社交关系的研究，大大提升了其广告投放的准确率，一方面不至于浪费流量，另一方面也不会让用户产生过多的厌恶感，毕竟瞎推乱搭的信息对于用户的体验伤害还是很大的。

推荐系统的场景

在上面，我们对于推荐系统的大致市场行情以及推荐产生的背景，以及分析信息获取的几种机制，最终我们确定推荐系统确实是一个刚需。现在具体来看看一些常见的推荐系统场景，以及分析其具体能解决什么问题。

通过下面的几个例子，我们对于推荐系统场景化的认识或许可以加强，以及具体推荐以一种什么样的形态去展现。

在线视频领域

这是腾讯视频某个视频播放页的推荐场景。在我截图的时候，当前播放主页是《蜘蛛侠3》。我们再来结合当前主体信息来推断其推荐列表的算法机制，不难发现其属性相关占比的权重会比较大。所谓属性相关，即与当前主体的相关属性，诸如同一系列、同个主题、同个导演等。

当然，这里我们只是做一个场景的熟悉，并不是要去评估一个推荐列表的好坏，那是后续课程需要做的事。

但需要顺带说一下的就是，一个完整的推荐系统，推荐算法并不是它的全部，甚至很多时候一个推荐列表的生成也并不单纯地依赖于某个推荐算法。

整个推荐系统，承载算法的模型层只是其中最重要的一环，除此之外，还有整个算法架构、工程架构、策略引擎，甚至包括推荐系统中涉及的一些产品思维。这些在本系列中将会逐一进行阐述。

在线音乐领域

我们再来看一下腾讯体系下其他的推荐场景，诸如 QQ 音乐平台的歌单推荐。

具体说根据什么逻辑进行的推荐，以及推荐的是否合理，有没有点击的欲望等，这里暂时不做评论。

网络文学领域

除了视频音乐领域，我们再来看看网文文学领域，这是同属大腾讯体系下的起点中文网图书主页的推荐列表。

从其推荐理由的设计来看，其推荐列表的生成与当前书本的关联性会比较大，与当前主体的属性关联性也很强。

不难发现，上述列了三个不同领域。三个不同推荐场景其推荐栏位的栏位名称，我们一般更喜欢称其为推荐理由，都是不尽相同的。推荐理由是推荐系统中的一个重要组成成分，甚至很多时候会在推荐转化的过程中，起到重要的作用。在后续涉及推荐产品思维的课程，我们会重点讲解。

电商领域

说到推荐的场景，不得不说的就是电商领域。电商平台是最早引入个性化推荐系统的领域，亚马逊可谓是推荐系统的鼻祖了。并且整个推荐的发展进程，亚马逊的 Push 作用确实是不容忽视。

据有消息称，亚马逊整个体系中已经有 20%~30% 的 GMV 是通过推荐带来的，我们来看看亚马逊网站的推荐场景。

当然，这只是其中的一个购买主页的场景，其他的场景大家自行去探索。至今为止，各大电商网站平台，推荐系统已经是一个标配，包括我们熟悉的某宝某东。在推荐方面，，今天的电商，或多或少都受到了亚马逊的影响。

推荐系统正在成为全领域的一种标配

如上，我们只是列举了在线视频、在线音乐、网络文学、电商等领域的推荐场景，实际上还有其他我们耳熟能详的一些产品，典型如内容资讯领域，也是推荐系统的“重灾区”。

不止如此，正如我们开篇所讲，面对着用户时间的碎片化，以及信息的同质化、海量化，以及用户耐心的减少，各个领域都需要解决同样的问题：如何尽可能留住用户，缩减用户获取有用信息的路径。

而推荐，或者说个性化推荐系统，是当前比较好的一种解决方案。一如开题所说，推荐系统正成为所有领域的一种标配。

基于此，我们所有涉及相关的从业人员，包括数据相关的技术人员、产品甚至是运营，我们对于推荐都需要有一定的了解和认知。

本课程将从推荐系统中的推荐常识讲起，到最核心的常见推荐系统算法，再到算法架构，到工程架构，再到推荐的核心迭代神器快速实验平台，最后再到推荐系统的产品思维等，来帮助大家逐渐构建起一个相对完善的推荐系统知识体系。

本系列课程分为以下三大部分：

• 第一部分（导读~第02课），主要阐述推荐系统的需求背景、目前常见的应用场景、一些推荐的基础常识等维度，对推荐系统涉及的相关基础知识进行一个大致的介绍。
• 第二部分（第03~09课），主要从推荐系统算法的维度进行常见推荐系统算法的学习和掌握，推荐系统算法是推荐系统的核心，针对于每个算法，我们都将结合理论，以及 Spark 工程代码实例进行讲解。
• 第三部分（第10~12课），主要从推荐系统的推荐架构以及推荐系统的产品设计思维两个大方向进行学习和了解，最终架构起整个推荐体系。

点击了解更多《Spark 案例上手推荐系统》

第01课：推荐算法不等于推荐系统

在上篇导读中，我们对推荐的需求背景以及场景等偏业务领域的知识，有了个大概的认知，从这篇起，我们将逐渐过渡到偏技术的层次上。

这里我们将对推荐，或者更确切的说是推荐系统有个更全面的认知，比如它的组成结构，涉及到哪些需要解决的技术问题、哪些技术领域，以及这些问题的具体表现等。

推荐系统概述

在上篇中，我们看到了很多推荐的应用场景、各个领域、各种应用都或多或少的体现了这个模式的可用性，但对于业务层来说，我们单纯看到的就是一个推荐栏位、栏位名称及推荐的形式，具体的推荐列表。

所以，这种情况会给人带来一种错觉，下意识的认为推荐算法其实就是推荐系统的全部，我们能看到的推荐列表就是通过某个推荐算法计算出来的，而我们研究推荐其实就是研究推荐算法。

这个观点实际上是很不负责任的，推荐系统是一个相对复杂的业务系统，其中会涉及到数据是如何处理的、架构是如何搭建的、推荐的算法如何去设计实现、反馈的数据如何收集、基于收集的数据如何做优化迭代、整体系统如何做评估、产品形态上如何做设计。

如此看来，整个推荐体系实际上是一个相对复杂的体系，远不止我们了解的那样简单，而想要达到一个好的推荐效果，整个体系的完善是必不可缺少的。

而我们所接触的最近的以及最熟悉的实际上是推荐的产品形态，以及推荐算法或者说推荐策略，当然，不可否认的是，推荐算法确实是整个推荐系统的灵魂，其好坏严重影响整个推荐的转化。

常见的推荐算法简介

既然推荐算法是推荐系统中的核心，我们有必要对常规常见的一些推荐算法有个直观的认知，然后再结合自身的产品体验对推荐算法的一些逻辑进一步深入的理解。

基于内容属性的推荐

这种推荐逻辑很简单，只是单纯的依赖物品之间的属性相似来构建推荐关系，结合导读中的腾讯视频推荐的例子，比如如果我在看《蜘蛛侠3》，你给我推荐《钢铁侠》、《蝙蝠侠》，理论上是有一定道理的，都是科幻大片嘛，说不定还是同个系列呢。

所以，基于内容的推荐，容易理解，并且很多时候还是有一定效果的，但实际上很多时候会存在这几种情况，导致了这种原始推荐失效。

• 如果用户浏览当前的物品本身就不是用户的菜，甚至是一个非优质信息（当前主体不可控），再基于当前物品进行推荐就是个伪命题。

• 基于上面这条，即使当前主体是用户的目标，但再推类似主体会造成信息冗余，即当前主体信息已经解决了用户的问题。

所以，由于用户行为的不可控，基于内容属性相似的推荐，风险还是挺高的，这是导致了这种原始直接的机制并不会得到广泛的推广。

但与乱推荐相比，还是有一定正向作用的，毕竟用户浏览的主体是自身选择的结果，本身用户对于其选择的信息主体是有一定偏好性的。

基于画像的推荐

基于物品本身属性的推荐，其实与个性化是没有任何的关系，毕竟推荐候选集只跟物品主体有关，与用户无关，就谈不上什么个性化了。

而基于用户画像（更多人喜欢用基于用户标签）的推荐，则更大程度上依赖于用户的画像属性来推荐，这就体现了用户偏好信息，根据偏好信息来选择候选集。

这是一种很通用的做法，并且在大规模数据集情况下，在很多实际的产生过程中喜欢使用这种机制。而用户的画像，或者更具体点用户的兴趣标签如何构建呢？其实就是依赖用户累积的行为数据了，通过行为数据生成用户的兴趣标签。

这看似是一种相对靠谱的做法，毕竟如果把用户的爱好都分析清楚了，主动给用户做推荐不就显得很个性化了吗？在实际的场景中，首先，并不是所有用户的行为都足够用来表征其兴趣偏好的，即我们会高估用户的行为集合，从而产生有偏差的画像属性，更甚者，如果用户完全没有行为怎么办呢？

其次，通常来说，用户的兴趣爱好是会随时间迁移而改变的，所以，把握用户的兴趣程度以及其变化并不是一个容易的事情，更何况用户实际的选择还会受很多因素影响，比如，我当前查找的一个信息并不是我之前掌握的信息，那意味着这些信息偏好在我的历史轨迹中都体现不出来，那单纯的通过我的兴趣去推荐就显得不靠谱了。

但不管怎么说，根据用户的偏好来做推荐，大方向肯定是没有问题的。

基于协同过滤的推荐

协同过滤，或许了解过推荐系统的的朋友，多多少少都能听过一些，并且协同推荐可是作为推荐领域典型案例而存在的。

协同过滤同样不会去研究物品的本身属性，甚至也没有空去构建用户的画像标签，正如他的名字描述的一样，他严重依靠于用户的行为以及其周边用户的协同行为。

举个例子，为一个用户推荐信息，那么我只需要参考其周边用户在看什么信息，就给他推荐什么信息就好了。

重点在于，如何限定周边这个范围，比如根据两个用户的行为，去构建相关关系，从而判断用户之间的相似程度，把相似用户的行为推荐给当前用户，这就是协同中典型的基于用户推荐。

而如果以物品为维度，以用户的购买或者观看记录为向量，则可以构建物品的相似度量，针对于每一个待推荐选项，用户的历史轨迹就是其向量构成，就可以判断该用户历史的轨迹信息与当前的待选物品的向量相关度了，从而判断是否要推荐，这就是基于物品的协同逻辑。

与基于用户画像的推荐对比，这种推荐有一定几率可以发现新物品，即并不严格依赖用户的兴趣。举个例子，假设几个信息的层级是 A、B、C，并且 A、B、C 是层级递进关系，并不是同一个东西，对于一个用户来说，他掌握的是 A，则意味着他的兴趣偏好大多偏向于 A，根据兴趣标签，其实是很难推荐这种递进相关的信息。

但是，如果其他用户的学习轨迹都是 A→B→C 这种轨迹，这意味着 A、B、C 三者之间本身就有前后潜在逻辑关系存在的，基于协同，即可为该用户在掌握 A 的基础上，推荐 B、C 的内容，这也是基于兴趣所做不到的地方。

当前，基于协同行为的推荐，除了基于物品还有基于用户，还有其他诸如基于模型的协同，典型如最近邻模型、基于矩阵分解以及基于图关系模型的构建的推荐机制。

基于关联规则的推荐

在上一篇中，相信大家有看到其中一个推荐场景的理由“看过 XX 的还看过”，或者“买过 XX 的用户还买过”类似的推荐理由。

实际上支撑类似理由的一个很重要的推荐算法就是关联规则。即我们通过一定的逻辑来寻找物品之间的相关关系，请注意是相关关系并不是相似关系，又或者说我们寻找并不是严格意义上属性上的相似，单纯只是为了寻找他们之间的关联性。

这就要从“啤酒与尿布”的故事说起，或许很多朋友已经听过这个故事，即超市对用户的的购物清单进行分析，发现一个很奇怪的现象，那就是很多经常在购买尿布的时候顺带会购买啤酒。

这是一个很奇怪的组合，单纯从物品属性的角度上看，两者之间很难有明面上的关系，但事实就是他们确实存在某种关联，超市于是将这两种商品放在同个货架中，于是大大提升了两者的搭配销售额，并且做了类似的计算，来优化整个货架陈列，从而提升销售额。

实际上这就是一个推荐场景，即在尿布的商品浏览的时候适当进行啤酒的推荐，从而提升搭配销售的效果，实际上这是一个关联分析的过程。

即通过他们历史的搭配售卖情况，来分析每个搭配之间的合理性，即分析不同商品组合之间的相关性，这种相关性很难去解释，但确实是在生效。

其他常见推荐算法

其实在我们实际的操作过程中，并不会严格的依赖于这种条条框框、只要合理即可行，比如我们完全可以把推荐问题转化为分类问题，针对于每个待选项，它都是 Yes or No 的问题，即一个二值分类。

再比如微信朋友圈，微信一定是会研究用户的朋友圈关系的，比如你对哪类朋友点赞、互动行为最多，它是不是会考虑推荐你欣赏的朋友偏好内容给你？毕竟微信是一个典型的熟人社交模型。

所以，推荐算法看似重要，但其实想想又没有这么重要，很多时候并不是一成不变的，都要我们根据场景去考虑，最最最重要的是，需要我们用实际效果来选择机制，也或许是多种机制共同生效的结果。

本篇主要从推荐系统的整体涉及的一些概念上，以及针对于推荐系统最重要的一些常见算法进行简单的介绍，让大家对于推荐的算法逻辑有个大致的了解。

在下一篇中，我们将继续补充推荐体系相关的基础知识，包括冷启动的机制，推荐里产生的马太效应的体现，以及具体深入分析推荐系统的评判方式，最终来帮助大家建立起推荐系统的基础知识框架。

然后再深入算法设计以及实现层，进行实操。

点击了解更多《Spark 案例上手推荐系统》

第02课：推荐冷启动 & 马太效应 & 评估机制

第03课：基于内容的推荐（原理）

第04课：基于内容的推荐（工程示例）

第05课：融合了用户兴趣的推荐才更具个性（原理）

第06课：融合了用户兴趣的推荐才更具个性（工程示例）

第07课：协同推荐（原理）

第08课：协同推荐（工程示例）

第09课：灵活多变的推荐算法设计

第10课：推荐系统的架构设计（上）

第11课：推荐系统的架构设计（下）

第12课：实验平台搭建 & 产品设计思维

阅读全文: http://gitbook.cn/gitchat/column/5b4ee9df01d18a561f3430d9