互联网智能推荐系统架构设计.docx

互联网智能推荐系统架构设计.docx

《互联网智能推荐系统架构设计.docx》由会员分享，可在线阅读，更多相关《互联网智能推荐系统架构设计.docx（14页珍藏版）》请在冰豆网上搜索。

互联网智能推荐系统架构设计

互联网智能推荐系统架构设计

一，题记

58同城智能推荐系统大约诞生于2014年（C++实现），该套系统先后经历了招聘、房产、二手车、黄页和二手物品等产品线的推荐业务迭代，但该系统耦合性高，难以适应推荐策略的快速迭代。

58同城APP猜你喜欢推荐和推送项目在2016年快速迭代，产出了一套基于微服务架构的推荐系统（Java实现），该系统稳定、高性能且耦合性低，支持推荐策略的快速迭代，大大提高了推荐业务的迭代效率。

此后，我们对旧的推荐系统进行了重构，将所有业务接入至新的推荐系统，最终成功打造了统一的58同城智能推荐系统。

下面我们将对58同城智能推荐系统展开介绍，首先会概览整体架构，然后从算法、系统和数据三方面做详细介绍。

整体架构首先看一下58同城推荐系统整体架构，一共分数据层、策略层和应用层三层，基于58平台产生的各类业务数据和用户积累的丰富的行为数据，我们采用各类策略对数据进行挖掘分析，最终将结果应用于各类推荐场景。

二，数据层

主要包括业务数据和用户行为日志数据。

业务数据主要包含用户数据和帖子数据，用户数据即58平台上注册用户的基础数据，这里包括C端用户和企业用户的信息，帖子数据即用户在58平台上发布的帖子的基础属性数据。

这里的帖子是指用户发布的房源、车源、职位、黄页等信息，为方便表达，后文将这些信息统称为帖子。

用户行为日志数据来源于在前端和后台的埋点，例如用户在APP上的筛选、点击、收藏、打电话、微聊等各类操作日志。

这些数据都存在两种存储方式，一种是批量存储在HDFS上以用作离线分析，一种是实时流向Kafka以用作实时计算。

三，策略层

基于离线和实时数据，首先会开展各类基础数据计算，例如用户画像、帖子画像和各类数据分析，在这些基础数据之上便是推荐系统中最重要的两个环节：

召回和排序。

召回环节包括多种召回源的计算，例如热门召回、用户兴趣召回、关联规则、协同过滤、矩阵分解和DNN等。

我们采用机器学习模型来做推荐排序，先后迭代了LR、FM、GBDT、融合模型以及DNN，基于这些基础机器学习模型，我们开展了点击率、转化率和停留时长多指标的排序。

这一层的数据处理使用了多种计算工具，例如使用MapReduce和Hive做离线计算，使用Kylin做多维数据分析，使用Spark、DMLC做大规模分布式机器学习模型训练，使用theano和tensorflow做深度模型训练。

三，应用层

再往上就是应用层，我们通过对外提供rpc和http接口来实现推荐业务的接入。

58同城的推荐应用大多是向用户展示一个推荐结果列表，属于topN推荐模式，这里介绍下58同城的几个重要的推荐产品：

猜你喜欢：

58同城最重要的推荐产品，推荐场景包括APP首页和不同品类的大类页，目标是让用户打开APP或进入大类页时可以快速找到他们想要的帖子信息，这主要根据用户的个人偏好进行推荐。

详情页相关推荐：

用户进入帖子详情页，会向用户推荐与当前帖子相关的帖子。

该场景下用户意图较明显，会采用以当前帖子信息为主用户偏好信息为辅的方式进行推荐。

搜索少无结果推荐：

用户会通过品类列表页上的筛选项或搜索框进入品类列表页获取信息，若当前筛选项或搜索条件搜索出的结果较少或者没有结果，便会触发推荐逻辑进行信息推荐。

此时会结合当前搜索条件的扩展以及用户偏好信息进行推荐。

个性化推送（Push）：

在用户打开APP前，将用户感兴趣的信息推送给他们，促使用户点击，提高用户活跃度。

这里包含推送通知的生成和推送落地页上帖子列表的生成两个推荐逻辑。

值得一提的是推送是强制性的推荐，会对用户形成骚扰，因此如何降低用户骚扰并给用户推荐真正感兴趣的信息尤为重要。

Feed流推荐：

我们的推荐产品在某些推荐场景下是以Feed流的形式展现的，例如APP消息中心的今日推荐场景、推送落地页场景。

