框架篇

推荐系统本质是对用户不同行为,从海量物料中选取用户可能感兴趣的物料进行展示,通过策略、算法、规则等途径引导用户产生点击或其他交互行为,那从用户打开特定app起,到展示出相关内容到底经历了何种操作,海量的物料是怎样被筛选出来?如果业务越做越大,用户和物料数据积累越来越多,仅靠规则不能进一步提升用户对物料感兴趣程度,那么该如何升级成为推荐系统为用户带来更好的浏览体验?本系列文章将展示如何从0搭建一套较为完整的推荐系统,进而一窥其内部原理。

高屋建瓴,各公司业务系统和场景各有不同,系统有繁有简,技术栈和使用细节千差万别,要搭建推荐系统,我们先把系统模块和数据流梳理清,大多都具有如下模块和流程。

如图所示,数据流实线为在线流程,虚线为离线流程。一般在线流程指用户实时访问系统用于计算及使用的服务,离线流程指跟用户请求无直接关系可对数据单独统计计算的过程。

物料数据

首先要有被推荐的物料数据,而且必须要多,非常多,几十上百个的也就可以先退出 了,与其花大量精力搭建推荐系统,还不如多开垦业务场景,丰富内容,一把好枪还需要充足的弹药供应才能发挥威力不是。一般来说可推荐物料需要数万到数千万甚至上亿,每个物料具有唯一id,除此之外还应有其自身的各类基础信息,各家业务不同信息也各不相同,例如类型(文本、视频、图片)、类别(新闻、娱乐、体育)、标签(宝马,奥迪,东坡肘子…)、时效、地域等等。物料数量规模庞大,再加上自身各类信息,那需要存储的物料池也会成倍增加,对不同规模的数据量就得盘一盘该如何存储,这里先简单抽象成一个物料池。

用户数据

有了物料数据还需要有用户数据,一般是系统日志通过埋点记录用户各类行为,通过日志收集系统计算处理,将有效的用户行为数据结构化并落到存储空间中,一般用数据仓库进行管理,便于后续分析、计算。用户行为一般是用户的浏览、点击、播放等普通行为以及点赞、评论、转发、下单等深层行为,结合访问时获取到的用户设备、时间、地域等,加上各行为打上时间戳,日积月累就能构造出一个用户的多维度行为轨迹和画像。

用户画像

用户数据结构化落仓后就方便后续对用户行为的统计分析了,结合用户时序信息,可以计算出所需维度的用户画像,例如用户的兴趣点标签,偏好什么内容,习惯在什么时段访问,常用的地理位置信息,通过浏览内容判断用户年龄段和性别等,深入些的后续还可进行用户聚类、分群等分析处理。

实时计算

这里还需要一个实时计算的环节,用于通过实时收集日志并解析物料与用户的实时统计信息,例如物料的曝光数、点击数、评论数等,可以丰富物料的基础信息;对用户来说可以收集用户实时曝光、点击及其他行为的实时数据,用于后续算法特征处理或在线规则处理。

算法模块

物料和用户数据齐备,就轮到推荐算法上场了,当然这里也是一个大模块,上面的数据虽有,但此数据非彼数据,算法需要用的还需要转化为特征和样本数据,绝大部分算法模型还是很挑食的,喂进去的数据必须要经过处理,否则再好的模型面对噪声数据也不会有好的结果。数据处理好,选好模型就可以训练了,结果不错皆大欢喜,效果不好不能直接把锅甩给模型不给力,还要分析数据、调整参数,经过几个来回后得到一个还不错的模型,就可以准备给用户使用啦。如果数据规模庞大还需要分布式训练。

推荐引擎

如果业务要求实时性不强,用户和数据量都不是很庞大,那么在离线按小时或天的频次直接计算各个用户可能的偏好物料即可,无论通过用户画像偏好匹配物料,还是使用训练好的模型进行直接预测排序,只要能满足业务要求就是一套好系统。但很多场景用户访问要求实时性高,业务特性复杂,就需要一套专门的推荐引擎将推荐系统及依赖的各模块整合起来,包括构建倒排索引、召回、排序、rerank及其他依赖模块,便于灵活开发与部署。另外评估推荐系统效果也需要科学的分桶实验系统也需要在推荐引擎模块中实现。

数据报表

截止目前一套完整的数据流已经可以跑通了,也可以为用户推荐计算好的结果,但还需要一个看起来不起眼却非常重要的模块——报表数据,用来展示推荐系统整体效果,包括AB实验效果,分标签、召回等维度效果等,用于后续迭代优化时提供数据支撑。

