AI技术内参
洪亮劼
Etsy数据科学主管,前雅虎研究院资深科学家
立即订阅
8829 人已学习
课程目录
已完结 166 讲
0/6登录后,你可以任选6讲全文学习。
开篇词 (1讲)
开篇词 | 你的360度人工智能信息助理
免费
人工智能国际顶级会议 (31讲)
001 | 聊聊2017年KDD大会的时间检验奖
002 | 精读2017年KDD最佳研究论文
003 | 精读2017年KDD最佳应用数据科学论文
004 | 精读2017年EMNLP最佳长论文之一
005 | 精读2017年EMNLP最佳长论文之二
006 | 精读2017年EMNLP最佳短论文
007 | 精读2017年ICCV最佳研究论文
008 | 精读2017年ICCV最佳学生论文
009 | 如何将“深度强化学习”应用到视觉问答系统?
010 | 精读2017年NIPS最佳研究论文之一:如何解决非凸优化问题?
011 | 精读2017年NIPS最佳研究论文之二:KSD测试如何检验两个分布的异同?
012 | 精读2017年NIPS最佳研究论文之三:如何解决非完美信息博弈问题?
013 | WSDM 2018论文精读:看谷歌团队如何做位置偏差估计
014 | WSDM 2018论文精读:看京东团队如何挖掘商品的替代信息和互补信息
015 | WSDM 2018论文精读:深度学习模型中如何使用上下文信息?
016 | The Web 2018论文精读:如何对商品的图片美感进行建模?
017 | The Web 2018论文精读:如何改进经典的推荐算法BPR?
018 | The Web 2018论文精读:如何从文本中提取高元关系?
019 | SIGIR 2018论文精读:偏差和“流行度”之间的关系
020 | SIGIR 2018论文精读:如何利用对抗学习来增强排序模型的普适性?
021 | SIGIR 2018论文精读:如何对搜索页面上的点击行为进行序列建模?
022 | CVPR 2018论文精读:如何研究计算机视觉任务之间的关系?
023 | CVPR 2018论文精读:如何从整体上对人体进行三维建模?
024 | CVPR 2018论文精读:如何解决排序学习计算复杂度高这个问题?
025 | ICML 2018论文精读:模型经得起对抗样本的攻击?这或许只是个错觉
026 | ICML 2018论文精读:聊一聊机器学习算法的“公平性”问题
027 | ICML 2018论文精读:优化目标函数的时候,有可能放大了“不公平”?
028 | ACL 2018论文精读:问答系统场景下,如何提出好问题?
029 | ACL 2018论文精读:什么是对话中的前提触发?如何检测?
030 | ACL 2018论文精读:什么是“端到端”的语义哈希?
复盘 7 | 一起来读人工智能国际顶级会议论文
搜索核心技术 (28讲)
031 | 经典搜索核心算法:TF-IDF及其变种
032 | 经典搜索核心算法:BM25及其变种(内附全年目录)
033 | 经典搜索核心算法:语言模型及其变种
034 | 机器学习排序算法:单点法排序学习
035 | 机器学习排序算法:配对法排序学习
036 | 机器学习排序算法:列表法排序学习
037 | “查询关键字理解”三部曲之分类
038 | “查询关键字理解”三部曲之解析
039 | “查询关键字理解”三部曲之扩展
040 | 搜索系统评测,有哪些基础指标?
041 | 搜索系统评测,有哪些高级指标?
042 | 如何评测搜索系统的在线表现?
043 | 文档理解第一步:文档分类
044 | 文档理解的关键步骤:文档聚类
045 | 文档理解的重要特例:多模文档建模
046 | 大型搜索框架宏观视角:发展、特点及趋势
047 | 多轮打分系统概述
048 | 搜索索引及其相关技术概述
049 | PageRank算法的核心思想是什么?
050 | 经典图算法之HITS
051 | 社区检测算法之“模块最大化 ”
052 | 机器学习排序算法经典模型:RankSVM
053 | 机器学习排序算法经典模型:GBDT
054 | 机器学习排序算法经典模型:LambdaMART
055 | 基于深度学习的搜索算法:深度结构化语义模型
056 | 基于深度学习的搜索算法:卷积结构下的隐含语义模型
057 | 基于深度学习的搜索算法:局部和分布表征下的搜索模型
复盘 1 | 搜索核心技术模块
推荐系统核心技术 (22讲)
058 | 简单推荐模型之一:基于流行度的推荐模型
059 | 简单推荐模型之二:基于相似信息的推荐模型
060 | 简单推荐模型之三:基于内容信息的推荐模型
061 | 基于隐变量的模型之一:矩阵分解
062 | 基于隐变量的模型之二:基于回归的矩阵分解
063 | 基于隐变量的模型之三:分解机
064 | 高级推荐模型之一:张量分解模型
065 | 高级推荐模型之二:协同矩阵分解
066 | 高级推荐模型之三:优化复杂目标函数
067 | 推荐的Exploit和Explore算法之一:EE算法综述
068 | 推荐的Exploit和Explore算法之二:UCB算法
069 | 推荐的Exploit和Explore算法之三:汤普森采样算法
070 | 推荐系统评测之一:传统线下评测
071 | 推荐系统评测之二:线上评测
072 | 推荐系统评测之三:无偏差估计
073 | 现代推荐架构剖析之一:基于线下离线计算的推荐架构
074 | 现代推荐架构剖析之二:基于多层搜索架构的推荐系统
075 | 现代推荐架构剖析之三:复杂现代推荐架构漫谈
076 | 基于深度学习的推荐模型之一:受限波兹曼机
077 | 基于深度学习的推荐模型之二:基于RNN的推荐系统
078 | 基于深度学习的推荐模型之三:利用深度学习来扩展推荐系统
复盘 2 | 推荐系统核心技术模块
广告系统核心技术 (18讲)
079 | 广告系统概述
080 | 广告系统架构
081 | 广告回馈预估综述
082 | Google的点击率系统模型
083 | Facebook的广告点击率预估模型
084 | 雅虎的广告点击率预估模型
085 | LinkedIn的广告点击率预估模型
086 | Twitter的广告点击率预估模型
087 | 阿里巴巴的广告点击率预估模型
088 | 什么是“基于第二价位的广告竞拍”?
089 | 广告的竞价策略是怎样的?
090 | 如何优化广告的竞价策略?
091 | 如何控制广告预算?
092 | 如何设置广告竞价的底价?
093 | 聊一聊“程序化直接购买”和“广告期货”
094 | 归因模型:如何来衡量广告的有效性
095 | 广告投放如何选择受众?如何扩展受众群?
096 | 如何利用机器学习技术来检测广告欺诈?
自然语言处理及文本处理核心技术 (0讲)
该章节暂未更新内容,敬请期待
计算机视觉核心技术 (0讲)
该章节暂未更新内容,敬请期待
数据科学家与数据科学团队养成 (0讲)
该章节暂未更新内容,敬请期待
热点话题讨论 (0讲)
该章节暂未更新内容,敬请期待
结束语 (0讲)
该章节暂未更新内容,敬请期待
AI技术内参
登录|注册

