《推荐系统实践》是“项亮”著的、较为出名的一本关于推荐系统的书籍。出版时间是2012年，距离今天已经很远了。 目前看了一点，觉得还不错，适合推荐系统入门者。这里将书中的重点内容做笔记并记录于此。

关于作者

根据推荐系统实践作者介绍，项亮， 毕业于中国科学技术大学和中国科学院自动化所，研究方向为机器学习和推荐系统。

2009年参加Netflix Prize推荐系统比赛获得团体第二名，且于当年发起创建了Resys China推荐系统社区。

1.1 什么是推荐系统

1. 从庞大物品中找到用户喜欢的东西，实现这个功能的工具，就是推荐系统。

   更精简的论述：推荐系统就是自动联系用户和物品的一种工具。

   关键词：自动，联系，用户和物品

2. 应用推荐系统需要满足的条件：

   1. 信息过载 (information overload)
   2. 用户需求不明确

   如果信息不过载，没必要做推荐；如果用户需求明确，通过搜索效率更高。

3. 信息获取工具的演进：分类目录 $\rightarrow$ 搜索引擎 $\rightarrow$ 推荐系统;

   其中

   • “分类目录”就是导航页，基本被淘汰
   • 搜索引擎的需求见顶

   搜索引擎和推荐引擎在功能上一定程度上是互补的。（但将二者结合到1个APP里，是否就是产品上的最优呢？）

1.2 个性化推荐系统的应用

1. 应用场景：

   • 个性化广告，无处不在；

     “广告算法工程师”就是做这个的！

     个性化广告技术可以分为3种：

     1. 上下文广告：基于观看的物料推送广告，代表案例谷歌的Adsense

     2. 搜索广告：基于query推送广告，代表案例是百度凤巢广告系统

        百度最开始的“竞价排名”系统，应该不算是个性化广告。

        插一句，从人为的“竞价排名”，到算法驱动的个性化广告，是否能通过“算法没有价值观”的论调（来自张一鸣大佬）， 洗清导致“魏则西”同学悲剧的罪恶呢？

     3. 个性化展示广告：基于用户兴趣推送广告，代表案例太多了，各种Feed里都会有学Python的广告
   • 电子商务，如亚马逊，淘宝；

   • 电影和视频，如Netflix, Youtube, 抖音；

     大名鼎鼎的Netflix Prize推荐系统比赛，对推荐系统发展起到了重要推动作用；

     Youtube模型，不得不读的经典!

     抖音，算法驱动的超级APP（但个人觉得内容质量也是关键）。

   • 音乐，如Last.fm, QQ音乐的个人电台；
   • 阅读/图文资讯，如Google Reader, 今日头条
   • 社交网络，如Facebook, 脉脉；

   • 基于位置的服务，如美团

     美团的餐馆推荐，总是会考虑位置信息；

   • 个性化邮件

     1. 文献中能查到的第一个推荐系统Tapestry就是个性化邮件系统（ 应该是2004年，paper），它完成对基于用户个性化的邮件排序
     2. Gmail在2010年推出了优先级收件箱功能

2. 推荐系统的3个组成部分

   1. 前端页面：复制展示推荐效果，设置推荐反馈，埋点传输日志
   2. 后台的日志系统（还可以+报表系统）：记录推荐系统的反馈，展示推荐指标
   3. 推荐算法系统：基于日志训练、评估；产出结果供前端展现

1.3 推荐系统评测

1. 推荐系统有3个参与者： a. 用户（消费者） b. 内容提供方（生产者） c. 平台（推荐系统运营者）
2. 好的推荐系统，要实现3者共赢！

3. 准确度预测是推荐系统最重要的指标，它好算；但预测准确不见得就是好的推荐。

   例子：用户本来想买《C++ Primer》，这时推荐系统推荐了，最终用户买了；那么算是预测准确。

   但是： a. 对用户，用户本来就想买，推荐没有新颖性 b. 对内容提供方，潜在地减少了卖出其他书的机会 c. 对平台，因为未使用户、内容提供方受益，他们可能流失

   极端例子： 预测明天太阳从东方升起，虽然100%准确，但无意义。

   不过我想，在实际中，推荐系统能够做到足够的准确性，肯定是非常有必要的。

1.3.1 推荐系统实验方法

1. 实验方法一般有3种，分别是 a. 离线实验(offline experiment) b. 用户调查(user study) c. 在线实验(online experiment)

2. 离线实验的一般步骤：

   1. 从日志中获取用户行为数据，并据此生成1个标准数据集
   2. 将数据集按照一定规则分为训练集、测试集（或者是训练、开发、测试）
   3. 确定离线评估指标和计算公式
   4. 基于评估指标，在训练集上训练推荐模型，（在开发集上选择，）在测试集上验证

