qq_37756660的博客

今天主要谈的是推荐系统中人的因素，包括了团队和个人，这部分内容本来和技术干货内容相比，就有点形而上，但是事实上却又绕不开这部分内容。因此，先用一个例子呈现了一个“有下限团队”应该有多少人。这里没有考虑人的个人能力差别，这里就假设大家智商都有一样，没有天才和白痴。很多时候，其实单机就能搞定很多看上去很复杂的事情，这是我不太推崇分布式的原因，因为多数时候没必要。最后，谈了我对推荐系统工程师的能力看法，一共有三个层次，建设起来由易到难，需要不断刻意练习，才可能有较大的能力进步，这一点和你共勉。

具体信息流会怎么发展，我们无法预测，但是可以肯定的有三点：1. 信息流是推荐系统在商业上最成功的应用；2. 完全依赖数据驱动的信息流会面临黑天鹅事件，所以人和算法协同进化的信息流会是最有生命力的；3. 数量上，注意力已被大厂囤在自己了手中，那么下一步要关注的是注意力的质量，这是信息流平台方的商品，毕竟广告主购买了注意力后，发现是地摊货，生意也不会长久的。

今天，换了一个角度去看待推荐系统的角色和作用，它是一台注意力存储机器，在注意力稀缺的今天，用投其所好的方式存储注意力，并将注意力作为商品与人交换产生价值，也就是广告、电商销售、其他增值服务。这些都是存储了注意力，并对存储的注意力进行了变现。但是，你要认识到，存储注意力并非只有推荐系统一种机器，所以你们家要不要采购这台注意力存储机器呢？那就需要再考虑一下成本了，如果存储的注意力价值远不及成本，想必你会采购这台注意力存储机器。这样就和专栏的开篇讲到，要不要上推荐系统的分析首尾呼应。

你可能注意到了，这里的推荐系统算法部分以 Python 和 C++ 为主，甚至一些 Python 项目，底层也都是用 C++ 开发而成。因此在算法领域，以 Python 和 C++ 作为开发语言会有比较宽泛的选择范围。至于完整的推荐系统开源项目，由于其封装过于严密，比自己将大模块组合在一起要黑盒很多，因此在优化效果时，不是很理想，需要一定的额外学习成本，学习这个系统本身的开发细节，这个学习成本是额外的，不是很值得投入。因此，我倾向于选择各个模块的开源项目，再将其组合集成为自己的推荐系统。

让效果指标真的在反映效果，也是要追求的效果。这句话虽然有点绕口，但是作为推荐系统从业者，应该牢记心间。这句话背后反映的就是推荐系统的健壮性。外部对推荐系统的攻击常常发生，而且又常常发生在协同过滤算法上。协同过滤相比训练出模型的推荐算法来说，的确更加脆弱些。基于用户的协同过滤又比基于物品的协同过滤要更常被攻击，究其原因，因为基于用户的协同过滤被攻击不容易在直观上发现，毕竟人在现实中也容易盲从，更何况在数字世界中被人伪造了几个知音一样的用户帮他们推荐呢？

推荐系统作为一种 AI 系统，其测试方法不完全相同于传统软件功能测试。对于推荐系统，也有一定的单元测试，扫描业务规则，对系统做一票否决制，因为这些业务规则定义明确。除此之外，还要先经过离线模拟，再线上小范围实测，这部分测试就是在践行数据驱动。这部分指标主要在回答系统的两个问题。系统表现有多好？系统还能好多久？只要系统现在表现好，并且系统生命力强，那么你的推荐系统就是好的推荐系统。这些指标就是在忠实反映这两个侧面的。

其实一个推荐系统的在线服务，和任何别的在线服务相比，也没有什么本质区别，只是仍然还有一些特殊性。提供一个在线服务，需要两个关键元素：数据库和 API。今天我就来专门说一说推荐系统中大家常常用到的数据库，并会谈谈推荐系统的 API 应该如何设计。今天主要讲解了推荐系统上线的两大问题，一个是线上数据存储，另一个是推荐系统的 API 有哪些。虽然实际情况肯定不是只有这点问题，但是这些也足以构建出一个简单的推荐系统线上版了。

实验平台是推荐系统要做到数据驱动必不可少的东西，但是如何做到科学高效快速地做实验呢？常见的做实验，只是简单地选择一个尾号的用户 ID 作为实验组，再选择另一个尾号作为对照组，甚至选择剩下所有的用户 ID 作为对照组。这样做出来的实验，显然是有问题，因为并不知道通过用户尾号来分组是不是能做到无偏？另一个问题是，这样就只能在一个时期只能做一个实验，非常低效。本文以 Google 开放的实验平台架构作为原型，对其核心技术做了详细介绍。这个实验平台做到了同时无偏地做多组对照实验。

