My Secret Rainbow

推荐系统那些事儿

从天猫双11到余弦公式

0.前言：

电商的双十一结束了，天猫今年有了很大的变化。很多人都有这样的感受：“天猫的双十一会场，怎么都是我自己想买的。”在这背后，其实是天猫推荐系统巨大的改变革新，甚至对于其他电商而言，几乎是碾压级别的革新，即使是最为接近的京东。

1. 天猫京东前端对比

首先是简单的架构图，大家可以看一下，天猫和京东相比，架构层面差别不大，区别在于，天猫把秒杀商品单独列出来作为一个tab。

从推荐质量而言，天猫和京东处理得都不错，比如我在天猫主要消费类型为服装，京东主要消费类型为书籍，可以看下效果（天猫主会场首屏&京东我的双十一·为你精选）：

2. 淘宝京东推荐逻辑对比

京东和天猫的组织结构除了常规的店铺和品牌维度，双十一的组织形式主要围绕两个商品组织形式展开：会场，清单。所以主要需要对比的点，也在于会场和清单的组织形式上。

天猫和京东推荐的共性：

• 在会场列表上，实现了个性化推荐
• 在清单列表上，实现了个性化推荐
• 在个性化推荐的单品排序上，实现了个性化推荐

天猫比京东做的超前的地方：

• 会场引导图上，淘宝实现了个性化推荐（你我都看到了男装专场，但是我们男装专场的引导图不同）

 

• 清单引导单品上，淘宝实现了个性化推荐（你我都看到了XXXX必败清单，但是我们每个人的引导单品不同不同）
• 会场内部的组织排序，实现了个性化推荐
• 京东的清单是静态清单，运营手动或者工具生成。但是淘宝的清单是自动聚合生成，根据每个人的情况高度定制。
• 天猫推荐更新时效很快，可感知到每逛一段时间，天猫会根据最新的用户行为，更新双十一会场。

总而言之，从亚马逊“买过了人还买了”协同过滤推荐应用以来，推荐算法在电商的应用达到了一个新的高度。天猫引领的本次革新，会对互联网产品有很深远的影响。这也是在本次文章留出一半篇幅来简单总结天猫和京东双十一的原因。

 

3. 推荐系统的核心是什么

在线下导购时代，导购员会通过比较系统的话术，了解用户的情况，给用户推荐东西。

以化妆品导购为例，导购员需要了解用户的肤质，品牌偏好，消费能力，使用习惯等等信息，然后给出最符合用户的商品推荐。

仔细考虑下导购员的思维逻辑，我们可以做一下还原：了解用户的信息，知道用户的类型。同时导购员了解全部商品的信息，知道什么类型的用户适合什么类型的商品，并进行推荐。这其中最核心的是三点：

• 将用户的信息转化为用户的类型
  
• 了解全部商品应该归属的类型
  
• 了解什么类型的用户，适合什么类型的商品

而这也是推荐系统算法需要思考的三个核心问题。无论是要给用户推荐商品，还是新闻，还是音乐，核心逻辑都是相同的。

4. 从余弦公式讲起

先思考一个问题，我们怎么量化两个事物的相似度呢？当然，这也是推荐系统需要多次面临的问题。

我们知道向量的概念，可以形象化地表示为带箭头的线段。二维空间向量表示方法为 ,多维空间向量表示为  ，向量是描述事物一种很好模型。

比如，假设用户有5个维度

对服装的喜欢程度（1~5分），对家居的喜欢程度（1~5分），对3C的喜欢程度（1~5分），对图书的喜欢程度（1~5分），对化妆品的喜欢程度（1~5分）。

一个用户A：对服装的喜欢程度3，对家居的喜欢程度1，对3C的喜欢程度4，对图书的喜欢程度5，对化妆品的喜欢程度0，用户A可以用向量表示为 

一个用户B：对服装的喜欢程度3，对家居的喜欢程度4，对3C的喜欢程度5，对图书的喜欢程度0，对化妆品的喜欢程度2，用户B可以用向量表示为 

这两个用户的相似程度是多大呢？既然我们把这两个用户表示为向量，那么我们可以考虑向量怎么判断相似性。没错，看这两个向量的夹角。夹角约小，则相似度越大。

对于向量  和  而言，他们的在多维空间的夹角可以用向量余弦公式计算：

余弦相似度的值本身是一个0~1的值，0代表完全正交，1代表完全一致。就刚才用户A和用户B的例子而言，我们可以知道他们的相似度为：

