推荐系统三十六式--读书笔记（35-38 产品-团队-参考阅读）

35.【产品篇】推荐系统在互联网产品商业链条中的地位

在商业世界里，就应该带一点“功利”的眼光看待推荐系统，但功利地看待推荐系统之前，要认识到推荐系统在商业链条中到底是个什么样的角色和作用。

36.【产品篇】说说信息流的前世今生

信息流，就是 Feed，包括社交动态信息流，也有图文资讯信息流，短视频信息流。

推荐系统是一种注意力存储器，注意力是信息经济时代的稀缺商品，广告商向平台方购买注意力，平台方把存储的注意力分一点给广告商，然后通过推荐系统收集更多注意力补充回来。在今天，最厉害的注意力存储器就是信息流，尤其是个性化信息流，也叫做兴趣 Feed，这也是推荐系统的一种。

前世今生

说信息流，就不得不提到 NewsFeed。2004 年，Facebook 问世，2006 年，信息流鼻祖 NewsFeed 横空出世，经过十多年，NewsFeed 已经是日收入几千万美金的现金大牛。

在 NewsFeed 上线前，经历过两个抗议阶段:

第一个是把新鲜事公布出来，原先的新鲜事被大家认为是隐私，在时间线中呈现出来被好友看见不妥，而事实是，每个人在意的除了自己的隐私被公布，更在意的是朋友的八卦，数据表明新鲜事被公布后，用户活跃度大幅上涨。
第二个就是 NewsFeed 上线，用户广泛抗议，原来按照时间先后顺序阅读新鲜事，现在却按照重要程度阅读，非常不习惯，然而数据表明，用户互动行为再一次大幅度提高。

这些年来，NewsFeed 有数不清的改进，甚至每天线上会同时部署很多算法版本进行 AB 测试。后来的故事大家都知道了，Facebook 上市，股价逐年上涨。

NewsFeed 的成功，验证了几个常识：

数据驱动比舆论驱动靠谱，别听人们嘴上是怎么说的，只看人们是如何行动的；

窥探隐私，向群体靠拢，害怕孤单是普遍人性，把新鲜事公开这件事验证了这一点；

注意力非常有限，用推荐系统的方法更好地储存注意力，基于兴趣的信息流验证了这一点。

后来，Twitter，微博，Instagram，老牌的时间线信息流方式如今都换成了按照兴趣筛选内容，原因都是信息泛滥，用户错过的信息量越来越多，注意力耗散很多，无法将耗散的注意力变现成了这些平台最大的痛。

配套设施

信息流是一个低衰减的注意力存储器，但是光有信息流是不完整的，最大的问题可能有两个：

内容源不足，无法形成信息过载，注意力就不会稀缺，注意力是无法待价而沽的商品；

在注意力变成稀缺的事物后，存储的注意力无法变现，反哺平台自身。

针对这两个问题，完整的信息流产品还需要配套设施。以 NewsFeed 为例，讲讲信息流的配套设施。

1. 内容源

内容源是注意力的重要间接影响因素。“内容哪里来”是信息流要不断思考的问题，对于 NewsFeed 来说，就是社交关系上的人发布新鲜事。NewsFeed 存在的前提是要依赖用户建立大量的社交联系，这样才会出现信息过载，因此 NewsFeed 的一个重要的配套设施就是“你可能感兴趣的人”推荐系统。这是一个我们在产品形式上比较熟悉的推荐系统，它是一套大规模矩阵分解算法，在前面的专栏已经专门讲过，这套推荐系统希望用户和用户，用户和 App、公共主页等都建立起大量的连接。

建立起连接，相当于变相地增加了内容源，这些用户发布的新鲜事，App 产生的内容，公共主页发布的帖子，都会通过这些连接流进用户的个人信息流。社交信息流中，内容源依赖于社交关系的数量。而图文资讯信息流，则更多依赖爬虫技术，“不生产内容，只是内容的搬运工”。依赖爬虫的信息流内容源，质量非常不可控，会有涉黄、涉政、涉暴力等敏感内容，甄别工作量非常巨大，而且一旦控制不好就是社会事件，代价惨重

