推荐系统三十六式
刑无刀
“贝壳找房”资深算法专家,8年推荐系统工程师
立即订阅
11390 人已学习
课程目录
已完结 39 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 用知识去对抗技术不平等
免费
第1章 概念篇 (3讲)
【概念篇】你真的需要个性化推荐系统吗?
【概念篇】个性化推荐系统那些绕不开的经典问题
【概念篇】这些你必须应该具备的思维模式
第2章 原理篇 (20讲)
【内容推荐】画鬼容易画人难:用户画像的“能”和“不能”
【内容推荐】从文本到用户画像有多远
【内容推荐】超越标签的内容推荐系统
【近邻推荐】人以群分,你是什么人就看到什么世界
【近邻推荐】解密“看了又看”和“买了又买”
【近邻推荐】协同过滤中的相似度计算方法有哪些
【矩阵分解】那些在Netflix Prize中大放异彩的推荐算法
【矩阵分解】Facebook是怎么为十亿人互相推荐好友的
【矩阵分解】如果关注排序效果,那么这个模型可以帮到你
【模型融合】经典模型融合办法:线性模型和树模型的组合拳
【模型融合】一网打尽协同过滤、矩阵分解和线性模型
【模型融合】深度和宽度兼具的融合模型 Wide and Deep
【MAB问题】简单却有效的Bandit算法
【MAB问题】结合上下文信息的Bandit算法
【MAB问题】如何将Bandit算法与协同过滤结合使用
【深度学习】深度学习在推荐系统中的应用有哪些?
【深度学习】用RNN构建个性化音乐播单
【其他应用算法】构建一个科学的排行榜体系
【其他应用算法】实用的加权采样算法
【其他应用算法】推荐候选池的去重策略
第3章 工程篇 (10讲)
【常见架构】典型的信息流架构是什么样的
【常见架构】Netflix个性化推荐架构
【常见架构】总览推荐架构和搜索、广告的关系
【关键模块】巧妇难为无米之炊:数据采集关键要素
【关键模块】让你的推荐系统反应更快:实时推荐
【关键模块】让数据驱动落地,你需要一个实验平台
【关键模块】 推荐系统服务化、存储选型及API设计
【效果保证】推荐系统的测试方法及常用指标介绍
【效果保证】道高一尺魔高一丈:推荐系统的攻防
【开源工具】和推荐系统有关的开源工具及框架介绍
第4章 产品篇 (3讲)
【产品篇】推荐系统在互联网产品商业链条中的地位
【产品篇】说说信息流的前世今生
【团队篇】组建推荐团队及工程师的学习路径
尾声与参考阅读 (2讲)
推荐系统的参考阅读
【尾声】遇“荐”之后,江湖再见
推荐系统三十六式
登录|注册

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

刑无刀 2018-04-27
从今天起,我们不再单独介绍推荐算法的原理,而是开始进入一个新的模块——工程篇。
在工程实践的部分中,我首先介绍的内容是当今最热门的信息流架构。
信息流是推荐系统应用中的当红炸子鸡,它表现形式有很多:社交网络的动态信息流、新闻阅读的图文信息流、短视频信息流等等。
如果要搭建一个自己的信息流系统,它应该是怎么样的呢?今天,我就来带你一探信息流架构的究竟。

整体框架

信息流,通常也叫作 feed,这个英文词也很有意思,就是“喂”给用户的意思。
传统的信息流产品知识简单按照时间排序,而被推荐系统接管后的信息流逐渐成为主流,按照兴趣排序,也叫作“兴趣 feed”。
所以我们通常提到信息流,或者兴趣 feed,其实都是在说同一个话题。
这里温馨提示一下:如果要搜索 feed 相关的技术文章,你应该用“Activity Stream”作为关键词去搜,而不应该只用“feed”搜索,Activity Stream 之于 feed,就好比多潘立酮之于吗丁啉,前者是行话,后者是通俗说法。
要实现一个信息流,整体逻辑上是比较清楚的。可以划分为两个子问题。
如何实现一个按照时间顺序排序的信息流系统?
如何给信息流内容按照兴趣重排序?
我这里先给出一个整体的框架,然后再分别详谈。
这张架构图划分成几个大的模块:日志收集、内容发布、机器学习、信息流服务、监控。这里分别介绍一下:
日志收集,是所有排序训练的数据来源,要收集的最核心数据就是用户在信息流上产生的行为,用于机器学习更新排序模型;
内容发布,就是用推或者拉的模式把信息流的内容从源头发布到受众端;
机器学习,从收集的用户行为日志中训练模型,然后为每一个用户即将收到的信息流内容提供打分服务;
信息流服务,为信息流的展示前端提供 Rest API;
监控,这是系统的运维标配,保证系统的安全和稳定等。

数据模型