余弦公式本身应用范围很广，量化相似度在搜索推荐，商业策略中都是常见问题，余弦公式是很好的解决方案。就推荐本身而言，计算内容的相似度，计算用户的相似度，计算用户类型的相似度，计算内容类型的相似度，这些都是可以应用的场景。

5. 总结

本期简单总结了双十一天猫京东的活动会场推荐策略的使用。天猫的推荐模式，是非常有想象力的一次革新。同时本期作为推荐系统的开篇，简单介绍了余弦定理，这是一个衡量相似度简单实用的方法。

其实很多看似复杂的问题，实现原理都比较简单，比较容易理解。思考问题，分解问题，构建合理的模型，量化问题，计算和解决问题。这是一个问题从提出到有策略化得解决方案，所要经历的步骤。

双十一天猫告诉我们，推荐系统可以做到的事情有多神奇。将推荐问题量化，余弦定理只是最基础的一步。那么推荐都有哪些类型？余弦定理是怎么被应用在推荐系统中？欢迎关注专栏，阅读下期。

常用推荐策略介绍

0. 前言：

在上一篇文章中，我们简单分析了双十一天猫和京东的推荐策略，同时也介绍了计算相似度的余弦公式。本期我们会介绍下常见的推荐策略，以及这些策略背后的逻辑。

1. 推荐的本质是什么

推荐和搜索本质有相似的地方。搜索满足用户从海量数据中迅速找到自己感兴趣内容的需求，属于用户主动获取。推荐则是系统从海量数据中根据获取到的用户数据，猜测用户感兴趣的内容并推荐给用户，属于系统推荐给用户。本质上都是为了在这个信息过载的时代，帮助用户找到自己感兴趣的东西。

推荐系统有很多种形式。运营或者编辑筛选出自己认为最好的内容放在首页，广义上讲这也是一种推荐。不过这个不在我们本期文章的讨论范围，本期主要是讨论系统级别的推荐。这里主要介绍四类常见的推荐方法。

• 基于内容的推荐
• 基于内容的协同过滤
  
• 基于用户的协同过滤
• 基于标签的推荐

2. 基于内容的推荐

基于内容的推荐是基础的推荐策略。如果你浏览或购买过某种类型的内容，则给你推荐这种类型下的其他内容。

以电影推荐为例。比如你之前看过《盗梦空间》，则系统会关联数据库中盗梦空间的信息。系统会推荐克里斯托弗·诺兰导演的其他作品，比如《致命魔术》；系统会推荐主演里昂纳多的其他作品，比如《第十一小时》。

如果这个电影系统的数据被很好地分类，那么推荐系统也会给用户推荐这个分类下的其他作品。盗梦空间如果被归为科幻作品，那么可能会推荐其他科幻作品，比如《星际迷航》。

基于内容的推荐好处在于易于理解，但是坏处是推荐方式比较依赖于完整的内容知识库的建立。如果内容格式化比较差，那么基于内容的推荐就无法实行。同时如果用户留下的数据比较少，则推荐效果很差，因为无法扩展。

3. 基于内容的协同过滤

协同过滤（Collaborative Filtering）与传统的基于内容过滤直接分析内容进行推荐不同，协同过滤会分析系统已有数据，并结合用户表现的数据，对该指定用户对此信息的喜好程度预测。

基于内容的协同过滤（item-based CF），通过用户对不同内容的评分来评测内容之间的相似性，基于内容之间的相似性做出推荐；最典型的例子是著名的“啤酒加尿布”，就是通过分析知道啤酒和尿布经常被美国爸爸们一起购买，于是在尿布边上推荐啤酒，增加了啤酒销量。

需要计算用户u对物品j的兴趣，公式如下：

这里  表示用户有关联的商品的集合， 表示物品j和i的相似度， 表示用户u对物品i的打分，示例如下：

这里还有两个问题没有仔细描述，如何打分，如何计算相似度。

打分的话需要根据业务计算，如果有打分系统最好，没有打分系统，则需要根据用户对这个物品的行为得到一个分数。

计算相似度除了之前我们提到的余弦公式，还可以根据其他的业务数据。比如对于网易云音乐而言，两首歌越多的被加入两个歌单，可以认为两首歌越相似。对于亚马逊而言，两个商品越多的被同时购买，则认为两个商品相似。这里其实是需要根据产品的具体情况进行调整。

4. 基于用户的协同过滤

