从零开始构建企业级推荐系统 (二十九)

写在前面：

大家好，我是强哥，一个热爱分享的技术狂。目前已有 12 年大数据与 AI 相关项目经验， 10 年推荐系统研究及实践经验。平时喜欢读书、暴走和写作。

业余时间专注于输出大数据、AI 等相关文章，目前已经输出了 40 万字的推荐系统系列精品文章，今年 6 月底会出版「构建企业级推荐系统：算法、工程实现与案例分析」一书。如果这些文章能够帮助你快速入门，实现职场升职加薪，我将不胜欢喜。

想要获得更多免费学习资料或内推信息，一定要看到文章最后喔。

内推信息

如果你正在看相关的招聘信息，请加我微信：liuq4360，我这里有很多内推资源等着你，欢迎投递简历。

免费学习资料

如果你想获得更多免费的学习资料，请关注同名公众号【数据与智能】，输入“资料”即可！

学习交流群

如果你想找到组织，和大家一起学习成长，交流经验，也可以加入我们的学习成长群。群里有老司机带你飞，另有小哥哥、小姐姐等你来勾搭！加小姐姐微信：epsila，她会带你入群。

在过去的一两年有很多人咨询作者怎么从零开始搭建工业级推荐系统，有做音视频的、有做新闻资讯的、有做在线教育的，不一而足。大家最大的困惑是不知道怎么下手，也不知道用什么算法合适，对为什么做推荐以及对推荐算法价值的预期也没有明确的想法和概念。总之，对产品是否需要搭建一套推荐系统、需要注意什么都比较迷茫，更不知道怎么为产品快速搭建一套有效的、具备商业价值的推荐系统。

基于上面的问题和困惑，我们用这一章来详细说明从零开始搭建一套企业级推荐系统需要考虑的问题及相应的对策，将搭建推荐系统中涉及到的知识点、关注点、可能存在的问题体系化地进行归纳总结，给希望从零开始搭建企业级推荐系统的读者提供一份参考指南，帮助读者系统化、有针对性地思考，让读者尽量少走弯路。

本章作者基于 5W3H(why 、who、when、where、what、how、how much、how feel)思考框架，从你的产品需要推荐系统吗、让谁来搭建推荐系统、在产品的什么阶段搭建推荐系统、搭建什么样的推荐系统、怎么搭建推荐系统、关于构建推荐系统的资源投入、对推荐系统价值的预期、从零搭建推荐系统必须做好的三件事、几个具体实用的建议等 9 个方面来讲解从零开始搭建推荐系统需要考虑的方方面面。

本书写作的目标是聚焦在企业级推荐系统上，是基于作者多年实践经验的梳理和总结。本章是希望给读者提供一份从零搭建推荐系统的参考指南，因此是本书中非常重要的一章，是具备实践参考价值的。

27.1 你的产品需要推荐系统吗(why)

在当今的信息爆炸时代，我们每时每刻都在线，每天需要面对各种各样的信息，而很多时候用户的目标也不是很明确，在这种背景之下，推荐系统的价值就体现出来了。推荐系统的主要目的是帮助人们解决信息过载的问题，推荐算法就是一种信息过滤的方法，通过推荐系统的过滤作用将用户想要的信息、产品及服务自动、及时地展示给用户。

在特定场景下，用户的需求是不明确的，这个是普遍存在的现象。一般来说，一个产品需要借助推荐系统来辅助进行内容分发，需要具备如下两个基本条件：一是产品提供的信息/服务足够多，用户没有时间、没有精力将所有信息/服务都查看一遍再选择适合自己的；二是用户规模足够大，如果只有很少用户，那么其实是可以通过专家提供一对一专业建议的方式来提供服务的。

在移动互联网时代满足这两个条件的产品是非常多的，如我们常见的新闻资讯类、视频类、电商类、音乐类、生活服务类、在线学习类、匿名交友类 APP 都有推荐系统的用武之地。一句话来概括，如果你的产品是面向 C 端用户提供海量信息/服务的，那就有做推荐的必要了。

相比于人工编排推荐，推荐系统最大的优势是千人千面、完全自动化、每天可以多次更新甚至实时更新推荐结果。因此，推荐系统具备更高的内容运营效率、更容易击中用户的兴趣点，从而提升用户使用体验，促进用户点击、购买的转化，进而产生商业价值。