至此,推荐系统的蓝图已构思完毕,数据可以在纸面上完全流动起来形成闭环,不断积累数据,不断迭代算法策略,不断提升效果指标,不断产生业务收益,不断提升程序员的工资,想想是不是很开心?后面我们就把上述的这些坑一块一块填起来,完整实现一套推荐系统。

数据篇

当前大数据的时代数据已经是各大小公司的重要资产和护城河,推荐系统也是对这些数据结合公司业务的合理再分配,将历史数据与现实流量打通,针对用户产生的行为数据挖掘出画像信息,结合物料信息共同构建出个性化的推荐模式。从时效角度可以分成离线数据与实时数据,两套流程可分别计算与存储;从用户和物料角度也可分别对其所属数据进行存储和计算。相对第一篇推荐系统框架,数据部分的角色如图1中黄色元素表示。

图1 数据架构所处位置

详细数据部分的拆解如图2所示,物料数据需要一个统一模块管理生成的所有物料,结构化后同步到资源池中,供后续正排及倒排的创建。用户日志通过kafka收集后,基于不同的计算方式消费日志数据,定时落入数据仓库或实时计算用户或物料数据,数据仓库中存储原始日志表和基于其生成的各种中间表,用来计算用户画像或统计物料信息。

图2 数据详细架构

1、物料数据

存储

物料资源根据各家家底业务不同可谓千差万别,有图文、视频、图像、音频、社交关系等各种类别,但通常都要有物料唯一标识id,以及其自身特有的属性信息如标题、类别、标签、关键词等,很容易构建结构化数据供后续存储。存储方式根据数据体量大小、使用方式、当前团队技术能力来选择,通常是mysql、redis、文件、MongoDB、elasticsearch、Lucene等,每种方式都够单开一篇介绍其特点与使用方法,不是本系列内容的主旨。

既然是从零搭建推荐系统,我们暂且以redis的方式作为存储方法,容量够大可扩展,读写及使用较为方便,但key-value的存储结构注定key为物料id,value为json字符串用于结构化物料的其他信息。确定存储方式后,内容生产方或管理方就要定时将物料数据结构化并同步到redis中,过期数据也要及时清理(其他存储方式同理,后面涉及到物料存储的流程基本一致,跟存储方式无关)。

正排及倒排索引构建

基础数据备好就该为使用做准备,通常使用方为推荐引擎及算法特征,尤其在推荐引擎侧常用到物料的正排及倒排索引。倒排最初是搜索的概念,一般根据物料某一字段或某些字段组合反查物料id,例如结构化数据如下:

如果按关键词建立倒排索引,倒排方式按物料时间倒序,“梅西”关键词对对应倒排索引如下:

正排就是相对倒排的概念,本质还是代表物料的各种基础信息。

在应用倒排和正排信数据时,每次推荐直接读取redis无论对存储和线上推荐引擎性能压力都比较大,为便于推荐引擎使用正排及倒排信息,一般将redis内的所有物料信息定时全量同步到内存中,正排构建数据结构并填充值,倒排可根据业务需要建立倒排索引关系。如果业务量较轻,可直接在推荐引擎中加载,这样的好处是后续应用都可直接在内存中使用物料数据信息,使用快捷。因为是基础数据,每次推荐引擎服务启动都要加载并建立倒排操作,数据量过大时服务启动会耗费大量时间,定时同步也会耗费计算资源,对测试和线上都不友好,因此会把倒排及正排操作与推荐引擎解耦,以服务化的形式独立提供功能,也为其他模块的使用带来便利,但这样会增加服务间的接口调用。因此是选用高耦合还是解耦的方式使用数据,需要根据系统存储和性能对数据的承载力来判断选择。特别是存储方式如果选择es,那么天然自带倒排索引查询功能,适用于解耦方式。

图3 物料数据与应用耦合及解耦方式

2、数据仓库

数据仓库也是一门大学问,非自己专长就不多妄言了,也非本文主旨,数据仓库是数据库的升华版,可以结构化记录下用户及物料的历史数据,便于查询及挖掘使用。数据仓库所有数据来源于日志,通过kafka实时收集并消费日志信息,通过一定计算逻辑整理成结构化数据落入数据仓库中,数据表有的是原始表,有的是根据原始表计算的二级表,根据使用方式不一而同,但目的都是为方便计算用户与物料信息。其中最主要是用户维度,主要有行为、画像及访问的上下文。

用户行为