内容源是信息流的一种重要基础设施，要想尽办法建设好。内容源应该考虑下面几种。

质量：虽然群体喜欢消费低质量的内容，便宜商品，但是一旦出现敏感内容，不合格的商品等，代价还是很高昂。

多样性：信息只有多样了才有信息量，有了多样性才能满足更多的用户，才能在存储海量注意力时不衰减。

数量：数量自不必说，推荐系统解决信息过载问题，没有信息过载问题怎么办呢？就是先制造信息过载问题，要制造信息过载，信息的数量就要有保障。

2. 广告系统

NewsFeed 还有另一个配套设施，也是它为什么每天能吸金几千万刀的原因：那就是广告系统。Facebook 的广告形态多样。

Suggested Page (你可能喜欢的公众页)

Page Post (公众号帖子推广)

Suggested App (你可能喜欢的应用)

Video Ads (视频广告)

广告主花钱购买信息流存储的注意力，俗称信息流变现。实际上就是信息流产品供应注意力，广告主消费注意力。注意这枚硬币的另一面：广告主供应的什么，用户是否消费了，则是另外一套看待角度。

以前，Facebook 鼓励商业机构花钱投广告增加粉丝，彼时的 NewsFeed 算法允许随意发广告，看上去就是公共主页发布了新鲜事。这一阶段对应着增加用户和内容源之间的连接阶段，是一个非常必要的步骤。看上去广告主增加了自己的粉丝，用户增加了内容源，而本质上则是让注意力买主先看到他种草的商品，这个阶段只让广告主每天摸摸自己种草的商品，并不是真的给他。

直到后来，平台方开始严格限制商业广告与普通用户触达，不只是 Facebook，任何的信息流平台，在广告主吸引了足够粉丝之后，都会果断限制广告无节制地触达用户。种草的商品突然提价，广告主就只能剁手买买买，这就是广告系统了。

跟据某个专门做 NewsFeed 推广的公司追踪结果，1000 个公共主页的 50000 条内容以原生方式触达用户的比例，从 2012 年 16% 降低到了 2014 年的 6.51%，降了一倍还多。当然也可能是因为用户平均关注的公共主页增多了，而本质上的原因就是，注意力市场开市了。

在注意力这边，存储注意力要做的事就是基于兴趣筛选信息流，重新排序展示，这样的好处就是用户不会错过自己感兴趣的，而本质上就是留住注意力，不要衰减。在注意力购买方这边，通过广告系统，大家去购买自己看中的注意力。信息流，看上去就是这么一个简单的商业逻辑。广告主这边一开始和信息流平台方有非常甜蜜的日子，直到要花钱购买自己帮忙存储的注意力时，就会有怨言了。

曾经就有广告主对 Facebook 抗议道：那你干脆不要干涉 NewsFeed 排序啊，按时间线自然展示，用户错过就错过，大家都公平。对此 Facebook 的解释则是：数据显示，重排序后的 NewsFeed 可以让用户阅读积极性提高很多。这句话的意思是：这样做才能存储注意力啊。

关于到底要不要重排序的争吵，我们要看清楚，双方都是商业机构：一边是要消费注意力，一边在销售注意力。
这本身就是买卖嘛，不要谈什么情怀，商业社会永远是逐利的，逐利的手段就是制造信息不对称，并且在制造过程中不断提高效率和降低成本。显然，“大家一起穷，完全拼人品”的时间线，不符合基本商业逻辑，信息流才符合商业逻辑。世界上最遥远的距离就是：手握大把粉丝，却不能随心所欲地曝光自己的产品。

具体信息流会怎么发展，我们无法预测，但是可以肯定的有三点：

信息流是推荐系统在商业上最成功的应用；

