“个性化推荐”到底何方神圣？本系列主要研讨人工智能背景下的个性化推荐系统，这是本系列第一篇：“如何从0到1搭建一套个性化推荐系统？”，之后将持续分享和探讨个性化推荐系统的优化思路和实践。

先来看看一个完整的推荐系统所需模块，核心包括内容源、内容处理、用户挖掘、算法、推荐搜索引擎、ABtest系统。本文将逐一介绍推荐架构的各个模块。

第一，大量级可推荐内容，即推荐的SKU

个性化推荐的本质是提升信息筛选的效率，如果信息量级小个性化意义不大（比如一个视频网站每天只能产生10条新闻，再怎么个性化也只是在这10条内循环，对用户来说没有差别），个性化推荐的SKU至少是千级或万级，而且理论上来说，优质内容越多、类别分布越广泛，个性化推荐效果越好。

这些内容可以是抓取的无版权内容、UGC、版权合作PGC等多种来源，由于来源不同，样式和质量可能千差万别，因此通常需要做内容抓取、清洗、转码等以保证样式统一，还可能需要用户管理体系、反垃圾等配合搭建内容生态。个性化推荐系统各家可能是相近的，推荐的内容不同就产生了不同的用户场景和产品壁垒。内容，本质是一种资源。

第二，用户行为日志收集、传输、挖掘、存储

推荐的基础是数据，前两步挖掘了内容数据，第三步就是挖掘用户行为生成用户画像。

采集：通常采用前端埋点的方式，上报用户的点击、分享、收藏等等行为。日志采集是数据挖掘非常重要的环节，如果采集又缺失或错误（很可能的事），那么后续不管怎么做都没有效果，同时前端的改动也可能影响日志，如果不有效协同，会对后端有很大影响。

传输：用于用户兴趣的收集往往越快越好，这样用户的某个操作就能快速反馈到下一步推荐中，所以就需要日志的稳定传输和更新，但由于成本考虑，用户profile不是都能实时更新的，有的可能延时1小时，有的可能1天1更、一周1更，甚至更久。

挖掘：这一过程是将用户数据计算、挖掘处理成我们想要的特征（俗称“用户画像”，业内通常叫用户profile），用户挖掘通常要与算法结合，而不能凭空挖特征，没有算法应用再牛逼的用户画像也是没有价值的。

存储：用户的兴趣在一段时间内不会变化太大，因此可以用用户长期留下的行为来积累用户画像，并需要把这些profile存起来。如果用户量很大，那么需要的存储资源也是海量的，那就需要一个能对大量数据进行分布式存储的数据库，并且需要可靠和廉价，例如hdfs（Hadoop Distributed File System），如果想要实时计算用户兴趣，就需要可快速存取的数据库比如redis，所以购买服务器也是微博、今日头条等公司很大的开支。

当然用户的兴趣不是一成不变的，因此用户兴趣需要随时间“衰减”，设置合理的衰减系数，对用户profile也很重要。

除此之外，用户行为挖掘还有一个历史性难题——用户冷启动，这个话题我们需要单起一篇文章探讨。

第三，内容的标准化处理

第一步内容已备齐，接下来是把内容处理成机器和算法可理解的特征（比如分类、标签、产品库等）。具体怎么处理要看业务需求，需要的技术：如果是文章、新闻、微博等，就需要自然语言处理；如果是图片、视频，就会涉及到图像识别和处理；如果是歌曲、电影、商品等，机器直接理解内容来打标签难度比较大，最好能建立一套用户打标签的机制，或者通过人工填写或抓取的方式打标签。

但不管什么内容，首先都要建立一套自己的标签体系，这是定义标准的过程，比如要给电影打标签，先定义一下有多少种电影，通常标签体我们系会是一个树状或网状结构；其次可能都要收集大量训练样本，比如要实现给图片打标签，首先需要人工标注上万张图片，供机器学习，标注的样本还要不断更新，这里面涉及到大量重复繁琐的人力劳动。所以圈内人经常开玩笑说，“人工智能”重点其实是“人工”。