基于推荐系统的上述价值，只要产品满足构建推荐系统的条件，作者是强烈建议在产品中引入推荐系统的。

当然，你的产品需不需要、能不能引入推荐系统还跟创始人的视野、格局、思路有很大关系，是否相信推荐技术可以更好地处理信息过滤问题、是否相信推荐系统能够产生极大的商业价值决定了推荐系统在他心目中的地位，进而决定了他是否愿意投入足够的资源来打造推荐系统。今日头条的张一鸣就是将推荐系统当做公司的核心竞争力，一切业务的发展都围绕个性化推荐来展开，这才让今日头条在短短几年时间内快速成长，预估市值超千亿美元，成为可以震撼 BAT 三巨头的挑战者。

27.2 让谁来搭建推荐系统(who)

随着大数据、云计算和 AI 技术的发展，目前有很多云服务厂商(如阿里云、百度云等)和一些做 toB 生意的 AI 创业公司(如神策数据等)都提供了推荐系统的 SAAS 或者 PAAS 服务。部分传统的外包公司在大数据与人工智能大背景下，也拓展了业务范围，开始提供搭建推荐系统方面的外包服务。因此，我们构建推荐系统就有如下三种主要方法，下面我们分别对每种方法进行简单介绍，我们会着重介绍各个方法的优缺点。

27.2.1 自建推荐系统

自建推荐系统最大的优势是整个系统的建设掌握在自己手上，可控性好，方便业务调整和快速迭代，另外算法可以更贴合自己产品的特质做定制化开发，部分开发资源也可以跟后端团队共享。自建最大的问题是需要自己公司招聘推荐系统相关专业人员，因此有更多的固定人力成本。目前对推荐系统比较精通的人才是非常少的，价格也相对很高，小的创业公司也很难吸引优秀的人才加入，因此组建推荐团队难度高。

27.2.2 通过外包构建推荐系统

将公司推荐业务范围和目标定义好，外包给第三方团队来开发是另一个可行的方案。这种方案的优点是相对轻资产，不需要自己搭建团队。但是最大的问题是，第三方可能对你的业务不熟悉，理解不够深刻，责任心也没那么强，无法做出非常贴合业务及产品特色的推荐系统。外包代码一般注释少，代码结构不清晰，因此后续的维护、迭代等等也是大问题。更大的问题是，外包团队离职率高，等你的系统需要优化了，可能对接的是另外一批人，这批人根本不熟悉原来的系统，怎么能优化得好呢？

27.2.3 购买推荐系统云服务

利用第三方云服务公司或者 toB 的 AI 创业公司提供的成熟的推荐服务也是一个不错的选择。该方案最大的优势是接入流程相对完善、标准化，可以快速构建一套可用的推荐服务。云服务最大的问题是采用的推荐算法是行业通用的解决方案，模型、数据无法完美匹配自己公司的业务，而我们只能适配云服务厂商提供的规范，比较死板，因此算法效果也不一定有他们鼓吹的那么好。云计算一般提供标准化服务，因此，很难、甚至无法对推荐系统进行个性化的调整和裁剪。有些 toB 创业公司提供 PAAS 的私有化部署，甚至将代码给你，可以进行二次开发。这种方式可控性会更好，也可以在代码基础上进行微调，更好地适应公司当前业务。由于要在原来的框架下进行修改或者调整，因此修改和调整是有限的。另外，对第三方框架的熟悉度不高，二次开发难度也比较大，做不到自建那样的灵活性。云服务厂商提供的产品和服务如果出现问题，需要提工单，反馈可能不会及时，特别对于创业公司这样的小客户，在云服务厂商那里的优先级是比较低的，响应度自然不会高。

关于怎么搭建推荐系统，下面给出作者的建议。如果公司将推荐系统作为产品的核心功能点，甚至是公司的核心竞争力的话，那么一定要自建推荐系统，这种方案是自己可以完全控制的。核心竞争力一定要掌握在自己手上。如果是期望产品具备推荐的能力，没有将所有希望奇托于推荐系统，推荐只是作为人工运营的一个补充，可以采用云服务的方式。作者最不建议的是外包的方式，风险太大。

