推荐系统三十六式--学习笔记（25-27 常见架构）

参考原作：推荐系统三十六式-刑无刀

25.【常见架构】典型的信息流架构是什么样的

在工程实践的部分中，我首先介绍的内容是当今最热门的信息流架构。信息流是推荐系统应用中的当红炸子鸡，它表现形式有很多：社交网络的动态信息流、新闻阅读的图文信息流、短视频信息流等等。

究竟。整体框架

信息流，通常也叫作 feed，这个英文词也很有意思，就是“喂”给用户的意思。传统的信息流产品知识简单按照时间排序，而被推荐系统接管后的信息流逐渐成为主流，按照兴趣排序，也叫作“兴趣 feed”。所以我们通常提到信息流，或者兴趣 feed，其实都是在说同一个话题。

温馨提示一下：如果要搜索 feed 相关的技术文章，你应该用“Activity Stream”作为关键词去搜，而不应该只用“feed”搜索，Activity Stream 之于 feed，就好比多潘立酮之于吗丁啉，前者是行话，后者是通俗说法。

要实现一个信息流，整体逻辑上是比较清楚的。可以划分为两个子问题。

1. 如何实现一个按照时间顺序排序的信息流系统？
2. 如何给信息流内容按照兴趣重排序？

这张架构图划分成几个大的模块：日志收集、内容发布、机器学习、信息流服务、监控。
这里分别介绍一下：

1. 日志收集，是所有排序训练的数据来源，要收集的最核心数据就是用户在信息流上产生的行为，用于机器学习更新排序模型；
2. 内容发布，就是用推或者拉的模式把信息流的内容从源头发布到受众端；
3. 机器学习，从收集的用户行为日志中训练模型，然后为每一个用户即将收到的信息流内容提供打分服务；
4. 信息流服务，为信息流的展示前端提供 Rest API；
5. 监控，这是系统的运维标配，保证系统的安全和稳定等。

数据模型

信息流的基本数据有三个：用户（User）、内容（Activity）和关系（Connection）。 用户不用说，就是区别不同用户的身份 ID，现在来说一说其他的两种。

1.内容即 Activity

用于表达 Activity 的元素有相应的规范，叫作 Atom，你可以参考它并结合产品需求，定义出自己的信息流数据模型来。
根据 Atom 规范的定义，一条 Activity 包含的元素有：Time、Actor、Verb、Object、Target、Title、Summary。下面详细解释一下这些元素。

1. Time：即“Activity 发生的时间”。
2. Actor：即“Activity 由谁发出的”。通常 Actor 就是用户 ID，但是我们也可以扩展到其他拟人化物体上，如关注的一个“店铺”，收藏的一部“电影”，或者用户喜欢的一个标签或者分类。也就是和用户建立连接的另一端。
3. Verb：动词，就是连接的名字，比如“Follow”“Like”等，也可以是隐含的连接，如挖掘出的用户兴趣词和用户之间这种潜规则。
4. Object：即动作作用到最主要的对象，只能有一个，比如一个人赞过的一张照片，店铺上新的一件商品，一个分类下一篇新的文章。
5. Target：动作的最终目标，与 verb 有关，可以没有。它对应英语中介词 to 后接的事物，比如“John saved a movie to his wishlist”（John 保存了一部电影到清单里），这里电影就是 Object，而清单就是 Target。
6. Title：这个是 Activity 的标题，用自然语言描述，用于展示给用户。
7. Summary：通常是一小段 HTML 代码，是对这个 Activity 的描述，还可能包含类似缩略图这样的可视化元素，可以理解为 Activity 的视图，不是必须的。

除了上面的字段外，还有一个隐藏的 ID，用于唯一标识一个 Activity。社交电商 Etsy 在介绍他们的信息流系统时，还创造性地给 Activity 增加了 Owner 属性，同一个 Activity 可以属于不同的用户，相当于考虑了方向。

2. 关系即连接

