推荐算法团队介绍_小言_互联网的博客

作者丨gongyouliu
编辑丨zandy
这是作者的第28篇文章，约9700字，阅读需40分钟

当前推荐系统受到越来越多的互联网公司的重视，推荐系统成为toC互联网产品的标配，在为用户提供个性化服务方面，推荐系统发挥着极其重要的作用。在此背景下，很多公司开始组建推荐算法团队来开发推荐系统，通过为自己的产品赋予千人千面的精准推荐能力，期望借助推荐系统更好地服务于用户，提升内容分发与转化，最终创造更多的商业价值。

推荐算法团队的主要目标是构建一套简洁易用、高效稳定、有商业价值的推荐系统，将推荐系统应用于产品中，通过精准推荐更好地服务于用户，并通过不断迭代，让它的价值越来越大。推荐系统是一类较复杂的偏工程化软件系统，推荐算法只是其中重要的组成部分，由于这一特点，需要不同专业技能的员工参与开发，并且跟很多其他团队密切配合，才能构建出一套有实用价值的推荐解决方案。

在本篇文章中我们对推荐算法团队组成及相关工作进行介绍，让读者更好地了解推荐团队的人员构成，日常工作，需要跟哪些团队打交道，他们之间是怎么协作的，推荐算法团队的目标等问题。具体来说，我们会从推荐团队组成、与推荐系统密切相关的其他团队、推荐团队的目标与定位三个维度来讲解，期望通过作者的介绍，读者可以更好地了解推荐团队的工作和价值。

这里提一下，本篇文章是建立在“我们的产品需要推荐系统并且公司选择自建推荐服务”的前提条件下，这时我们才需要构建推荐算法团队，这里的讨论才有意义。读者可以参考《从零开始构建企业级推荐系统》(点击紫色字体查看相关文章，后面类似，不再说明)这篇文章第二节了解三种为产品提供推荐算法能力的方案，自建推荐系统只是其中一种可行方案。

一、推荐团队组成

在讲推荐团队组成之前，我们需要对推荐的业务流程有一个初步了解，下面图1就是一般推荐算法开发需要经历的步骤和阶段。我们本节讲解的推荐团队组成根据该业务流程涉及到的工作进行划分。

图1：推荐系统业务流程

如果将机器学习比作一架飞机引擎，那么数据就是算法的燃料，对于推荐系统也是一样。我们需要从各种数据源获取数据，将数据统一收集到数据中心(对于互联网公司，目前很多公司构建了自己的大数据平台，有自己的数据仓库体系，这时数据会收集到数据仓库中，按照一定的规范进行存储)。有了各类数据，我们需要对推荐算法依赖的数据进行处理、构建特征(读者可以参考《推荐系统之数据与特征工程》这篇文章了解更多关于数据收集和特征工程相关的介绍)，然后选择合适的推荐算法构建推荐模型，通过对推荐模型进行筛选(根据一定的评估指标，筛选不同的模型或者同一模型选择不同参数，这个过程就是离线评估，读者可以参考《推荐系统评估》了解离线评估，特征作为模型的输入，是受不同模型决定和影响的，不同的模型对特征的数量、形式、缺失值的耐受度等有不同的要求)获得较好的模型，最终为用户进行推荐预测，并提供推荐服务接口。当用户在产品上使用推荐模块时，前端通过推荐接口获取推荐结果并展示给用户，让用户体验到个性化推荐服务。同时我们还需要对推荐算法的效果进行及时评估，不断优化推荐效果，让推荐质量越来越高，满足企业的各项商业化指标(读者可以参考《推荐系统的商业价值》了解细节)，这个过程就是在线评估。

根据上面的推荐业务流程的介绍及每个流程中涉及到的技能和知识点，推荐算法团队一般至少包括如下4类开发人员。

1. 数据处理与特征工程开发人员

数据处理与特征工程人员主要的工作是将推荐算法依赖的数据进行处理，构建合适的特征，供推荐算法使用，通过构建新的特征或者优化已有的特征，让推荐算法获得更好的效果。

