从0到1实现文章个性化推荐系统

一、背景

    当今互联网信息呈现爆炸式增长，简单的人工筛选、物料召回的运营方式已无法让资源快速变现，通过用户历史行为、用户画像精准推荐用户感兴趣内容已成为必然趋势，主流个性化推荐系统流程包括用户行为采集、分类提取、离线用户建模、在线用户模型预测等。结合目前主流推荐业务发展需求，从无到有搭建一套个性化推荐系统支撑专区App分发业务。

二、主要业务流程及核心模块

    构建一套完善的推荐系统涉及到的主要业务流程及核心模块，具体流程如下图所示：

1. 同步业务数据：

    将文章、用户属性等状态数据，以全量或增量模式从MySQL存储导入到Hive中

2. 收集用户行为日志

(1) 原始数据收集

    数据收集主要通过应用APP或者应用Web埋点或者通过线上任务上报到DataBank来完成，主要收集指标包括：

埋点事件	事件ID
曝光	exposure
点击	click
浏览时长	read
收藏	collect
分享	share

    埋点日志数据结构如下：

{
     
    "actionTime":"2019-04-10 18:15:35",
    "readTime":"",
    "channelId":0,
    "param":{
     
        "action":"exposure",
        "userId":"2",
        "articleId":"[18577, 14299]",
        "algorithmCombine":"C2"
    }
}

(2) ETL

    通过Flume将日志定时并增量收集与结构化存储到 Hive中

3. 构建离线文章画像

文章画像，就是给每篇文章定义一些词。主要包括关键词和主题词。
关键词：文章中权重高的一些词。
主题词：是进行规范化处理的，文章中出现的同义词，计算结果出现次数高的词。

(1) 构建方法

关键词：TEXTRANK计算出的结果TOPK个词以及权重
主题词：TEXTRANK的TOPK词 与 ITFDF计算的TOPK个词的交集

(2) 文章画像存储结构

hive> desc article_profile;
OK
article_id              int                     article_id          
channel_id              int                     channel_id          
keywords                map      keywords            
topics                  array           topics      

hive> select * from article_profile limit 1;
OK
26      17      {
     "策略":0.3973770571351729,"jpg":0.9806348975390871,"用户":1.2794959063944176,"strong":1.6488457985625076,"文件":0.28144603583387057,"逻辑":0.45256526469610714,"形式":0.4123994242601279,"全自":0.9594604850547191,"h2":0.6244481634710125,"版本":0.44280276959510817,"Adobe":0.8553618185108718,"安装":0.8305037437573172,"检查更新":1.8088946300014435,"产品":0.774842382276899,"下载页":1.4256311032544344,"过程":0.19827163395829256,"json":0.6423301791599972,"方式":0.582762869780791,"退出应用":1.2338671268242603,"Setup":1.004399549339134}   ["Electron","全自动","产品","版本号","安装包","检查更新","方案","版本","退出应用","逻辑","安装过程","方式","定性","新版本","Setup","静默","用户"]
Time taken: 0.322 seconds, Fetched: 1 row(s)

(3) 实现步骤

• 合并原始文章表数据，得到所有的词语句信息：包括文章标题、文章频道内容、文章内容
• 计算所有历史文章的TD/IDF，TD/IDF存储结果如下图所示：
  
• 计算所有历史文章的TEXTRANK，存储结构如下：

hive> select * from textrank_keywords_values limit 10;
OK
98319   17      var     20.6079
98323   17      var     7.4938
98326   17      var     104.9128
98344   17      var     5.6203
98359   17      var     69.3174
98360   17      var     9.3672
98392   17      var     14.9875
98393   17      var     155.4958
98406   17      var     11.2407
98419   17      var     59.9502
Time taken: 0.344 seconds, Fetched: 10 row(s)
hive> desc textrank_keywords_values;
OK
article_id              int                     article_id          
channel_id              int                     channel_id          
keyword                 string                  keyword             
textrank                double                  textrank

• 计算文章画像结果
  • 加载IDF，保留关键词以及权重计算(TextRank * IDF)
  • 合并关键词权重到字典结果
  • 将tfidf和textrank共现的词作为主题词
  • 将主题词表和关键词表进行合并，插入表，结果如下：

