知乎Feed流的架构演进.doc

1、1知乎 Feed流的架构演进2我们每天都在刷知乎、刷微博、刷 Twitter，推文一条接一条地从你的指尖流过，信息就这样被你获取了。可你有没有想过背后支撑着这信息流的技术是怎么样的呢？什么是 feed 什么是 feed？你现在手机上的知乎、微信、微博等 App 中就存在着 feed。不太严谨地划分，用户获取信息的方式可以分为 Pull 和 Push，即“拉”“推”。再详细一些，用户主动去获取、并且明确指定自己希望获取的信息的过程是 Pull，而在不明确表述自己的信息需求的情况下，被动接受信息的过程是 Push。举个例子：一个人走到图书馆，按照字母表找到某一本书，获取这本书的内容，可以看作是主动

2、寻找信息；当这个人坐到电视前，他并不知道可能会有什么内容出现，这可以看作是被动接受内容。feed 从英文翻译过来是【投喂；供给；满足】的意思，feed 流产品形象地将用户等待接受信息的场景描绘为用户被信息“投喂”。feed 流在中文里可以翻译为“信息流”。如果将 feed 描述为一个信息准备被投喂，那么 feed 流则是多个准备投喂的“信息”像流水线一样按照一定规则排列好。feed 的特点 现在，当大家讨论 feed，一般来说会特指一列可以不断向下滑动不断加载的信息列表。feed 具备以下几个特点： 使用简单，主要操作只有点击、向下滑动加载。3 信息量大，每个 feed 条目都是一个独立的信息

3、。 兼容性好，可以在 feed 中展示文字、图片、视频、甚至是可操作的卡片。它被大量地应用在不同领域的不同应用上，也成为了用户上网消费大量内容时，最熟悉的交互模式。feed 流产品的发展历史 feed 流是一个非常笼统的说法。在我看来，将一类信息按照一定规律进行排序就可以称为 feed 流产品。由于其同时兼顾了大量信息下的展示与消费，如今 feed 流产品越来越被大多数互联网产品所使用。早期互联网中，门户网站上一列列的文章标题，可以算作最早的 feed。由编辑筛选，每个人看到的都是一致的内容。随着媒体式的中心化发声方式从线下纸媒，理所当然般继承到了互联网上，不论中美，在最初的互联网世界上都出现

4、了许多门户巨头。此时门户主页可以看作是最原始的 feed，这个时候并没有后来流行的“订阅”及“个性化”等信息分发方式，所有人接受到的信息是相同的。互联网上基于“订阅”的个性化 feed 开始被较大规模使用是从 RSS（Really Simple Syndication，一个互联网信息来源格式规范）开始的。在 Web 时代，每个站点会独立发布消息。由于网站数量的爆发式增长，RSS 协议开始被用户用来订阅独立站点发布的消息，这样，用户可以在一个 RSS 阅读器上看到所有订阅站点发布的消息，而不需要再去不同的网站接受信息。4从 RSS 阅读器开始，这种“持续更新不同来源的信息，并呈现给用户的信息组织

5、形式”也就正式拥有了“feed 流”的名字。而接下来，随着互联网的发展，“订阅”行为已经不再局限于 RSS 协议这个媒介。一系列产品的出现，开始允许用户以极低的成本发布信息，并非常容易的在一个产品中关注其他发布信息的人，比如：Facebook、Twitter、微博、知乎、微信的朋友圈等。由于 feed 流产品可以将所有订阅的信息源（信息创作者 / 信息类型 / 信息发布者等）发布的信息汇集到一个地方，同时按照一定的规则排序展示出来，大大提高了用户接受信息的效率，这也就成为了这些产品的主要消费场景。随着互联网产品和技术的演进，将 feed 的使用成本再次降低。之前主流的 feed 大都依赖“订阅

6、”这一关注关系实现，而此时可以在取消了关注行为后，直接根据用户的信息消费历史，使用数据挖掘的手段，计算使用者可能对哪些内容感兴趣，从而进行 feed 生成。这将 feed 的使用成本再次降低，使用者的门槛变得无比之低，越来越多的产品开始向此方向尝试，例如 YouTube、Facebook、知乎。总的来说，feed 中的内容来源有以下几种： 由少部分人发布。 基于订阅行为获取。 由机器计算。当然，也可以是他们 3 者的任意混合所组成。5feed 流排序规则演进 最开始 feed 是一类信息按照一定规则排列，上面讲述了 feed 的来源与发展，那么排序规则同样存在这个“进化”的过程。最初的 fee