不同算法对特征的表现形式、种类、精度、数量等要求是不一样的，因此，特征是强依赖于选择的算法的。特征工程在整个机器学习流程中是非常重要的一环，有很多枯燥、繁杂的工作需要处理，看起来不那么高大上，并且很多特征工程的技巧是需要经验积累的，也是领域相关的(不同领域有自己的一套做特征工程的独特的方法和思路)。特征工程的质量往往直接决定了机器学习的最终效果，在机器学习圈有一句很出名的话很好地说出了特征工程的价值，这句话大致意思是“特征工程的好坏决定了机器学习能力的上限，而算法和模型只是无限逼近这个上限”。

特征工程是一个比较花费人力的工作，虽然跟问题和领域相关，但是有一般的方法思路可供参考。推荐系统是机器学习的一个子领域，非常多的推荐算法(如logistic回归、分解机、深度学习等，这些算法主要用于推荐排序阶段)都需要大量的特征工程获得优质的特征。读者可以参考《推荐系统之数据与特征工程》这篇文章了解更多关于特征构建的细节。

目前绝大多数具备一定用户规模的提供toC服务的互联网公司都有自己的大数据平台(自建的或者租用大数据云平台)，数据处理和特征工程的工作一般会基于大数据平台之上构建，比如主流的Spark分布式计算框架的MLlib库就包含很多特征工程方面的算法，我们可以直接使用，大大减少了开发人员的投入成本，成熟的云平台更是提供了更多更完善的机器学习模型和特征处理方法，如阿里云的PAI机器学习平台就提供一套完善的机器学习解决方案。

2. 推荐算法研究人员

算法研究人员的主要工作是基于产品形态、业务场景、现有数据、计算资源、用户规模、软件架构等约束，设计适合当前阶段的新推荐算法或者不断迭代优化现有老推荐算法，提升算法的各项指标，并最终应用于产品中，促进标的物的分发与转化，提升用户体验，创造更多的商业价值。

算法研究人员需要关注当前学术或者其他公司中关于新技术(如新的算法框架、新的计算范式等)与新(推荐)算法的最新动态，对新的论文进行学习解读，评估在本公司产品中应用的可行性，他们的工作更接近于学术前沿研究，需要对新技术、新动态敏感，并持续跟进。他们一般只负责具体算法的研究和测试，对算法的优缺点、商业价值提供专业建议，具体算法的落地实施、工程实现细节、特殊情况处理等需要借助算法工程实现人员的帮助，最终还需要产品团队的帮助完成算法的产品化。很多大公司的研究院(如微软亚洲研究院)中的员工就属于该范畴。

3. 推荐算法工程实践人员

算法工程实践人员根据算法研究人员的具体工作，理解他们提出的新的算法的原理或者老算法的具体优化策略，并基于公司现有的技术积累(技术栈、相关组件、计算平台等)实现该新算法或者对老算法进行优化。对于新算法，需要封装成模块化、简单易用的组件(比如支持大规模分布式计算、算法稳定收敛等)，最终通过AB测试等工具用于实际产品中，对部分流量(或者部分用户)进行测试，验证算法的效果，效果好就可以拓展到更多的用户规模和场景并逐步取代老的算法体系。如果达不到事先定义的目标，还要跟算法研究人员配合进行优化调整，整个过程是一个闭环迭代的过程。

幸好目前开源生态系统非常丰富，有大量的开源组件和算法框架可供我们选择，比如Spark的MLlib库中就包含ALS矩阵分解推荐算法，基于Python的Surprise推荐算法库，包含非常多的推荐算法(包含KNN、矩阵分解等推荐算法)，基于R语言的recommenderlab推荐算法库，TensorFlow、PyTorch等深度学习框架中也包含部分推荐算法的实现(读者可以参考《深度学习在推荐系统中的应用》第4节，其中有各种深度学习框架及相关的推荐算法库的介绍)。读者可以基于这些框架进行研究和工程实践，Spark和TensorFlow是工业界比较流行的计算平台，作者在自己公司业务中也主要使用这两类开源库，特别是Spark，是主要的基础软件平台，绝大多数推荐算法就是基于该平台结合公司相关产品业务进行深度定制开发的。

推荐系统工程实践不只是实现新推荐算法及优化已有算法，更重要的是按照软件工程的思想将整个推荐系统涉及到的各个环节、各个组件、各个模块构建成模块化、可复用、接口简洁易用的工程体系，方便业务的迭代、优化、问题定位与排查，读者可以参考《推荐系统的工程实现》了解更多的工程实践方面的思路和设计哲学。

4. 支撑组件开发人员