互联网产品里处处皆连接，有强有弱，好友关系、关注关系等社交是较强的连接，还有点赞、收藏、评论、浏览，这些动作都可以认为是用户和另一个对象之间建立了连接。有了连接，就有信息流的传递和发布。
定义一个连接的元素有下面几种。

1. From：连接的发起方。
2. To：被连接方。
3. Type/Name：就是 Atom 模型中的 Verb，即连接的类型：关注、加好友、点赞、浏览、评论，等等。
4. Affinity：连接的强弱。

如果把建立一个连接视为一个 Activity 模型的话，From 就对应 Activity 中的 Actor，To 就对应 Activity 中的 Object。连接的发起从 From 到 To，内容的流动从 To 到 From。Connection 和 Activity 是相互加强的，这是蛋和鸡的关系：有了 Activity，就会产生 Connection，有了 Connection，就可以“喂”（feed）给你更多的 Activity。

在数据存储上可以选择的工具有下面的几种：
Activity 存储可以采用 MySQL、Redis、Cassandra 等； Connection 存储可以采用
MySQL； User 存储可以采用 MySQL。

内容发布

用户登录或者刷新后，信息流是怎么产生的呢？我们把内容出现在受众的信息流中这个过程称为 Fan-out，直觉上是这样实现的：

1. 获取用户所有连接的终点（如好友、关注对象、兴趣标签）；
2. 获取这些连接终点（关注对象）产生的新内容（Activity）；
3. 按照某个指标排序后输出。
   上面这个步骤别看简单，在一个小型的社交网络上，通常很有效，而且 Twitter 早期也是这么做的。这就是江湖行话说的“拉”模式（Fan-out-on-load），即：信息流是在用户登录或者刷新后实时产生的。
   这里有一个示意图:

拉模式就是当用户访问时，信息流服务才会去相应的发布源拉取内容到自己的 feed 区来，这是一个阻塞同步的过程。“拉”模式的好处也显而易见，主要有下面两种。

1. 实现简单直接：一行 SQL 语句就搞定了。
2. 实时：内容产生了，受众只要刷新就看得见。

但是也有很大的不足：

1. 随着连接数的增加，这个操作的复杂度指数级增加；
2. 内存中要保留每个人产生的内容；
3. 服务很难做到高可用。

与“拉”模式对应，还有一个“推”模式（Fan-out-on-write），如下图所示：

当一个 Actor 产生了一条 Activity 后，不管受众在不在线，刷没刷新，都会立即将这条内容推送给相应的用户（即和这个 Actor 建立了连接的人），系统为每一个用户单独开辟一个信息流存储区域，用于接收推送的内容。如此一来，当用户登录后，系统只需要读取他自己的信息流即可。

“推”模式的好处显而易见：
在用户访问自己的信息流时，几乎没有任何复杂的查询操作，所以服务可用性较高。

“推”模式也有一些不足：

1. 大量的写操作：每一个粉丝都要写一次。
2. 大量的冗余存储：每一条内容都要存储 N 份（受众数量）。
3. 非实时：一条内容产生后，有一定的延迟才会到达受众信息流中。
4. 无法解决新用户的信息流产生问题。

既然两者各有优劣，那么实际上就应该将两者结合起来，一种简单的结合方案是全局的：

1. 对于活跃度高的用户，使用推模式，每次他们刷新时不用等待太久，而且内容页相对多一些；
2. 对于活跃度没有那么高的用户，使用拉模式，当他们登录时才拉取最新的内容；
3. 对于热门的内容生产者，缓存其最新的 N 条内容，用于不同场景下的拉取。

还有一种结合方案是分用户的，这是 Etsy 的设计方案：

1. 如果受众用户与内容产生用户之间的亲密度高，则优先推送，因为更可能被这个受众所感兴趣；
2. 如果受众用户与内容产生用户之间的亲密度低，则推迟推送或者不推送；
3. 也不是完全遵循亲密度顺序，而是采用与之相关的概率。

在中小型的社交网络上，采用纯推模式就够用了，结合的方案可以等业务发展到一定规模后再考虑。

对于信息流的产生和存储可以选择的工具有：

