32.【效果保证】推荐系统的测试方法及常用指标介绍
为什么要关注指标
面对推荐系统这样一个有诸多复杂因素联动起作用的系统，要时时刻刻知道它好不好，健不健康，你同样需要掌握一些测试方法和检测指标。
推荐系统的测试方法
需要有不确定性思维，但是这绝不是帮你在老板那里开脱的说辞。推荐系统也需要测试，只是它不同于传统的功能测试。传统软件的功能测试，功能的响应是有预期的，点击一个加关注按钮，应该有什么响应，是被产品文档明确规定的；也因此在开发功能的时候，可以同步写出测试用例来。
这非常明白，在功能开发时，你做了任何改动，只要跑一下测试用例，逻辑对不对就一目了然了。反观推荐系统就没那么容易了，你什么都没动，可能两次推荐的结果都有可能不一样，而且很可能这个不一样也是你自己或者你老板要求的。
那么推荐系统要怎么测试呢？与其说推荐系统没有确定性的预期响应，不如说推荐系统的响应维度更高。因为确定性的功能响应像是一个点，而推荐系统的响应则是高维空间中的一个区域，而不是一个点。那么是不是推荐系统不需要单元测试了呢？显然也不是。
归纳起来，推荐系统的测试方法有四种：业务规则扫描、离线模拟测试、在线对比测试、用户访谈。
1. 业务规则扫描
首先，业务规则扫描本质上就是传统软件的功能测试。确定的业务规则会对应有确定的规则，这些规则就可以翻译成单元测试，像是运行单元测试那样，对推荐系统逐一扫描业务规则。
通常这些业务规则对测试的要求也有“软的”和“硬的”两种。前者会对业务规则违反情况做一个基线规定，比如触发几率小于万分之一，在扫描测试时统计触发次数，只要统计触发几率不超过基线，就算是合格。而硬的规则，就是一票否决，例如一些业务黑名单，简直就是高压线，测试时碰不得，碰了就是 Bug，就要想办法修正。
除了业务规则，还有一些容易被人忽视的地方，比如绝大多数推荐模型都涉及了数学计算，而数学计算中也有一些潜在的规则不能违反。比如除数不能为0，比如计算机的浮点数精度有限，经过一些指数运算后可能就出现预期之外的结果，还可能一些连续相乘的计算要防止出现0的乘数，类似这些在计算中的潜在业务规则，也需要扫描测试。
2. 离线模拟测试
其次，就是在离线模拟测试。这是一种军事演习式的测试。模拟测试当然无法代替真实数据，但是也能暴露一些问题。通常做法是先收集业务数据，也就是根据业务场景特点，构造用户访问推荐接口的参数。这些参数要尽量还原当时场景，然后拿这些参数数据去实时访问推荐推荐，产生推荐结果日志，收集这些结果日志并计算评测指标，就是离线模拟测试。
显然，离线模拟测试是失真的测试，并且评测指标也有限，因为并不能得到用户真实及时的反馈。但是仍然有参考意义。这些模拟得到的日志可以统称为曝光日志，它可以评测一些非效果类指标，例如推荐覆盖率，推荐失效率，推荐多样性等。
那是不是离线模拟测试就对效果一无所知、无法模拟呢？也并不是，有一种办法是，利用历史真实日志构造用户访问参数，得到带评测接口的结果日志后，结合对应的真实反馈，可以定性评测效果对比。
比如，可以评测推荐结果的 TopK 的准确率，或者排序效果 AUC。这些模型效果类指标，虽然不能代表终关注的商业指标，但是两者之间一般存在一定的相关性。通常来说 TopK 准确率高，或者 AUC 高于 0.5 越多，对应的商业指标就会越好，这是一个基本假设。通过离线模拟评测每一天的模型效果指标，同时计算当天真实的商业指标，可以绘制出两者之间的散点图，从而回归出一个简单的模型，用离线模型效果预估上线后真实商业指标。
3. 在线对比测试
第三种测试方法就是真正的实战了，那就是 ABTest，即在线对比测试，分流量做真实的评测。这需要一个支持流量正交切分的 ABTest 框架，在前面的文中已经讲到过。ABTest 在样本充分的前提下，基本上可以定性新的推荐系统是否比老的推荐系统更加优秀。
4. 用户访谈
后一种测试方法就是用户访谈，或者说用户调查。前面三种测试方法，背后的思想是数据驱动。然而正如我在本文开篇时所说，数据测量的是系统外在表现，并不反映系统原理，而且数据指标是人设计的，是存在主观性和片面性的，人的认知广度和深度各有不同。
因此，除了要紧紧团结在“数据驱动”这个核心思想周围，还需要深入用户，对用户做直接的交流，对用户访谈，更重要的意义不是评测推荐系统，而是评测推荐系统的指标，设计是否合理，是否其高低反映了你预先的设定。
除此之外，通过前面三种测试方法如果得知系统表现不好，那么结合直接真实的用户调查和访谈，可以为系统优化找到真实原因。这种方法类比一下就是：维修下水道时，你需要钻进下水道。
常用指标
推荐系统有很多指标。你之前如果阅读过一些介绍推荐系统指标的文献或书籍，想必会对繁多的指标望而却步，总之就是各种率。实际上所有指标就是在回答两个问题：系统有多好，还能好多久？这两个问题恰恰就是推荐系统里面一个老大难问题的反映：探索利用问题。
系统有多好？这就是想问问：对数据利用得彻底吗？还能好多久？这个问题就是想问问：能探索出用户新的兴趣吗？这样就能继续开采利用了。也好比在职场中看一个人，除了看他现在的经验和解决问题能力有多强，还要看他学习能力有多强，毕竟世界是变化的，朝阳也会变成夕阳。
下面分别说说这两类指标有哪些。
1. 系统有多好？
检测系统到底有多好，其实，也有两类，一类是深度类，一类是广度类。
把数据看做是一座矿山，推荐系统是一个开采这座矿山的器械，“系统有多好”这个问题就是在关心开采得好不好，所以其实就看现有矿山上开采得深不深，开采得到不到位。广度类指标就是指在矿山上打满了钻井，而不仅仅盯着一处打钻井。
深度类指标，就是看推荐系统在它的本职工作上做得如何。还记得推荐系统的本职工作是什么吗？就是预测用户和物品之间的连接，预测的方法又有评分预测和行为预测。因此深度类指标就指在检测系统在这两个工作上是否做得到位，有针对离线模型的指标，也有在线的指标，下面分别说一说。
- 评分准确度。通常就是均方根误差 RMSE，或者其他误差类指标，反映预测评分效果的好坏。在讲协同过滤时已经详细说过这个指标。这里不再赘述。
- 排序。检测推荐系统排序能力非常重要，因为把用户偏爱的物品放在前面是推荐系统的天职。
由于推荐系统输出结果是非常个人化的，除了用户本人，其他人都很难替他回答哪个好哪个不好，所以通常评价推荐系统排序效果很少采用搜索引擎排序指标，例如 MAP，MRR，NDCG。搜索引擎评价搜索结果和查询相关性，具有很强的客观属性，可以他人代替评价。推荐系统评价排序通常采用 AUC。也在前面介绍 BPR 模型时，专门讲到过。 - 分类准确率。这个指标也是针对行为预测的，而行为预测就是分类问题，所以评价准确度就很自然。
在推荐系统中，评价准确度略微特殊，一般评价 TopK 准确率，与之对应还有 TopK 召回率，这里的 K 和实际推荐系统场景有关，就是实际每次推荐系统需要输出几个结果。
opK 准确度计算方式如下：
如果日志中用户有 A、B 两个物品有正反馈行为，推荐系统推出一个物品列表，长度为 K，这个列表中就有可能包含 A、B 两个物品中的一个或多个，下面这个表格就说明了 TopK 准确率和 TopK 召回率的含义:
| K | 推荐输出 | 包含用户反馈物品数 | TopK准确率 | TopK召回率 |
|---|---|---|---|---|
| 1 | A | 1 | 100% | 100% |
| 2 | A,C | 1 | 50% | 50% |
| 3 | A,C,D | 1 | 33% | 50% |
| 4 | A,C,D,E | 1 | 25% | 50% |
| 4 | A,B,C,D | 1 | 50% | 100% |
这三个指标，比较直观地反映了推荐系统在“预测”这件事上对数据开采的深度，实际上由于模型不同，还可以有不同的指标，也可以自己设计指标，这里不再赘述。但这三个指标也属于比较初期的指标，距离终商业指标还有一定的距离。
通常检测推荐系统的商业指标有：点击率，转化率。其实把用户从打开你的应用或者网站开始，到最终完成一个消费，中间要经历数个步骤，也是大家常说的漏斗转化过程。推荐系统如果在其中某个环节起作用，那么就要衡量那个环节的转化率，这个相比前面三个指标，更加接近真实效果。
除了比例类的商业指标，还要关注绝对量的商业指标，常见的有：社交关系数量，用户停留时长，GMV（成交金额），关注绝对数量，除了因为它才是真正商业目标，还有一个原因，是要看推荐系统是否和别的系统之间存在零和博弈情况。假如推荐系统导流效果提升，搜索引擎导流下降，从整个平台来看，因为整个平台的商业目标并没有那么成绩喜人，也需要警惕。
- 覆盖率
这项指标就是看推荐系统在多少用户身上开采成功了，覆盖率又细分为 UV 覆盖率和 PV 覆盖率。UV 覆盖率计算方法是:
解释一下，首先要定义有效推荐，就是推荐结果列表长度保证在 C 个之上，独立访问的用户去
重就是 UV，有效推荐覆盖的独立去重用户数除以独立用户数就是 UV 覆盖率。PV 覆盖率计算
方法类似，唯一区别就是计算时分子分母不去重:
- 失效率
失效率指标衡量推荐不出结果的情况。也分为 UV 失效率和 PV 失效率。UV 失效率计算方法是：
分子是推荐结果列表长度为 0 覆盖的独立用户数，分母依然是去重后的独立访问用户数。PV 失
效率也一样，区别是不去重:
- 新颖性
对于用户来说，“总是看到你这张老脸”会让他们审美疲劳，所以对用户来说，推荐的物品要有一定的新颖性。直观理解就是用户没见过。所以新颖性需要讲粒度，物品粒度、标签粒度、主题粒度、分类粒度等等。每个粒度上评价用户没见过的物品比例。对于物品级别的新颖性，更多是靠直接过滤保证，前面章节已经专门讲到了对应的过滤算法。
- 更新率
检测推荐结果更新程度。如果推荐列表每天几乎一样，显然不可取，尤其是新闻资讯类，要求每次刷新都不一样，对更新率要求更高。更新率可以有很多衡量方式，有一种是衡量每个推荐周期和上个周期相比，推荐列表中不同物品的比例。这个周期，可以是每次刷新，也可以是每天。
2. 还能好多久？
也就是系统是否健康。在推荐系统中，需要数据不断更新，这样系统才是一个活系统，用户兴趣客观上会变迁，数据源客观上也是会用光的一天，所以推荐系统如果不能应对这两个变化，就好不了太久。
衡量推荐系统是否健康的指标常用的有三个。
- 个性化。
虽然说到推荐系统时，言必称个性化，但实际上能做到真正个性化很难，那要求用户每个人都独立思考、爱好明确、不受群体影响。但是个性化程度的确能够反映推荐系统的健康程度，如前面提到的公式：
如果没有个性化，那么分子上增加的连接数，其实是不受分母上增加的物品数影响的，因为所有人都只消费那少数几个物品，那么你其实不需要推荐系统。个性化如何检测呢？有一个直观的方法，取一天的日志，计算用户推荐列表的平均相似度，如果
用户量较大，对用户抽样。
- 基尼系数。
基尼系数衡量推荐系统的马太效应，反向衡量推荐的个性化程度。把物品按照累计推荐次数排序，排在位置 i 的物品，其推荐次数占总次数为$p_i$ 。那么基尼系数为：
看这个公式可以知道，如果推荐次数越不平均，那么基尼系数就越趋近于 1。
- 多样性
多样性不但要在推荐服务吐出结果时需要做一定的保证，也要通过日志做监测。多样性可能会损失一些效果指标，但是从长远上来看，对推荐系统所在平台是有利的。多样的推荐结果也会让产品显得生机勃勃，提升品牌形象。多样性衡量方式通常要依赖维度体系选择，例如常见的是在类别维度上衡量推荐结果的多样性。方法是下面这样的:
多样性衡量实际上在衡量各个类别在推荐时的熵，一共有 n 个类别，分母是各个类别最均匀，都得到一样的推荐次数情况下对应的熵。分子则是实际各个类别得到的推荐次数， 是类别 i 被推荐次数占总推荐次数的比例，计算它的熵。两者求比值是为了在类别数增加和减少时，可以互相比较。
这种计算多样性是一个整体的评价，还可以具体评价每次推荐的多样性，每个用户的多样性，也就是 PV 多样性和 UV 多样性。
33.【效果保证】道高一尺魔高一丈：推荐系统的攻防
推荐系统是某一方流量诸侯的运转规则，那么就不能不考虑到在其诸侯封地之内会有刁民闹事、钻营规则的漏洞，从而达到自己的目的。
攻和防
用行话说，就是推荐系统也会受到攻击，推荐系统也是一种软件，只要是软件，就一定有安全问题，推荐系统也不能免俗。如果推荐系统非常脆弱，容易受到攻击，那么推荐系统就不是为平台利益而运转，而是为攻击者利益而运转，推荐系统不过是个傀儡，前面讲到的那么多酷炫的算法也就成了摆设。
让前面讲到的所有算法、架构起到它该起的作用；让那些指标数据反映真实的效果，这两件事都很重要。推荐系统如果被攻击也就需要被防护。
攻击
知己知彼，百战不殆。要更好地守护你的推荐系统，就需要先了解别人会怎么攻击你的推荐系统。在推荐系统攻防研究领域，被研究得最为彻底的就是针对协同过滤的攻防。
因为一方面是协同过滤本身就应用广泛，另一方面是针对协同过滤的攻击容易生效。
为什么呢？一方面是协同过滤本身就应用广泛，另一方面是针对协同过滤的攻击容易生效。
我们先概略认识一下推荐系统的攻击是怎么回事，然后再认识一下攻击怎么做。有人对身为流量控制器的推荐系统攻击，并不是他吃饱了没事做，来帮你测试系统，根据“无利不起早”这条社会公理，攻击方一定是想扶持或者打压某些物品，从而获得他想要的个人利益。攻击方要扶持一个物品，就想要推荐算法在计算他的评分时给出高分，想要打压一个物品，就要反之行事。不论目的是扶持还是打压，都需要先达到操纵选民的目的，你知道的，协同过滤，无论是基于物品还是基于用户，都是群体智慧，也就是说需要有投票过程。
所以攻击协同过滤，核心问题在于如何操纵选民。选民有两种，一种是用户，一种是物品，前者是基于用户的协同过滤所需要的，后者是基于物品的协同过滤所需要的。现在，从一个简单例子开始来思考，如何攻击基于用户的协同过滤算法。
我们先回顾一下它的原理，首先计算出用户之间的相似度，在给一个用户计算推荐结果时，让相似的用户集体决策，其背后的思想也很直接：人以群分，与你口味相似的人给你推荐的结果你会喜欢。
那么攻击任务就是，要让自己扶持的物品在推荐算法决定是否要推荐给一个用户时，得到高分。方法就是操纵选民，这里的选民就是和被欺骗用户相似的用户，被欺骗用户肯定是吃瓜群众，也是攻击方的利益攫取，所以不会成为被操纵的选民。通常的手段就是，批量制造假用户资料，并装作是与被欺骗用户兴趣相投的人。这叫做托攻击或者 Shilling Attacks，托也就是水军，名字很形象有没有？具体怎么制造这批选民呢？
首先，攻击者会注册一批用户，这部分用户就是攻击者可以操纵的选民，然后让这批用户去做出和被欺骗用户一样的历史评分行为。被欺骗的用户打高分的物品，这批水军也打高分，这样一来就可以在计算用户相似度时，这一批新注册的用户都和那个用户有较高的相似度，从而就变成了参与推荐算法计算时的选民，也就可以给扶持的物品打高分或者给打压的物品打低分。
只不过，针对一个吃瓜群众做这些事情显然是一个不划算的事情，所以攻击者会先找到目标用户群体，针对目标用户群体来做这些事，这样一来就可以把扶持的物品推荐给这个群体，让打压的物品从这个群体面前消失。攻击者在伪造用户兴趣时，除了要做出和被欺骗用户相似的历史行为之外，还要做出掩人耳目的行为，以防止被平台发现，所以还会给一些无关的物品打分。至此，一个简单的攻击过程完成了。
总结一下，攻击手段包含这些元素。
- 目标物品，就是攻击方要扶持或者打压的那个物品。
- 助攻物品，就是用来构造假的相似用户所需要的物品。
- 陪跑物品，就是用来掩饰造假的物品。
三类物品构成一个靶子，靶心是攻击者要拿下的，层层包围，示意如下。
其中，根据对最外环物品的评分构造方法不同，可以把攻击分为两种：
- 随机攻击。
随机攻击就是在上面示意图中，构造最外环“陪跑物品”评分时，采用随机打分方式生成。随机打分就是用全局平均分构造一个正态分布，给无关物品打分时，用这个正态分布产生一个随机分值。- 平均分攻击。
平均分攻击也是用在最外环物品中，给他们打每个物品的平均分。需要先统计出被打分物品的平均分，然后攻击方给这个物品也打上平均分。
前面举例的这种攻击手段，需要先找到一批被欺骗用户，然后逐一为它们构造相似用户，最后才能如愿地实现扶持或打压目标物品。于是就有更为狡猾的攻击办法，这里举两种，一种是热门攻击，还有一种是分段攻击。
热门攻击就是攻击者会想办法让目标物品和热门物品扯上关系。这样做有事半功倍的效果，热门物品有个特点是：评分用户多。如果和它扯上关系，那就找到了一个数量较大的群体，攻击的影响也会巨大。和热门物品扯上关系最常用的就是，使用假用户同时给热门物品和目标物品评上高分，这是针对扶持目标物品的做法，如果要打压，则给热门评高分，给目标物品最低分，陪跑物品就采用随机评分的方式。
热门攻击，若干年前在某电商网站真实发生过，攻击者想让自己的图书得到更多推荐，于是大量同时购买畅销书以及那本想得到推荐的图书，最后在畅销书页面的相关推荐中就推出了那本书，攻击者目的达成。
热门攻击有两个“优势”。
- 如果是扶持目标物品，则经过热门攻击后，基于物品的协同过滤算法会把目标物品计算为热门物品的相似物品，上述实际案例就是如此；
- 基于用户的协同过滤算法，也会把消费过多个热门物品的用户计算为假用户的相似用户，从而为这些用户推荐出目标物品。
热门攻击有时候并不是攻击者有意发起的，而是一种群体现象，例如粉丝出征，消费者集体维权，都可能产生出热门攻击的效果。
分段攻击就是想办法把目标物品引入到某个群体中，做法就是攻击者先圈定好用户群体，再列出这个群体肯定喜欢的物品集合，然后同时用假用户给目标物品和这批物品集合评分，做法类似热门攻击。
最后的攻击效果就是：如果扶持目标物品，那么这个被圈定的用户群体会看见，如果打压，那么目标物品就会在这群人面前消失。
防护
上述这些攻击手段，核心都是操纵选民，手段是构造假用户兴趣，因此你自然会想到，防护的手段核心就是识别出被操纵的选民，这是当然的，但是并不仅仅如此，防护手段按照层级，可以分为下面几种。
平台级。
这一层属于在推荐系统之外的防护手段，一面是提高批量注册用户的成本，从攻击者的第一步遏制，比如弹验证码，另一方面是产品教育用户积极参与，并提供真实的反馈，让推荐系统所用的数据真实性比例越高，越不容易被攻击，这是最根本的。数据级。
数据级别防护重点是从数据中识别出哪些数据是假的，哪些用户是被操纵的选民，一旦识别出来就将这些数据删除。做法通常是采用机器学习思路，标注一批假用户或假反馈数据，训练分类器，在线上识别出反馈，将其延后或者排除在推荐计算之外，通常要和反垃圾系统紧密结合。或者对用户数据聚类，假用户产生的数据一定有着和正常用户不一样的分布，因为它目标明确，所以无监督的办法可以 找出假用户群体来，一旦确认可以删除整个群体，可以采用的有主成分分析等做法。算法级。
算法级别就是在推荐算法设计时，要根据情况做一些改进和选择。一般来说基于用户的协同过滤更容易受到攻击，因此需要对基于用户的协同过滤做改进。
改进方向包括下面几种：
引入用户质量，限制对于低质量的用户参与计算，或者限制新用户参与计算；
限制每个用户的投票权重，即在计算用户相似度时引入较重的平滑因子，使得用户之间的相似度不容易出现过高的值，也就是变相使得投票时参与用户更多一些，提高攻击者的成本。
除此之外，采用多种推荐算法最后再走模型融合之路也是一种提高推荐系统健壮性的有效做法。
将上述三个层级的防护表示如下图更清楚些，核心要保护推荐结果符合平台方的利益:
34.【开源工具】和推荐系统有关的开源工具及框架介绍
轮子不要重复造
但是事实上你没必要这样做也不应该这样做。大厂研发力量雄厚，业务场景复杂，数据量大，自己从挖地基开始研发自己的推荐系统则是非常常见的，然而中小厂职工们则要避免重复造轮子。
这是因为下面的原因。
- 中小企业，或者刚刚起步的推荐系统，要达成的效果往往是基准线，通用的和开源的已经能够满足；
- 开源的轮子有社区贡献，经过若干年的检验后，大概率上已经好于你自己从零开始写一个同样功能的轮子；
- 对于没有那么多研发力量的厂来说，时间还是第一位的，先做出来，这是第一要义。
既然要避免重复造轮子，就要知道有哪些轮子。有别于介绍一个笼统而大全的“推荐系统”轮子，我更倾向于把粒度和焦点再缩小一下，介于最底层的编程语言 API 和大而全的”推荐系统”之间.选择开源项目时要优先选择自己熟悉的编程语言、还要选有大公司背书的，毕竟基础技术过硬且容易形成社区、除此之外要考虑在实际项目中成功实施过的公司、最后还要有活跃的社区氛围。
内容分析
基于内容的推荐，主要工作集中在处理文本，或者把数据视为文本去处理。文本分析相关的工作就是将非结构化的文本转换为结构化。
主要的工作就是三类。
- 主题模型；
- 词嵌入；
- 文本分类。
以做这三类工作的开源工具有下面的几种:
| 开源项目名 | 用途 | 接口语言 | 单机/分布式 | 支持方 |
|---|---|---|---|---|
| LightLDA | 主题模型 | C++ | 分布式 | Microsoft |
| gensim | 主题模型，词嵌入 | Python | 单机多线程 | adimrehurek.com |
| plda | 主题模型 | C++ | 单机多线程/分布式 | |
| DMWE | 词嵌入 | C++ | 分布式 | Microsoft |
| tensorflow-word2vec | 词嵌入 | Python | 分布式或单机 | |
| FastText | 词嵌入 | C++/Python | 单机多线程 | |
| liblinear | 文本分类 | C++,Java,Python | 单机 | 台湾大学 |
这其中 FastText 的词嵌入和 Word2vec 的词嵌入是一样的，但 FastText 还提供分类功能，这个分类非常有优势，效果几乎等同于 CNN，但效率却和线性模型一样，在实际项目中久经考验。LightLDA 和 DMWE 都是微软开源的机器学习工具包。
协同过滤和矩阵分解
基于用户、基于物品的协同过滤，矩阵分解，都依赖对用户物品关系矩阵的利用，这里面常常要涉及的工作有下面几种：
- KNN 相似度计算；
- SVD 矩阵分解；
- SVD++ 矩阵分解；
- ALS 矩阵分解；
- BPR 矩阵分解；
- 低维稠密向量近邻搜索。
可以做这些工作的开源工具有下面几种:
| 开源项目名 | 用途 | 接口语言 | 单机/分布式 | 支持方 |
|---|---|---|---|---|
| kgraph | KNN相似度计算和搜索 | C++,Python | 单机/多线程 | aaalgo(Wei Dong) |
| annoy | 稠密低维向量的KNN相似搜索 | C++,Python | 单机多线程 | Spotify |
| faiss | 稠密低维向量的KNN相似搜索，聚类 | C++,Python | 单机多线程，支持GPU加速 | |
| nmslib | 稠密低维向量的KNN相似搜索 | C++,Python | 单机 | nmslib |
| Spark.RowMatrix.columnSimilarities | 基于用户/基于物品协同过滤 | Scala,Java,Python | 单机多线程，分布式 | |
| lightfm | SVD矩阵分解,SVD++矩阵分解，BPR矩阵分解 | Python | 单机多线程 | lyst |
| implicit | 基于用户/物品的协同过滤，ALS矩阵分解，BPR矩阵分解 | Python | 单机多线程，支持GPU加速 | benfraderickson.com |
| QMF | 加权矩阵分解，BPR矩阵分解 | C++,Python | 单机多线程 | Quora |
这里面的工作通常是这样：基础协同过滤算法，通过计算矩阵的行相似和列相似得到推荐结果。矩阵分解，得到用户和物品的隐因子向量，是低维稠密向量，进一步以用户的低维稠密向量在物品的向量中搜索得到近邻结果，作为推荐结果，因此需要专门针对低维稠密向量的近邻搜索。同样，除非数据量达到一定程度，比如过亿用户以上，否则你要慎重选择分布式版本，非常不划算。
模型融合
模型融合这部分，有线性模型、梯度提升树模型。
| 开源项目名 | 用途 | 接口语言 | 单机/分布式 | 支持方 |
|---|---|---|---|---|
| LightGBM | GBDT等树模型 | C++ | 分布式 | Microsoft |
| XGBoost | GBDT等树模型 | C++,Python,R | 单机多线程，分布式 | Distributed (Deep) Machine Learning Community |
| Tensoeflow_wide and deep | Wide&Deep模型 | Python | 单机多线程，分布式 | |
| LibFFM | 因子分解机，厂敏感的因子分解机 | C++,Python | 单机 | 台湾大学 |
| vowpal_wabbit | 线性模型 | C++,Python,Java,C#等 | 单机多线程 | Microsoft |
线性模型复杂在模型训练部分，这部分可以离线批量进行，而线上预测部分则比较简单，可以用开源的接口，也可以自己实现。
其他工具
Bandit 算法比较简单，自己实现不难，这里不再单独列举。至于深度学习部分，则主要基于 TensorFlow 完成。存储、接口相关开源项目和其他互联网服务开发一样，也在对应章节文章列出，这里不再单独列出了。
完整推荐系统
这里也梳理一下有哪些完整的推荐系统开源项目，可以作为学习和借鉴。所谓完整的推荐系统是指：包含推荐算法实现、存储、接口。
|开源项目名| 说明 | 开发语言 |
| ：—-： | ：—-： | ：—-：|
| PredictionIO | 基于Spark(算法)、HBase(存储)、Spray(接口)开发 | Scala |
| recommendationRaccoon | 以协同过滤为核心算法的推荐系统，Redis作为存储 | Node.js |
| easyrec | 存储采用MySQL，接口基于Tomcat | Java |
| hapiger | 存储采用PostgreSQL，接口采用Hapi.js框架 | Node.js |
总结
你可能注意到了，这里的推荐系统算法部分以 Python 和 C++ 为主，甚至一些 Python 项目，底层也都是用 C++ 开发而成。因此在算法领域，以 Python 和 C++ 作为开发语言会有比较宽泛的选择范围。
倾向于选择各个模块的开源项目，再将其组合集成为自己的推荐系统。这样做的好处是有下面几种。
- 单个模块开源项目容易入手，学习成本低，性能好；
- 自己组合后更容易诊断问题，不需要的不用开发；
- 单个模块的性能和效果更有保证。