完全依赖数据驱动的信息流会面临黑天鹅事件，所以人和算法协同进化的信息流会是最有生命力的；

数量上，注意力已被大厂囤在自己了手中，那么下一步要关注的是注意力的质量，这是信息流平台方的商品，毕竟广告主购买了注意力后，发现是地摊货，生意也不会长久的。

37.【团队篇】组建推荐团队及工程师的学习路径

团队组建

我们先定义团队的角色，这里既然是组建“有下限团队”，当然按照能省则省的原则。

算法工程师，承担的是数据科学家和机器学习工程师的双重职责，主要职责是清洗数据，训练离线推荐模型，开发算法接口，评估指标。

软件开发工程师，承担算法之外的开发任务，例如数据库的搭建维护，API 接口的开发，日志的收集，在线系统的高可用等，当然“有下限的团队”可以适当简陋些，不用考虑高性能。

其他非技术角色，如果是“有下限团队”的话，这一项也可以省略，如果涉及了跨部门合作，或者你不幸被老板提出各种“推得不准”的伪 Bug，那么你就需要一个这样的角色去充当工程师港湾，来阻挡外界的风雨。

关于算法工程师，最低配需要 2 位，一位三年左右经验的算法工程师负责数据分析，数据清洗，推荐模型训练，评估和上线，外带一位三年以下经验的初级工程师，从中辅助分担琐碎工作。

为什么说有经验的算法工程师一位就够了，假如你使用矩阵分解作为推荐系统第一版核心算法，那么推荐使用 Quora 开源的 QMF 工具。它能在一台 32 核、244G、640G 固态硬盘的服务器上用 20 分钟完成 10 亿非零元素，千万用户和物品的矩阵分解。工具简单易用，一个有经验的工程师足够让其运转起来。

那么核心问题就是，一台机器是不是撑得起你老板的野心？我认为，撑得起，具体的估算如下。根据前文中对注意力的定义：内容消耗的加速度乘以内容的消耗难度。当注意力为正数时，是上马推荐系统的好时机。因为这说明平台方已经有了注意力的原始积累，只需要加上推荐系统将它保存下来并加以扩大即可。那么组建的这个“有下限团队”最低要求就是能留住当前的注意力。

注意力为正时，每天的用户消耗内容数量应该是指数级别，比如$f(a,t)=t^a(a>=2)$。其中t是时间，a大于2时才会有正的注意力。因为它的二阶导数为:$a(a-1)t^(a-2)$。

每天的内容消耗量，其实就是用户产生的行为数据条数，至少是正比关系，这里从简考虑，认为
二者等同。假如 a=2，t 的单位是天。那么在 t 天后，累计产生的日志数量是：

$\sum_{i=1}^Ti^2 = \frac{T(T+1)(2T+1)}{6}$

现在看看，如果你公司使用的服务器和 Quora 评测 QMF 时所用服务器一样的配置，用单机运行 QMF，极限是撑多久？我简单列个方程:

$\frac{T(T+1)(2T+1)}{6}=6000000000$

方程右边就是 QMF 评测时处理的 60 亿非零元素。解这个一元三次方程，得到唯一的实数解是
1441.75 天，也就是 3.9 年。那么为什么明明一位算法工程师就可以，还要外带一位，这主要是考虑，团队人才应该有梯度和备份。

关于软件开发工程师，至少需要四位，是的，要证明的是需要两位，还有两位是为了人才梯度和冗余备份。分工是这样的。

推荐服务输出，一位三年及以上经验的后端开发工程师，外带一位三年以下的初级工程师。负责调用推荐 RPC 服务，开发必要的过滤逻辑，填充详细字段等；

反馈数据收集和管理，一位三年以上经验的运维工程师，外带一位三年以下的初级工程师，负责回收用户反馈数据，统一存储日志数据。

以上就是一个最低配推荐系统团队的配置。当然，如果能复用现有团队的部门工程师，则灵活处理。上面的估算也只是一个示例。