• 用户信息流的存储可以采用 Redis 等 KV 数据库, 使用 uid 作为 key。
• 信息流推送的任务队列可以采用 Celery 等成熟框架。

信息流排序信息流的排序，要避免陷入两个误区：

1. 没有目标；
2. 人工量化。

   “没有目标”意思就是说，设计排序算法之前，一定要先弄清楚为什么要对时间序重排？希望达到什么目标？只有先确定目标，才能检验和优化算法。
   “人工量化”，也就是我们通常见到的产品同学或者运营同学要求对某个因素加权、降权。这样做很不明智，主要是不能很好地持续优化。

目前信息流采用机器学习排序，以提升类似互动率，停留时长等指标，这已经成为共识。比如说提高互动率则需要下面几个内容:
首先，定义好互动行为包括哪些，比如点赞、转发、评论、查看详情等；
其次，区分好正向互动和负向互动，比如隐藏某条内容、点击不感兴趣等是负向的互动。

基本上到这里就可以设计成一个典型的二分类监督学习问题了，能产生概率输出的二分类算法都可以用在这里，比如贝叶斯、最大熵、逻辑回归等。互联网常用的是逻辑回归（Logistic Regression），谁用谁知道，用过的都说好；也有 Facebook 等大厂采用了逻辑回归加梯度提升树模型（又称 GBDT）来对信息流排序，效果显著。

如今大厂都已经转向深度学习了，但我还是建议小厂或者刚起步的信息流先采用线性模型。
对于线性模型，一个重要的工作就是特征工程。信息流的特征有三类：

1. 用户特征，包括用户人口统计学属性、用户兴趣标签、活跃程度等；
2. 内容特征，一条内容本身可以根据其属性提取文本、图像、音频等特征，并且可以利用主题模型提取更抽象的特征。
3. 其他特征，比如刷新时间、所处页面等。

排序模型在实际使用时，通常做成 RPC（远程过程调用协议） 服务，以供发布信息流时调用。

数据管道

这个管道中要使用的相关数据可能有：

1. 互动行为数据，用于记录每一个用户在信息流上的反馈行为；
2. 曝光内容，每一条曝光要有唯一的 ID，曝光的内容仅记录 ID 即可；
3. 互动行为与曝光的映射关系，每条互动数据要对应到一条曝光数据；
4. 用户画像内容，即用户画像，提供用户特征，具体请见我在第 4、5、6 三篇中的内容；
5. 信息流的内容分析数据，提供内容特征，即物品画像。

对于一个从零开始的信息流，没必要做到在线实时更新排序算法的参数，所以数据的管道可以分成三块：

1. 生成训练样本，可离线；
2. 排序模型训练，可离线；
3. 模型服务化，实时服务；像 Pinterest 早期的管道也差不多就是这样。

在离线训练优化模型时，关注模型的 AUC 是否有提升，线上 AB 测试时关注具体的产品目标是否有提升，比如互动率等，同时还要根据产品具体形态关注一些辅助指标。
另外，互动数据相比全部曝光数据，数量会小得多，所以在生成训练数据时需要对负样本（展示了却没有产生互动的样本）进行采样，采样比例也是一个可以优化的参数。
固定算法和特征后，在 0.1~0.9 之间遍历对比实验，选择最佳的正负比例即可。经验比例在 2:3 左右，即负样本略大于正样本，你可以用这个比例做启发式搜索。

---

26.【常见架构】Netflix个性化推荐架构

工程落地很重要，虽然影响是否用户产品的因素有很多很多，但是能否流畅地给用户提供服务是一个最基本的标准。

架构的重要性

推荐系统向来是一个锦上添花的东西，因此传统的观点是推荐系统更加注重线下的模型效果，而非线上的服务质量。但是你也知道，时至今日，推荐系统不再只是锦上添花，而是承担了产品的核心功能。因此，对推荐系统架构的要求也高了很多：

1. 实时响应请求；
2. 及时、准确、全面记录用户反馈；
3. 可以优雅降级；
4. 快速实验多种策略。

一种更符合经典推荐系统的架构，这就是著名的流媒体Netflix 的推荐系统架构。