系统日志全量记录用户在业务系统或app中的行为,其中有效行为如浏览、点击、播放、点赞、评论、转发,结合对应操作的物料信息,通过时间的积累从仓库中拿到这些信息后就能完整刻画用户在该系统中的访问路径、行为习惯、使用偏好等。这些数据作为原始用户特征可为算法提供充足的训练数据,如长用的基于时间序列算法RNN、GRU等,基于图神经网络的GNN、GCN等,以及构建用户embedding向量的双塔模型、item2vec等,这里放在后续推荐算法部分单独介绍。

用户画像

通过统计挖掘的方式,计算出用户对特定维度的偏好,以带权列表的方式刻画出不同用户的兴趣偏好,以达到千人千面个性化推荐的第一步,数据直观,可解释性强,有明确的画像数据也可不止用于推荐系统,为公司其他业务层面的个性化也打下基础。挖掘方式主要还是MapReduce技术框架。

常用统计方式计算一定时间窗口内(用于区分短期兴趣和长期兴趣)用户点击、播放的物料,并通过物料自身属性权重计算对某一个属性值的兴趣程度,尤其对于点赞、评论、转发等深层行为表明用户对这类内容更具偏好性,需要加权处理,可简单归纳为如下公式:

score为关键词k的兴趣得分,分子是用户对所有行为物料中带有关键词k的兴趣累加,i为用户行为中的第i个物料,α为对该物料行为权重,比如点赞就比点击的权重要高,ω为关键词k在物料上的权重分,f(t)是一个时间衰减函数,表明用户在某一时刻对物料关键词的兴趣衰减程度,距离当前时间越长,感兴趣的衰减程度越高。分母是所有行为物料的个数。所有关键词计算出score值后再进行归一化排序,即可得出用户在关键词兴趣上的偏好序列。其他维度依赖的计算方式类似,但各维度计算结果都是带权重分的多值列表,毕竟用户也没实打实告诉你他的真实偏好(可能他自己也不知道)。

通过这种方式可以初步定量计算用户偏好,但验证和评估不好定量,而且只考虑显示行为反馈信息,隐式反馈如曝光未点击、停留时长这类“不感兴趣”的影响未考虑在内,需要后续再去优化迭代。

还有一类画像是通过聚类、embedding等算法计算出的用户隐式画像,例如通过用户行为聚类/分群会给特定用户标记上类别id,有的具有含以上的不可解释性。embedding更是将用户兴趣或用户表示为一个向量,隐式的表现出用户兴趣。这也是通过对用户历史行为数据计算得到,聚类算法如kmeans、pca降维等,embedding方式如前文提到的item2vec、yutube dnn等。

其他诸如用户上下文信息,这类主要是用户访问时的时间、使用设备、系统、城市地域等,也可以输出在用户画像当中,供统计或用户特征。

此时各类用户画像信息经过计算还是存储在中间数据表中,如果推荐引擎线上使用还需要转存到redis中,为节省redis访问最好一个用户id作为key,所有画像信息用json字符串作为value。但面临到问题就是不同计算任务可能只计算一类画像,但最终存储结果势必要合一,整合过程中要兼顾各类任务的异步性。另一种做法是搭建画像服务,画像服务统一定时同步各类离线任务计算的画像结果,同时也便于整合后文介绍的实时流画像,通过接口调用方式给使用方解析使用,灵活可扩展,通过日志系统也便于分析计算过程中的异常。

图3 用户画像redis同步方式与画像服务方式

物料挖掘信息

数仓中记录用户的行为,也间接记录了物料被消费的状态,通过挖掘手段能对物料的历史整体表现作出评估,作为物料特征供算法模型使用。例如统计出物料近3天、5天、7天、10天、15天及30天的曝光和点击数,进而计算分阶段的ctr数据,即可拿到物料在时间维度上的效果表现,作为特征加入到模型训练中,学习到的特性可以预测一个相似物料在未来一段时间内的效果走势。这类数据可以定时计算作为中间结果存在单独的数据表中,后续使用可以直接读取。

3、实时流计算

实时流用于实时从日志中获取有效信息,对于用户访问频次较高的应用属于必需品,可以反馈用户的实时行为和物料的实时统计信息,流式计算工具如flink、storm、spark,可针对业务特点任君挑选。

一般从数据仓库中生成的离线画像数据是天级或小时级的定时任务,对一些需要实时反馈用户行为的场景无法满足要求,例如用户刚曝光过的数据需要过滤或降权,刚点过的物料在一刷推荐时可以推些相似的物品,一些负反馈信息需要记录并实时生效,通过实时收集的用户日志根据不同需求逻辑进行实时计算能快速获取这些信息,反馈给系统快速做出变化,是一个好推荐系统的必备要求。根据功能不同实时计算结果一般输出到不同的redis key当中,供线上取用。