基于用户的协同过滤（user-based CF），通过用户对不同内容的行为，来评测用户之间的相似性，基于用户之间的相似性做出推荐。这部分推荐本质上是给相似的用户推荐其他用户喜欢的内容，一句话概括就是：和你类似的人还喜欢下列内容。

需要计算用户u对物品i的兴趣，公式如下（可以和基于物品的协同过滤仔细对比）：

这里  表示对物品i有过行为的用户集合，  使用用户u和用户v的相似度，  表示用户v对物品i的打分，示例如下：

同样的，这里也没有介绍如何计算相似度，但是在上一篇文章我们给出了一个例子，计算相似度如果用到余弦公式，其实最主要的是选好维度。对于音乐而言，可能是每首歌都作为一个维度，对于电商而言，也可以是每个商品都是一个维度。当然，用一些可理解的用户标签作为维度也是可以的。

5. 基于标签的推荐

标签系统相对于之前的用户维度和产品维度的推荐，从结构上讲，其实更易于理解一些，也更容易直接干预结果一些。关于tag和分类，基本上是互联网有信息架构以来就有的经典设计结构。内容有标签，用户也会因为用户行为被打上标签。通过标签去关联内容。

需要计算用户u对物品i的兴趣，公式如下（可以和基于物品的协同过滤仔细对比）：

这里  表示用户u和物品i共有的标签， 使用用户u和标签k的关联度， 表示标签k和物品i的关联性分数，示例如下：

标签查找的方法这里有很大可以发挥的空间，比如，通过知识库进行处理，或者语义分析处理。而对于一些设计之初就有标签概念的网站， 就比较容易，比如豆瓣和知乎。对于知乎而言，公共编辑的标签是天然的标签内容，对于知乎的用户而言，浏览回答关注等行为则是天然的用户标签素材。

6.总结

对于推荐而言，这几种基本的方法彼此之前都有些应用场景的差别：比如基于知识的推荐，这是比较老旧的推荐方法，但是对于系统和结构比较好的内容，则低成本且高效。比如基于内容的协同过滤，就适用于内容比较有限，但是用户数特别多的情况，比如电商公司。比如基于用户的协同过滤，则比较容易根据用户的兴趣点，发觉热点内容，比如新闻门户。对于基于标签的推荐，有标签系统的很占便宜，它在灵活性和可控制性上都好一些，但是做好很难。

本期主要是介绍了常见推荐算法的基本原理，那么在推荐系统策略设计的时候，有哪些需要特别注意的地方呢？我们怎么衡量一个推荐系统的优劣呢？推荐系统有哪些典型的应用场景呢？欢迎关注专栏，继续阅读下期。

推荐策略设计的Notes

推荐算法的基本原理表述起来比较简单，但是具体实施起来还是比较复杂。没有任何一个标准的推荐系统，可以适用全部的情形，在真正实现的过程中，需要对算法有融汇贯通的掌握，以及对业务本身有深刻的理解。本章会介绍一些碎片化的推荐系统notes。

1. 要解决哪些bad case？

这个问题是推荐系统被设计出来的根本，产品遇到了哪些bad case,无法通过现有的机制实现，而一定要通过推荐系统才能解决？

以传统门户而言，之所以用推荐系统，是因为随着受众的增多，受众对于新闻的偏好越来越多样化，而针对全体人的推荐系统并不能满足所有人的需求。编辑默认只会推荐绝大多数人喜欢的内容，国内的情况就是“强奸新闻”和“奇闻异兽”，但是这显然不满足高端用户的需求。相反会降低门户产品的调性，造成高端用户的流失。推荐系统就可以根据不同人的需求推送不同的内容，解决这个问题。

这里的要解决的case如下：

如何让互联网新闻偏好者的首页主要是互联网新闻而非大众新闻。

如果让女性用户首页不出现大量男权色彩重的新闻，比如“强奸新闻”。

只有明确了bad case，才知道了解决问题的方向。

2. 设计怎样的合理路径？

推荐系统最终形态是基于机器学习的推荐系统，那么如果设计一个一个月就上线的推荐系统，怎样既保证有效性，同时也又保证最后的合理演化？

举个例子，如果最终路径是无人驾驶电动车代步。有两种演化方案：

方案一：电动滑板>>电动自行车>>电动摩托车>>无人驾驶电动车

方案二：汽油动力汽车>>混合动力汽车>>电动汽车>>无人驾驶电动车