到底采用哪种方式，还与公司所处阶段、产品定位、公司发展目标、当前的人力、财力、资源等因素都有关系，所以需要事先评估清楚再决策，这种决策一定是公司高层的事情，只有老板想清楚了，自上而下达成一致，目标明确，才能做好推荐系统。当然，也不是一种方式一成不变，先采用云服务的方式，等招聘到合适的推荐系统人才或者产品更稳定了再自己搭建也是可行的方案。

27.3 在产品的什么阶段搭建推荐系统(when)

产品的生命周期一般会经历起步期、成长期、成熟期、衰退期、消亡期等五个阶段。一般建议在产品的起步阶段和成长阶段来构建推荐系统，这样可以更早地利用 AI 技术的红利，发挥推荐算法的优势，提升内容的分发效率，提高用户的参与度和粘性，最终让产品更快地成长、获得更多的用户。

越早想清楚推荐的价值，趁早做，可以尽快验证推荐对产品的贡献，及时决策调整，所谓船小好调头。早做的另一个好处是，可以更好地巩固推荐系统在产品中的主导地位。如果在后期做推荐，整个产品运营体系都很成熟了，很难让推荐在产品中占得一席之地，因为不同模块运营人员之间会存在“权力斗争”，大家互相争夺地盘，抢核心位置的运营权，其结果可能会让推荐系统难以落地，最终变得可有可与，无法发挥应有的价值。

27.4 搭建什么样的推荐系统(what、where)

推荐系统主要有排行榜推荐、相似推荐、个性化推荐、流式推荐等几种主流的核心产品形态。那么我们的产品应该选择哪几类推荐产品形态呢？

一般来说个性化推荐与相似推荐是两类最重要的推荐产品形态，如果你打算在你的产品中引入推荐技术的话，相似推荐和个性化推荐是强烈建议采用的。这是因为这两个推荐产品是用户触点多的推荐形态(所谓用户触点多，就是用户大概率必经的路径，相似推荐一般放在标的物详情页中，这个是用户浏览的必经路径，个性化推荐一般放在首页，也是用户必经路径)，这样用户就可以更方便、更频繁地接触到推荐了，推荐系统才有用武之地，推荐系统才有机会真正发挥业务价值。

在产品中位置是非常重要的，要做好推荐，必须放到核心位置(不一定是一开始就放到核心位置，可以通过 AB 测试评估，当效果足够好了就有资格这样放了)。古语说的“酒香不怕巷子深”这句真理在当今的产品中是不适用的，因为酒是有气味的，不能看到也能闻到，而推荐产品只有用户看到了才知道它的存在。

相似推荐一般部署在详情页中，通过不同的特征维度构建推荐算法，在标的物的详情页中关联一组有相关关系的标的物作为推荐列表。详情页是任何一个标的物都有的，所以是一个非常核心的用户触点多的位置。

而个性化推荐可以安置在首页等核心位置为用户提供个性化的推荐服务(个性化推荐的标的物数量、排放位置是可以根据场景、产品阶段做动态调整的)。个性化推荐可以做成实时推荐的形式，即所谓的信息流推荐，这样可以给用户实时反馈，让用户获得所见即所得的效果，从而提升用户体验，同时让更多的标的物曝光(实时推荐提升了标的物的流转效率，当然会让更多的标的物曝光)，这对平台方及标的物提供方都是非常有价值的，实时个性化推荐也是未来的发展趋势。像新闻资讯、短视频等“快消类”产品(用户“消费”完标的物的时间短，这类产品一般会占据用户的碎片化时间)是非常适合做实时个性化推荐的，就连淘宝、天猫的首页也切换到了信息流推荐。首页是用户打开产品就能第一个看到的页面，所以一定是用户触点多的核心位置。

排行榜推荐是一类非个性化推荐，可以根据最新、最热、购买量、播放量等统计维度来构建排行榜，实际计算非常简单，排行榜可以放置在首页某个提供榜单功能的模块中，给用户提供大众化的推荐。由于人类普遍具有从众心理，排行榜类推荐实际效果还是可以的。即使我们的产品不提供排行榜这类推荐形态，排行榜推荐一般也可以作为个性化推荐的默认推荐(当个性化推荐数量不足时用排行榜填充，或者当个性化推荐接口出问题时，用排行榜推荐替代)。

27.5 怎么搭建推荐系统(how)