物料侧的计算目标类似,例如物料被曝光、点击、点赞等数据的实时情况,特别是新物料经过冷启动曝光后,能快速反映出这个物料的效果走势,判别出物料质量优劣,影响其后续的推荐策略。物料的实时计算结果也存在redis当中,一般供数据侧如物料正排信息和建立倒排索引使用,倒排中可能会影响物料的实时热度分从而影响倒排链的变化。

4、数据应用

数据自从被生产出来后的命运主要是被推荐系统消费,在系统当中循环,如同形象好气质佳的鲜肉小哥只能沦落到工厂流水线中拼命工作。而另一类特殊的数据就如同明星般被放在聚光灯下,接受大众的赞美与八卦吐槽,这就是外展及监控数据,一般通过专门平台展示给老板及各使用方,推荐效果的整体好坏,各策略实验对ctr的影响,用户行为的整体情况,一篇物料的历史及实时表现,都需要这类数据加持,因此也需要从数据仓库与实时流中分别计算各取所需,加之web页面炫酷展示,季度的kpi,岁末的年终奖,全依靠数据表现来实现了。

引擎篇

如果把推荐系统比作一辆汽车,那推荐引擎可以看做是传动系统,把发送机、变速箱及底盘三大件串起来,为整车提供正常运行。本坑主要介绍推荐系统的中场核心推荐引擎,在推荐系统中的地位如图。

图1 推荐引擎是推荐系统的中场核心

推荐引擎能够实时给用户提供推荐服务,用来解析用户请求,将物料数据与画像数据打通,匹配符合用户兴趣的物料,同时调用算法召回,控制整体候选集多样性。通过排序预测服务为候选集打分排序给出用户可能感兴趣的结果,并根据业务和体验规则对推荐结果进行重排序,呈现给用户最终结果。同时推荐引擎还承担着线上AB实验精准分桶的功能,保证实验流量的科学分配,提升实验效果的置信度。因此涉及推荐引擎核心功能的主要有用户请求解析、实验分桶染色、召回、排序、重排等模块。索引部分在上一篇文章有过概述,可根据系统规模评估是否纳入到整体推荐引擎中。

实验染色

AB实验已成为绝大多数互联网公司面向用户展示不同策略的通用做法,尤其推荐系统千人千面,线上系统会有各种策略、算法需要快速迭代验证效果,科学准确的实验分桶策略能够均匀分配实验组对照组流量,同时互斥的实验需要互不干扰,例如在召回阶段做的实验A和B需要互斥,而和重排序阶段的实验C互不影响,在切分流量时需要考虑分层机制,同一层实验要求互斥,流量互不影响;不同层之间的实验并不相干,流量可以打通。目前基本思想都是参考Google的论文:《Overlapping Experiment Infrastructure: More, Better, Faster Experimentation》,具体可根据公司业务特点进行实现。

分层实验框架原理

一般实验配置通过一个管理平台,底层通过mysql数据库管理各实验增删改查,用户侧则根据用户id(cookie、设备id等)用于hash分桶标识,这里展示一个简单的分桶逻辑。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
# 遍历所有实验,exp_list是从实验平台获取的有效实验列表 
for exp in range exp_list:
# exp_name为唯一实验名,主要用于分层,配合用户deviceid,保证本层hash是唯一的
hashvalue = deviceid + '-' + exp.exp_name
# 将字符串哈希成int值并模100,这里看做每个实验为100%流量,同层互斥实验从这100%中切分流量桶
# 例如:{bucketA:20, bucketB:40}
hashint = hash(hashvalue)%100
# 存储当前用户走哪些实验桶
exp_map = {}
# 遍历该实验下所有分桶, 找到符合流量分配的桶后记录在exp_map中
for bucket_id, bucket_value range exp.buckets
: if hashint < bucket_value:
: exp_map[bucket_id] = True
break
else:
: hashint -= bucket_value
return exp_map

后续线上做实验时,只需在代码中判断若exp_map[bucketA]==True,则用户需要走bucketA实验桶控制的实验逻辑。

召回

物料池中的物料千千万,最终曝光给用户展示的只有几十甚至十几条,如果直接对所有物料计算排序无疑成本非常高,需要对物料进行初筛也就是召回用户可能感兴趣的一批候选集,一般是几百到一千条左右。召回的方式主要分为基于兴趣内容类,协同过滤类及算法类,最终候选集的呈现可以是这些召回的组合。