hive> select * from article_profile limit 1;
OK
26      17      {
     "策略":0.3973770571351729,"jpg":0.9806348975390871,"用户":1.2794959063944176,"strong":1.6488457985625076,"文件":0.28144603583387057,"逻辑":0.45256526469610714,"形式":0.4123994242601279,"全自":0.9594604850547191,"h2":0.6244481634710125,"版本":0.44280276959510817,"Adobe":0.8553618185108718,"安装":0.8305037437573172,"检查更新":1.8088946300014435,"产品":0.774842382276899,"下载页":1.4256311032544344,"过程":0.19827163395829256,"json":0.6423301791599972,"方式":0.582762869780791,"退出应用":1.2338671268242603,"Setup":1.004399549339134}   ["Electron","全自动","产品","版本号","安装包","检查更新","方案","版本","退出应用","逻辑","安装过程","方式","定性","新版本","Setup","静默","用户"]
Time taken: 0.322 seconds, Fetched: 1 row(s)

4. 构建离线用户画像

用户画像，业界有两种截然不同的解释：

1. User Persona，用户角色：Persona是真实用户的虚拟代表，是建立在一系列真实数据之上的目标用户模型。通过调查和问卷去了解用户，根据他们的目标、行为和观点的差异，将他们区分为不同的类型，并从中抽取出典型特征，赋予其名字、照片、人口统计学要素、场景等描述，就形成了一个Persona。用户角色是用户群体属性的集合，不需要指代特定的谁，而是一个目标群体的"特征"组合。
2. User Profile，用户画像：用来描述用户数据的标签变量集合。User Profile主要用来描述单个用户的不同维度的属性，也可以用来描述一个用户群体。应用中主要描述的是User Profile。

    用户画像的核心工作，就是给用户打标签。标签通常是人为规定的高度精炼的特征标识，如年龄、地域、兴趣等。通过从不同维度上对用户进行标签刻画，我们便得到了对用户的整体全貌描述。如下图，一般用户画像的维度主要包括：
    (1) 基础属性：是指较长的一段时间内，不会发生变化(如性别)，或者不频繁变化(如年龄每年增加1岁)的属性。标签的有效期都在一个月以上。
    (1) 用户兴趣：指用户在一段时间内的行为倾向性；比如用户在过去一周内频繁搜索手机相关的信息、查看手机比价等，则推测用户有"手机"类兴趣，这类兴趣随时间变化很快，标签有很强的时效性，我们一般称之为短期兴趣或者商业即时兴趣；如果用户在过去较长一段时间内（比如连续一年或者更久）都比较关注宠物等相关的信息，则推测用户有喜欢"宠物"的长期兴趣。

    不同的业务场景对用户画像的诉求都不一样，我们需要根据自身实际业务需求，构造符合自己业务场景的用户画像体系。但是像基础属性类的数据，比如年龄、性别、学历、婚恋等，则没有必要每个业务都投入人力重复建设。

(1) 构建方法

• 用户基础信息表+用户行为表构建用户画像表
• 构建用户标签库：采集用户行为过程中，已经把用户喜好的内容采集下来了，所以基础标签可以直接使用内容的标签。也就是通过用户喜欢的内容给用户贴标签。所以可将用户点击过、收藏过或分享过的文章的主题词作为用户标签，主题词可从文章画像直接提取。
• 计算每一个主题词对于用户的权重，用户标签权重的计算公式为：用户标签权重 =（用户行为分值之和）x 时间衰减。其中，时间衰减公式为：时间衰减系数 = 1 / (log(t) + 1)，其中 t 为发生行为的时间与当前时间的差。
• 添加用户基础属性到用户画像中，

5. 构建离线文章特征

文章特征包括文章关键词权重、文章频道以及文章向量，我们首先读取文章画像

    文章关键词及其权重已在“文章画像”中通过TEXTRANK求得，本节首先通过word2vec求出文章向量，文章向量可用于计算文章相似度。

• 某频道历史所有文章词向量训练
• 加载该频道word2vec模型，得到每个词的词向量
• 获取文章画像，在文章画像中筛选出权重最高的 K 个关键词
• 将文章每个关键词的词向量加入权重信息，这里使每个关键词的词向量 = 关键词的权重 x 关键词的词向量
• 文章向量=TopK关键词的词向量的平均向量
• 将TopK关键词的权重，作为文章关键词的权重向量
• 将 频道ID, 文章关键词权重向量, 文章向量合并为一列 features，即文章特征

6. 构建离线用户特征

• 将每个频道内权重最高的 K 个标签的权重作为用户标签权重向量
• 特征元组第一个元素 即为用户ID，第二个元素是长度为N(频道数)的用户频道标签权重列表，列表中每个元素是长度为 K 的用户标签权重列表，代表用户在某个频道下的标签权重向量。