第四，排序算法

前三步有了内容和用户的数据，第四步可以用算法对两者做match了。个性化推荐本质是在做Top N ranking，通常包括“召回”和“排序”两个模块。举个例子，如果我有10万条信息，但是用户每天可能只能看10条，那么推荐哪10条给用户呢？我可以把这10万条从1-10万排个序，这样用户不管想看多少条，我只要从我排的10000个序里从前往后挑就可以了，这个过程就是“排序”；但这种排法在实时索引中计算量太大，可能会带来较高延时，那么我们先用某种相对简单的方法从这10万中选相对靠谱的1000，再对这1000排序，10万选10000的过程就是“召回”。

算法方面门道很多，之后会单起一篇文章，详细介绍目前推荐系统常用的、最有效的算法。此外，不管什么算法都需要使用内容推荐之后的“动态指标”（比如ctr），但没推荐之前我们如何获得这个动态指标呢？这里涉及到内容的冷启动问题，也会之后单独讨论。

第五，ABtest系统

ABtest系统虽不是个性化推荐系统的必需模块，但没有ABtest的推荐系统一定是个假的推荐系统！推荐系统的优化实际上就是一个y=f(x)，y是目标函数，首先目标函数一定要十分明确，且是可量化的指标；f(x)是选用的算法、算法特征参数、算法调度等等组成的，其实业界通过有效的算法一直是那么几个，算法原理也就是那么几个，但如何结合自己的产品场景选择特征、参数，就成了个性化推荐精准度的关键因素。如果有ABtest系统，那么我们可以尝试带入多种参数、特征，ABtest实验得出最佳的y，这样推荐系统就可以不断迭代、优化。

当然，算法的优化不是改改参数这么简单，做推荐的人需要要对数据十分敏感，并能将复杂问题抽象到可量化的指标上，再结合ABtest实验快速迭代。我总结的算法优化的过程是：“数据分析发现问题、合理假设、设计实验、实现、数据分析、得出结论或新的假设”，不断循环反复。其中改改参数只是“实现”那一步，也是最简单的一步，而往往多数人只重视“实现”，却对分析和假设的过程重视程度太低，这样优化的效果是没有保障的，还有些产品、技术人员会陷入盲目ABtest的误区，漫无目的的尝试，经常做ABtest发现AB组数据没有任何差别，甚至产生了ABtest效率低的想法。这些分析思路便拉开了算法工程师之间的差距。

第六，推荐搜索引擎

怎么还有搜索引擎？是的，你没看错。实际上个性化推荐和搜索是非常相似的领域，两者都是信息筛选方式，也都是在做一种“相关性”rank，目标函数都是很接近的（点击率）。只不过搜索更注重用户当下搜索关键词的相关性，而推荐更注重内容与用户profile的相关性。用户每一次浏览都是一次实时请求，因此需要实时计算当下最符合用户兴趣的内容，这一步就是在线搜索引擎承担的。但由于性能要求，在线索引这步不宜做太耗时的计算，一般是排序算法计算了初始结果，在线引擎做算法调度和归一化排序，此外在线索引还会承担接收请求、输出数据、曝光点击排重等服务，通常还会承担业务和产品需求的二次排序（比如插入广告、打散同类型内容等）。

总结

有了这6部分，一个完整的个性化推荐系统就已经搭建起来了，整个体系里涉及到算法工程师、自然语言处理/图像处理工程师、服务端工程师/架构师、数据挖掘工程师、数据分析师、产品经理，还需要大量标注审核人员、内容运营，此外还会涉及到前端、客户端技术等的支持。因此想做一个好的个性化推荐系统耗费还是比较大的，但有时候我们并不需要一个系统，可能一些简单的规则就可以实现相对个性化、提升用户使用效率（比如把用户最近浏览过的商品放在前面），因此提升效率的思维和方法才是最重要的，这也是我们需要长期探讨的内容。