《一路打怪升级，360推荐系统架构演进》阅读笔记

 

推荐系统的核心排序算法已经从传统的 LR、GBDT 等模型进化到了 Deep&Wide、DeepFM、PNN 等若干深度模型和传统模型相结合的阶段。

• 推荐系统相关算法最新研究进展

• 深度推荐系统在 360 的应用实践

推荐系统相关算法最新研究进展

在介绍应用系统之前，首先让我们从抽象的层次上理解一下，在图像领域的相关概念。

上图是我们对推荐系统的一个分层与抽象。在顶层，我们可以理解为是一个函数。

其中 U 代表用户、I 代表需要推荐的商品、C 代表上下文、Y 则是我们需要优化的目标。

当然，不同的应用场景，Y 的取值会有一定的差异。如果我们的目标是点击率的话，那么 Y 的取值就是 0 和 1。

而如果我们要预估某个时长的话，那么 Y 的取值就变成了实数，它对应的就是某个回归问题。可见，根据不同的场景，定义好 Y 是至关重要的。

如果是从算法人员的角度出发，他们会认为定义 Y、和对 F 求解的优化是非常重要的。

而在业务方的那些做产品的人看来，U 的反馈则更为重要，如果出现用户投诉的话，那么该算法也就失败了。

另外，他们也会关注 I。由于 I 的背后实际上关联的是商家，那么同样要避免出现用户对于 I 的抱怨。可见，不同角色对于此公式的关注点是不相同的。

在上面抽象图的中间，我们一般会把顶层简单的数学公式拆分成三个不同的算法模块：

• 召回（Recall）

• 排序（Rank）

• 策略（或称重排序 Rerank）

目前市面上的一些工业领域和学术界的论文，大部分会重点研究和讨论 Rank，毕竟 Rank 是非常重要的。

而对于那些针对 Recall 和 Rerank 的技术而言，由于它们并不适合被抽象成为一个统一的理论架构，因此相关的论文也不多。后面我们会重点讨论有关召回部分的内容。

经历了上面两个抽象层次，图中的底层就需要让推荐系统服务于“线上”了。

它由五大关键部分所组成：

• ETL 对数据的清洗。不同于那些已经准备好了数据集的传统竞赛，我们面临的是在真实的线上场景中所产生的日志数据，它们不但“脏”，而且体量非常大。

  因此，我们需要有一个对应的数据清洗场景，以缓解系统的处置压力。

• Server 模块。针对各种排序和召回的模型场景，我们需要提供实时的服务。

  因此服务端不但需要具有高性能的计算能力，同时也需要我们的架构能够应对大规模的深度学习与计算。如有必要，还可能会用到 GPU 等硬件。

• Platform。这里主要是指深度学习或者机器学习的训练平台。在各种算法上线之后，随着在线学习的推进，其模型不可能一成不变。

  有的它们需要被“日更”，甚至是以分钟为单位进行更新。因此我们需要有一个良好的深度学习平台提供支持。

• 测试。推荐系统在上线之后，需要被不断的迭代与优化，因此我们需要通过测试来查看效果。

  在系统的起步阶段，用户数量迅速上升，而实验的整体数量则不多，因此我们很容易通过对百万级用户的切分，来开展与流量相关的实验。

  但是随着业务的发展，用户数量不再呈爆发式增长，而我们每天又需要进行成百上千次实验，所以我们需要选用 A/B 测试的实验平台，以方便算法人员加速迭代的进程。

• 报表。之前在与业务方合作时，我们发现：他们几乎每个人都在通过自行编写简单脚本的方式获取所需的报表，因此其工作的重复度相当高。

  然而，由于许多报表的计算都是简单算子的累加，如果我们拥有一个简单且统一的平台，就能够帮助大家获取常用的指标，进而加速整个系统的迭代。

从深度推荐系统的发展来看，最早出现的是传统 LR（线性回归）的机器学习。

之后，随着特征交叉需求的增多，出现了非线性回归和使用 FM 来实现二阶特征交叉。

近年来，随着深度学习在图像领域的广泛应用，如今大家也将它们引入到了推荐系统之中。

不过，相对于图像领域动辄一两百层的神经网络深度而言，推荐系统的深度只有四到六层。

如今各家“大厂”都能够提供诸如 FNN、DFM、以及 Google Wide&Deep 之类的算法，我们很难断言哪种模型更好。

转自：https://mp.weixin.qq.com/s?__biz=MzI1NDAxNjQzMA==&mid=2662955980&idx=2&sn=0652ae434a712db95f490dbeab882304&chksm=f286750dc5f1fc1bdfe93b96783f343303bda1c9d6ea0ee027d2df0985ecb26df9a5c482d0d1&scene=21#wechat_redirect