用户可以在这些页面中不断下拉刷新消费信息，类似时下火热的各大资讯Feed流推荐。

推荐系统是一个复杂的工程，涉及算法策略、工程架构和效果数据评估三方面的技术，后文将分别从这三方面介绍58同城推荐系统。

四，算法

推荐涉及了前端页面到后台算法策略间的各个流程，我们将推荐流程抽象成如下图所示的召回、排序、规则和展示四个主要环节：

召回环节即使用各种算法逻辑从海量的帖子中筛选出用户感兴趣的帖子候选集合，一般集合大小是几十到上百。

排序即对候选集合中的帖子进行打分排序，这里一般会使用机器学习排序模型，排序环节会生成一个排序列表。

规则环节即我们可能对排序列表采取一定的规则策略，最终生成一个包含N条结果的列表。

例如在规则环节我们可能会采取不同的去重策略，如文本去重、图片去重、混合去重等，可能会采取不同的列表打散策略，可能会迭代产品经理提出的各种规则逻辑。

由于推荐系统的最终评价是看统计效果，因此各种人为的规则都会影响最终结果，我们抽象出规则环节后便可以对任何逻辑做线上ABTest，最终评价相关逻辑是否合理。

生成N条推荐结果列表后，不同的前端展示方式也会影响最终的推荐效果，例如不同的UI设计，采用大图模式还是小图模式，页面上展示哪些字段都会影响用户在推荐列表页上的点击，因此在推荐产品迭代过程中不同的展示样式迭代也很重要。

在上述的四个环节中，召回和排序是推荐系统最重要的两个环节。

规则和展示样式一般变化周期较长，而召回和排序有很大的挖掘空间，会被不断的迭代，我们的推荐算法工作也主要是围绕召回和排序进行。

下图是我们推荐算法的整体框架，主要包括基础数据的计算以及上层的召回策略和排序模型的迭代。

基础数据计算主要包括用户标签和帖子标签的挖掘，这部分工作由用户画像、搜索和推荐多个团队共同完成，最终各团队共享数据。

基于用户注册时填写的基础属性信息和用户行为日志，可以挖掘出用户人口属性和兴趣偏好信息，如用户的年龄、性别、学历、收入等基础属性，用户感兴趣的地域商圈、二手房均价、厅室、装修程度等偏好信息。

帖子标签挖掘包括提取帖子的固定属性、挖掘衍生属性以及计算动态属性。

固定属性直接从帖子数据库提取即可，如分类、地域、标题、正文、图片、房源价格、厅室、小区等。

我们还会基于贴子信息是否完备、价格是否合理、图片质量好坏、发帖人质量等多个维度来计算帖子质量分。

基于用户行为日志数据可以计算帖子的PV、UV、点击率、转化率、停留时长等动态属性。

这些数据最终会在召回环节和排序环节使用，例如基于用户标签和帖子标签可以进行兴趣召回，将用户标签和帖子标签作为特征迭代机器学习模型。

召回主要负责生成推荐的候选集，我们采用多种召回源融合的方式来完成该过程。

我们先后迭代了如下各类召回策略：

热门召回。

基于曝光和点击日志，我们会计算不同粒度的热门数据。

以二手车业务线为例，从粗粒度到细粒度的数据包括：

城市下的热门商圈、商圈下的热门车系和品牌、特定车系和品牌下的热门车源等。

每一个车源的热度我们通过最近一段时间内帖子的PV、UV、CTR等指标来衡量，这里的CTR会通过贝叶斯和COEC做平滑处理。

热门召回策略会在冷启动时被大量采用。

地域召回。

58同城是向用户提供本地生活服务类信息，用户的每次访问都会带上地域信息，如选择的城市、定位的地点等。

我们主要结合地域信息和热门数据做召回，如附近最新或最热帖子召回、城市热门帖子召回等。

兴趣召回。

基于帖子基础属性字段和帖子标签信息，我们构建了一套帖子检索系统，通过该系统能够以标签或属性字段检索出最新发布的帖子。

在用户画像中，我们计算了每个用户的兴趣标签，因此基于用户兴趣标签便能在检索系统中检索出一批帖子，这可以作为一种召回源。

此外，在帖子详情页相关推荐场景中，我们也可以利用当前帖子的属性和标签信息去检索系统中检索出相关帖子作为召回数据源。

这两种检索召回其实就是我们常说的基于内容的推荐。

关联规则。