3. 离线实验的优缺点：

   优点	缺点
   不需要有对实际系统的控制权（不需要与实际系统交互）	无法计算商业上的关心的指标（如点击率，转化率）
   不需要用户参与实验	离线指标与商业指标有差距/差别
   迭代速度快，一旦数据集构建完成，可以方便、简单地测试大量算法

   讨论：关于其中的“无法计算商业上关心的指标”，这点是否成立呢？
   反对：很对离线评估指标不就是基于用户点击数据来做的吗，怎么算不到点击率、转化率呢？
   支持：离线指标，算的还是“是否点击”准确率啊？当然我们得到模型后，可以在一批数据上，基于模型的预测结果来计算点击率， 但是这个结果有什么意义呢…… 它虽然看起来像“点击率”，但是是“模型预测的这批数据上的点击率”，而不是商业上关心的 这个模型跑起来后实际的点击、转化率。所以，它的确没法计算商业上的指标的。

4. 用户调查的意义：

   1. 离线实验的效果与线上有差异，直接上线上实验可能有风险（比如导致用户满意度下降）或效率太低，需要引入用户调查，做效果进一步保证
   2. 用户主观感受的指标（如惊喜度），只有通过用户调查获得

5. 用户调查的一般步骤：

   1. 挑选用户：尽可能保证测试用户（做调查的用户）和真实用户分布相同（如性别、年龄、活跃度等维度）
   2. 定义规范：需要告诉测试用户如何评估
   3. 保持双盲：不让实验人员、测试用户知道哪个是实验组、哪个是对照组
   4. 准备&分发数据：准备评估数据，分发给用户
   5. 收集调查，统计结果

6. 用户调查的优缺点：

   优点	缺点
   相较直接上线，可以更低风险地确认离线实验效果	成本太高
   获取涉及用户主观感受的指标	受限成本，调查用户规模小，结论可能无统计意义*
   	用户标注标准很难统一
   	用户在测试环境和真实环境的行为可能有所不同

   * 用户调查时，一方面要控制成本，一方面要尽可能保证结果的统计意义

7. 在线实验(AB测试，ABTest，小流量)的一般步骤：

   1. 将用户随机分组，一组用户对应一份流量的分配；为了保证实验间互不干扰，各组间最好正交
   2. 选取2个组，一组为实验组，一组为对照组；两组的设置应该仅在实验部分有差异
   3. 让实验运行一段时间
   4. 最后统计实验、对照组的线上指标，确认实验效果

   其中，需要特别注意的点：为了让实验、对照组仅在实验部分有差异，防止某个组使用的系统的其他部分被其他实验影响， 应该保证流量的切分入口是统一的！ 即任何人想对系统的任何部分做实验，必须从统一的流量池中获取流量。

   在实现ABTest系统时，一般需要3个关键组件：

   1. 用户分组系统：1个用户固定分到某组；所有用户均分到各组； 一般是hash来做

   2. 实现实验、对照逻辑的实验模块： 一般，各模块基于用户的分组，确定是走实验逻辑还是对照逻辑。

      我以前天然的以为，走实验、对照应该是由1全局中控来实现的。但实际上，看起来一般还是各个模块自己去实现流量划分。

   3. 日志报表： 行为日志包含用户的组号；报表基于用户组号来统计数据。

8. 在线实验的意义：

   1. 可以获取实验在线上的实际性能指标，包括离线实验、用户调查无法获取的商业指标
   2. 通过AB测试，可以明确实验的确切收益

9. 在线实验的优缺点：

   优点	缺点
   可以公平获得算法在线时的性能指标，包括商业关注的指标	周期比较长
   	AB测试的设计、DEBUG是一项复杂工程

10. 通常，1个新算法要上线，需要完成上面的3个实验：

    1. 通过离线实验，证明在一些离线指标上优于已有算法，或者有新增收益
    2. 通过用户调查，确认新算法的用户满意度不低于已有算法
    3. 通过在线AB测试，确定在商业指标上由于已有算法

1.3.2 评测指标

1. 用户满意度

   是从用户这一个维度，评估推荐系统效果。

   没法离线计算，只能通过用户调查或者在线实验获得。

   用户调查时，需要设计调查问卷。调查问卷需要精心设计，因为“满意”常常难以简单地二分：可能满意部分，不满意另一部分； 因此，调查问卷需要尽可能涵盖多个满意级别，但是又要尽量保证简单、好选。

   在线实验时，一般通过统计用户行为来得到。一般地，可以通过点击率、用户停留时长、转化率等来衡量。 例如，在电子商务场景，用户对推荐商品的购买率，就可以一定程度反应用户的满意度。 此外，也可以通过设置反馈界面来显式地得到用户满意度的反馈。 例如，推荐物品页面上，常常有“不感兴趣”，“喜欢”等按钮来供用户选择、反馈。