推荐系统从入门到实战笔记

推荐系统从入门到实战

今天在 b 站上找到了一个宝藏视频（推荐系统从入门到实战），看完后做的笔记如下。

1. 推荐系统包含哪些环节

推荐系统一般包含召回（粗排）、排序（精排、计分）和调整（重排）三个过程。

• 召回：它是推荐系统的第一阶段，从潜在的庞大语料库中筛选并生成较小的候选集。给定模型可以有多个召回队列，每个召回队列都筛选出不同类型的候选子集。召回所筛选的子集数据量为万/百万/亿。常见的召回策略：
  • 协同过滤召回
  • 内容相似召回
  • 图算法召回
  • 热门召回
  • 新课召回
• 排序：使用另一个模型对候选集进行评分和排序。所筛选的子集数据量为万/千。常见的排序策略有：
  • 机器学习
  • 二分类算法
    • 逻辑回归（LR）
    • 梯度提升决策树（GBDT）
    • 深度神经网络(DNN)
    • Wide&Deep
• 调整：考虑最终排名的其他限制，如：
  • 删除重复的物品
  • 删除用户已购或已读的物品
  • 删除已线下的物品（有些召回算法以“天”为粒度进行运行，有些物品可能已下线）
  • 删除用户明确不喜欢的物品
  • 提高时效内容的得分或权重
  • 热门补足：有些新用户，用户行为数据较少，涉及冷启动问题，可以使用一些热门物品进行补足
  • 合并内容信息：一般推荐过程中使用的都是物品的ID，这时需要根据物品ID获取物品的详细信息，如：物品名称、价格、图片等
  • 分页提取：对所推荐的物品进行分页

2. 推荐系统有哪些召回路径

上图中的 u, i, tag 都是结点， 2 为边。

• i2i（item to item）是指给用户推荐和用户喜欢的物品相似的物品，可以使用的策略有：
  • 基于内容的召回
  • 基于协同过滤的召回
  • 基于关联规则挖掘的召回
• u2i（user to item）是根据用户的直接行为做召回，如用户的点击、播放、收藏、购买等行为。
• u2i2i（user to item to item）是先基于item的协同过滤或者先得到用户行为列表，然后查 i2i扩展。如上图所示，UserC 购买过 ItemZ ，而根据 i2i 知，ItemY 和 ItemZ 相似，所以将 ItemY 推荐给 UserC。
• u2u2i（user to user to item）是先根据用户画像或者用户聚类等方式找到和目标用户相似的用户，然后将相似用户喜欢的物品推荐给目标用户。
• u2tag2i（user to tag to item）是先收集用户喜欢的物品的 tag ，然后给用户推荐具有该 tag 的物品。

3. Netflix经典的推荐系统架构

Netflix经典推荐系统架构分为在线层、近线层和离线层。其工作过程如下：

• 对用户行为日志的处理：
  • 首先将用户的播放、评分或浏览等行为数据（打点日志）分发至近线层的事件队列和离线层的Hadoop中。
  • 在离线层，Netflix.Hermes（调度平台）会将从HIVE中查询的数据和离线的历史数据用于模型训练和离线计算。
    • 模型训练是对机器学习算法的训练，其输出是一个训练好的模型（模型的参数）。该模型会用于在线计算和离线计算。
    • 离线计算使用离线模型对Netflix.Hermes传来的数据进行离线计算，如：提前预计算用户的推荐列表、做矩阵分解，得到用户向量和物品向量等。离线计算的结果可以用于近线层的使用。
  • 在近线层，可以使用一些机器学习算法对Netflix.Manhattan(流式计算平台)的数据、近线层计算的数据和在线层的输入（如：用户行为）进行计算，并将计算结果输出到高速缓存中。
• 给用户推荐
  • 用户直接调用算法服务，算法服务从高速缓存中获取数据，并调用在线计算。在线计算可以使用在线数据服务中的数据、离线计算中的模型和离线计算中的信号进行计算。
    

架构的挑战：

架构既能处理海量数据，又能及时响应用户交互。

在线层：

• 特点：快速响应，使用最新的数据输入，比如200MS

• 缺点：不能使用复杂的算法，只能读取少量数据

离线层：

• 特点：大部分计算包括模型训练都在这层完成

• 优点：可采用复杂算法、可扫描海量数据

• 缺点：不能对最新情景和新数据做响应，比如天粒度

近线层：

• 特点：离线和在线的折中，一般将结果存入高速缓存

