073-现代推荐架构剖析之一：基于线下离线计算的推荐架构【萌萌家】.pdf

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

2018-04-02洪亮劼来自北京

《AI技术内参》

上周，我们讨论了推荐系统的评测，聊了推荐系统的线下评测、线上评测和无偏差估计。至

此，我们已经聊了推荐系统的一些基本技术和评测体系，相信你已对推荐系统有了一个基本的

认识。

那么，到底该如何搭建一个工业级的推荐系统呢？这周，我们就来谈一谈现代推荐系统的架构

体系，帮助你从宏观上对推荐系统的构建有一个更加完整的认识。

今天，我们先来看一看，基于线下离线计算的推荐架构。

推荐架构需要解决的问题

在讨论任何一种架构之前，我们首先来看一下这个架构需要解决什么样的问题。然后在这些问

题的指引下，我们就可以来分析不同架构在解决这些问题上的优劣。

那么，对于一个推荐架构来说，我们需要解决什么样的问题呢？

首先，从大的角度来说，一个用户来到我们的网站或者服务，推荐系统最重要的一个任务就

是，能够在一两百毫秒内给用户提供当前的推荐结果。也就是说，从用户的角度来看，推荐结

果的呈现必须是实时的。这一条就是把工业级应用和学术模型区分开的一个重要指标。

在过去十多年里，学术界的推荐系统，或者是Kaggle竞赛的推荐系统，往往是一个使用了很

多不同模型的集成模型（EnsembleModel），这种方式虽然在比赛和论文发表中能够取得较

高的精度，但是在现实的系统中，如果不加修改直接使用，必然无法在规定的时间内，也就是

一两百毫秒内产生所有的推荐结果。同样的，很多非常复杂的深度学习模型，也无法在规定的

时间内产生所有的推荐结果。由此可见，很多推荐架构的核心就是在解决这些问题。

其次，推荐系统架构需要对用户和系统的交互结果做出响应。什么意思呢？如果用户看了推荐

结果，并且点击了一些推荐结果，或者明确表达了对推荐结果的不喜爱，那么推荐模块需要对

这些互动的结果给予回馈。试想，如果一个用户已经明确表示了对某些结果的不喜欢，然后在

下一次访问的时候，用户又看到同样的推荐，那一定是一个非常不好的体验。

最后，推荐系统架构需要考虑用户群体的覆盖率的问题。如果一个系统架构只能为部分用户服

务，这想必无法真正做到对一个网站或者服务产生影响力。因此，在模型以及其他的技术选择

上面，如何能够做到“为更广阔的用户群体服务”，就是一个非常关键的因素。

基于线下离线计算的架构

刚才我们简单讨论了一个现代推荐系统架构需要满足的一些需求。那么，在这些需求的驱动

下，一种简单易行的架构就诞生了，那就是“基于线下离线计算的架构”。

什么叫基于线下离线计算的架构呢？

试想一下，我们有一个推荐模块，是在一个网站首页为用户推荐新闻。现在假设，我们有M

个用户，N个新闻文章。M的数量级可能是几千万，N的数量级可能是几百万。那么，理想

状态下，需要用我们的模型，对每一个用户，以及每一个新闻进行打分。具体地，对于某一个

用户来说，当这个用户访问网站的那一瞬间，我们需要对几百万的新闻进行打分，并且在一两

百毫秒内返回结果，这很有可能是不现实的。

既然我们无法实时对所有的新闻打分，那么，退一步讲，我们能不能事先把这些打分的工作都

做了，然后当用户来到网站的时候，我们仅仅是显示结果呢？答案是，可以的，并且这就是线

下离线计算的核心思想。

通俗地说，线下离线计算的一个主要想法就是：把计算中复杂的步骤尽量提前做好，然后当用

户来到网站需要呈现结果的时候，我们要么已经完成了所有的计算，要么还剩非常少的步骤，

可以在很快的时间内，也就是所说的一两百毫秒内完成剩下的计算。

回到我们刚才的新闻推荐的例子。我们可以把针对每一个用户的所有新闻的打分，在线下都提

前计算好，然后存放在一个数据库或者数据存储的地方，当用户来到网站的时候，我们只需要

展示已经完全计算好的推荐结果。

完全线下离线计算的最大好处就是，当用户来临的时候，基本没有任何的计算成本。系统唯一

需要做的就是从一个数据存储的地方直接取得当前的推荐结果。

也就是说，线下离线计算的最大好处，就是解决我们刚才说的在规定的时间内计算出推荐结果

的需求。然而，线下离线计算对其他两个需求则无法很好地处理。

第一，因为我们是完全提前计算好了所有的结果，并且存储在数据库中。那么，假设用户和推

荐结果进行了交互，希望更新推荐结果，离线计算的模式就无法支持这样的操作，或者是非常

困难。

我们可以试想一下，如果一个用户不喜欢某一个新闻推荐结果，那么在当前的框架下，我们应

该如何应对呢？首先，我们需要启用线下的计算流程，重新计算这个用户所有的推荐结果，然

后把这个推荐结果存储到刚才说的数据库里，这样用户下一次来到网站的时候，就会看到更新