个人成长

下面来说说，工程师个人该如何学习和成长的问题。
推荐系统工程师和一般意义的软件工程师相比，看上去无需像 IOS 或者 Android 工程师写大量的代码；也无需像研究院的研究员那样，非得憋出漂亮的数学模型才能工作；更无需像数据分析师绘制出漂亮的图表。那推荐系统工程师的定位是什么呢？
实际上，这里说的几个“看上去无需”，并不是降低了推荐系统工程师的要求，而是提高了要求。因为你得具备三个核心素质：

有较强的工程能力，能快速交付高效率少 Bug 的算法实现，虽然项目中不一定要写非常大量的代码；

有较强的理论基础，能看懂最新的论文，虽然不一定要原创出漂亮的数学模型；

有很好的可视化思维，能将不直观的数据规律直观地呈现出来，向非工程师解释清楚问题所在，原理所在。

首先，虽然世人目光都聚焦在高大上的推荐算法上，然而算法模块确实是容易标准化的，开源算法实现一般也能满足中小厂的第一版所需，而实现整个推荐系统的路径却不可复制，这个实现路径就是工程。可以说，是工程能力决定了推荐系统的上限。如何提高工程能力，无他，就是反复刻意练习。

但是对于入行不同年限的人来说，提高的办法则各不相同。对于在校生，一个比较好的办法是，将看到的任何算法知识、论文或者图书，都亲手转换成代码，一个简单的算法，从你看懂到你无 Bug 地实现出来，其实还有很远的距离，在实现完成后，去阅读对应的热门开源应用，阅读它的实现方法，对照自己的，总结差距。

对于刚工作的新人，这时候你已经有一定的工程基础，并且没有太多的整块时间，那么就要好好把握工作中的项目实战。避免重复造轮子的前提是知道有轮子，并且知道轮子好在哪，这要求你熟读现有轮子的各种，对它性能、实现方法了如指掌，如此才能在不重复造轮子的基础上安心实施拿来主义，并且可以进一步将轮子按照实际使用的所需问题进行改良。

对于工作一定年限的人，这时候你已经熟知各种轮子极其弊端，也能改进了，那么在业务逐渐增长后，需要考虑将系统中部分模块中所使用的开源加上补丁，整体升级为自研系统。这个开发可以从一些风险不高的模块着手，逐渐锻炼。

上述三个大的阶段，比较粗略。但是核心思想就是：爱动手，爱思考，爱阅读，爱总结。

第二，是理论基础。对于一个从事推荐系统的工程师来说，一定需要有数理基础。高等数学、概率统计、线性代数这些大学基础课一定还在自己心中，没有还给老师。
如果不幸还给老师，你需要重新捡起来，因为整个机器学习都是建立在高等数学基础上的。另外，有一个学科我个人认为很重要，甚至成为人生的指南，那就是信息论。信息论用量化方式确定了什么是信息，很多算法问题也因此可以从通信角度考虑。

第三，是数据可视化思维，在做数据分析和清洗工作时，需要想办法直观地呈现出来，在工具层面，掌握一些常用的绘图工具就很有必要了。Python 中的 Matplotlib，R 语言中的 ggplot2，Linux 命令里面的 Gnuplot，Windows 里的 Excel 等等都是非常常用的绘图工具。

掌握工具并不难，还需要有 show 的冲动，直观方式呈现出数据规律不但对自己优化算法和系统有非常大的作用，还可以与合作伙伴快速达成任务共识，节省沟通成本。这三个能力，建立起来的难度逐渐增加，需要持之以恒，与《卖油翁》那句著名的“无他，但手熟尔”，规律相同。

除此之外，还有一些非典型工程师的加分项。

学习能力：虽然缓慢，但是科学一直在突破边界，技术更是日新月异地升级了一代又一代，而文化的进化则远远快于人类基因的进化，这些变化，都要求你我要有不断学习的意识，还要有会学习的能力。