073 | 现代推荐架构剖析之一:基于线下离线计算的推荐架构

洪亮劼 2018-04-02
上周,我们讨论了推荐系统的评测,聊了推荐系统的线下评测、线上评测和无偏差估计。至此,我们已经聊了推荐系统的一些基本技术和评测体系,相信你已对推荐系统有了一个基本的认识。
那么,到底该如何搭建一个工业级的推荐系统呢?这周,我们就来谈一谈现代推荐系统的架构体系,帮助你从宏观上对推荐系统的构建有一个更加完整的认识。
今天,我们先来看一看,基于线下离线计算的推荐架构

推荐架构需要解决的问题

在讨论任何一种架构之前,我们首先来看一下这个架构需要解决什么样的问题。然后在这些问题的指引下,我们就可以来分析不同架构在解决这些问题上的优劣。
那么,对于一个推荐架构来说,我们需要解决什么样的问题呢?
首先,从大的角度来说,一个用户来到我们的网站或者服务,推荐系统最重要的一个任务就是,能够在一两百毫秒内给用户提供当前的推荐结果。也就是说,从用户的角度来看,推荐结果的呈现必须是实时的。这一条就是把工业级应用和学术模型区分开的一个重要指标。
在过去十多年里,学术界的推荐系统,或者是 Kaggle 竞赛的推荐系统,往往是一个使用了很多不同模型的集成模型(Ensemble Model),这种方式虽然在比赛和论文发表中能够取得较高的精度,但是在现实的系统中,如果不加修改直接使用,必然无法在规定的时间内,也就是一两百毫秒内产生所有的推荐结果。同样的,很多非常复杂的深度学习模型,也无法在规定的时间内产生所有的推荐结果。由此可见,很多推荐架构的核心就是在解决这些问题。
其次,推荐系统架构需要对用户和系统的交互结果做出响应。什么意思呢?如果用户看了推荐结果,并且点击了一些推荐结果,或者明确表达了对推荐结果的不喜爱,那么推荐模块需要对这些互动的结果给予回馈。试想,如果一个用户已经明确表示了对某些结果的不喜欢,然后在下一次访问的时候,用户又看到同样的推荐,那一定是一个非常不好的体验。
最后,推荐系统架构需要考虑用户群体的覆盖率的问题。如果一个系统架构只能为部分用户服务,这想必无法真正做到对一个网站或者服务产生影响力。因此,在模型以及其他的技术选择上面,如何能够做到“为更广阔的用户群体服务”,就是一个非常关键的因素。

