Feed是什么?在知乎上如何应用?

2017 年 11 月 24 日 聊聊架构 雨多田光
嘉宾 | 姚钢强
编辑 | 雨多田光

我们每天都在刷知乎、刷微博、刷 Twitter,推文一条接一条地从你的指尖流过,信息就这样被你获取了。可你有没有想过背后支撑着这信息流的技术是怎么样的呢?

12 月份 ArchSummit 大会上,来自知乎首页组的技术负责人姚钢强将进行演讲,主题是“知乎 Feed 流架构演进”,在此之前,我们对姚老师进行了一次采访,请他为我们简单介绍了一下 Feed 的相关知识,同时分享了知乎 Feed 的发展历程。以下内容由采访整理而成。

什么是 Feed

什么是 Feed?你现在手机上的知乎、微信、微博等 App 中就存在着 Feed。

不太严谨地划分,用户获取信息的方式可以分为 Pull 和 Push,即“拉”/“推”。再详细一些,用户主动去获取、并且明确指定自己希望获取的信息的过程是 Pull,而在不明确表述自己的信息需求的情况下,被动接受信息的过程是 Push。

举个例子:一个人走到图书馆,按照字母表找到某一本书,获取这本书的内容,可以看作是主动寻找信息;当这个人坐到电视前,他并不知道可能会有什么内容出现,这可以看作是被动接受内容。

Feed 从英文翻译过来是【投喂;供给;满足】的意思,Feed 流产品形象地将用户等待接受信息的场景描绘为用户被信息“投喂”。Feed 流在中文里可以翻译为“信息流”。如果将 Feed 描述为一个信息准备被投喂,那么 Feed 流则是多个准备投喂的“信息”像流水线一样按照一定规则排列好。

Feed 的特点

现在,当大家讨论 Feed,一般来说会特指一列可以不断向下滑动不断加载的信息列表。Feed 具备以下几个特点:

  • 使用简单,主要操作只有点击、向下滑动加载。

  • 信息量大,每个 Feed 条目都是一个独立的信息。

  • 兼容性好,可以在 Feed 中展示文字、图片、视频、甚至是可操作的卡片。

  • ……

它被大量地应用在不同领域的不同应用上,也成为了用户上网消费大量内容时,最熟悉的交互模式。

Feed 流产品的发展历史

Feed 流是一个非常笼统的说法。在我看来,将一类信息按照一定规律进行排序就可以称为 Feed 流产品。由于其同时兼顾了大量信息下的展示与消费,如今 Feed 流产品越来越被大多数互联网产品所使用。

早期互联网中,门户网站上一列列的文章标题,可以算作最早的 Feed。由编辑筛选,每个人看到的都是一致的内容。随着媒体式的中心化发声方式从线下纸媒,理所当然般继承到了互联网上,不论中美,在最初的互联网世界上都出现了许多门户巨头。

此时门户主页可以看作是最原始的 Feed,这个时候并没有后来流行的“订阅”及“个性化”等信息分发方式,所有人接受到的信息是相同的。

互联网上基于“订阅”的个性化 Feed 开始被较大规模使用是从 RSS(Really Simple Syndication, 一个互联网信息来源格式规范)开始的。在 Web 时代,每个站点会独立发布消息。由于网站数量的爆发式增长,RSS 协议开始被用户用来订阅独立站点发布的消息,这样,用户可以在一个 RSS 阅读器上看到所有订阅站点发布的消息,而不需要再去不同的网站接受信息。

从 RSS 阅读器开始,这种“持续更新不同来源的信息,并呈现给用户的信息组织形式”也就正式拥有了“Feed 流”的名字。

而接下来,随着互联网的发展,“订阅”行为已经不再局限于 RSS 协议这个媒介。一系列产品的出现,开始允许用户以极低的成本发布信息,并非常容易的在一个产品中关注其他发布信息的人,比如:Facebook、Twitter、微博、知乎、微信的朋友圈等。

由于 Feed 流产品可以将所有订阅的信息源(信息创作者 / 信息类型 / 信息发布者等)发布的信息汇集到一个地方,同时按照一定的规则排序展示出来,大大提高了用户接受信息的效率,这也就成为了这些产品的主要消费场景。

随着互联网产品和技术的演进,将 Feed 的使用成本再次降低。之前主流的 Feed 大都依赖“订阅”这一关注关系实现,而此时可以在取消了关注行为后,直接根据用户的信息消费历史,使用数据挖掘的手段,计算使用者可能对哪些内容感兴趣,从而进行 Feed 生成。