沟通能力：在一些中大型厂，一些数据资源分散在不同部门，在技术之外需要去整合这些资源，这需要沟通能力。

表达能力：能把一件事情讲清楚，最直接的好处是在团队内部减少无效的沟通，提高工作效率。

38.推荐系统的参考阅读

这些资料分成这么几个类型。

论文：以论文形式发表的，期刊数据库中可以下载到。

网络文章：就是在网上自由流传的内容或者博客，为了方便阅读，我将它们保存为 PDF 格式。

演示文稿：就是作者曾公开演讲过的内容，相对来说不是那么严谨，但是更容易理解。

书：推荐系统相关的书较少，我在专栏中参考过的书只有一本（附件中不提供书的电子文档）。

原理篇

1. 内容推荐

题目：Bag of Tricks for Efficient Text Classification
类型：论文作者：Facebook
说明：Facebook 开源的文本处理工具 fastText 背后原理。可以训练词嵌入向量，文本多分类，效率和线性模型一样，效果和深度学习一样，值得拥有。

题目：The Learning Behind Gmail Priority Inbox
类型：论文作者：Google
说明：介绍了一种基于文本和行为给用户建模的思路，是信息流推荐的早期探索，Gmail 智能邮箱背后的原理。

题目：Recommender Systems Handbook(第三章，第九章)
类型：书作者：Francesco Ricci等
说明：这本书收录了推荐系统很多经典论文，话题涵盖非常广，第三章专门讲内容推荐的基本原理，第九章是一个具体的基于内容推荐系统的案例。

题目：文本上的算法
类型：网络文章 (网络免费版，已有成书《文本上的算法: 深入浅出自然语言处理》，内容更丰富) 作者：路彦雄
说明：介绍了文本挖掘中常用的算法，及基础概念。内容涉及概率论，信息论，文本分类，聚类，深度学习，推荐系统等。

题目：LDA 数学八卦
类型：网络文章作者：Rickjin(@靳志辉) 说明：由浅入深地讲解 LDA 原理，对于实际 LDA 工具的使用有非常大的帮助。

2. 近邻推荐

题目：Amazon.com recommendations: item-to-item collaborative filtering
类型：论文作者：Amazon
说明：介绍 Amazon 的推荐系统原理，主要是介绍 Item-Based 协同过滤算法。

题目：Slope One Predictors for Online Rating-Based Collaborative Filtering
类型：论文作者：Daniel Lemire 等
说明：Slope One 算法。

题目：Item-Based Collaborative Filtering Recommendation Algorithms
类型：论文作者：Badrul Sarwar 等
说明：GroupLens 的研究团队对比了不同的 Item-to-Item 的推荐算法。

题目：Collaborative Recommendations Using Item-to-Item Similarity Mappings
类型：专利作者：Amazon
说明：是的，Amazon 申请了 Item-Based 算法的专利，所以如果在美上市企业，小心用这个算法。

题目：Recommender Systems Handbook（第 4 章）
类型：书作者：Francesco Ricci 等
说明：第四章综述性地讲了近邻推荐，也就是基础协同过滤算法。

3. 矩阵分解

题目：Matrix Factorization and Collaborative Filtering
类型：演示文稿作者：Daryl Lim
说明：从 PCA 这种传统的数据降维方法讲起，综述了矩阵分解和协同过滤算法。矩阵分解也是一种降维方法。

题目：Factorization Meets the Neighborhood: a Multifaceted Collaborative Filtering Model
类型：论文作者：Yehuda Koren
说明：把矩阵分解和近邻模型融合在一起。

题目：BPR- Bayesian Personalized Ranking from Implicit Feedback
类型：论文作者：Steffen Rendle 等
说明：更关注推荐结果的排序好坏，而不是评分预测精度，那么 BPR 模型可能是首选，本篇是出处。

