第10课:推荐系统的架构设计(上)

在前面的课程中,我们陆续学习了诸如基于内容的推荐算法、基于用户兴趣的推荐算法,以及基于典型协同的推荐算法,并且都相应的进行简单的实践讲解。

并且,从第09课中我们也知道,对于整个推荐算法来说,实际上并不是固定的,只要能够达到我们推荐最终的业务目标即可,而推荐算法的设计实际上是开放的。

再回到基础知识的第01课中,我曾着重提醒了,虽然推荐算法很重要,但是从整个推荐的设计角度来讲,推荐算法并不等于推荐系统,因为推荐系统所涵盖的范围远不止推荐算法所承载的内容。

推荐系统的需要解决的问题

我们来试想一下,如果要构建一个推荐系统,除了设计和开发推荐算法以外还需要什么,甚至可以追问,如果想要设计一个推荐算法并实现我们需要什么。

或者说,我们需要解决哪些难题?

推荐底层数据的依赖

首先需要面临的就是设计一个推荐算法,算法的训练过程依赖什么数据,具体有哪些数据可以参与计算,怎么清洗怎么计算,存储在哪里?

在算法层我们可以做哪些动作

我们知道最终想要的是什么,以电商场景为例,其实就是要商品候选列表嘛!然后在恰当的时候将列表给出去,这就是所谓的推荐。

但是,在实际操作过程中,就没有这么简单了,我们需要计算出哪些商品是适合推荐出去的,但是又需要控制住推荐的效果,这个时候就需要考虑待推荐商品的可能转化效果等等,这就涉及到了排序。

业务方的诉求是什么

原则上我们是什么好推什么,这个是终极理想和目标,但实际上业务的诉求有时候是需要权衡的,举个简单例子:假如你的公司跟某个品牌有重要合作,合作方案中就是有曝光流量的要求,你要不要给人家的商品多点曝光?

这就是典型规则干扰最终列表的案例,更何况你怎么知道有些强规则的效果就一定弱于算法模型的结果?!更何况通常不同业务上都有一些强制的业务限制。

一个算法模型还是多个算法模型

上面有说到过,不同算法模型可能其侧重点不同,带来的效果也不同,甚至其召回的范围,带来的推荐多样性,待选推荐的新颖性等各个维度都不同。

那么,一个推荐场景下,到底是哪个推荐模型呢?是一个还是多个,多个怎么做融合?

是实时还是离线

对于整个推荐流程来说,数据回流效率对于推荐结果会有比较大的影响,简单的离线推荐和实时推荐的架构区分对于效果也可能影响很大。

两者技术架构的不同,实现架构起来难度到底有什么不同,什么阶段应该上什么架构?而不同的架构搭建的成本输出又想回收什么样的效果。

如何做模型的迭代,效果的快速持续优化

推荐系统是个长期而漫长的事,它永远都不仅仅是个功能,它更大的价值在于不断提升的转化效果。但如何保证迭代的稳步进行,以及模型的不断调优,需要在架构设计上进行搭建,提供快速试验迭代的机制。

以上,我们在整个推荐系统的搭建过程中,都是需要解决的问题。

推荐系统常见架构设计

基于上面的考量,我们先来看一张图。

1-5

这是一张相对通用的推荐系统业务逻辑架构图,自底向上,分别由底层数据源层、数据处理层、推荐召回层、策略融合层、列表排序层、数据服务输出层,以及与推荐列表输出多个环节都有关联的规则引擎,还有贯穿整个处理逻辑的推荐实验平台或者叫 AB 测试机制,最后加上最上层的推荐业务层组成整个推荐系统。

现在看来,推荐算法只是其中的一个点而已,即影响最大的召回模型层,即我们所有的推荐算法最终也只是对于推荐列表进行召回而已。

我们一一来看下每层所要承载的任务以及达到的架构职能。

数据层

首先数据层一般由业务数据和行为数据组成,其中业务数据比较好理解,比如如果是电商业务,那就是用户的下单、购买、商品的基本信息,还有购物车的一些记录等等诸如此类。

而我们更加关注的其实是行为数据,这也是大数据时代最重要的标志,即开始对用户行为进行研究。在用户行为收集上,我们对于用户在整个平台上的任何操作,都基本进行监控和数据回收。

例如,用户逛了哪些商品页面,用户搜索了什么,用户将哪些商品加入了购物车,购买了哪些商品,访问了哪些营销活动等等,基本上全面覆盖,这些信息都是需要进行上报的。这些信息都是用户的行为数据,对于挖掘用户的偏好有着重要作用。