从零开始搭建推荐系统，个人建议尽量快速让新的推荐业务上线，再逐步优化，提升算法效果。在如今竞争非常激烈的大环境下，快是第一位的。不要想着一开始就做出一个非常完美的、效果非常好的推荐系统，期望系统一上线就可以大大提升标的物的分发与转化，这种想法是不切实际的。在没有上线之前，我们只能根据离线评估或者个人经验来判断算法是否有效，个人经验判断往往是有误的，另外离线评估效果好的算法在真实业务场景中不一定就能提升商业化指标，也就是说离线评估和在线评估(商业化指标)可能不是正相关的(即使是正相关，有可能相关度也非常低)。

对于早期阶段的产品，由于用户很少，数据量不多，计算成本不大，我们甚至可以利用单台服务器、单进程部署一个推荐系统，而不用考虑后面当用户多了之后的分布式计算，这样算法可以先快速上线。当用户足够多，单机算不过来了可以再考虑利用 Spark 等分布式计算平台重构现有业务逻辑。

下面我们根据产品所在不同阶段来说明搭建什么类型的推荐系统及怎么搭建，给读者提供一份切实可行的参考指南。

27.5.1 产品起步阶段的推荐

在产品的起步阶段，由于用户规模小，用户行为数据少，没有足够多的行为数据来训练协同过滤推荐算法，这时比较适合基于内容的推荐算法，该类方法可以有效地缓解冷启动问题。基于内容的推荐算法也是比较简单的一类算法，开发简单、容易部署上线。前面我们讲到推荐系统最好在产品起步和成长阶段搭建，下面我们根据这两个产品阶段来说说怎么构建推荐系统。

(1) 资讯新闻等文本类产品

对于新闻资讯这类主要是文本标的物的产品，最简单的方式是基于 TF-IDF 模型来构建推荐算法，每个文本(标的物)基于 TF-IDF 构建向量表示，通过向量的 cosine 余弦相似度来计算两个文本的相似度。

这种文本相似度可以直接用于构建相关推荐(某个文章最相似的 N 个文章作为相似推荐列表)。我们可以将用户最近看的文章的向量进行加权(根据观看时间、停留时间等)获得用户的向量表示，用户向量与文章向量的 consine 余弦就是用户对该文章的喜好度，还可以用 item-based 协同过滤的计算思路(见下面公式，其中 S 是所有用户看过的文章列表，

是用户 u 对文章

的喜好度，

是文章

与 s 的相似度)来计算用户对新文章的评分，还有一种方式是先对文章进行聚类，在推荐时，推荐用户看过的文章所在类别的其他文章作为推荐列表。

新闻资讯类文章一般可以做成信息流推荐，基于上面提到的 TF-IDF 算法也是可以实现实时推荐的。对于新发布的一篇文章，可以基于现有的词库(corpus)来生成该文章的向量表示(如果该新文章中包含某些词，不在 corpus 中，那么可以直接忽略这些词，虽然这样做精确度有所下降，但是不用对所有文章进行重新求向量化的过程，因此可以做到实时化，向量化的过程可以每天利用所有文章作为 document 重新训练一次)，向量化后这篇新的文章就跟其他文章一样处理了。

(2) 视频类产品

视频类产品，一般可以分为长视频和短视频两大类，它们的内容来源不同、内容生产的频度不一样、用户的消费习惯也不一样，因此我们分长视频和短视频两种情况进行介绍。

长视频

长视频一般属于 PGC(Professional Generated Content)内容，内容生产周期长、成本大、更专业。内容在创作完成就会包含大量的 metadata 信息，比如演职员、年代、标签、剧情、类别、语言、地区等等。这时我们可以采用如下两种算法来构建推荐系统：

l 基于标签

如果长视频标签比较完善(PGC 内容一般在生产完成后就会包含一些核心标签的)，可以采用标签 n-hot 编码来(嵌入)表示每个视频，这样每个视频就向量化了，就可以轻易地计算任意两个视频的相似度。我们可以采用(1)中类似的方法来做相似推荐和个性化推荐。

另外，根据用户的播放记录，我们可以给用户打上相关的兴趣标签，再采用基于标签的反向倒排索引方法做推荐(读者可以参考《基于内容的推荐算法》中 5.2.4(5)节的具体算法原理)。

l 基于结构化的 metadata 信息