7. 多路召回

召回层：负责从数以百万的物品中快速地找到跟用户兴趣匹配的数百到数千个物品
排序层：负责对召回的物品打分排序，从而选出用户最感兴趣的top K物品

(1) 不同场景常用召回方案

    召回层在为排序层缩小排序范围的同时，也决定了推荐效果的上限。如果召回的内容不够准确，再厉害的排序模型也无法返回一个准确的推荐列表给用户。因此召回层很重要。常用的召回方法可以分为基于内容的召回和基于行为的召回。两种召回方法各有自己的优缺点，相互补充，共同提升召回的质量。
    目前，不同场景下可选用不同的召回方法：

• 用户冷启动（前期点击行为较少情况）
• 非个性化推荐
  • 热门召回：自定义热门规则，根据当前时间段热点定期更新维护人点文章库
  • 新文章召回：为了提高新文章的曝光率，建立新文章库，进行推荐
• 个性化推荐
  • 基于内容的协同过滤在线召回：基于用户实时兴趣画像相似的召回结果用于首页的个性化推荐
• 后期离线部分（用户点击行为较多，用户画像完善）
• 建立用户长期兴趣画像（详细）：包括用户各个维度的兴趣特征
• 训练排序模型
• 离线部分的召回
  • 基于模型协同过滤推荐离线召回：ALS
  • 基于内容的离线召回：或者称基于用户画像的召回

(2) 基于模型的离线召回：ALS

• 读取用户历史点击行为，构造训练集数据，其中只需要包括用户 ID、文章 ID 以及是否点击
• 通过Spark ALS模块，训练得到结果：针对每个用户的<文章ID，评分>结果列表

(3) 基于内容的召回

• 获取用户历史(对于离线召回) 或者指定时间窗内(对于在线召回)点击过的文章
• 获取与之相似度最高的 K 篇文章
• 根据历史召回结果进行过滤，防止重复推荐

8. 排序

排序主要分为精排和粗排2个阶段，二者主要的区别在于候选集的量级不一样，粗排输入候选集在1千级别，精排只有1百级别。候选集的数量差异决定了粗排在性能上要求会更高，因此在特征上只能选取粗粒度、区分度较高的少量特征，而模型侧也只能选择线性模型，或者复杂度较低的深度模型。粗排其他部分的工作和精排比较类似，这里着重介绍精排。

    精排阶段需要对粗排候选池中的ItemList进行打分，这个分数是针对每个用户对候选文章点击概率的预测，即Ctr预估。业务中每天有千万级别的活跃用户，这些用户的每一次刷新、点击、转发、点赞带来了海量的真实数据，我们需要利用这些海量日志来进行模型训练以建模用户的喜好。

(1) CTR预估-业界主流排序模型

• 业界主流排序模型
• 宽模型 + 特征⼯程
  • LR/MLR + 非ID类特征(⼈⼯离散/GBDT/FM)
  • spark 中可以直接使用
• 宽模型 + 深模型
  • wide&deep,DeepFM
  • 使用TensorFlow进行训练
• 深模型
  • DNN + 特征embedding
  • 使用TensorFlow进行训练

(2) 通过LR(逻辑回归)模型进行CTR预估

• 读取用户点击行为表、用户画像、文章画像，构造训练样本
  • 目标值：clicked
  • 特征值
    • 用户画像关键词权重：权重值排序TOPK，这里取10个
    • 文章频道号：channel_id, ID类型通常要做one_hot编码，变成25维度(25个频道)
    • 文章向量：article_vector
    • 合并特征向量(channel_id1个+用户特征权重10个+文章向量100个+文章关键词权重) = 121个特征
• 点击率预测结果
• 模型评估-Accuracy与AUC

9. 推荐中心

• 流量负载均衡
  • 我们可以根据用户 ID 进行哈希分桶，将流量切分到多个桶，每个桶对应一种排序策略，从而对比不同排序策略在线上环境的效果。
• 推荐数据多级缓冲
  • 优先读取 Redis 和 Hbase 中缓存的推荐结果，若 Redis 和 Hbase 都为空，则调用在线排序服务获得推荐结果。
• 兜底补足（超时截断）
  • 当调用排序服务无结果，或者读取超时的时候，推荐中心会截断当前请求，直接读取 Redis 中的热门文章和新文章作为推荐结果。
• 合并信息
  • 合并物品基础信息，将包含完整信息的物品推荐列表返回给客户端。

10. 参考文献

1. https://www.jianshu.com/u/ac833cc5146e