今天以协同过滤为例讲到了如何构建一个实时推荐，实际上，并不是每一种推荐算法都适合做实时推荐的，或者没必要。幸运的是，很多机器学习算法，都可以使用一些在线学习方法更新模型，这些在线学习算法非常适合作为流计算的任务运行，属于我说的第三层次实时推荐。另外还有一种算法天然就适合在线实时进行，那就是前面讲到的 Bandit 算法，通过和用户之间反复互动更新推荐。

今天和聊了数据采集的若干要点。数据是推荐系统做饭的米，没有数据就没有任何推荐策略的落地，因此采集数据是一个非常重要的工作。采集数据需要首先梳理好自己的数据有哪些，本文不是帮你梳理你的自己的产品中有哪些数据，而是告诉你看推荐系统需要哪些数据。另外有一点，数据采集的需求方有很多，推荐系统只是其中一个，通常数据分析对数据的需求，集中在多维数据分析，当然推荐系统也需要多维数据，只是推荐系统更关注事件。把这些数据全都看成矩阵，有了矩阵，无论是内容推荐还是协同过滤，矩阵分解，还是机器学习深度学习，就都有了输入。

总结一下，今天我们提到了推荐架构和搜索、广告的关系，并将三者分别作了对比。最后，我还分别抽象了三者的架构。以上分析只是基于纯粹技术和业务角度作的简单分析，不过几乎所有人都觉得这个提法是意料之中，大家承认三者有统一的概念基础，对此亦有共识，但是我们在实现时还需要考虑一些困难，毕竟仅有少数公司有统一架构的成功案例。实际上，这三者有统一的可能性，而且不低。如果要统一，从 0 就应该开始，这其实更适合创业公司或中小公司。

今天以 Netflix 架构为原型，向你介绍了一个经典的推荐系统架构长什么样子。关于这个架构你只需要记住一点：它有三层，三层分别是离线，近线，在线。用如下的表格将这三层综合对比，并且简单举例，我们看看每一层分别放哪些任务。以上就是对这个架构的宏观总结对比。如前所说，其实架构都是进化出来的，你千万不必在一开始就追求完美的架构，满足最低要求就好。

今天逐一梳理了实现一个通用信息流的关键模块，及其已有的轮子，从而能最大限度地降低开发成本。这些对于一个中小型的社交网络来说已经足够，当你面临更大的社交网络，会有更多复杂的情况出现，尤其是系统上的。所以，壮士，请好自为之，时刻观察系统的监控、日志的规模。

今天介绍了两种去重算法。在推荐系统中，虽然我们十分关心推荐匹配的效果，但是别忘了，对原始内容的挖掘和清洗往往更加重要。这其中就包括对重复内容的检测。两种去重策略都是牺牲一点误伤的概率换得大幅度的效率提升，具体的做法都是要借助哈希函数。只是哈希函数的结果在两个算法中有不同的处理手段，Simhash 是加权，Bloomfilter 则是用来做寻址。

今天介绍的算法非常简单，但是在推荐系统中有很多的用途。尤其是面对的数据需要采样、需要有所变化时，加权采样本质上来说就是让权重影响采样概率。前面的几种加权采样算法，都是让采样概率和权重成正比，这意味着你的样本权重之间的关系要合理。那么，请思考另一个问题，如果你的样本权重有正有负，该如何加权采样呢？

今天，主要讲到了三种构建排行榜分数的算法，因为排行榜的意义重大，所以不可以太随便对待，甚至应该比常规的推荐算法更加细心雕琢。一个最最朴素的排行榜就是统计一下销量、阅读量等，但要让排行榜反映出热度的自然冷却，也要反映出用户赞成和反对之不同，还要反映出用户评价的平均水平。不要被前面那个非常大的一坨公式所吓倒，实际上，它统计起来很方便。这些公式都是在实际生产中演化而来的，根据这些原理结合自己实际遇到的问题，也可以设计出符合自己业务要求的排行榜公式。

好了，今天介绍了如何使用循环神经网络推荐音乐播单，播单是一个时间序列，听完上一首歌会影响下一首歌。循环神经网络和普通神经网络相比，就是在两个时刻的隐藏状态之间多了网络连接。看上去这个网络连接只与上一个时刻有关，事实上，上一个状态又与上上个状态有关，所以实际上任意一个时刻的状态是与此前所有的状态有关的。