如果长视频标签不够丰富或者标签质量不佳，可以利用结构化 metadata 信息(基于长视频 PGC 内容属性，这类数据一定是有的)，可以采用向量空间模型来计算两个视频之间的相似度。具体参见第 5 章《基于内容的推荐算法》中 5.2.3(2)节对向量空间模型的介绍，后面我们也会在第 29 章《基于 Erlang 语言的视频相似推荐系统》介绍一个采用向量空间模型做视频相似推荐的真实案例。有了视频相似度，可以采用(1)中类似的方法来做个性化推荐。

短视频

短视频一般属于 UGC(User Generated Content)或者 PUGC(Professional User Generated Content)内容，内容生产周期短、成本低、内容产量大、内容质量参差不齐。短视频由于生产量大、有时效性(如新闻类)，一般平台方通过人工构建标签体系是不现实的，但是可以制定一定的标准和规范，辅助一些奖惩措施(制作良好标签，满足规范的内容生产者给予一定的内容曝光优先级，反之，质量差的生产者降低曝光概率)，让内容生产者根据规范或者标准来事先定义好标签，在内容上传到平台时附带上传定义好的标签。不过不同的内容生产者由于专业度相差较大、理解上也不一致，可能会导致最终的标签体系质量不够高。基于现在短视频标题一般比较长(一般有 10-30 字)这一事实，另外一种低成本快速获得标签的方法是基于 NLP 技术，从标题中提取关键词作为该短视频的标签，在电视猫短视频推荐中我们也部分采用了这种方式生成的标签。如果这些标签都不够完善，那么基于来源渠道、内容分类、上线时间等几个少数标签都可以构建出一套简单的内容推荐系统。有了标签，就可以按照上面讲到的类似方法构建相似推荐和个性化推荐。

短视频一般没有长视频那类丰富的结构化信息，因此采用标签推荐也可能是唯一可行的方式。短视频属于“快消”类的内容，因此最好是打造实时的个性化推荐，具体技术实现案例可以参见《基于标签的实时短视频推荐系统》中的案例介绍。

(3) 电商类产品

电商类产品相对复杂，会有非常多的品类及类目，这些信息本身属于标签的范畴，不同品类包含的信息也会不一样。比如衣服会有颜色、款式等信息，手机等有重量、尺寸等信息。价格、生产商等共用的 metadata 信息也是有的。电商类产品一般会在同一品类下计算相似推荐，这时可以用同一品类下的标签、metadata 信息采用与上面类似的方法计算相似度。电商的个性化推荐会更加复杂，一般可以基于用户过去的浏览记录及购买记录给用户打上相关的兴趣标签，再采用标签倒排索引的方法进行推荐(读者可以参考《基于内容的推荐算法》中 5.2.4(5)节的具体算法原理)。

当我们的产品经过一段时间的发展，积累了更多的用户和数据后，对推荐系统的架构、价值、运营方法等有了更深入的了解，我们就进入了产品成长阶段的推荐。

27.5.2 产品成长阶段的推荐

对于成长阶段的产品，用户规模会较大，也有足够多的行为数据，这时可供我们选择的算法会非常多，除了上面介绍的基于内容的推荐算法，常用的协同过滤算法，如 item-based 协同过滤、矩阵分解、分解机等都是不错的选择，有资源、有条件的公司还可以选择深度学习等更复杂的模型。一般来说，协同过滤算法的效果好于基于内容的推荐算法，建议有条件可以在这一阶段适当采用协同过滤相关算法。具体怎么实施协同过滤算法，可以参考《协同过滤推荐算法》、《矩阵分解推荐算法》、《因子分解机》、《嵌入方法在推荐系统中的应用》以及《深度学习在推荐系统中的应用》，这里作者不再赘述。

上面我们只列举了新闻资讯、视频类、电商类的产品在不同阶段怎么做推荐，对于其他产品需要根据产品特性、已有的数据形式等采用类似的策略，这里不再赘述。

27.6 关于构建推荐系统的资源投入(how much)

做任何一件事情都是需要资源投入的，特别是做好一件事情更需要投入足够多的时间和精力，对于构建推荐系统也不例外。在本节我们来讲讲从零开始构工业级建推荐系统需要哪些资源投入，让还没有太多相关经验、但是想了解怎么从零构建推荐系统的读者有一个初步认知，并且作者会基于自己多年实践经验给出一些建议。