信息流的基本数据有三个:用户(User)、内容(Activity)和关系(Connection)。
用户不用说,就是区别不同用户的身份 ID,我来说一说其他的两种。

1. 内容即 Activity。

用于表达 Activity 的元素有相应的规范,叫作 Atom,你可以参考它并结合产品需求,定义出自己的信息流数据模型来。
根据 Atom 规范的定义,一条 Activity 包含的元素有:Time、Actor、Verb、Object、Target、Title、Summary。下面详细解释一下这些元素。
Time:即“Activity 发生的时间”。
Actor:即“Activity 由谁发出的”。通常 Actor 就是用户 ID,但是我们也可以扩展到其他拟人化物体上,如关注的一个“店铺”,收藏的一部“电影”,或者用户喜欢的一个标签或者分类。也就是和用户建立连接的另一端。
Verb:动词,就是连接的名字,比如“Follow”“Like”等,也可以是隐含的连接,如挖掘出的用户兴趣词和用户之间这种潜规则。
Object:即动作作用到最主要的对象,只能有一个,比如一个人赞过的一张照片,店铺上新的一件商品,一个分类下一篇新的文章。
Target:动作的最终目标,与 verb 有关,可以没有。它对应英语中介词 to 后接的事物,比如“John saved a movie to his wishlist”(John 保存了一部电影到清单里),这里电影就是 Object,而清单就是 Target。
Title:这个是 Activity 的标题,用自然语言描述,用于展示给用户。
Summary:通常是一小段 HTML 代码,是对这个 Activity 的描述,还可能包含类似缩略图这样的可视化元素,可以理解为 Activity 的视图,不是必须的。
举个例子: 2016 年 5 月 6 日 23:51:01(Time)@刑无刀(Actor) 分享了(Verb) 一条微博(Object) 给 @极客时间 (Target)。把前面这句话去掉括号后的内容就是它的 Title,Summary 暂略。
除了上面的字段外,还有一个隐藏的 ID,用于唯一标识一个 Activity。社交电商 Etsy 在介绍他们的信息流系统时,还创造性地给 Activity 增加了 Owner 属性,同一个 Activity 可以属于不同的用户,相当于考虑了方向。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《推荐系统三十六式》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(6)

  • 林彦
    大晚上的,偷偷懒不做产品经理去研究2家公司的实际信息流了。这2个应用我都没安装,平时很少用。根据网上的文章抛个砖头。

    共同点:
    1. Facebook和今日头条都是要通过内容提取,用户和环境的分析找到最匹配的信息;
    2. 根据用户的各种行为来衡量效果;
    3. 都会引入一些无法完全用数据衡量的目标。比如屏蔽广告,屏蔽骚扰帐号,屏蔽有害内容;
    4. 特征提取,特征匹配,用各种机器学习和深度学习的模型。用户标签/画像,内容标签的建立。这些工作后面的机制是相通的;
    5. 实时信息流的更新量大,对性能要求高;
    6. 都会有实验平台和长期跟踪效果的记录平台;
    7. 都有人工介入评估。

    不同点:
    1. Facebook里原创和转发的动作比今日头条更频繁(我的理解),这个动作的衡量会不同;
    2. 今日头条的内容更复杂,种类更丰富,需要提取的特征种类,特征信息和衡量效果的因素更多;
    3. 今日头条的内容是有层级逻辑关系的;
    4. Facebook人之间的关系,互动的影响要比今日头条之间要大;
    5. 今日头条内容团队的中国特色。评估效果时人工介入的更多。
    2018-04-27
    12
  • 🐱您的好友William🐱
    我认为facebook的根本是社交,头条的根本是内容。所以对于算法和架构的搭建是围绕两个根本不一样的命题开展的,虽然会用到相似的手段去实现各自的目标。
    2018-10-11
    2
  • 微微一笑
    脸书生产的都是个性化的内容,基本不会重复!头条是个内容聚合平台,不同来源的数据很多重复
    2018-04-27
    2
  • jt120
    关键看生产者和消费者的关系,脸书是大家都会生产消费,头条是只少数人生产,消费多用推,生产多用拉
    2018-04-27
    2
  • 宇天飞
    请问下,离线得到的模型数据什么时候更新,让实时服务可以使用呢
    2019-04-06
  • 帅帅
    非常感谢作者,最近在做一个信息流,刚好都能套上:

    输入数据:用户画像、物品画像、行为数据(浏览、点击、播放、购买、关注、分享)
    目标:提升互动率,比如CTR

    排序算法想到用spark的Lr,但是想了想,其实tf的wide/deep也有现成的程序,可以一步到位;

    有两个疑问还没解决:
    1、信息流架构中,不用先召回?
    2、模型为什么需要在线服务,因为我的内容更新不频繁,我直接给每个用户计算好待推送的列表是不是更好?
    2018-09-24
收起评论
6
返回
顶部