兴趣内容召回

这时上篇内容介绍的用户画像和索引就该出场了,基于用户兴趣画像,匹配不同维度物料,用户喜欢体育类的,那就从体育类内容中选取最新/最热内容召回,非常直观且可解释性强。根据不同维度组成一级或多级索引可以组成多路兴趣召回,因为用户画像中各维度兴趣点都有权重,那召回对应物料的数量可根据权重自适应调整。有这些基础召回作为候选集,推荐系统就可以向后进行排序、重排序等工作,基础通路就可打通。

协同过滤召回

协同过滤Collaborative Filtering可分为基于用户的和基于物料的,基于用户的原则可理解为“将跟你看过相同物料的用户,他们看过的物料推荐给你”,即User Collaborative Filtering——UCF ,基于物料的原则可以理解为“将你看过物料的相似物料推荐给你”,即Item Collaborative Filtering——ICF,所以根本在于找到相似用户或相似物料的过程。

计算用户相似有Jaccard相似度、余弦相似度、皮尔逊相似度等。以较直观的Jaccard相似度作为基础版本的UCF,例如有用户A、B,两用户的相似度可以用sim(A,B) = |ra ∩ rb| / |ra ∪ rb|,ra、rb分别为两个用户产生行为的物料集,得分越高代表用户越相似,则基于UCF的召回流程如下,其他得分类相似度计算都可共用流程。

离线部分
1、拿到所有用户对应操作行为的物料,及user: item1,item2,item3…
2、对全量用户计算两两用户间相似度得分
3、对每个用户获取到得分排序最高的topN用户
4、获取topN用户的历史行为item并与目标用户的item做去重
5、将去重后的item存入以目标用户为key的redis中,userid:“item1,item2,item3…”
在线部分
1、获取用户id,读取redis拿到物料召回
基于ICF召回需要计算物料间的相似度,直观可以理解为文本、音频、图像、视频等物料类别中,通过NLP、图像理解、视频理解等方式综合计算出物料的向量表达embedding,通过embedding聚类出各物料最近似的物料,从而计算得到目标物料的相似物料。

另一种应用最多的还是基于向量做内积来计算相似度,所以问题又转化为如何得到用户和物料的向量embedding,这类方法就很多了,从MF矩阵分解到item2vec从用户直观行为计算用户和物料embedding。利用神经网络如yutube dnn及最新火热的图卷积网络GCN通过用户对物料行为的隐式特征表达构建更为丰富的embedding信息,此类模型训练计算更为复杂但在大数据量学习用户行为更加准确。通过高效的faiss服务快速计算embedding间的相似度,从而拿到用户可能感兴趣的物料。这类方法在使用时可以归纳为如下流程:

离线部分
1、拿到所有用户对应操作行为的物料,及user: item1,item2,item3…
2、搭建模型训练出各用户和物料的embedding向量
3、可以通过faiss找到目标用户的相似用户(群),获取相似用户的物料(同传统UCF)存入redis
在线部分
直接通过redis获取目标用户的物料候选集(同传统UCF)
或者
拿到目标用户近期操作的物料id,通过faiss服务获取这些物料embedding距离最近的物料候选集(传统ICF)
或者
通过目标用户id,直接从faiss服务中获取同用户embedding距离最近的物料候选集
可以看到,通过计算用户及物料的embedding,使用时更为灵活,从效果上通过向量可以将用户和物料的高维稀疏特征转化为稠密特征,同时也可表示出用户和物料的隐含关系。

算法类召回

严格来说协同过滤和各类embedding也是算法,但这里算法类召回主要聚焦于通过特征和模型来对所有物料进行排序,筛选出topN物料进入候选集,也就是常说的粗排。因为要在线对万到千万级别的物料进行排序,对计算性能有严格要求,因此这类算法需要模型较为简单,特征较少,主要使用线性模型例如LR、FM、GBDT等。

离线通过记录的用户、上下文及物料特征及样本数据训练好模型并同步给预测服务,线上获取到用户id及用户上下文,传入预测服务生成用户特征、上下文特征,结合物料特征及模型计算各物料的打分,排序后取topN作为召回集传回推荐引擎,流程如图。