对于推荐系统的资源投入主要有两类，一类是人力投入，一类是计算资源(如服务器)资源。下面分别对这两类投入进行细致分析。

27.6.1 人力投入

推荐系统的人力投入主要是从数据收集到推荐算法上线提供推荐服务以及后续的推荐系统优化迭代整个过程中的人力投入。包括日志埋点、数据收集、数据存储、特征工程、模型训练、推断预测、前端接口开发、UI 交互、产品设计、项目跟踪等等。日志埋点、数据收集、数据存储这些可以复用大数据相关技术栈和人力(一般互联网公司都会有相关的大数据分析团队)，前端推荐接口开发可以复用后端人力，UI 交互、产品设计、项目管理这些也是可以复用的资源(不过当产品规模足够大，公司会专门招聘算法类产品经理)。所以构建推荐系统最核心的人力资源就是特征工程、模型训练、模型推断预测这几个核心算法业务需要的人力(即推荐算法工程师的工作)，这也是推荐系统最重要、最有技术含量的部分。如果不是采用外包或者直接利用云厂商的 SAAS/PAAS 解决方案的话，是需要相关专业人才进行开发的。那么这个人是内部选拔还是重新招聘呢？下面给出作者的建议。

如果团队人力比较充足，短期内也很难招聘到合适的有经验的推荐算法开发人员，是可以(从后端开发)先借调一些人力通过自学一些相关知识，快速开发一个推荐系统的原型并上线的。不过为了避免走很多弯路，技术负责人是需要全程参与把关的，并且最好能够咨询一些外部有经验的推荐系统专家的建议。如果有条件的话，是可以招聘一个有经验的专业的推荐开发人员来做的，招聘的原则也是希望以前做过或者了解过推荐系统全流程的候选人，这样可以更好地把握推荐系统建设的方方面面。

27.6.2 计算资源投入

推荐系统是一个数据密集型、计算密集型工程技术，因此是需要一些软硬件资源来支撑推荐服务的构建的。目前云计算已经非常成熟，这些资源都可以从云平台购买，而不是自己搭建。作者公司是从 2012 年开始做大数据和推荐的，当时国内云计算还不成熟(阿里云 2009 年才成立，2012 年还没有相关大数据云服务产品)，因此自始至终都是自己搭建数据平台与计算中心的，这中间由于人力、资源不足，也没有专门的大数据基础架构资深专家进行较底层的开发与维护，中间遇到很多坑，对整个推荐系统的开发速度和推荐系统的稳定性是有一定的负面影响的，因此作者强烈建议采用购买云服务的形式构建大数据的存储与计算中心，减少运维成本，将核心放到推荐业务上。

前面我们也讲过，在产品早期，用户规模相对小，我们没必要构建大数据平台，单机单线程就可以跑出一个推荐系统。当用户足够多、数据量足够大时，再投入资源构建大数据平台。因此，为了节省公司成本，一切资源的投入需要遵从从简原则。

27.7 对推荐系统价值的预期(how feel)

我们构建推荐系统，一定是对推荐系统抱有期望的。那么推荐系统对产品、对公司到底有什么价值呢？概括来说推荐系统的价值主要体现在如下 4 个方面：

27.7.1 用户增长方面：提升用户留存、活跃、停留时长

个性化推荐可以做到千人千面、实时推荐用户感兴趣的内容，更容易击中用户的兴趣点，当然可以让用户更好地留存下来，也更容易让用户跟产品互动(在抖音你只要简单滑动，就有源源不断的新视频出现在你眼前)，增加用户的使用时长，最终也提升了用户体验。

27.7.2 经济价值方面：节省人力成本、促进“标的物”变现

节省人力成本应该很好理解，有了个性化推荐，就不需要那么多人工运营的工作，甚至不需要那么多人工运营人员了。这里“标的物”的变现，如果“标的物”中包含广告(如视频的前贴片广告)或者“标的物”就是广告(如信息流广告)，那么就是促进广告的曝光与点击，如果标的物包含会员内容(推荐付费的会员视频)，那么就是促进会员转化，如果标的物本身就是商品(如淘宝上的各种商品)，那么就是促进商品的售卖。

