洋码头推荐系统技术架构

电子商务网站的推荐系统是根据用户的兴趣特点和购买行为，向用户推荐其感兴趣的信息和商品的一个系统，在主流电商平台均具有广泛应用。从 16 年开始，洋码头根据自己的业务场景，自研了一套推荐系统，为客户提供个性化的商品推荐。本文介绍洋码头推荐系统的技术架构。

本文约 4200 字，可参阅下面的大纲阅读。

1. 数据架构与数据流

2. 推荐系统流程

3. 综合模块介绍

3.1 用户画像

3.2 商品画像

3.3 基础数据

3.4 召回

3.5 重排与算法模型

3.6 线上排名系统

4. 小结

1. 数据架构与数据流

这里主要讲数据平台相关模块，以及数据流向。数据怎么来，到哪里去，最终达到了什么效果。底层数据平台主要是 Hadoop 相关的大数据架构。

图 1 - 数据架构图

如上图所示，数据从 APP 日志中收集后，经 Flume 持久化到 HDFS。Flume 是 Cloudera 提供的一个高可用的、高可靠的、分布式的海量日志采集、聚合和传输的系统，HDFS 是 Hadoop 底层的一个文件系统，可以看到与其他数据库和计算任务均有紧密交互。

数据流向上看，有的日志数据直接走 Flume，有的则走 Kafka。Kafka 是一种高吞吐量的分布式发布订阅消息系统。从离线和实时性上看，Flume 这条路径的数据主要是离线的收集与录入，数据经 ETL 到最终落地到数据库，可能是每小时更新一次，比如我们的流量表数据更新即是如此。另一条路径则从 Kafka 经 SparkStreaming 直接到数据库，是实时数据的收集与处理。在推荐系统的依赖数据中，有一些用户的实时的行为数据就是如此获得。

推荐系统计算功能模块主要分为离线计算部分和在线服务部分。

离线计算主要是离线生成数据和模型，比如离线定时计算用户和商品的偏好度、商品的统计信息等，把结果存放到数据库，供在线服务使用。按时间级别主要分为分钟级、小时级和天级的计算任务。
在线服务部分主要是利用数据库中的一些结果，实时计算出用户最终将看到的商品的部分。

在图 1 中可以看到，离线计算部分主要与数据库交互及生成各种数据及算法模型，在线服务部分则应用算法模型及生成的数据产生线上的最终推荐结果，即用户在 APP 中看到的商品排名等。

2. 推荐系统流程

从系统流程上来说，我们的推荐系统跟业界主流一样，主要也分为两个阶段：召回阶段和重排阶段。

所谓召回阶段，在商品推荐中，主要是从数百万商品中先按一定的方式挑选出一些候选集合，目的是完成商品的初步筛选。
所谓重排阶段，主要是对候选集进行更加复杂和精确打分，目标是得到一个更小的用户可能最感兴趣的目标列表。

图 2 - 推荐系统流程图

如图 2 所示，整个流程分为了四个阶段：

第一阶段数据源，数据经过加工，主要生成用户画像与商品画像。
第二阶段召回，可以按照各种条件召回许多商品，也可以按模型召回。
第三阶段重排，会使用更精准的条件和模型。
第四阶段即是最终排名，这里会应用各种其他业务规则与策略。

在召回和重排上，进一步也可以有线上召回、线下召回，线上重排、线下重排等区别，具体与某一个推荐场景中使用的技术和最终实现有关。举例来说：某个购物车页面商品的推荐，线上并没有应用过多的策略规则，而是直接查数据库获得推荐的结果 (数据库中的结果是某个离线的推荐算法生成的，但是离线生成这个结果时也有召回阶段)。

每一阶段都会有许多事情可做，且可以分解出许多模块。下面就每个具体模块做些细分介绍。

3. 综合模块介绍

图 3 - 综合模块图

洋码头推荐系统包含多个综合模块，在图 3 中并未划分层级，这是刻意的，因为特征工程即可以产生模型应用于召回，又可以产生模型应用于重排。又比如有的模块是偏算法的，有的是偏数据的，有的是偏工程的。而召回可能又是图 2 中的第四阶段中线上服务在做的事情。大家只要知道一个推荐系统中会有许多模块。当然，为了方便理解，下文描述中还是增加了一些层级。

3.1 用户画像

用户画像主要是用户的基础属性、用户行为、用户的兴趣内容偏好等，是个性化推荐的基石。用户画像不只是应用于推荐系统，也用在搜索个性化、DMP 用户标签制作等许多其他方面。

一般来讲，用户画像主要可以分为静态属性类和用户行为类。

静态属性类主要是性别、年龄、地域、城市等相对固定的基础属性，不用从行为日志中获取，可以直接从 SQL 等数据库中获取，注册用户会有一些更详细的信息。
行为类是会动态变化的比如短期浏览品牌类目的次数、品牌类目的偏好等等，也经常单独称为用户行为，主要通过埋点等手段获得用户操作记录，经日志收集和处理后生成，非注册用户也会有一些行为，但是没有注册用户的一些详细信息。

