073 | 现代推荐架构剖析之一：基于线下离线计算的推荐架构
洪亮劼
该思维导图由 AI 生成，仅供参考
上周，我们讨论了推荐系统的评测，聊了推荐系统的线下评测、线上评测和无偏差估计。至此，我们已经聊了推荐系统的一些基本技术和评测体系，相信你已对推荐系统有了一个基本的认识。
那么，到底该如何搭建一个工业级的推荐系统呢？这周，我们就来谈一谈现代推荐系统的架构体系，帮助你从宏观上对推荐系统的构建有一个更加完整的认识。
今天，我们先来看一看，基于线下离线计算的推荐架构。
推荐架构需要解决的问题
在讨论任何一种架构之前，我们首先来看一下这个架构需要解决什么样的问题。然后在这些问题的指引下，我们就可以来分析不同架构在解决这些问题上的优劣。
那么，对于一个推荐架构来说，我们需要解决什么样的问题呢？
首先，从大的角度来说，一个用户来到我们的网站或者服务，推荐系统最重要的一个任务就是，能够在一两百毫秒内给用户提供当前的推荐结果。也就是说，从用户的角度来看，推荐结果的呈现必须是实时的。这一条就是把工业级应用和学术模型区分开的一个重要指标。
在过去十多年里，学术界的推荐系统，或者是 Kaggle 竞赛的推荐系统，往往是一个使用了很多不同模型的集成模型（Ensemble Model），这种方式虽然在比赛和论文发表中能够取得较高的精度，但是在现实的系统中，如果不加修改直接使用，必然无法在规定的时间内，也就是一两百毫秒内产生所有的推荐结果。同样的，很多非常复杂的深度学习模型，也无法在规定的时间内产生所有的推荐结果。由此可见，很多推荐架构的核心就是在解决这些问题。
其次，推荐系统架构需要对用户和系统的交互结果做出响应。什么意思呢？如果用户看了推荐结果，并且点击了一些推荐结果，或者明确表达了对推荐结果的不喜爱，那么推荐模块需要对这些互动的结果给予回馈。试想，如果一个用户已经明确表示了对某些结果的不喜欢，然后在下一次访问的时候，用户又看到同样的推荐，那一定是一个非常不好的体验。
最后，推荐系统架构需要考虑用户群体的覆盖率的问题。如果一个系统架构只能为部分用户服务，这想必无法真正做到对一个网站或者服务产生影响力。因此，在模型以及其他的技术选择上面，如何能够做到“为更广阔的用户群体服务”，就是一个非常关键的因素。
基于线下离线计算的架构
刚才我们简单讨论了一个现代推荐系统架构需要满足的一些需求。那么，在这些需求的驱动下，一种简单易行的架构就诞生了，那就是“基于线下离线计算的架构”。
什么叫基于线下离线计算的架构呢？
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
现代推荐系统的架构体系是基于线下离线计算的推荐架构。该架构旨在解决推荐系统需要实时提供推荐结果、对用户和系统的交互结果做出响应以及考虑用户群体的覆盖率等问题。基于线下离线计算的架构通过提前对用户和物品的打分进行计算，并将结果存储在数据库中，以在用户访问时实时呈现推荐结果。这种架构的优点在于减少了用户访问时的计算成本，但无法很好地处理用户交互结果的更新和新用户、新物品的推荐。因此，在复杂的网站需求下，单靠提前计算结果是不能满足动态用户需求的。然而，理解离线计算的需求对于构建复杂架构很有帮助，因此在设计更加复杂的架构时，仍然会依靠离线计算，用线下时间来换取线上时间。这种思路是现代推荐系统架构中非常重要的一个想法。
仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《AI 技术内参》，新⼈⾸单¥98
《AI 技术内参》，新⼈⾸单¥98
立即购买
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(4)
- 最新
- 精选
帅帅@林彦的第3条很喜欢 不是根据每个用户做推荐，而是先将用户做聚类；把(userId、itemId、rank)变成(userGroupId、item、weightdRank)进行训练，得到每个聚群的推荐结果； cache只需要存储每个聚群的推荐结果、每个用户的聚类映射即可，每次查询，先查询用户的聚类，然后取出聚类的推荐结果返回； 如果这个聚类算法能在线高实时调用，那连新用户冷启动问题都解决了；不过画像数据一般很大，要在几十MS返回画像，同时返回聚类结果，难道有点大；可以借鉴netflix的结构，加入近线层；把用户聚类的计算用streaming(spark streaming/flink/storm)计算，更新到CACHE即可；2018-10-205
林彦如果用户数量和物品数量太大，线下计算无法满足每天全部更新推荐一次推荐。 1. 可以根据用户访问的频率，优先计算访问频率高的用户的线下更新。尽可能满足更新频率略高于用户的历史访问频率(或预测访问频率)。另外新用户和新物品一般第一次更新尽可能及时。 2. 对权重高的物品和用户，对整个系统效果影响较大的物品和用户，尽可能保证他们的更新频率。同时适度保持exploration，多样性，新颖性。 3. 把用户和物品分类，同一类用相同的推荐结果，降低线下计算量。 4. 如第1条回答所述，公司如果有资源上分布式计算，甚至还可以做运维的优化，底层性能的优化，也可以提高公司对于大数据量的计算能力。2018-04-054- 永夜架构是时间，空间，算力等多种东西的折衷，分析问题将可离线计算和必须在线计算的数据拆解，主要还是看每种选择可能性的潜力和提升量。现在往往几十ms的时限下，空间换时间，加cache，分级别离线算好直接取都比较常用2018-04-092
极客星星计算量过大时的解决方法 1采样降低数据量 2 模型几天才更新一次 3如果原来是单机计算 改用分布式2018-04-02
收起评论