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
收起评论