这将 Feed 的使用成本再次降低,使用者的门槛变得无比之低,越来越多的产品开始向此方向尝试,例如 YouTube、Facebook、知乎。

总的来说,Feed 中的内容来源有以下几种:

  1. 由少部分人发布。

  2. 基于订阅行为获取。

  3. 由机器计算。

当然,也可以是他们 3 者的任意混合所组成。

Feed 流排序规则演进

最开始 Feed 是一类信息按照一定规则排列,上面讲述了 Feed 的来源与发展,那么排序规则同样存在这个“进化”的过程。

最初的 Feed 是编辑按照人主观的意识,来决定不同文章的排序,就像编辑一本杂志,所有人会看到相同的内容与序列。

在“订阅”行为变得普及以后,不同的人由于订阅内容的不同,会有完全不一样的 Feed 流产生,显然这时不会再有编辑为每一个人排序。

在各种类型的信息订阅产品中,信息的时效性都是一个比较重要的考量,一个最简单也是比较符合使用者需求的做法是:把所有订阅的内容按照时间倒序排列,将最新生产的内容展示给用户。早期的 Facebook、微博、知乎,现在的微信朋友圈皆是如此。

而当用户订阅数量突破一个阈值时,订阅所产生的内容量会远远大于用户可消费的量,如果此时仍然按照时间倒序排列,显然是一个非常低效的做法:用户最关心的信息并不一定是最新产生的信息。

帮助用户把最可能有价值的信息筛选出来则可以大大提高消费效率。所以有人在 Feed 排序中引入了“排序算法”。排序算法在初期是非常简单且粗暴的:

  • 认为来自某些高价值订阅源的信息更重要——提升排序中的权重;

  • 认为带有图片的文章对用户更有吸引力——提升排序中的权重;

  • 认为... 提升排序中的权重。

  • ……

也就是全靠主观判断,觉得哪些地方重要就提升权重。

第二阶段,会根据用户的行为动态地调整内容权重,不再是全靠产品运营者拍脑袋决定。比如你经常点击某个订阅源生产的内容,给某些文章点赞,评论一些人的回答等等。因为具体产品形态不同而产生不同的各种交互行为都在暴露你的喜好,甚至不点击任何内容也是一种反馈信号。

但即使是在第二阶段中引入了用户行为作为排序的依据,却依然有产品运营者在对各种行为下主观判断,这种主观判断是否和用户的真正需求匹配?根本无从分析。

而随着产品复杂度的提高以及用户量及分发量的急剧扩大,越来越多的信息开始被收集到:内容的长度、视频阅读时间、包含的链接、好友有没有读过、跟你比较相似的用户是否喜欢看、标题中的关键字等等,人类大脑没有办法为如此多的变量设定一个权重,将排序交给“机器学习”来进行则是一个必然的结果。

做好 Feed 的关键要素是什么?
  1. 快:新生产的内容能第一时间出现在 Feed 流中

  2. 准:尽量推荐和用户的兴趣、调性相关的内容

  3. 优:保证内容优质,过滤掉谣言、反智、低俗的内容

  4. 多:保证多样性,帮助用户发现更大的世界

知乎 Feed 的发展过程与规划

知乎 Feed 的发展经历了以下一系列过程:

第一阶段

2011 年,知乎上线,在初期用户积累阶段,Feed 是基于用户间的关注关系,将每个用户的动态按照时间倒序的形式展示。这是起步时采用的方式,简单易懂。但随着用户量的上涨,刷屏、新内容量过多等问题很快就暴露出来。

技术架构上采用了推模型,当用户产生新的动态时会向他的每个关注者进行推送。这种构架逻辑简单,实现容易,响应时间快。但是随着用户量的增加,推送方式资源占用多的劣势随之显现出来,特别是对于关注了很多人的用户,动态推送需要占用大量的资源,推送的速度也随之变得非常慢。

第二阶段

2013 年 11 月,知乎参考 Facebook 所提出的 EdgeRank 算法模型,上线了新的 Feed 流产品。此时的知乎 Feed 流主要根据 Affinity Score(用户与 Feed 源的亲密度),Edge Weight(权重),Time Decay(时间衰减)来进行排序。

随着用户量的增加,技术构架上从“推”转换成了“推”/ “拉”结合的方式,节省了大量资源占用。但是由于 Feed 的计算逻辑都放到了在线,响应时间急剧变慢。