通过观察 YouTube 的推荐系统中所用到的深度学习来看，在排序方面，深度神经网络已经崭露头角，包括前面讲融合模型时，专门讲到的 Wide&Deep 模型，也是深度学习在排序方面的贡献。除此之外，深度学习更多发挥作用的地方是特征表达上，各种嵌入技术得以让物品、用户、关系等对象的特征化有更好的输出。今天主要介绍了深度学习在推荐系统可以发挥哪些作用，同时以 YouTube 为例，介绍了国际大厂在这方面的落地情况。从 YouTube 的推荐系统可以看出，深度学习主要贡献在于特征表达学习和排序模型上。

今天，介绍完成了 MAB 问题和推荐系统之间的千丝万缕联系。Bandit 算法是一种不太常用在推荐系统的算法，究其原因，是它能同时处理的物品数量不能太多。但是，在冷启动和处理 EE 问题时，Bandit 算法简单好用，值得一试。当然，这个专栏介绍的所有推荐算法都不是单打独斗最好，而是与其他算法结合使用才能相映生辉，Bandit 算法亦是如此。今天介绍的 COFIOBA 算法，原理很简单，就是把协同过滤思想引入到了 Bandit 算法中，不再是用户独立决策，而是用户所在的群体共同决策推荐结果。

今天分享了一种上下文有关的 Bandit 算法，叫做 LinUCB，它有这么几个优点：1. 由于加入了特征，所以收敛比 UCB 更快，也就是比 UCB 更快见效；2. 各个候选臂之间参数是独立的，可以互相不影响地更新参数；3. 由于参与计算的是特征，所以可以处理动态的推荐候选池，编辑可以增删文章；当然，LinUCB 以及所有的 Bandit 算法都有个缺点：同时处理的候选臂数量不能太多，不超过几百个最佳。因为每一次要计算每一个候选臂的期望收益和置信区间，一旦候选太多，计算代价将不可接受。

今天介绍了一种走一步看一步的推荐算法，叫做 Bandit 算法。Bandit 算法把每个用户看成一个多变的环境，待推荐的物品就如同赌场里老虎机的摇臂，如果推荐了符合用户心目中喜欢的，就好比是从一台老虎机中摇出了金币一样。今天重点介绍的 Bandit 算法有汤普森采样，UCB 算法，Epsilon 贪婪，并且用模拟的方式对比了它们的效果，汤普森采样以实现简单和效果显著而被人民群众爱戴，需要时不妨首先试试它。

将传统的“宽模型”和新的“深模型”结合，虽然更多的是一种工程上的创新，但是非常有实用性，模型也容易很理解。简单画一下全文重点。1. 深宽模型是一个结合了传统线性模型和深度模型的工程创新。2. 这个模型适合高维稀疏特征的推荐场景，稀疏特征的可解释性加上深度模型的泛化性能，双剑合璧。3. 这个模型已经开源在 TensorFlow 中，大大减小了落地成本，感兴趣可自行取用。4. 为了提高模型的训练效率，每一次并不从头开始训练，而是用上一次模型参数来初始化当前模型的参数。

今天，介绍了另一种常用来做 CTR 预估的模型，因子分解机。因子分解机最早提出在 2010 年，在一些数据挖掘比赛中都取得了很好的乘积，后来被引入工业界做模型融合，也表现不俗。严格来说，因子分解机也算是矩阵分解算法的一种，因为它的学习结果也是隐因子向量，也是用过隐因子向量的点积代替原来的单个权重参数。

今天主要讲了简单的逻辑回归和梯度提升决策树，两者都是不太复杂的模型。并且无论是逻辑回归，还是梯度提升决策树，都有非常成熟的开源实现，可以很快落地。由于篇幅限制，在梯度提升决策树那部分有一些细节被略过了，你能自己手算出例子中的第二棵树是什么样的吗？

今天是矩阵分解三篇的最后一篇，传统的矩阵分解，无论是隐式反馈还是显式反馈，都是希望更加精准地预测用户对单个物品的偏好，而实际上，如果能够预测用户对物品之间的相对偏好，则更加符合实际需求的直觉。BPR 就是这样一整套针对排序的推荐算法，它事实上提出了一个优化准则和一个学习框架，至于其中优化的对象是不是矩阵分解并不是它的重点。但在这里结合矩阵分解对其做了讲解，同时还介绍了排序时最常用的评价指标 AUC 及其计算方法。