上述三类召回可以组合使用,一般为多路召回共同构成候选集,在召回过程中需要根据业务规则对用户曝光、点击或负反馈等数据进行过滤,同时召回层面也需要兼顾用户兴趣与多样性探索,否则用户可能陷入到细化看的内容越来越多,后面精排的操作空间较小,用户未知偏好的内容推不出来。因此需要在召回阶段让候选集类别更多样,协同过滤的原理能够产生一定多样性但也是在相似的圈子里打转,可以通过对更多类别或相似类别进行探索召回。另外多路召回会带来的问题就是各路召回的数量不好控制,如果是统一参数值设定多少才合适?如果要个性化参数就需要按用户实际召回的偏好来制定规则甚至一个小模型来计算,这里也是后续要优化的点。

在召回阶段还需要重要一环即新用户和新物料冷启动。新用户可以在进入应用时产品层面给出一些偏好选项来做基础画像兴趣,同时根据用户地域、设备信息、访问时段等信息协同出一些热门内容,加上各类别的热门内容,综合出候选集逐渐探索出用户兴趣及行为。新资源冷启是当物料新入物料池时,没有曝光点击等效果信息,虽然可以通过计算质量分等方式判断,但真正效果还需通过上线检验。可以将曝光量小于一定量(例如500)的物料单独建一个池子,通过ICF或embedding或用户兴趣单独进行冷启动召回,通过比较线上效果就可以判定物料的真实情况,结合质量分,效果差的资源就可以打入冷宫,不用进正式物料池给用户推荐了。

排序

也称精排阶段,针对召回出的候选集进行排序得到用户最可能感兴趣的内容,需要打分的物料只有几百上千条,因此可以使用更多维度的特征和复杂模型进行线上预测,这块流程同算法召回类似,统一调用排序预测服务即可,具体细节会放到本系列算法篇详述。初始搭建可以使用LR或GBDT等线性模型快速实现上线,作为baseline效果,后续通过不断迭代特征工程及模型调参,在线实验对比效果进行更新。

重排序

到这个阶段所有候选物料已经是按用户最可能点击的顺序排好,但这里需要重排来优化用户体验,例如同类内容的控量或打散,当然也需要根据用户行为进行策略上的调整,根据用户连续几刷点或不点来决定下一刷控量打散的度量等。同时还需要调整内容多样性来进行兴趣探索,特别是对于画像及行为不够丰富的用户。同时对于运营业务也需要在这里调整排序,比如时政内容的置顶、热点内容的加权、运营内容的提权或降权等。经过重排序后的所有物料,就整装待发,根据前端调用所需返回结果数量进行topN截断,展示给用户。

推荐引擎的本质是将各种功能模块串接起来,既保证各模块功能各自独立解耦,又将其有序统一,使数据流顺利流动起来。如果业务越做越大,在召回、排序及重排的逻辑越来越复杂,那可能需要用微服务架构将召回、排序(也可直接看做预测服务)、重排等模块分别抽离成单独服务,便于独立的团队维护独立的服务模块,同时也要尽可能优化网络接口减少网络开销。

作为服务端引擎,还需要有通用的监控信息监控各接口性能、模块性能、系统整体性能以及各阶段功能,这里就不展开说了。

算法篇

推荐系统自诞生之日起就是为解决海量物料如何高效分发给海量用户,一套高效的算法流程就是推荐系统的核心。如今火热的各类机器学习、深度学习、强化学习等都可以在推荐系统中大显身手,推荐也是AI在工业界最广泛的落地场景之一。推荐算法在推荐系统中的位置如图1所示,主要是通过离线或在线拿到特征及样本数据训练模型,将训练好的模型同步给召回或排序的预测服务,推荐引擎实时调用预测结果供召回及排序使用。

推荐算法在推荐系统中地位

如果更宽泛意义上,推荐内容的质量、类别、理解等都可通过各自AI算法计算,节省大量人工成本,通过NLP、音频、视频、图像理解等领域内的先进算法,丰富物料的正排信息进入资源池,如物料质量、物料类别、关键词提取,图像视频理解、音频转文本、物料属性的embedding向量等等。

各领域算法对用户与物料信息的丰富

推荐效果主要以提升ctr为目标,但转化率、完播率、停留时长等均可作为辅助指标,可以说只要能够抽象出问题并描述出要最优化的损失函数,有较丰富的特征及样本,那就一定能够用算法来解决问题。这里我们先以精排阶段的算法为例说明如何构建起完整的排序算法通路。

特征库/服务

算法需要数据,数据需要特征,特征是模型训练数据中最重要的部分,各类算法的本质也是根据现有样本分布拟合出一个最接近真实情况的概率分布函数,需要拟合的参数就是各个特征,通过这个函数即可获取特定用户或物料的特征下用户对物料的感兴趣程度(点击的概率),因此特征工程也是推荐算法工程师的必备技能,人工智能圈广为人知的调侃“人工智能靠人工”,在推荐领域的重要体现就在于通过分析数据来获取重要特征。