为了解决这个问题,我们对用户按照活跃度进行分群,为每个用户计算活跃度,然后根据用户的活跃度离线提前计算,只有非活跃用户实时计算。这样活跃用户访问的都是缓存,速度很快。但是这种架构也存在问题:

  1. 用户产生的动态不能实时分发

  2. 算法策略不能实时调整

  3. 离线计算策略维护复杂

相比第一阶段,知乎 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 上做进一步升级,将会尝试将关注关系产生的 Feed 内容和推荐引擎产生的 Feed 内容做一些隔离,这样能更好地满足用户不同的需求。

嘉宾介绍

姚钢强,知乎首页组技术负责人,2013 年加入知乎,担任首页 Feed 流技术负责人。专注于改进 Feed 流的稳定性和性能,有丰富的编码和工程攻坚经验。在负责 Feed 流项目期间,通过构架优化使响应时间 p95 从 1.6s 降低到 700ms,通过开发规范使稳定性由 99.9% 提升到 99.99%。

More

你朋友圈里的广告是怎么做到合你胃口的?

什么是Service Mesh?以及为什么我们需要它

其它

AI 大数据、微服务、大前端、各业务形态的架构如何落地?2017 年有哪些值得学习和借鉴的实践经验?给你来自 100+ 顶尖架构师的经验总结:ArchSummit 全球架构师峰会将于 12 月 8-11 日北京举行,部分分享嘉宾如下:

  • 阿里技术委员会主席王坚博士

  • 微软亚洲研究院首席主任研究员曾文军

  • Instagram 最早华人工程师,现 Reddit 高级经理陈晨

  • Snap 研究科学家徐宁

  • 摩拜首席架构师范同祥

目前大会 9 折报名最后一周,大会完整演讲目录,可识别下方二维码或点击 阅读原文 了解,期待和你一同进步!


登录查看更多
0

相关内容

知乎是中文互联网最大的知识社交平台,拥有认真、专业和友善的独特氛围,连接各行各业的精英。用户分享着彼此的专业知识、经验和见解,为中文互联网源源不断地提供高质量的信息。

【高能所】如何做好⼀份学术报告& 简单介绍LaTeX 的使用
深度学习自然语言处理概述,216页ppt,Jindřich Helcl
专知会员服务
212+阅读 · 2020年4月26日
中科大-人工智能方向专业课程2020《脑与认知科学导论》
Transformer文本分类代码
专知会员服务
116+阅读 · 2020年2月3日
视频内容理解在Hulu的应用与实践
AI前线
12+阅读 · 2019年2月16日
推荐系统BAT面试题:说说协同过滤的原理
七月在线实验室
50+阅读 · 2019年1月30日
知乎八年,大而不美
新榜
7+阅读 · 2019年1月26日
一文简单理解“推荐系统”原理及架构
51CTO博客
8+阅读 · 2018年10月31日
从零开始一起学习SLAM | SLAM有什么用?
计算机视觉life
18+阅读 · 2018年9月17日
AI都干过什么让人细思极恐的事?
全球创新论坛
4+阅读 · 2017年9月15日
自然语言处理技术(NLP)在推荐系统中的应用
CSDN大数据
4+阅读 · 2017年6月29日
Compositional Generalization in Image Captioning
Arxiv
3+阅读 · 2019年9月16日
Music Transformer
Arxiv
5+阅读 · 2018年12月12日
Arxiv
4+阅读 · 2018年10月31日
Doubly Attentive Transformer Machine Translation
Arxiv
4+阅读 · 2018年7月30日
VIP会员
相关资讯
视频内容理解在Hulu的应用与实践
AI前线
12+阅读 · 2019年2月16日
推荐系统BAT面试题:说说协同过滤的原理
七月在线实验室
50+阅读 · 2019年1月30日
知乎八年,大而不美
新榜
7+阅读 · 2019年1月26日
一文简单理解“推荐系统”原理及架构
51CTO博客
8+阅读 · 2018年10月31日
从零开始一起学习SLAM | SLAM有什么用?
计算机视觉life
18+阅读 · 2018年9月17日
AI都干过什么让人细思极恐的事?
全球创新论坛
4+阅读 · 2017年9月15日
自然语言处理技术(NLP)在推荐系统中的应用
CSDN大数据
4+阅读 · 2017年6月29日
相关论文
Compositional Generalization in Image Captioning
Arxiv
3+阅读 · 2019年9月16日
Music Transformer
Arxiv
5+阅读 · 2018年12月12日
Arxiv
4+阅读 · 2018年10月31日
Doubly Attentive Transformer Machine Translation
Arxiv
4+阅读 · 2018年7月30日
Top
微信扫码咨询专知VIP会员