在真正的推荐系统的实际应用中，评分预测实际上场景很少，而且数据也很少。因此，相比预测评分，预测“用户会对物品干出什么事”，会更加有效。然而这就需要对矩阵分解做一些改进，加权交替最小二乘就是改进后的矩阵分解算法，被 Facebook 采用在了他们的推荐系统中，这篇文章里，也详细地解释了这一矩阵分解算法在落地时的步骤和注意事项。其中，提到了针对 One-Class 这种数据集合，一种常用的负样本构建方法是根据物品的热门程度采样，你能想到还有哪些负样本构建方法吗？

至此，我们介绍了在 Netflix Prize 比赛中最为出众的模型：SVD 及其一些典型的改进。改进方案分别是：1. 考虑偏置信息；2. 考虑隐式反馈和用户属性；3. 考虑时间因素。其实 Netflix Prize 比赛上诞生了很多其他优秀的算法，或者把一些已有的算法应用得到很好的效果，比如受限玻尔兹曼机用来融合多个模型，这个会在后面的专栏文章中专门再讲。

今天，介绍了常用的几种相似度计算方法，以及其各自的使用场景。这里的场景是按照数据形式划分的，按照向量维度取值是否是布尔值来看，杰卡德相似度就只适合布尔值向量，余弦相似度弹性略大，适合两种向量。欧式距离度量的是绝对差异，余弦相似度度量的是方向差异，但是调整的余弦相似度则可以避免这个弱点。

今天我们在基于用户的协同过滤基础上介绍了比较常见的一个算法：基于物品的协同过滤。这个方法常常在电商网站上见到，“买了又买”“看了又看”这样的相关推荐，都是由这个推荐算法产生。最后我们介绍了一个改良版的基于物品推荐算法 Slope One。这里也留下了一个问题：为什么说 Slope One 可以做到在线更新呢？

今天聊了基于用户的协同过滤方法，也顺带普及了一下协同过滤这个大框架的思想。基于用户的协同过滤算法简单直接，但是非常有效。只是，在实现这个方法时，有很多需要注意的地方，比如：1. 相似度计算本身如果遇到超大维度向量怎么办；2. 两两计算用户相似度遇到用户量很大怎么办？

基于内容的推荐一般是推荐系统的起步阶段，而且会持续存在，它的重要性不可取代。因为：1. 内容数据始终存在并且蕴含丰富的信息量，不好好利用就可惜了；2. 产品冷启动阶段，没有用户行为，别无选择；3. 新的物品要被推荐出去，首选内容推荐。基于内容的整体框架也是很清晰的，其中对内容的分析最为重要，推荐算法这一款可以考虑先使用糙快猛的相似度计算，也可以采用机器学习思路训练预估模型，当然这必须得有大量的用户行为做保证。

用户画像对于推荐系统还是非常必要的，而产品中属文本数据最多，那如何用文本数据构建出用户的画像内容呢？本文按照如下步骤梳理了这一过程：1. 分析用户的文本和物品的文本，使其结构化；2. 为用户挑选有信息量的结构化数据，作为其画像内容。

先说说“用户画像”这个词，它对应的英文有两个：Personas 和 User Profile。Personas 属于交互设计领域的概念，不在本文讨论范围内，请出门右转去找交互设计师们聊，留下来的人，我们聊聊 User Profile 这种用户画像。User Profile 原本用于营销领域。营销人员需要对营销的客户有更精准的认识，从而能够更有针对性地对客户和市场制定营销方案。这个理念本身没有错，但是有一个问题：传统营销领域，是以市场销售人员为第一人称视角去看待客户的，也就是用户画像为营销人员服务。

今天，主要说了两个内容：1. 推荐系统构成元素的相对重要性，搞清楚重点，才能快速前进；2. 建立起目标思维和不确定性思维，抓住目标，不择手段地增长目标，不纠结一城一池的得失。

今天，从两个角度总结了推荐系统中的常见问题。第一个角度是模型的角度，将推荐系统的模型分成了预测评分和预测行为，这样一来，自己有什么数据就选择什么样的模型。另一个角度是看看推荐系统中一些永恒存在但是潜在的问题，包括冷启动、EE 问题、安全问题。

到底什么是推荐系统？按照维基百科的定义：它是一种信息过滤系统，手段是预测用户（User）对物品（Item）的评分和偏好。这个定义不是很好理解，也不恰当。它用“怎么做”来定义了“是什么”，这相当于变相规定了推荐系统的实现路径。让我们来换一个角度回答三个问题，从而重新定义什么是推荐系统：1. 它能做什么；2. 它需要什么；3. 它怎么做。对于第一个问题“它能做什么”，我的回答是：推荐系统可以把那些最终会在用户（User）和物品（Item）之间产生的连接提前找出来。