推荐系统是一个复杂的工程应用领域，要想让推荐系统发挥稳定、可靠的作用，除了算法外，需要非常多的其他模块和组件的支持。广义的支撑组件开发人员是开发与推荐系统业务相关的其他组件，比如数据质量治理、任务调度、监控、错误恢复、AB测试平台、在线评估指标、数据转运组件、推荐数据存储组件、推荐Web服务接口等。当然这些复杂的组件和模块的开发职能不一定都放在推荐团队中，部分与大数据相关的能力可以放在大数据团队(如数据治理、在线评估指标，由于大数据与算法的密切关系，实际上很多公司的大数据团队和算法团队是同一个团队，作者公司就是这种组织架构)，部分功能可以放在后端开发团队(比如AB测试平台、推荐Web服务接口等)。

上面介绍的推荐系统涉及到的4类人员是从推荐业务流程中涉及到的具体任务的角度进行的分类，实际推荐系统实施中需要这四类角色，但是这4类角色是否一定是不同的4波人可不一定，这需要根据公司规模、产品所处的阶段、推荐系统在产品中的重要性定位等进行权衡，受到很多因素的影响。

对于像今日头条这类将推荐系统作为核心技术的公司和产品，参与推荐系统开发相关的员工组成一个庞大的团队，这几类角色确实是不同的4个子团队，并且可能分得更细，每类人员可能拆分成更多的小团队，比如特征工程，可能有专门基于文本信息做特征工程的团队，也有专门基于图片、视频等视觉信息进行特征构建的团队。大的推荐团队，每个人可能只是参与或者负责推荐业务流程中很小、很窄的一部分，每个人在整个系统中所起的作用就相当于生产线中的一道工序。每个人就像螺丝钉一样，通过大家协力构建一套庞杂的推荐系统。个人更容易成为某个知识点上的专家，而对推荐系统整体的把握可能就没有那么熟悉。

而对于刚开始构建推荐算法的产品、初创公司等几类刚开始组建推荐算法团队的情况，所有这4类角色可能就是同一个人，他需要解决推荐系统中涉及到的所有问题，面面俱到，构建端到端的推荐解决方案。经过这样的锻炼，他的知识面一定是最全的，但人的精力是有限的，他不可能在所有这些知识点上都做到极致。作者正好经历了这个过程，作者从2012年开始就加入电视猫做大数据与推荐系统，在相当长一段时间(大概2年左右)只有作者一个人做推荐系统相关的开发工作，因此，有机会参与推荐系统全流程开发，后面随着产品的成熟和团队的壮大，有更多的人员加入进来，参与推荐系统的设计、开发、维护。

上面讲的只是与推荐算法实施密切相关的几类开发人员，推荐算法要想在产品中落地，还需要更多团队、更多人的配合，下面一节讲解的就是跟算法团队有交集的其他相关团队的工作介绍及他们对推荐系统落地所起的作用。

二、与推荐系统密切相关的其他团队

推荐系统是一个复杂的体系化工程，因此推荐系统要想产生真正的业务价值还需要更多团队的配合，下面图2从业务流向(类似业务流水线)的角度来切分推荐系统所涉及的各类人员，其中下面的红色虚线框在上一节已经做过介绍，下面自下而上对其他部分涉及的人员及工作进行简单讲解。

图2：推荐系统涉及到的其他团队工作

1. 基础架构团队

图2最下面是基础架构团队，他们构建大数据与软硬件基础设施，基于这些基础设施及组件，推荐算法团队才能更专注地研究、落地推荐算法。

随着大数据技术的发展与成熟，大数据技术对推荐系统起着至关重要的作用。只要是toC的互联网产品，本质就是一种规模化经济，依赖海量的用户通过会员、广告等商业模式来赢取利润。因此，当产品发展到一定阶段，当用户量足够大之后，用户产生的行为数据会非常多，这时必须要用大数据技术来处理这些实时产生的海量数据。大数据技术在推荐中所起的作用主要有三点：一是将推荐依赖的各类数据通过大数据组件进行收集、处理、构建特征存于数据仓库中，解决推荐算法的“原材料”问题(Spark MLlib中包含很多与数据处理与特征工程相关的算子)；二是大数据平台本身是包含巨大算力的，可以为推荐系统提供算力支持(Spark MLlib中就包含ALS矩阵分解推荐算法，并且我们可以基于Spark平台提供的编程接口开发各种推荐算法)；三是很多推荐算法本身是需要利用大数据的，如深度学习推荐算法需要极大的数据量、多维度的数据，才能训练出效果好的模型，另外，很多近实时推荐算法(如今日头条的信息流推荐)是需要实时数据处理技术支撑的。