基于线下离线计算的架构

刚才我们简单讨论了一个现代推荐系统架构需要满足的一些需求。那么,在这些需求的驱动下,一种简单易行的架构就诞生了,那就是“基于线下离线计算的架构”。
什么叫基于线下离线计算的架构呢?
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《AI技术内参》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(4)

  • 林彦
    如果用户数量和物品数量太大,线下计算无法满足每天全部更新推荐一次推荐。

    1. 可以根据用户访问的频率,优先计算访问频率高的用户的线下更新。尽可能满足更新频率略高于用户的历史访问频率(或预测访问频率)。另外新用户和新物品一般第一次更新尽可能及时。

    2. 对权重高的物品和用户,对整个系统效果影响较大的物品和用户,尽可能保证他们的更新频率。同时适度保持exploration,多样性,新颖性。

    3. 把用户和物品分类,同一类用相同的推荐结果,降低线下计算量。

    4. 如第1条回答所述,公司如果有资源上分布式计算,甚至还可以做运维的优化,底层性能的优化,也可以提高公司对于大数据量的计算能力。
    2018-04-05
    2
  • 永夜
    架构是时间,空间,算力等多种东西的折衷,分析问题将可离线计算和必须在线计算的数据拆解,主要还是看每种选择可能性的潜力和提升量。现在往往几十ms的时限下,空间换时间,加cache,分级别离线算好直接取都比较常用
    2018-04-09
    1
  • 帅帅
    @林彦的第3条很喜欢

    不是根据每个用户做推荐,而是先将用户做聚类;把(userId、itemId、rank)变成(userGroupId、item、weightdRank)进行训练,得到每个聚群的推荐结果;
    cache只需要存储每个聚群的推荐结果、每个用户的聚类映射即可,每次查询,先查询用户的聚类,然后取出聚类的推荐结果返回;

    如果这个聚类算法能在线高实时调用,那连新用户冷启动问题都解决了;不过画像数据一般很大,要在几十MS返回画像,同时返回聚类结果,难道有点大;可以借鉴netflix的结构,加入近线层;把用户聚类的计算用streaming(spark streaming/flink/storm)计算,更新到CACHE即可;
    2018-10-20
  • 极客星星
    计算量过大时的解决方法 1采样降低数据量 2 模型几天才更新一次 3如果原来是单机计算 改用分布式
    2018-04-02
收起评论
4
返回
顶部