• 优点：

  • 能使用几乎最新数据计算，延迟10秒~1分钟级别
  • 允许更复杂的算法处理，加载查询更多数据

组合使用的例子：

1. 天粒度：离线层做矩阵分解，得到用户向量和物品向量做数据存储MySQL

2. 10秒钟：近线层根据用户行为，查询TOPN相似的物品列表，存入Cassandra

3. 200毫秒：在线层查询第2步骤的结果，更新推荐列表

4. 推荐系统通用架构图（数据流图）

5. 推荐系统如何实现多路召回的融合排序

背景：

• 一般会使用多个召回策略，互相弥补不足
• 每个策略之间毫不相关，一般可以使用多个线程并发执行

问题：

如何将多个召回列表融合成一个有序列表？

案例：

策略：

1. 按顺序展示：比如实时>购买数据召回>播放数据召回，则直接展示A、B、C、D、E

2. 平均法：分母为召回策略个数，分子为权重加和，C为(0.7+0.5+0.3) / 3，B为(0.8+0.6)/3，

3. 加权平均：比如三种策略自己指定权重为0.4、0.3、0.2，则B的权重为(0.40.8+0.60.3+0*0.2)/(0.4+0.3+0.2)

4. 动态加权法：计算X/Y/Z三种召回策略的CTR，作为每天更新的动态加权

   每种召回源CTR的计算方法：

   $$CTR=每种召回的点击数/展现数$$

   如：展现日志-带召回源：X, Y, Z, X, Z, Y

   ​ 点击日志-带召回源：点击 一次 X

   $$CT{R}_x=\frac{1}{2}=0.5$$

5. 机器学习权重法：逻辑回归LR分类模型预先离线算好各种召回的权重，然后做加权召回

6. 如何实现AB测试

6.1 AB 测试的定义

AB测试是一种向产品的不同受众展示 同一内容的2个或多个变体，并比较哪个变体带来了更多转化的做法。AB测试通常用于对测试中的改进版本所产生的效果的好坏不能十分确定。

AB测试是转化率优化过程的重要方法之一，使用它来收集定性和定量的用户见解、了解潜在用户并根据测试结果优化转化渠道。

6.2 为什么需要AB测试

• 想要数据驱动，重点是做AB实验，然后根据实验结果对模型、策略、设计等不断地迭代更新；
• 进行低风险的修改，先在小流量测试，如果没有问题再调大流量；
• 实现数据统计上的重大改进，降低人工猜测、直觉决策的不确定性；
• 怎样证明自己做的好？工程开发职位和算法岗位的重大区分:后者更能用对比数据说话。

6.3 如何实现AB测试

6.4 AB测试的常见错误

• 不要同时运行太多测试：要确定测试的优先级，一起测试太多的元素会很难确定哪个元素对测试的成功或者失败影响最大。
• 合理设置实验流量的大小：流量样本的数据量过小，实验结论不能使人信服；流量样本过大，会增加试错的成本。
• 测试持续时间不宜太短：运行测试时间过短可能造成测试失败或者产生不重要的结果。
• 无法遵循迭代过程：AB测试是一个迭代的过程，每个测试都是基于先前测试的，不管成功或者失败，都不要停止AB测试，要通过测试持续迭代产品。

7. 如何实现用户聚类推荐

7.1 用户聚类推荐

7.2 技术实现流程

1. 特征工程：将用户的人口统计信息使用 one-hot 编码，将用户的行为列表使用 embedding 表示，并将两者拼接在一起，作为聚类算法的输入；
2. 聚类算法：根据输入特征进行聚类，得到的聚类结果（键值对的形式）为：用户ID => 聚类数字，并将该结果缓存起来；
3. 分群热榜统计：将聚类结果（用户ID=>聚类数字）和用户历史日志（用户=>播放记录）做 join 操作，得到热榜结果（聚类数字 => 热榜列表），并将该结果缓存起来；
4. 在线推荐：根据输入的用户ID获得该用户所属的聚类编号，根据聚类编号获取推荐列表。
   

7.3 用户聚类推荐的优缺点

优点：

• 实现简单，spark、sklearn 均有现成接口，数据结果存储量很小，只需要存储用户ID，聚类编号等；
• 可以用于 新用户冷启动，使用用户注册信息、从站外获取用户信息、行为列表做聚类，即可个性化推荐。

缺点：

• 精度不高，群体喜欢的内容，并一定个人喜欢，不够"个性化"。

8. 推荐系统 API 接口长什么样子