上面讲的大数据技术本身就是一种软件基础设施，而其他与推荐系统相关的基础设施还包括数据存储、除大数据之外的其他计算平台(如TensorFlow等)、测试环境、虚拟机、容器等。

推荐系统产生的最终推荐结果、中间特征等都需要进行存储，方便推荐各个模块实时调用获取，因此需要数据库的支持。数据库包括传统的关系型数据库(如MySQL等)、非关系型数据库(如Redis、CouchBase等)，这些数据库在推荐系统中有广泛的使用(参考《推荐系统的工程实现》这篇文章相关章节的介绍)。

不是所有的推荐算法都适合基于Spark等大数据平台构建的，典型的如深度学习技术就不适合在Spark平台上开发，这时我们需要搭建其他的计算平台。如果当产品发展到一定阶段，推荐团队又有精力去做复杂的推荐算法研究，这时就需要基础架构团队帮助推荐团队构建其他的计算平台，如流行的TensorFlow计算平台。并且还需要通过一些技巧打通大数据平台与TensorFlow平台之间的数据、流程、业务依赖关系(这主要是因为老的基础设施不可能立马被全部替代，新的平台也很难满足所有的业务需求，因此在很长一段时间内需要两套平台)。是否需要引入另一套平台这个需要做好权衡，在推荐系统业务流程还没有做到非常成熟，作者不建议直接堆砌复杂算法，关于这一点的论述，读者可以参考《深度学习在推荐系统中的应用》第六节相关介绍。

有过软件开发经验的读者对测试环境的重要性是非常清楚的，推荐算法在真正上线之前是需要进行测试的，因此需要测试团队的大力支持。只有具备一套完善、高效易用的测试平台，我们的产品才可以更快地迭代。推荐系统的特点(实时性、个性化、数据量大)决定了它的测试跟一般后端软件系统测试不一样，这也加深了构建完善的推荐系统测试平台的难度，同时也需要更多的测试资源。具体来说，很多产品的推荐算法是实时的，验证测试实时性的动作是比较困难的，推荐系统也是个性化的，每个人的推荐结果是不一样的，测试验证业务逻辑、算法逻辑的正确性更加困难，同时，推荐系统为每个用户生成推荐，需要存储海量的推荐结果，因此需要的测试资源也更多，推荐系统个性化的特性决定了比较难于使用CDN等缓存技术，对推荐系统的高并发测试是必须重视的一环。

推荐系统的web服务需要部署到独立的服务器(一般是虚拟机或者容器)上提供服务，虚拟机、容器等软硬件资源也是基础架构团队需要提供的。

目前伴随着云计算技术的成熟，非常多的行业借助云计算的能力快速发展业务，越来越多的业务上云，这是一个大的趋势。所有上面提到的基础架构能力(包括大数据平台)都可以在主流的云计算平台中找到对应的PAAS或SAAS解决方案。作者在12年开始构建大数据与推荐系统，那时国内还没有一家云计算公司提供大数据相关服务(国内最早的云计算公司阿里云2009年才成立)，因此，我们是自己构建大数据基础架构平台的，这中间遇到很多坑，也出现过很多问题，维护成本极高。因此作者强烈建议，能够用云的尽量用云服务，将专业的事情交给专业的团队做，这样整个推荐系统会更加轻量，将更多的精力放到业务迭代中。

2. 产品设计团队

推荐系统要想发挥业务价值，一定要落地到产品中，成为产品中的一个模块、一个功能点，用户通过使用产品接触到推荐模块，通过与推荐系统交互获取推荐结果，这就涉及到产品团队和设计团队的工作。