按应用层级划分，我将我们的用户画像分两级：基础层级和特征工程层级。

3.1.1 基础层级

基础用户画像，各种场景中均会使用，比如线上召回。在最开始我们上模型之前，我们使用的就是这套基础的用户画像。

按行为时间可以简单分为中长期画像和短期、实时画像。

长期画像是按用户长期的历史行为计算用户的品牌、品类等偏好（数据跨度较长，比如一个月）。
短期画像的数据跨度较长期画像要短很多，通常为小时级或者天级
实时画像是实时或近实时计算的用户的短期兴趣偏好和实时行为，生成和更新方式上可以简单理解为有个 Java 程序，一直在跑。

3.1.2 特征工程层级

基础画像经过后处理，增加特征及特征编码就构成了特征工程画像。比如基础画像中没有搜索词，为了丰富特征，我们会从其他数据源加入搜索词。

在我们“千人千面 1.0”的特征工程中，用户行为的画像按时间粒度划分，有实时的、小时的、当天累积、天级的、7 天、30 天和长期的。

首先在推荐系统中，用户画像直接应用于线上服务的召回，其次在特征工程中应用于与商品画像作匹配，与推荐目标画像做交叉、特征组合等等。

目前行为实时画像有部分由 SparkStreaming 等从 Kafka 读取日志处理生成后存于 Redis、Mongo 供后续使用。

3.2 商品画像

按不一样的推荐目标，会构造不同目标的画像。在洋码头的场景中，直播推荐、商品推荐、买手推荐、页面内容推荐、视频推荐、信息流等等这些都是推荐目标。有的目标是跟商品直接相关的，有的目标是文本内容相关的。本文主要以商品推荐为例。

商品画像主要也分两类，静态和动态。

静态属性特征，如商品的品牌、类目、核心词、价格等。
动态统计特征，如商品的点击率、Rankscore、DSR 等。

商品画像与用户画像做交互是特征工程的目标之一。

3.3 基础数据

推荐系统会依赖许多基础数据，比如我们的 Rankscore、消费等级、类目价格偏好、用户之间的相似与聚类、商品之间的相似与聚类等。

用户和商品的向量化表征是深度学习的一块试验田，也是算法工程师比较感兴趣的一块。

这些数据会广泛地应用于召回、不同的特征工程、不同的算法模型中。

3.4 召回

除了规则和用户画像召回外，我们还包含了多个通道的召回模型，比如协同过滤、主题模型内容召回、GBDT 树模型的召回、神经网络召回等等。

3.5 重排与算法模型

算法模型的重点在这一块，因为算法越是复杂，需要的计算资源和开发成本就越高，如果商品太多，可能复杂的模型算不过来。我们的“千人千面 1.0”中使用的 CTR 预估的算法方案，应用了比如逻辑回归算法模型，同时对应一个复杂的离线和在线的特征工程。

3.5.1 特征工程

不同的算法会有不同的特征工程的版本，所谓特征工程就是把用户画像、商品画像及相关数据结合起来，生成一份喂给目标算法的数据的工程，比如目标算法是协同过滤，特征工程的一大块就是在生成一个用户对商品的偏好矩阵。

重排中应用的逻辑回归模型对应的特征工程是相对较复杂的，目前只做到了千万特征级别，但是随着业务和数据的演进，这套架构到亿级别特征还是不成问题。

3.5.2 模型训练

模型训练的目标是产生模型，用于线上预测。我们会按一定的时间周期更新模型。针对不同的模型，会用不同的工具和训练方式。这部分内容我们后续会撰文详细介绍。

3.5.3 评估系统

评估主要有不同的维度和视角，有业务目标、算法目标、算法模型的评估和系统的评估等等。

评价推荐系统的常用指标分线下和线上来看，线下做离线实验，线上做 AB 测试。

整个系统有系统的评价指标，具体不同的算法有不同的指标，比如订单支付页使用的 FPGrowth 做的关联推荐，它只是整个推荐系统的一部分，不同的栏位的业务目标还不一样，有的栏位重点击，有的重转化。

线下主要有模型训练相关的指标和模型效果相关指标及系统效果相关指标。

就我们的 LR 逻辑回归模型来讲，是个二分类问题，训练指标如分类问题的 AUC、Log-Loss、RMSE、F1Score 等常用的。同时还有相关指标计算时的细化，比如按商品 ID 或用户 ID 进行聚合及筛选样本处理后的指标等。参照业界的案例及 Paper 使用一些常用的其他辅助指标，如 NE、Group-AUC 等。

系统效果相关指标有一些是常用的，比如多样性、惊喜度、新鲜度等，有一些是自定义的，比如集中度，用户触达分析等，许多时候要写一些统计脚本与任务去监控一些指标。

线上主要指标是 CTR/CVR、订单数、GMV、相关转换率等等。