这里并非直接采用传统Apriori、FP-growth关联规则算法，而是参考关联规则思想，将最近一段时间中每个用户点击所有物品当做一次事务，由此计算两两物品之间的支持度，并在支持度中融入时间衰减因子，最终可以得到每个物品的topK个关联性强的物品。

这种召回方式其实类似协同过滤中的item相似度矩阵计算，我们主要将其应用在详情页相关推荐中。

协同过滤。

我们使用Spark实现了基于User和基于Item的批量协同过滤计算，由于数据量大，批量计算会较消耗时间，我们又实现了基于Item的实时协同过滤算法。

通常情况下我们会直接将用户的推荐结果列表作为一种召回源，而在详情页相关推荐场景，我们还会使用协同过滤计算出的Item相似度矩阵，将帖子最相似的topK个帖子也作为一种召回源。

矩阵分解。

我们引入了SVD算法，将用户对帖子的点击、收藏、分享、微聊和电话等行为操作看作用户对帖子进行不同档次的评分，从而构建评分矩阵数据集来做推荐。

DNN召回。

Google在YouTube视频推荐上使用了DNN来做召回，我们也正在进行相关尝试，通过DNN来学习用户向量和帖子向量，并计算用户最相近的topK个帖子做为召回源。

上述不同的召回算法都产生出了一部分推荐候选数据，我们需要将不同的召回数据融合起来以提高候选集的多样性和覆盖率，这里我们主要使用两种召回融合策略：

分级融合。

设置一个候选集目标数量值，然后按照效果好坏的次序选择候选物品，直至满足候选集大小。

假设召回算法效果好坏的顺序是A、B、C、D，则优先从A中取数据，不足候选集目标数量时则从B中取数据，依次类推。

我们的系统支持分级融合策略的配置化，不同召回算法的先后顺序可以灵活配置。

这里的效果好坏顺序是根据离线评价和线上评价来决定的，例如离线我们会比较不同召回算法的召回率和准确率，线上我们会比较最终点击或转化数据中不同召回算法的覆盖率。

调制融合。

按照不同的比例分别从不同召回算法中取数据，然后叠加产生最终总的候选集。

我们的系统也支持调制融合策略的配置化，选择哪些召回算法、每种召回算法的选择比例均可以灵活配置。

这里的比例主要根据最终线上点击或转化数据中不同召回算法的覆盖率来设置。

召回环节新召回源的添加或者新融合策略的上线，例如开发了一种新召回算法、需要修改调制融合策略中的配比等，我们都会做线上ABTest，最终通过比较不同策略的效果来指导我们的迭代。

值得一提的是，召回环节我们还会有一些过滤规则，例如过滤低质量帖子、在某些特定场景下对召回算法产生的结果加一些条件限制等。

排序环节我们主要采用Pointwise方法，为每个帖子打分并进行排序，通过使用机器学习模型预估帖子的点击率、转化率和停留时长等多指标来做排序。

早期我们主要优化点击率，目前我们不仅关注点击率外还会注重转化率的提高。

在58同城的产品场景中，转化主要指用户在帖子详情页上的微聊、打电话操作。

排序离线流程主要包括样本生成和选择、特征抽取、模型训练和评价。

首先对埋点日志中的曝光、点击、转化和停留时长等数据做抽取解析，如基于曝光序列号关联各类操作、解析埋点参数（例如日志中记录的实时特征）、解析上下文特征等，并同时打上label，生成模型样本。

然后对样本进行过滤，例如过滤恶意用户样本、过滤无效曝光样本等。

然后对样本做特征抽取，生成带特征的样本，我们主要从用户、帖子、发帖人和上下文四个维度做特征工程。

之后，按照一定正负样本比例做采样，最终进行模型训练和评估，离线评估指标主要参考AUC，离线效果有提升后会进行ABTest上线，逐步迭代。

我们先后迭代上线了如下排序策略：

规则序。

早期未上线机器学习模型时，对候选集中的帖子会直接使用刷新时间、统计CTR或者一些产品规则来做排序。

单机器学习模型。

我们最早实践的是LR模型，它是线性模型，简单高效、可解释性好，但对特征工程要求较高，需要我们自己做特征组合来增强模型的非线性表达能力，早期我们使用LibLinear来训练模型，后来迁移到了Spark上。

之后我们引入了XGBoost树模型，它非线性表达能力强、高效稳定，是目前开源社区里最火热的模型之一，最初我们采用单机版