个性化推荐在产品中的定位，需要推荐产生什么价值，个性化推荐和人工运营的分工、所占比重及各自的侧重点和价值体现的差异，这些都是从产品角度需要思考的宏观问题。思考清楚了这些问题，剩下的就是推荐业务的落地了，在落地过程中需要思考在产品中哪些路径、哪些模块设置个性化推荐，用户怎么跟推荐模块交互，需要展示多少个推荐标的物，推荐标的物的排列方式，需要展示待推荐标的物的什么信息，在极端情况下(如推荐接口挂掉)的应对策略，这些具体工作都需要产品提前思考情况并制定相应的解决方案。读者可以参考《推荐系统产品与算法概述》第一节中有关推荐产品的介绍，了解更多关于推荐产品形态的知识。这里不得不提的一个重要角色是数据产品经理，它们需要对推荐的效果、推荐的价值发挥、推荐算法的优化从产品维度提供优化的建议，帮助推荐团队一起让算法发挥出最大的商业价值。

上面提到的用户跟推荐模块交互中具体怎么交互，交互分为几个阶段，交互的动画效果，推荐标的物的排列方式中大小、形状、位置关系、跟背景的关系、跟前后左右模块的关系，展示的标的物信息中展示信息的颜色、背景、亮度、不同信息之间的关系、对比度，维护推荐模块与整个产品设计风格的一致性等等这些都是设计师需要思考做决策的问题。读者可以参考《推荐系统的UI交互和视觉展示》这篇文章了解更多与推荐系统UI交互和视觉展现相关的知识。

作者认为即使是推荐算法工程师也需要关注推荐产品与设计相关的知识点，它们所起的左右不亚于好的算法所起的作用，甚至产品形态或者视觉展示的微小调整带来的转化效果提升比得上推荐算法工程师一年辛苦的调参与优化。

3. 运营团队

推荐产品与推荐算法从本质上讲是一种数据化、个性化运营的方法和工具，推荐系统价值的发挥离不开运营团队的支持。当前的运营工作已经从传统的位置化运营进化到数据化运营、用户运营、内容运营、事件运营等丰富复杂的运营策略体系，运营在发展用户、提升用户粘性、促进“标的物”消费、维护“标的物”提供方的生态平衡等各类商业目标中发挥着越来越重要的作用。

推荐系统作为一个工具，是运营手上的一项强有力的武器。推荐系统产品形态、业务逻辑一定要构建得高效灵活，需要并且能够根据运营的阶段性策略和重点事件进行非常容易的调整和改变，具体需要支持的调整包含如下几个方面：

(1) 调整位置与展示

比如调整推荐产品的位置、调整推荐标的物的数量、调整展示风格、甚至调整交互方式等。

(2) 干预具体的推荐结果

比如在推荐结果中插入适当的运营内容，在推荐结果中插入广告，过滤掉满足一定条件的标的物等。

(3) 对算法逻辑的干预

比如对不同标的物推荐比例的要求，对某些标的物提供商的引导(让提供优质标的物的提供商获得更多的机会)等方面的要求。

上述(2)、(3)中涉及到的干预可能以一些规则或者策略的形式提供，推荐团队必须提供一些操作界面、流程、方法等接口，让运营人员的“干预权”可以有效行使。

推荐算法团队还需要提供一定的“素材”供运营团队使用，比如提供标的物在各个维度的排行榜供运营人员进行决策，对标的物进行聚类供运营人员更方便地制作各类专题，提供基于各类标签的标的物关联关系供运营团队按照类别进行运营，提供用户画像能力供运营团队进行精细化用户运营等。

总之，运营团队和推荐团队是一个互相配合的过程，中间也可能存在一些利益冲突，我们需要维护好关系，最终的目的是一致的，最终大家都希望提升用户体验、让用户留下来，产生更大的商业利润。

推荐系统落地过程中还少不了的一个重要角色是项目经理，项目经理全程跟进推荐相关的需求评审、项目排期、项目迭代、项目验收，并对完成的项目进行复盘梳理，总结经验教训等。有了项目经理专业的项目跟踪，对时间进度的把控，推荐业务才能在规定时间内保质保量地完成。

三、推荐团队的目标与定位

组建一个推荐团队是一件费时、费力、费钱的事情(好的推荐算法人员不好找、价格比较贵)，因此，公司管理层决定组建推荐团队一定是期望该团队能够产出价值的。推荐团队的终极价值跟公司的目标是一致的：通过为用户提供有价值的信息、产品、服务，在服务好用户的同时从用户身上获取商业利益(广告虽说是从广告主身上挣的钱，但广告是投向的用户，广告主之所以给你钱，是看上了你的用户价值)。推荐系统通过为用户创造价值并从用户身上获得价值，这是一个价值交换的过程(参见参考文献第二章)。

