如何构建个性化推荐的系统架构？

我们先简单描述个性化推荐的基本概念，再结合一个具体的案例场景来描述典型的个性化推荐系统是如何构建的。

个性化推荐的概念

个性化推荐目前可以查到的最早的记录，是 1995 年 3 月，卡耐基·梅隆大学的罗伯特·阿姆斯特朗（Robert Armstrong）等人在美国人工智能协会上提出的个性化导航系统 Web Watcher；斯坦福大学的马可·巴拉巴诺维奇（Marko Balabanovic）等人在同一会议上推出的个性化推荐系统 —— LIRA。

当然，在这之前，传统的“非个性化”推荐，例如编辑精选、热门榜单、店长推荐、超市折扣货柜等，在不同的行业和领域，早就得到了广泛的应用。

这些“非个性化”推荐，主要由领域专家结合领域知识和对整体用户群体的理解，来给全体用户的一个推荐。当然，这种推荐容易受到马太效应1影响，导致给所有人的推荐结果千篇一律，同时由于推荐的结果数量也有限，所以容易埋没优质的长尾素材。

随着科学技术的进步，特别是数据采集手段的丰富，在信息（例如用户行为数据）足够丰富（甚至过载）的情况下，可以考虑使用个性化推荐系统，来帮助用户快速发现对自己有价值的信息，做到推荐结果千人千面，提高获取信息的效率，解决“非个性化”推荐中的一些问题，从而最终达到提升用户体验的目的。

架构实现

我们以一个具体的短视频个性化推荐的实际案例，来看一下典型的个性化推荐系统是如何实现的，如图 1 所示。在这个案例中，客户使用了神策分析的数据采集方案来采集用户行为与用户 Profile 数据，并且推荐系统基于神策分析的相应 API 和 PaaS 类型接口，共用计算与存储资源。

下面，我们依次对架构图中的各个层级进行相应的说明。

首先是数据层。在这个项目中，个性化推荐所需的基础数据共由两部分组成，按来源可分为神策分析系统数据与外部数据。

其中，用户的行为数据与用户的部分 Profile 数据天然地存储在神策分析系统中，这些数据格式规范，各业务间属性关联完备，为后续的数据计算工作打下了坚实的基础。

但是，神策分析系统作为一款用户行为分析产品，目前本身并不持有客户的 Item 数据，所以需要额外提供推荐候选 Item 数据并商定其更新方式。而之前在个性化推荐业务上的一些积累，比如用户标签体系、分类体系等，也会对后续的数据建模等工作具有指导意义。

另外，除了用户相关数据与 Item 相关数据，对于某些其他的应用，有时候也需要开发爬虫抓取第三方数据，例如，在进行小说推荐的时候，就可以通过爬虫抓取一些第三方网站的小说评价数据，当然，在这个短视频推荐的案例中，暂时没有用到爬虫。

上述的两部分数据有实时流计算和批量计算两种计算方式。其中，在实时流计算时，可直接从kafka订阅数据，而批量计算则是对已落盘至 HDFS 上的数据进行处理。

数据层之后是策略层。策略层本身又分为两层，一为基础数据计算层，紧随其后的是更加直接决定个推业务效果的召回与排序。由数据层汇总的数据，经过简单的 ETL，被抽象为 User、Item 和 Event 三张表，这些表构建起了整个短视频产品的数据集市。在此基础上，我们可以轻易地进行各项数据分析，特征工程，以及部分召回源的索引构建工作。

策略层中有召回和 排序 两个关键要素。

其中召回决定了对每一个用户的个性化推荐的候选短视频集合，它可能有多种来源与方法。例如，在这个案例中，我们已实现了诸如 CF（Collaborative Filtering， 协同过滤）、SVD（Sigular Value Decomposition，奇异值分解）、HMF（hybrid matrix factorization，混合矩阵分解）、Item 2 Vec，当然还有最简单的人工规则与现在热议的DNN（Deep Neural Networks，深度神经网络）等模型（方法）。同时，对于这些数据，我们根据产品的实际需求，分别按照优先级和具体比例完成了多召回源之间的组合，以便在确保召回源丰富的同时，控制合理的召回数量，保证前端在线服务的效率。

而个性化推荐的排序则比较复杂，其目标并不只是考察推荐结果的相关性，还要看真实的业务场景与产品形态结合，以确定排序的目标。

通常，我们采用 CTR 预估来融合各种召回策略得到的候选集，但在不同的业务场景中，需要不同的降权或过滤处理。例如，电商类的个推需要过滤已购买的 Item，加强相关而非相似 Item 的推荐；而新闻视频类，则需要做内容去重，根据不同主题的特点，借助主题模型优化多样性或进行时效性加权。除了简单的策略规则排序，在这个案例的迭代过程中也尝试过单（机器学习）模型、融合模型（GBDT + LR，GBDT + FM）和深度模型。它们各有特色，单模型高效可解释性强，但特征工程较为复杂；深度模型端到端的特点，大大简化了特征工程的工作，但可解释性较差，不容易在模型上后续调优。在实际的应用中，需要针对具体需求来挑选最适合的模型。

对线上服务召回策略的变更与排序模型的修改，都需要通过实验分流平台来建立一组A/B 测试。在这个案例中，这些 A/B 测试充分借助了神策分析系统的强大的分析能力，来实时对比流量效果，灵活响应，靠数据驱动来迭代业务升级。而最终的推荐Item，也都记录了其在产品中的路径，可以追溯其召回来源。