Fork me on GitHub

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

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

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

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

究竟。整体框架

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

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

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

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

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

  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),即:信息流是在用户登录或者刷新后实时产生的
    这里有一个示意图:

fan-out.jpg

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

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

但是也有很大的不足:

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

与“拉”模式对应,还有一个“推”模式(Fan-out-on-write),如下图所示:

fan-out-on-write.jpg

当一个 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 的推荐系统架构。

经典架构

Netflix架构.jpg

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

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

  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. 离线层

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

offline.jpg

离线阶段主要面对的数据源就是 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 的架构作为蓝本,做一定的简化:

Netflix简化架构.jpg

关键简化有两点:

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

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

Netflix三层架构对比.jpg

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


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

三种信息获取方式

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

三者对比

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

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

架构抽象

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

搜索&推荐&广告.jpg

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

1. 过滤候选

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

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

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

2. 排序候选

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

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

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

3.个性化输出

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

4.三者的协同

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

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

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

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

常见架构.jpg


-------------本文结束感谢您的阅读-------------

本文标题:推荐系统三十六式--学习笔记(25-27 常见架构)

文章作者:小火箭

原始链接:https://www.xiemingzhao.com/posts/9d49d40e.html

许可协议: 署名-非商业性使用-禁止演绎 4.0 国际 转载请保留原文链接及作者。