基于上面的描述，推荐团队肩负提升用户体验、为公司创造商业利润两大核心使命，概括来说，推荐算法团队的目标可以从如下三个角度来理解：

1. 从用户角度，推荐系统期望提升用户体验

推荐系统可以做到千人千面，为每个人提供个性化的内容，因此，可以更好地满足用户的个性化需求。当推荐系统将用户想要的标的物第一时间展现给用户时，用户就不需要自己再去花额外的时间找寻自己想要的标的物了，为用户节省了时间(从经济学角度说，时间就是一种机会成本，因而时间是有价值的，虽然很多用户没有这种意识)。现在非常流行的实时信息流推荐，更是让用户所见即所得，将主动权交给用户，通过简单的滑动操作，获得短期的“奖赏”，让用户沉浸在其中，欲罢不能。

2. 从标的物（提供商）角度说，提升（优质）内容的分发转化

推荐系统能够做到千人千面，当然会将更多的标的物分发给用户。现在很多推荐产品都做到了近实时推荐，这进一步提升了标的物分发的效率，提升了单个推荐位的产出效率。推荐系统的精准性保证了将用户喜欢的标的物展示给用户，这极大地提升了标的物的点击率，促进标的物的购买转化。

在推荐系统中整合一些辅助的运营策略，对优质标的物进行适当的流量支持(第二节3中有提到)，能够提升优质标的物的分发，让标的物提供方获得更多的利润，促进标的物生产的良性循环。

3. 从公司角度说，产生商业价值

如果推荐系统推荐的内容本身是商品或者付费内容(比如付费视频，可以是单个视频付费或者购买会员才能观看该视频)，通过跟用户兴趣的精准匹配，能够促进标的物的售卖，这本身就直接产生了商业价值。即使推荐的标的物是免费的视频、资讯等，也可以通过在推荐的视频中增加前贴片广告、信息流中插入广告等方式获取收益。除了这两种收益方式外，还可以通过付费会员、流量交换等方式获得利润。

当然，公司和产品所处阶段不同，关注的重点会不一样，对于初创公司或者新产品，推荐团队的目标更多地关注前两个，而对于成熟的产品，商业价值可能就成为重点。读者可以参考《推荐系统的商业价值》这篇文章，对推荐系统的商业价值进行更加深入的了解。

作为推荐算法工程师一定要对推荐在产品中的价值有深刻的理解，保持对商业的敏锐嗅觉，并在平时工作中基于该理解不断践行，努力创造价值，只有这样才能在为公司创造价值的同时发挥个人价值、提升个人能力，为自己赢得“地位”和尊重，这本身也是一个价值交换的过程(员工与公司的价值交换，员工的时间及产出就是一种商品，公司通过工资购买了员工的上班时间及这段时间的产出)。

推荐系统作为一个内容分发工具，它优势体现在3个方面：千人千面的内容推荐、极高的内容分发效率、无人干预的自动化决策(推荐)。虽然推荐系统相比于人工推荐有这么多优势，但推荐系统是无法取代人工运营的(在内容安全性等方面目前技术还做不到取代人的程度，这就是为什么今日头条、Facebook等公司有大量的人工编辑审核人员)。推荐系统作为人工运营的一种有效工具和补充，我们需要发挥推荐系统的优势，让推荐更好地产生价值。

推荐团队对自身的定位应该是一种高效的内容分发工具，通过发挥推荐系统的上述三大优势，辅助运营团队更好地进行内容与用户运营，最终完成推荐团队的三大目标。

总结

本文作者介绍了推荐算法团队4类核心人员(数据处理与特征工程开发、推荐算法研究、推荐算法工程实践、支撑组件开发)的主要工作内容及特点，同时介绍了与推荐团队密切相关的其他团队在支撑推荐业务落地过程中需要跟推荐团队的分工与配合，最后介绍了推荐团队的目标与定位，简单介绍了推荐团队的价值与使命。

通过本文的介绍，希望从事推荐算法开发的读者对推荐算法团队的定位，推荐算法团队的工作，推荐算法团队跟其他团队的配合有一个初步的认知，有了这些了解，才可以更高效、更容易、更有目标地开展推荐系统开发的各项工作。

-end-

参考资料