题目：Collaborative Filtering for Implicit Feedback Datasets
类型：论文作者：Yifan Hu 等
说明：不同于通常矩阵分解处理的都是评分数据这样的显式反馈，本文介绍一种处理点击等隐式反馈数据的矩阵分解模型。

题目：Matrix Factorization Techniques For Recommender Systems
类型：论文作者：Yehuda Koren 等
说明：本文是大神 Yehuda Koren 对矩阵分解在推荐系统中的应用做的一个普及性介绍，值得一读。

题目：The BellKor Solution to the Netflix Grand Prize
类型：论文作者：Yehuda Koren
说明：也是一篇综述，或者说教程，针对 Netflix Prize 的。

4. 模型融合

题目：Adaptive Bound Optimization for Online Convex Optimization
类型：论文作者：Google
说明：FTRL 是 CTR 预估常用的优化算法，本文介绍 FTRL 算法原理。

题目：在线最优化求解
类型：网络文章作者：冯扬
说明：是对 FTRL 的通俗版解说。

题目：Ad Click Prediction: a View from the Trenches
类型：论文作者：Google
说明：FTRL 工程实现解读。

题目：Factorization Machines
类型：论文作者：Steffen Rendle
说明：提出 FM 模型的论文，FM 用于 CTR 预估。

题目：Field-aware Factorization Machines for CTR Prediction
类型：论文作者：Yuchin Juan
说明：FFM 模型，用于 CTR 预估。

题目：Practical Lessons from Predicting Clicks on Ads at Facebook
类型：论文
说明：提出了 LR + GBDT 的 CTR 预估模型。

题目：Wide & Deep Learning for Recommender Systems
类型：论文作者：Google
说明：提出融合深度和宽度模型的Wide&Deep 模型，用于 CTR 预估。

5.Bandit 算法

题目：Introduction to Bandits- Algorithms and Theory Part 1- Bandits with small sets of actions
类型：演示文稿作者：Jean-Yves Audibert 等
说明：介绍 bandit 算法概念，理论和算法，这部分主要针对小的选项候选集。

题目：Introduction to Bandits- Algorithms and Theory Part 2- Bandits with large sets of actions
类型：演示文稿作者：Jean-Yves Audibert 等
说明：介绍 Bandit 算法概念，理论和算法，这部分主要针对较大的选项候选集。

题目：A Contextual-Bandit Approach to Personalized News Article Recommendation
类型：论文作者：Yahoo
说明：Linucb 的原始论文，考虑上下文的 Bandit 算法。

题目：Collaborative Filtering Bandits
类型：论文作者：Shuai Li 等
说明：Bandit 算法与协同过滤结合，提出 COFIBA 算法。

6. 深度学习

题目：Deep Neural Networks for YouTube Recommendations
类型：论文作者：Google
说明：介绍 YouTube 视频推荐系统在深度神经网络上的尝试。能从中看到 wide&deep 模型的影子。

题目：Efficient Estimation of Word Representations in Vector Space
类型：论文作者：Google
说明：Word2Vec 的作者在这篇文章中提出了一种词嵌入向量学习方法，也就是把开源工具包 Word2Vec 背后的模型详细介绍了一次。理论上很简单，更多是一些工程技巧的分享。 Word2Vec 给推荐系统带来了一种新的隐因子向量学习方法，深陷评分预测泥潭的矩阵分解被开拓了思路。

题目：Item2Vec: Neural Item Embedding for Collaborative Filtering
类型：论文作者：Microsoft
说明：这篇就是借鉴了 word2vec 在语言建模中的思路，为推荐系统的行为建模，从中为物品学习嵌入向量。

题目：Learning Representations of Text using Neural Networks
类型：演示文稿作者：Google
说明：理解为 word2vec 作者写一个教程。

题目：Long Short-Term Memory
类型：论文作者：Sepp Hochreiter 等
说明：可以用来为序列建模的 LSTM，实际上在 1997 年就发表论文了，只是在十几年后才大火。