27.7.3 效率方面：提升内容分发效率、促进长尾内容分发

推荐系统完全是程序化自动完成内容分发的，可以做到实时、全天候无人管控的推荐，分发效率自然高。推荐系统根据用户的兴趣来分发内容，长尾内容一定有喜欢它的用户，推荐系统可以很好地发挥从“标的物”找人这个逆向功能。头部内容毕竟是少量的，长尾内容才是常态，这无疑让推荐系统发挥了无可比拟的作用，让海量的长尾内容价值得到体现。

27.7.4 生态方面：促进“标的物”提供方的生态繁荣

这个价值可能不太好理解，如果你的产品是像淘宝这类做平台的，那么借助推荐系统可以将优质商家的优质商品推荐出去，而一般的商家的商品由于质量不高，没有太多的购买量，用户评价也不高，推荐系统的协同效应就会降低它的权重，让这些品质不太好的商品很难被推荐出去。这里推荐算法起到了择优筛选的作用，自然可以促进平台上的商家生态越来越健康。

我们不光要知道推荐系统的价值，更应该提前思考清楚哪些价值是自己产品追求的、哪些是当前阶段最重要的，想清楚了这些问题，我们就需要量化这些维度的价值。我们需要根据产品发展阶段和公司整体运营策略确定核心指标，有了核心指标，我们还要确定具体的 KPI 或者 KR(Key Results，OKR 方法中的关键结果)。关于这一块的详细介绍，读者可以参考《推荐系统的商业价值》进行深入了解。

27.8 从零搭建推荐系统必须做好的三件事

前面对从零开始搭建一套可行的工业级推荐系统的各个方面进行了介绍，那么在搭建推荐系统中什么是最重要的呢？基于作者个人经验，我觉得一个可用的、有商业价值的工业级推荐系统必须需要建设好下面 3 个核心功能点。

27.8.1 产品与算法

产品形态和推荐算法是推荐系统的核心，两者就像硬币的正反面，是不可分离的。好的产品形态能够提升用户体验，同时体现商业价值，好的算法才能够更精准、更有效地将标的物分发给喜欢它的用户。在开始设计推荐系统时，一定要结合产品当前的阶段、产品具备的数据、现有资源情况等选择一个合适的推荐产品形态和推荐算法并快速落地。

27.8.2 评估指标

我们做推荐算法的目的就是要让推荐算法产生效果、产生商业价值，那么效果怎么评估呢？不是我们通过思考或者拍脑袋就可以知道的。在精细化运营时代，我们需要用数据说话，对于推荐系统也不例外。因此，我们需要对构建的推荐系统定义一些评估指标(这些评估指标是跟公司的战略、产品当前的目标息息相关的)来评估推荐算法的效果。

常用的评估推荐效果的指标有转化率、人均点击次数、人均播放时长、客单价等等。当然为了统计这些指标，我们需要对用户操作行为进行日志埋点，收集用户对推荐标的物的反馈，才能统计出这些指标。

在第 27.7 节我们已经对部分指标进行了解读，读者可以参考《推荐系统的商业价值》了解更多关于推荐系统指标的介绍。

27.8.3 AB 测试

AB 测试是一种对比测试，比较两种操在某个变量不一样而其他变量都是完全一样的情况下，两种方法的优劣。通过构建推荐系统的 AB 测试平台，我们可以让推荐系统的迭代变得有据可依。刚构建推荐系统时，不需要 AB 测试建得多么复杂，只要能用就行，这样可以让系统快速跑起来，当业务需求更加复杂时，可以再迭代优化 AB 测试，让 AB 测试可以支撑更复杂场景的对比测试。

最简单的 AB 测试可以根据用户 id 进行 hash，将两种(或者多种)不同的推荐算法的推荐结果分别存于不同的库中，推荐接口通过请求中用户 id 参数，hash 出对应的库，再去相关的库中获取对应的推荐结果，给做 AB 测试的不同组用户展示不同的推荐结果。读者可以参考《AB 测试平台的工程实现》了解怎么实现 AB 测试平台。

只有当我们构建出了推荐系统产品与算法，有了评估指标，有了对比测试的工具，我们就可以根据算法的效果(由评估指标来衡量)来优化算法，再将新老算法做对比测试，新的更好就用新的，否则再进行优化对比测试，这个过程可以不断进行下去，这样我们就将推荐系统打造成了一个可以进行闭环迭代的业务系统。只要做到了闭环，我们就可以无限迭代优化下去了。