经典架构

先整体看一下这个架构，一共分成三层：在线、近线、离线。

可以这样定义这三个层级：

1. 离线：不用实时数据，不提供实时服务；
2. 近线：使用实时数据，不保证实时服务；
3. 在线：使用实时数据，要保证实时服务。

1. 数据流

用户在产品 UI 上使用产品，消费展示的内容，产生行为事件数据，实时地被收集走，一边进入分布式的文件系统中存储，供离线阶段使用，另一边流向近线层的消息队列，供近线阶段的流计算使用。

离线存储的全量数据被抽取出来，组成离线计算所需的训练数据，这些训练数据被一个管理数据生成和发布的组件统一管理，要使用数据的下游，比如模型训练会在离线数据生成时得到这个组件的通知，从而开始训练，训练得到的模型用于进一步为用户计算推荐结果。

离线阶段的推荐结果或者模型在近线阶段被更新，进一步在在线阶段被直接使用，产生最终的推荐结果，呈现给用户。

2. 在线层

在线层的触发时机是当用户发出请求，也就是用户进入一个推荐场景，推荐位等着展示推荐结果时，这个时候需要承担责任就是在线层。在线层就是实时响应用户请求。简单说，在线层的特点就是“使用实时数据，要保证实时服务”。

在线层的优势有：

1. 直接首次接触到大多数最新数据；
2. 对用户请求时的上下文了如指掌；
3. 只需计算必须的信息，不需要考虑所有的信息。

在线层也有严格的制约：

1. 严格的服务响应时间，不能超时，或者让用户等太久；
2. 服务要保证可用性，稳定性；
3. 传输的数据有限。

在线层常常展现出的形式就是 Rest API 形式，后端则通常是 RPC 服务内部互相调用，以用户 ID、场景信息去请求，通常就在 ms 响应时间内返回 Json 形式的推荐结果。那么哪些计算逻辑适合放在在线层呢？

1. 简单的算法逻辑；
2. 模型的预测阶段；
3. 商业目标相关的过滤或者调权逻辑；
4. 场景有关的一些逻辑；
5. 互动性强的一些算法。

在线阶段要处理的对象一般是已经预处理后的推荐结果，是少量物品集合。比如说当用户访问一个物品详情页，需要做相关推荐，那么在线阶段给在线服务的 Rest API 传入用户身份以及当前的物品 ID，实时地取出物品 ID 对应的相关物品 ID，再根据用户信息对这些物品 ID 做一些重拍和过滤，就可以输出了，整个过程都是在 ms 级别完成。如果发生意外，比如说这个物品 ID 就没有相关的物品，那么这时候服务就需要降级，但是不能低于最低要求，这里的最低要求就是必须要返回东西，这就降级为取出热门排行榜返回。这就是服务的可用性。

3. 离线层

讲完在线层，再来看看离线层。离线层就是躲在推荐系统的大后方，批量、周期性地执行一些计算任务。其特点是“不用实时数据，不提供实时服务”。
离线层的示意图如下：

离线阶段主要面对的数据源就是 Hadoop，实质上是 HDFS。收集到的所有日志都存在这里面，是一个全量的数据中心。通过 Pig 或者 Hive 等工具，从全量日志中按照算法要求抽取出不同的数据，再加上其他数据变成了不同算法所需的数据源。

如果这种数据源比较多时，就需要有专门的工具统一管理起来，这个管理上要求：

1. 数据准备好之后及时通知相关方，也就是要有订阅发布的模式；
2. 能够满足下游不同的存储系统；
3. 完整的监控体系，并且监控过程对于数据使用方是透明的。

在 Netflix 内部，承担这个管理任务的工具叫做 Hermes，类似 Kafka，但是又有不同的内部工具。
离线阶段的任务主要是两类：模型训练和推荐结果计算。

离线阶段有以下这么几个好处：

1. 可以处理最大的数据量；
2. 可进行批量处理和计算；
3. 不用有响应时间等要求。当然坏处也是明显的：

同样的有几点短处：