题目：An Empirical Exploration of Recurrent Network Architectures
类型：论文作者：Google
说明：Google 在 RNN 模型使用上的经验分享。

题目：Recurrent Neural Networks for Collaborative Filtering
类型：网络文章作者：Erik Bernhardsson
说明：这是 Erik Bernhardsson 在 Spotify 期间所做的尝试，用 RNN 自动构建音乐播单。Erik
Bernhardsson 还有一项开源项目 Annoy，用于稠密向量的近邻搜索，在推荐系统中也用得较多。

7. 其他实用算法

题目：Detecting Near-Duplicates for Web Crawling
类型：论文作者：Google
说明：在这篇论文中提出了 simhash 算法，用于大规模网页去重。

题目：Weighted random sampling with a reservoir
类型：论文作者：Pavlos S. Efraimidis
说明：对流式数据的加权采样。

题目：Weighted Sampling Without Replacement from Data Streams
类型：论文作者：Vladimir Braverman 等
说明：介绍了两种对流式数据的加权采样。

工程篇

1. 常见架构

题目：Activity Feeds Architecture
类型：演示文稿作者：Etsy
说明：本文非常详细地介绍了社交动态信息流的架构设计细节。

题目：Atom Activity Streams 1.0
类型：规范文档作者：Activity Streams Working Group
说明：这是一份动态信息流数据模型的协议规范文档，由 Activity Streams Working Group 共同发出，这个组织包含 Google 和 Microsoft。

题目：Beyond the 5 stars（Netflix Recommendations）
类型：网络文章作者：Netflix
说明：Netflix 详细宏观上介绍了自家推荐系统的产品形态，不只是比赛中的评分预测那么简单的。

题目：System Architectures for Personalization and Recommendation
类型：网络文章作者：Netflix
说明：Netflix 推荐系统的架构介绍。

题目：Information Seeking-Convergence of Search, Recommendations and Advertising
类型：论文作者：H Garcia-Molina 等
说明：探讨搜索、推荐、广告三者架构统一。

2. 关键模块

题目：Overlapping Experiment Infrastructure- More, Better, Faster Experimentation
类型：论文作者：Google
说明：ABTest 实验平台的扛鼎之作，Google 出品，值得拥有。

题目：TencentRec：Real-time Stream Recommendation in Practice
类型：论文作者：腾讯
说明：介绍了腾讯内部的实时推荐系统架构。

题目：Personalization at Spotify using Cassandra
类型：网络文章作者：Spotify
说明：介绍了 Spotify 在推荐系统所用到的数据存储中间件。

3. 效果保证

题目：Tutorial on Robustness of Recommender Systems
类型：演示文稿作者：Neil Hurley
说明：本文非常详细讨论了对推荐系统的攻击和防护，并有实验模拟。

题目：Recommender Systems Handbook(第八章)
类型：书作者：Francesco Ricci 等
说明：该书第八章介绍了能见到的几乎所有推荐系统评价指标，只是实际上用不到这么多指标。

其他书目

Pattern Recognization and Machine Learning（机器学习基础，有此一本足够了）。

推荐系统实践（国内唯一一本非翻译的推荐系统书籍，入门必选）。

信号与噪声（介绍贝叶斯统计的一本科普书）。

复杂（推荐系统面对的是复杂网络，了解复杂系统和复杂网络的特点，有助于开脑洞）。

信息简史（既然是信息经济，当然要读一本关于信息的历史）。

$r_i = \bar r + (r_i - \bar r)*min(1,\frac{n_i}{\bar n})$

其中$r_i$是第i个产品的平滑后的评分，$\bar r$是当前产品簇的平均分（这里可用其他统计量，比如分位数，具体看各自项目的效果），$r_i$是第i个产品原始评分，$n_i$是第i个产品的评分人数，$\bar n$是当前产品簇的平均评分人数（这里也可用其他统计量，具体看效果）。