27.9 几个具体实用的建议

前面几节对从零开始搭建推荐系统的各个方面进行了细致介绍，在这一节我们重点讲解几个在搭建推荐系统过程中需要特别关注的点，部分在前面章节已经简单提到了，这里再明确地强调一下。

27.9.1 新闻资讯、短视频类产品建议采用基于内容、标签的算法

这类产品，标的物本身存量大、单位时间产出量也大、有一定的时效性，物品冷启动问题较严重。采用基于内容标签的算法可以一定程度避免该问题。同时，基于内容标签的推荐算法可解释性好，只要你推荐的部分内容跟用户看过的内容具备相似性，用户就可以自我意识到推荐的原因，因此用户更容易接受和认可(下面会讲到这类产品一般提供实时推荐，在实时推荐中直观简单的推荐解释是非常容易让用户接受你的推荐策略的)。

对于这类产品，基于内容的推荐方法相对简单，并且有上面提到的一些优点，企业开始搭建个性化推荐系统时可以采用这类方法。

27.9.2 提供“快消”类标的物的产品建议采用流式推荐

“快消”类产品，如短视频、新闻资讯等，用户消费一个标的物的时间很短，用户也更愿意在零散的时间片段使用，因此可以很好地占领用户的碎片化时间。产品只有做到在短时间内给用户提供感兴趣的东西、击中用户中区神经的快感中心，用户才会一直跟产品交互获得更多的短期刺激，否则用户直接退出了。而流式实时推荐可以很好地解决这类问题，通过将主动权、控制权部分给予用户，用户通过不断刷的动作来快速地、不间断地寻找自己的兴趣点。

27.9.3 尽量使用简单的推荐算法快速上线，快是核心竞争力

在从零开始构建推荐系统时，最重要的目标是让系统快速上线，尽早跑起来，在使用过程中发现问题，快速迭代、逐步完善。有时简单的算法的效果也不差，相对于复杂的更精准的算法有更高的投入产出比。读者可以参考《基于朴素 ML 思想的协同过滤推荐算法》，里面讲到了 YouTube、Google News 在早些年利用关联规则、naive bayes、聚类三大简单机器学习算法做个性化推荐的技术方案，非常值得我们借鉴。

27.9.4 构建推荐系统业务闭环比什么都重要

企业级推荐系统一定是一个业务系统，最终的目标是为业务服务，在服务好用户、为用户创造价值的同时创造商业价值。因此，我们首先需要量化业务价值，确定业务核心指标，并构建具备快速评估、快速迭代现有推荐系统和算法的能力，这就是我们在 27.8 节中说的最重要的三件事，只有做到这些，我们才能构建出一个推荐系统的业务闭环，通过不断迭代、不断优化，让推荐系统源源不断地输出价值。

27.9.5 推荐系统专人负责制

企业在开始搭建推荐系统时，最好选定一个人作为整个推荐系统业务的负责人，直接向更高层领导(如 CEO)汇报，负责包括推荐算法、工程、推荐产品、推荐运营等所有相关业务，负责整个推荐业务的落地，并对最终结果负责。这个人不光懂推荐算法，更应该有产品思维、有用户思维、有业务意识。

如果推荐各个模块由不同人负责，这些人汇报的对象也不是同一人，这时资源会太分散，无法形成更好的合力，只有确定了唯一的负责人，决策才更容易执行下去，才能更好地从零开始搭建出推荐系统，让推荐系统走上正轨，尽快产生业务价值。

总结

作者在本章中基于自己多年推荐系统研发的实践经验，通过深入思考，利用 5W3H 分析法，对从零开始构建一套商业级推荐系统涉及到的方方面面的问题进行了归纳和总结，并提供了作者自己的思考方法和解决方案。

工业级推荐系统的构建需要考虑 ROI(Return On Investment，即投入产出比、投资回报率)，希望利用最小的资源投入产出最大的价值。因此，在构建推荐系统之前我们需要思考清楚我们的目标，结合我们现有的资源和当前所处的阶段，选择合适的算法和工具来快速构建推荐系统，并通过不断迭代，逐步提升效果，让推荐系统真正产生商业价值。