8.1 推荐系统的两大场景

• U2I 推荐
  给每个用户推荐个性化的内容，实现“千人千面”，如：首页推荐、猜你喜欢等。
  
• I2I 推荐
  根据用户当前互动的内容，给用户推荐其可能喜欢的内容，一般叫相关推荐。
  

8.2 API 接口要完成的任务

给定某个用户、其所在场景、某个物品，计算该用户在该场景下喜欢该物品的概率。

喜欢的概率 function(用户信息, 环境信息, 物品信息);

• 前端传入：用户ID、环境信息，需要API接口传入
• 后端返回：返回的是按概率排序的TOP N物品
• 后端计算：根据用户ID查询用户信息、物品ID查询物品信息、计算用户对每个物品的喜欢概率

8.3 API 接口设计

整个推荐系统只有一个大接口，通过 HTTP + JSON 的方式对外提供服务。

入参：

• 用户 ID

  设备号、手机号、微信号、QQ号

• 场景 ID

  代表某个页面的某个推荐区块

  比如首页猜你喜欢、详情页相关推荐

• 物品 ID

  相关推荐/相似推荐需要

• 环境信息

  设备平台、网络类型Wifi/4G、地理位置

• 分页参数

  pageidx、size

出参：

• 物品列表

  物品信息，比如标题、价格、封面图

  每个Item的召回算法，可以多个，reltime@cf

• 分桶 ID

  代表某个推荐算法，比如协同过滤、内容推荐、混合推荐等

  前端行为上报打点需要带上该ID，跟踪分桶效果

• 推荐eventid

  跟踪单次推荐的展现、点击等效果

  前端行为上报打点需要带上该ID

• 分页信息

9. 解决物品冷启动问题

9.1 基于内容的推荐

思路：

使用基于内容的推荐，即利用新物品本身的内容属性（如：标题、描述、分类、标签、作者等）来计算其与老物品的相似度，可以将新物品推荐给喜欢和该物品相似的老物品的用户。

9.2 多级流量池机制

思路：

相传为抖音的内容推荐算法，使用多级流量池机制进行推荐，其思路如下：

• 对于新物品，根据其内容属性（如：标题、简介、封面等内容质量；账号粉丝数等评级）来判断该物品是否可以用于推荐（即是否可以进入流量池）；
• 若满足进入流量池的标准，则将该物品放入一级流量池（假设该池中推荐量为500），根据基于内容/标签的推荐，将该物品推荐给500个用户；
• 根据一些评判标准（如：播放率、点赞率、评论率、转发率等）判断该物品是否可以进入下一级流量池；
• 以此类推，若该物品在某级池中不达标，则不再晋升流量池，推荐量也停止；若该物品到达最后一级流量池，则冷启动结束。

10. Embedding

10.1 Embedding 是什么

• 直观上看，Embedding 是一个数组，元素是小数数字

• 物理上看，每个小数代表一个属性强度

可解释的 Embedding：

比如数组第一个元素代表“喜剧”，第二个代表“动作”，用户Embedding：[0.8, 0.3]，含义是：这个人喜欢0.8强度的喜剧，喜欢0.3强度的动作；

电影Embedding：[0.4, 0.6]，含义是：

这个电影0.4的强度是喜剧片，0.6的强度是动作片，余弦函数([0.8, 0.3], [0.4, 0.6])就能算出来这个人喜欢这个电影的程度。这是可解释的embedding

不可解释的 Embedding：

但一般情况下，是用机器学习得到用户/物品的Embedding，这时候每个数值没法解释代表什么“兴趣”。虽然没法解释，这样的“兴趣向量”却可以大量使用，也叫作latent factor、隐因子、隐含兴趣向量

10.2 Embedding有什么用途

Embedding 的用途：

• 物-物推荐
• 人-物推荐
• 人-人推荐

10.3 如何使用数据生成 Embedding

Embedding 的生成方法：

• 基于内容的 word2vec
• 协同过滤矩阵分解
• DNN 深度学习

1. 基于内容 word2vec 的 Embedding
   
2. 协同过滤矩阵分解的方法
   
3. DNN 深度学习的方法
   

10.4 使用 Embedding 有什么技术难题

11. 推荐系统依赖数据源和特征工程

11.1 数据源与数据应用

11.2 推荐系统数据分类

11.3 数据源的特征处理

12. 参考资料

• 推荐系统简明教程-概述 - 刘十三的文章 - 知乎
• 推荐系统从入门到实战