1. 无法及时响应前端需求；
2. 面对的数据较静态，无法及时反应用户的兴趣变化。

大多数推荐算法，实际上都是在离线阶段产生推荐结果的。离线阶段的推荐计算和模型训练，如果要用分布式框架，通常可以选择 Spark 等。

4. 近线层

最后，来讲讲近线层。近线层的特点是“使用实时数据，不保证实时服务”。

虽然这看上去蛮不讲理，但实际上这是一个非常重要的一层，它结合了离线层和在线层的好处，摒弃了两者的不足。近线层，也叫做准实时层，所谓“准实时”，就是接近实时，但不是真的实时。

从前面的架构图中也可以看出，这一层的数据来源是实时的行为事件队列，但是计算的结果并不是沿着输入数据的方向原路返回，而是进入了在线数据库中，得到用户真正发起请求时，再提供服务。

一个典型的近线计算任务是这样的：从事件队列中获取最新的一个或少许几个用户反馈行为，首先将这些用户已经反馈过的物品从离线推荐结果中剔除，进一步，用这几个反馈行为作为样本，以小批量梯度下降的优化方法去更新融合模型的参数。

这两个计算任务都不会也不需要立即对用户做出响应，也不必须在下一次用户请求时就产生效果，就是说当用户实时请求时，不需要去等待近线任务的最新结果，因为两者是异步的。

近线计算任务一个核心的组件就是流计算，因为它要处理的实时数据流。常用的流计算框架有Storm，Spark Streaming，FLink 等，Netflix 采用的内部流计算框架 Manhattan，这和Storm 类似。略有区别的是 Spark Streaming，实际上并不是实时流计算，而是小批量计算。

简化架构

Netflix 是为全球多个国家同时提供在线服务的，因此推荐系统的架构略微复杂。倘若你现在刚刚接手一个新产品，要从 0 开始搭建一个推荐系统，那么可以以 Netflix 的架构作为蓝本，做一定的简化：

关键简化有两点：

1. 完全舍弃掉近线层；
2. 避免使用分布式系统。

在一个新产品的场景下， 当数据量还没有那么大时，使用分布式存储或者计算框架，非常不划算。如果性能不足，请升级单机配置。根据经验，一个几千万用户，几十万到百万的物品的协同过滤或者矩阵分解，如果充分发挥单机的性能，综合效率会远远优于在 Spark 上运行。

以上就是对这个架构的宏观总结对比。如前所说，其实架构都是进化出来的，你千万不必在一开始就追求完美的架构，满足最低要求就好。

---

27.【常见架构】总览推荐架构和搜索、广告的关系

三种信息获取方式

当用户想要从浩如烟海的网页中，找到对自己有用的信息，首选当然是搜索引擎，这是属于“已知的未知”需求，剩下的“未知的已知”和“未知的未知”则需要推荐系统去满足，只是推荐系统常常会出现画蛇添足去满足“已知的已知”这样的伪需求。
另外介于两者之间，还有一种商业化解决信息触达问题，就是广告系统。在线广告从条幅广告，到搜索广告再到社交精准广告，也逐渐形成了一个理念就是：把广告当成一种有用的信息去找到最需要它的人。

三者对比

搜索，推荐和广告本质上都在解决信息过载的问题，各自解决的手段、目标不相同，各自诞生在产品生命周期不同阶段，以至于系统实现也不尽相同。我们从几个维度对比一下：

-	搜索	推荐	广告
信息送达方式	拉	推和拉	推
关注点	内容消费方	内容生产方消费方	内容生产方
是否期待惊喜	否	是	否
是否需要集体智慧	可能	可能	需要
是否需要query	需要	可能	可能
是否依赖上下文	可能	可能	可能