除此之外,我们需要对于推荐的一些信息进行上报,例如,哪些推荐的商品进行了曝光,哪些推荐的商品被点击,进而追溯到是否被购买,然后就是推荐列表的输出是源自于哪个模型、哪个策略。这些信息都是需要被回收的,因为这些信息对于我们后续的算法模型迭代有着重要的参考意义,以及对于算法模型的优略评估也起着决定性的作用。

数据计算层

数据计算层很容易理解,在数据源回收的基础上,我们需要进行数据的进一步规整处理,即数据仓库的构建,每个维度的数据都按逻辑进行清洗、汇总,最终拿到我们需要的原始数据。

甚至,很多时候我们同样需要进行进一步的特征处理,将一些数据进行变换,将一些特征进行计算等等,为模型的训练,或者推荐候选集的生成提供数据准备。

策略融合层

正如上面的一个问题,到底哪个模型是有效的,其实谁也不清楚,而实际的操作过程中会发现,不同的推荐算法模型其适应性是不同的,其侧重点也是不同的,所以很多时候并不是单一的某个模型就一定比多个模型有效。

所以,在我们很多实操的过程中,在一些场景中对多个推荐算法进行融合,从而达到一个相对比较好的效果。

排序层

一般情况下,我们的推荐算法负责将推荐候选集进行召回,但实际上我们知道一个栏位的曝光实际上是有限的,并且跟其曝光的顺序有很大的关系。

而以转化的角度来看,我们肯定需要将最有可能转化的候选项进行前置,这就是所谓的点击预估了,即通过历史数据进行点击预估,然后根据预估情况进行召回候选集的重新排序,以符合利益的最大化。

规则引擎

如图我们知道,规则引擎是影响包括召回/排序/策略融合,甚至是数据服务层。规则引擎需要解决的就是强规则的定义以及对推荐的影响。

正如上面举的例子,如果业务的前提下我们需要对某个方向的 ITEM 进行加权,就是通过规则引擎进行干预的,比如在排序的时候进行适当加权等。

又比如我们对于某些商品就是不能出现在推荐栏位中,那么规则层就需要过一遍黑名单而这些操作都可以集成到规则引擎中,而具体在哪个层次生效,就需要看情况了,有可能是在模型计算的数据输入源进行处理,也可能是在排序的层次上,甚至可能在数据化输出的时候进行规则过滤。

数据服务层

数据服务层比较好理解,实际上就是将最终的推荐列表如何对外进行服务提供,他需要保证的是访问的并发问题、缓存的处理、各种配置的热加载生效、规则引擎的执行等。

推荐实验平台

或者换个更通用的说法,其实就是 AB 测试,他是贯穿在整个推荐流程中的,从推荐点击上报反馈开始,我们就需要追踪不同流量位,不同策略,不同模型的结果输出,再到策略融合、规则生效、接口的输出,推荐效果的查看等各个维度。

基于这个平台,我们能够快速的观测到每个策略的,每个模型的效果,从而基于这个平台我们进行快速的模型迭代,然后部署上线,分流测试。

推荐栏位

实际上就是业务层,最终我们推荐列表生效的位置,实际上不同的推荐场景或者说推荐栏位,其适应的算法模型都是不同的,举个简单例子,商品详情页的推荐逻辑和个人中心的推荐逻辑是不一样的。

一个算法在某个场景下可能转化点击都很高,但是切换另一个场景可能效果就会大打折扣,所以,我们在架设整个推荐系统架构的时候,同样必须要考虑整个业务层。

总结

综上,我们可以清晰的看到,如果仅仅是需要有这么一个推荐功能,可能很简单,直接上个推荐算法就完事,但如果需要可持续发展,整个推荐架构如果想要完善搭建其实工程量还是蛮大的。

在下一篇,我们将沿着架构设计的角度进一步拆解,每一步我们如何进行技术选型,以及解决这个章节依然没有解决的问题,那就是实时还是离线的问题。

最后,我们将直接观测一个推荐的实际实验平台的例子,来观测整个实验平台的运作,这也是我认为除了推荐算法模型外,整个推荐架构中最最核心的存在,也是整个推荐能够稳健稳步迭代的基石,下个章节见。

(全文完)

(转载本站文章请注明作者和出处 第10课:推荐系统的架构设计(上)