7、d 是编辑按照人主观的意识，来决定不同文章的排序，就像编辑一本杂志，所有人会看到相同的内容与序列。在“订阅”行为变得普及以后，不同的人由于订阅内容的不同，会有完全不一样的 feed 流产生，显然这时不会再有编辑为每一个人排序。在各种类型的信息订阅产品中，信息的时效性都是一个比较重要的考量，一个最简单也是比较符合使用者需求的做法是：把所有订阅的内容按照时间倒序排列，将最新生产的内容展示给用户。早期的 Facebook、微博、知乎，现在的微信朋友圈皆是如此。而当用户订阅数量突破一个阈值时，订阅所产生的内容量会远远大于用户可消费的量，如果此时仍然按照时间倒序排列，显然是一个非常低效的做法：用户最关心

8、的信息并不一定是最新产生的信息。帮助用户把最可能有价值的信息筛选出来则可以大大提高消费效率。所以有人在 feed 排序中引入了“排序算法”。排序算法在初期是非常简单且粗暴的： 认为来自某些高价值订阅源的信息更重要提升排序中的权重； 认为带有图片的文章对用户更有吸引力提升排序中的权重； 认为. 提升排序中的权重。6也就是全靠主观判断，觉得哪些地方重要就提升权重。第二阶段，会根据用户的行为动态地调整内容权重，不再是全靠产品运营者拍脑袋决定。比如你经常点击某个订阅源生产的内容，给某些文章点赞，评论一些人的回答等等。因为具体产品形态不同而产生不同的各种交互行为都在暴露你的喜好，甚至不点击任何内容也是一

9、种反馈信号。但即使是在第二阶段中引入了用户行为作为排序的依据，却依然有产品运营者在对各种行为下主观判断，这种主观判断是否和用户的真正需求匹配？根本无从分析。而随着产品复杂度的提高以及用户量及分发量的急剧扩大，越来越多的信息开始被收集到：内容的长度、视频阅读时间、包含的链接、好友有没有读过、跟你比较相似的用户是否喜欢看、标题中的关键字等等，人类大脑没有办法为如此多的变量设定一个权重，将排序交给“机器学习”来进行则是一个必然的结果。做好 feed 的关键要素是什么？ 快：新生产的内容能第一时间出现在 feed 流中 准：尽量推荐和用户的兴趣、调性相关的内容 优：保证内容优质，过滤掉谣言、反智、低俗

10、的内容 多：保证多样性，帮助用户发现更大的世界知乎 feed 的发展过程与规划 7知乎 feed 的发展经历了以下一系列过程：第一阶段 2011 年，知乎上线，在初期用户积累阶段，feed 是基于用户间的关注关系，将每个用户的动态按照时间倒序的形式展示。这是起步时采用的方式，简单易懂。但随着用户量的上涨，刷屏、新内容量过多等问题很快就暴露出来。技术架构上采用了推模型，当用户产生新的动态时会向他的每个关注者进行推送。这种构架逻辑简单，实现容易，响应时间快。但是随着用户量的增加，推送方式资源占用多的劣势随之显现出来，特别是对于关注了很多人的用户，动态推送需要占用大量的资源，推送的速度也随之变得非常

11、慢。第二阶段 2013 年 11 月，知乎参考 Facebook 所提出的 EdgeRank 算法模型，上线了新的 feed 流产品。此时的知乎 feed 流主要根据 Affinity Score（用户与 feed 源的亲密度），Edge Weight（权重），Time Decay（时间衰减）来进行排序。随着用户量的增加，技术构架上从“推”转换成了“推”/“拉”结合的方式，节省了大量资源占用。但是由于 feed 的计算逻辑都放到了在线，响应时间急剧变慢。为了解决这个问题，我们对用户按照活跃度进行分群，为每个用户计算活跃度，然后根据用户的活跃度离线提前计算，只有非活跃用户实时计算。这样活跃用户访

12、问的都是缓存，速度很快。但是这种架构也存在问题：8 用户产生的动态不能实时分发 算法策略不能实时调整 离线计算策略维护复杂相比第一阶段，知乎 feed 的 CTR（Click-Through-Rate）和 Duration 都有了 20% 左右的提升。第三阶段 2017 年初至今，知乎上线了基于机器学习的排序算法，采用 GBDT 算法，根据用户维度的特征、内容维度的特征、以及交叉特征来进行排序，更重要的是加入了内容质量的判断，质量高的内容会得到更好的分发。技术构架上采用了计算接近存储的设计方案，使用 Redis Module 将部分固定的计算逻辑放到 Redis 中进行计算，去掉了所有的离线计算，使用户的动态能够快速分发，算法模型能够实时调整。相比第二阶段，这次进化取得了较大的成果。feed 的响应时间的 P95 降低了 45%，资源占用减少了 40%，CTR 和 Duration 分别有 100% 和 40% 的提升。高质量内容分发占比提升 10%。未来规划 在算法角度正在基于深度学习搭建更加个性化的推荐模型。技术构架上使用 Redis Module 后的 Redis 的动态扩容和比较多内存占用也是正在解决的问题。产品上我们会在 feed 上9做进一步升级，将会尝试将关注关系产生的 feed 内容和推荐引擎产生的 feed 内容做一些隔离，这样能更好地满足用户不同的需求。