• 搜索更关注内容消费者，搜索要解决的是精确快速找到想要的结果，最重要的目标是降低延迟和提高相关性。搜索引擎是一个效率工具，希望用户找到信息越快越好，而不是希望用户沉迷在搜索引擎中。
• 传统的推荐系统大都是起一个“锦上添花”的作用，一般很少会将其作为核心功能来承载产品。希望用户消费内容，消费越多越好。可以给用户制造惊喜。
• 基于内容的推荐，本质上就是一个小的搜索引擎。例如使用用户的兴趣标签召回推荐结果，就需要先对推荐候选池按照兴趣标签建立倒排索引，从而检索出候选集。
• 广告是一个很特殊的存在，前面也说了，搜索和推荐都是为人找信息，而广告是为信息找人。但它在形式上又像推荐，总是“不请自来”，在技术实现上又兼有推荐和搜索两者特点。

架构抽象

我们抽象一下三者的需求共性：本质上都是在匹配，匹配用户的兴趣和需求（看成 context），但匹配的目标，条件和策略不尽相同。示意图如下：

我们再进一步抽象下去，又可以分为三步：过滤候选、排序候选、个性化输出。

1. 过滤候选

从查询关键字中解析得到查询意图，以及结构化的搜索条件，再用结构化的查询条件从倒排索引中检索出排序候选。与之相似的是广告系统，搜索广告也是查询关键字去检索候选广告，而联盟广告则是拿着用户标签去需求方获取广告候选。

在推荐系统中，一再强调有挖掘、召回和排序三个阶段，其中的召回阶段就是过滤候选阶段，基于内容的就和搜索一样，用标签检索候选，协同过滤则检索出相似物品来，等等。

一种离线阶段的推荐算法对应一种召回策略，为了保证高效地召回，都要建立相应的索引，这样一来，是不是搜索、广告和推荐都离不开过滤候选这一步，而过滤候选就离不开建立索引。

2. 排序候选

候选排序这一步，对于三者来说，主要区别在于排序的目标和约束。搜索的排序目标是高相关性，无论 BM25 为代表的传统排序模型，还是以 Learn to Rank 为代表的机器学习排序皆是如此，把用户每次在搜索上花费的时间是不是更少（而不是更多）来衡量搜索的效果。

通常推荐系统用 CTR 预估来融合召回策略得到的候选集，如果做得深入，还需要考虑探索利用问题。附加的约束则是千变万化。电商中，当天买过的当天就不能再推了，新闻推荐里，重复的新闻不能再推了。某些场景需要推荐搭配，某些场景需要推荐相似，TopN 推荐还需要考虑多样性，序列推荐要考虑前序和后续等等。

广告系统的排序更多是从经济学角度去看，CPC 广告的排序方式是结合预估 CTR、出价、广告质量三者一起考虑。同时还要考虑很多别的因素，尤其是商业因素，平台方的要求，广告主的要求等等，是一个纯动态的博弈。

3.个性化输出

个性化只是推荐系统的衡量指标之一而已，个性化的前提也一定是信息够丰富够垂直才行。搜索的个性化需求相对来说松弛一些，常见的是利用地域等人口统计学体现个性化，而且对于歧义较少的查询关键字，搜索如果太个性化既没意义又有风险。

4.三者的协同

有一部分搜索需求是无法用搜索相关性满足的，比如“一个人的夜晚听什么歌”这样的 query，这就需要推荐系统去满足，交互形式可能是眼下大热的聊天机器人，也可能是流推荐等等。如果能够识别出这样的搜索请求，其实更应该交给推荐系统来响应，这类是看似搜索请求，实际上则是漫无目的。

推荐系统总体上滞后于用户的即时需求，再强大的推荐系统，也要有搜索引擎来与之配合。

• 一方面，搜索因为能够满足用户的主动寻找需求，所以能够化解一些推荐不力不及时的尴尬。
• 另一方面，搜索可以积累用户兴趣数据；当二者结合起来考虑时，可以避免“搜什么推什么”的窘境，整个系统能够综合考虑哪些是即时快速需求，哪些是长期兴趣。

广告系统，在技术上和搜索跟推荐并无本质差异，差异在意图不同，功能不同。对用户的信息需求满足，搜索和推荐离真正得到满足之间总是有一定的鸿沟，要么是信息不足，要么是信息过载，这些鸿沟可以利用经济手段进行调配，这就是广告系统。

---