推荐系统连接的是人与物,特别是独特业务场景下的人与物,那么一定也会有独特的物料属性特征与用户行为特征,针对深入理解业务的基础上构造好的特征,那推荐算法出来的结果也就成功了一半以上。从人和物的角度,特征也分为物料特征、用户特征及上下文特征,上下文也可算作用户特征的一种。用户特征一般通过明确记录或统计挖掘得到,如用户的地理位置、访问时段、使用设备、性别年龄(可能通过填写资料获取)一般在访问时即可拿到;挖掘特征通过历史用户的操作行为,统计用户的画像偏好。物料特征一般是物料自身属性及其统计数据,例如类别、关键词、主题等固有属性,以及历史一段时间窗口内的效果统计如曝光、点击、点赞、转发等。从直观含义看可分为类别特征和数值型特征,对不同特征也要多种特征工程处理方式,这里推荐一份slide讲解特征工程,很香!原始出处要翻墙,为方便大家直接搬运了。

Feature Engineering.pdf

特征工程是一项实践性很强的工作,基本的技术方法就那么几种,但真正用来调好模型的特征工程方法一般网上也很少,原因之一就在于是跟自己公司具体业务挂钩的,不具有普遍性,即使放出来也只适用于自己公司业务,无法放之四海而皆准,可以看下各大厂主要产品线的推荐系统特征工程是如何做的。

腾讯技术工程:浅谈微视推荐系统中的特征工程

这里用户特征,包括上下文特征,可以根据用户离线的行为日志统计,类似用户画像,假设此时用户属性类别、各维度偏好、对各行为的统计量等都已用特征工程处理完毕并结构化存入hive表,同理对物料在资源池获取属性类别特征,通过客户端日志获取物料各维度统计类信息,保存至hive表,再通过一个定时任务将hive内的特征数据整合,这样将离线计算的用户及物料维度特征保存至hive表,同时更新至redis供线上实时获取。

特征构建

有了特征就能方便的构建出模型训练样本数据,这时要针对推荐效果指标来构建样本,对于ctr指标来说一般是分类问题,使用用户对物料是否点击作为label,对于视频类播放时长指标一般可作为回归问题,用户对物料的播放时长作为样本y值,这里以ctr作为评价指标,正样本为用户点击物料,负样本为用户曝光未点击物料。

训练数据

说到算法并无太多神秘之处,如果了解基础的机器学习原理,各类算法只是针对大量样本数据的一个拟合过程,拟合出一个接近真实数据分布的概率分布函数,即所谓的“规律”,大量的样本正是这条规律的基础,算法只是用数学的方式来求解。通过用户行为日志可获取全量用户曝光点击物料信息,通过用户及物料特征库抽取特征,从而构建出样本矩阵,通过离线计算保存到样本文件。

接下来需要对整个样本集做处理,否则会引入大量噪声,不能让模型很好的拟合出样本分布。

非真实用户访问样本

例如爬虫、机器人等大量非真实用户的频繁访问,带来大量高曝光未点击行为,会严重影响样本数据分布,一段时间窗口有大量相同用户id频繁访问远超正常访问量的均值等,刷次数方差较大的数据需要去除

极少行为用户样本

这类用户样本虽然是真实行为,但极少的行为并不能为其在模型中找到属于该类用户的“规律”,或者说引入这些数据后,模型会开始学习这类用户的数据分布,对整体分布的拟合带来噪声,易引起模型过拟合。通常对这类用户可以看做类似新用户,通过用户冷启动的手段为其探索兴趣补充推荐。

特征缺失值及异常值等处理

这里参考特征工程处理方法,针对方差较大的少量异常值做抛弃或均值处理,缺失值用均值或中值代替等

正负样本处理

机器学习中正负样本的选取也直接关系着训练出的模型效果,在推荐系统中不同公司也有针对自家业务采取的样本划分方法。

一次请求会产生N条推荐结果,但大部分手机端通常用户只能看到其中的m条,m<N,通过客户端埋点计算出用户真实可见曝光的物料,在这批物料中选取点击与未点击样本直观上一次曝光中可能有点击或无点击
早期yutube推荐中,会对所有用户选取相同数量训练样本,可以同时避免低活跃用户和高活跃用户对整体模型的影响,使训练的模型更符合绝大多数用户行为
对于有曝光无点击行为的用户,其曝光未点击的负样本可随机选取,这样可以学到这类用户“不感兴趣”的部分
样本在通过定时任务整合时需要做shuffle打散,避免同类用户样本数据扎堆引起数据分布偏差,在训练模型时,也通过batch训练方式中每个batch的样本也进行shuffle打散
总之正负样本处理还是要根据深入理解业务和用户行为基础上进行调整,可以让模型学习到更适合的效果。