方案一看似不断演进，其实每一次都是很大成本的重构。而第二个方案，则能看到清晰的技术演化路线，驾驶动力在演化，最终是无人驾驶系统的上线，而大的架构没有修改。

我一直觉得一个产品经理的能力很大程度体现在架构思维和中间版本的设计。

具体到推荐系统的设计，短期内要看到效果，一开始直接上CF，是不明智的，一开始直接上基于语义分析的推荐方法也是不明智的。而如果是利用现有内容信息进行人工干预的聚类，利用这个内容聚类去实现用户聚类，则更加明智一些。后续转为自动化聚类也更加合理。

3.可调整性

推荐系统最需要考虑的问题是，如果出现了问题，怎么可以快速调整来满足需求？

措施无外乎三种：提权，降权，屏蔽。

这里就要求，权重是否能够快速调整？召回策略是否能够快速调整？只有系统级别支持粒度较细的权重调整策略，以及灵活的召回策略，才能够保证策略的快速调整，保证推荐系统的可持续迭代。

这也是不建议直接上线CF或者机器学习的原因，因为CF和机器学习等策略，一开始可调整性比较差，前期无法快递迭代，可能对于项目而言，就是死刑。

4. 离线评估、 灰度上线和用户反馈

离线评估是指在发布之前，需要去检验典型的bad case 是否解决。是否达成一开始的目标，如果没有，则需要继续调整对应算法，直到能够明显解决问题。

灰度上线则也是稳妥的措施。一开始推荐系统一定是充满了各种问题，所以为了解决这个问题，刚开始上线一定不能直接全量上线。正确的做法是，灰度上线一段时间期间，快速的根据用户反馈迭代算法，再考虑全量上线。

用户反馈的方案包括但不限于：用户问卷，负反馈操作入口。典型的负反馈入口如下（今日头条）：

5.说服别人的数据

所有改进工作效率的系统，都会触碰别人的利益。这句话话值得读三遍。

推荐系统正是这样。如果没有推荐系统，运营或者编辑能确定所有的位置应该摆放什么内容。有了推荐系统，原来10个人做的事情可以3个人能做完。那么这个部门裁谁？没有推荐系统，可能有一些特定KPI完成的余地，甚至可能有利益输送的空间，现在交给推荐系统，这个损失怎么办？

另一方面，并不是所有人都有技术信仰，觉得推荐系统能比运营或编辑的经验判断会比推荐系统差，如果领导本身对推荐系统有怀疑，这也会是一大阻力。

推荐系统最开始的目标并不是要大范围的上线，并且证明自己能替代编辑或者运营，而是要能够说服别人，推荐系统是可用的。这样才会减少阻力。最常见的做法是在运营或编辑不会干预的地方，上线推荐策略。因为这些地方上线推荐，业务数据是绝对的增量。或者如果在重要运营位上线，一定不要改变运营或者编辑最好的位置，而是在相对次要的位置增加推荐模块儿。

而只有在这些位置不断迭代系统，效果足够好之后，达到能够说服别人的时候，再考虑进一步推进推荐系统的覆盖率。

6. AB test

之前在讲搜索的时候，我也是在最后强调了AB test的重要性。推荐和搜索一样，本身极大依赖参数的配置。而这些参数的配置并没有通用的法则，同时也依赖各个平台自身具体的情况，只能在了解其原理的基础上，不断迭代摸索。在算法迭代的过程中，能够测试其效果是算法迭代的核心。只有能同时在线上部署多套搜索算法，并且监控其效果，推荐的迭代和改进才能展开。而这一切的基础，正是一个看不见的功能：AB test机制。

7. 总结

本期总结了推荐系统实现过程中一些需要特别注意的地方。

结束之前，讨论另一个问题，推荐系统的产品经理需要懂算法么？

答案也很简单，一定要懂。如果不懂算法，就只能是做简单的评估并提出改进，很难有系统性的优化方案。懂算法也不是要知道具体怎么实现，而是要知道实现的原理，这样才能更好地把产品需求转为推荐策略，并且和算法工程师商量出解决方案。

By the way

最近手上的几个项目都到了比较紧张的时期，所以更新会慢一下，也正在考虑更新一些组织难度没那么高的内容。本专栏的关注者我大致看了下，产品经理居多。对于入行比较短的，应该比较关注怎么系统地提高自己，对于老司机，也会有给自己手下新人推荐书的需求。下一期我会给出一份新人产品经理书单，希望能在偷懒的同时，也解决一些大家的问题，欢迎关注专栏并阅读下期。