生成样本数据后,将样本随机分成训练集与测试集,一般为七三开或八二开,丢给模型来训练了

模型训练

首次搭建排序模型可以先用基础模型如LR或GBDT跑出一个baseline快速上线,后续逐步迭代为复杂模型。推荐算法模型一般经历了由简入繁的过程,数据量不断增大,模型不断复杂,大规模数据集下深度学习模型已经逐渐成为主流,但这也是行业头部公司所独享,只有他们才有足够的数据和算力来支撑庞大复杂的模型,绝大多数公司在中等数据集下,仍然使用主流的线性模型,通过分析用户行为及数据,构建特征工程及样本数据优化,得来的效果要比深度学习模型更好。

模型进化:lr/gbdt->fm/xgboost/dnn->LR+GBDT/wide->;deep/deepFM->embedding->GNN/GCN知识图谱

模型训练过程根据使用的框架不同,大体流程可以统一成下面的伪代码

1
2
3
4
5
6
7
8
9
10
11
12
13
# 从文件读入训练集与测试集 
train_data = read(TRAIN_DATA_FILE)
test_data = read(TEST_DATA_FILE)
# 对数据处理并生成样本与特征数据结构
y_train, x_train = preprocess(train_data)
y_test, x_test = preprocess(test_data)
# 实例化模型,传入参数
# 对经典模型各主流框架中只需传入参数,若需对模型结构调整需要自己实现模型结构
model = SomeModel(y_train, x_train, y_test, x_test, batchsize, optimizer, learning_rate, other_param...)
# 开始训练
model.fit()
# 评估模型效果
model.evaluate()

通过优化训练数据、优化模型超参等方法训练得到AUC指标较好的模型,可提供给线上应用。模型训练可根据数据量和计算复杂度离线按天或小时定时训练更新。

线上预测

通常线上使用预测服务的形式实时提供模型推断功能,这时需要通过推荐引擎接口将待排序候选集的物料id、用户id以及请求上下文信息传给预测服务。预测服务中也分为特征抽取、物料打分排序、模型同步校验等模块。通过传入的物料id及用户id,可以从特征库中在线抽取特征,结合上下文特征得到所有候选集的特征信息,进而通过模型中各特征权重,计算每个物料的打分。这个过程中注意被抽取的特征id要同训练好模型中的特征权重id保持一致,同时各物料特征抽取和打分过程可以通过并行化方式提升系统性能。训练好的模型由离线训练流程定时同步到线上预测服务机器,注意同步时需要同时把模型的checksum一并同步并在服务端进行校验,当同步失败时仍使用缓存的上次同步模型进行预测,避免数据不一致。候选集物料被打分后进行整体排序,结果返回给推荐引擎。

预测服务

到此通过算法模型给出个性化排序的流程就打通了。关于模型打分步骤对于基于DNN的模型TensorFlow有专门tf.server用于部署生产环境的模型预测服务,TensorFlow也有为服务端语言golang/java/C++等专门适配

对于传统机器学习模型LR、GBDT等,可以将模型特征id及权重直接序列化为文件,在排序服务端定时加载解析,打分预测时直接使用特征id及其权重值运算即可。

番外

推荐系统算法侧主流程架构大体就是这样,已经可以跑通一个基本模型并应用于线上观察效果。后续算法侧的迭代优化,一方面可以跟进业界前沿的模型方法,一方面通过分析用户行为与业务数据来尝试在特征和样本数据层面做优化,而后者可能才是产生更直接收益的法宝,毕竟不是所有公司都能有Google阿里家那种量级的用户数据,复杂模型应用起来因为过拟合的问题甚至带来负向效果。反过来说大厂在模型上的创新也是基于不断分析累积用户行为的经验得来,比如yutube关于视频推荐的论文

魔鬼吊儿郎:Youtube 排序系统:Recommending What Video to Watch Next

也是分析用户点击一个视频不一定是真喜欢,而可能和正好排在前面有关,从而设计模型结构将排序位置特征引入模型,通过多目标学习将这种实际样本“有偏”的影响消除。


参考文章:
从零搭建推荐系统——框架篇
从零搭建推荐系统——数据篇
从零搭建推荐系统——引擎篇
从零搭建推荐系统——算法篇