【实践篇】推荐算法PaaS化探索与实践
为什么是PaaS化:首先,我们认为PaaS化是一个比较好的解决办法和方案,因为它提供了一种解决超级公司复杂业务的可变化、可扩展、可复用能力的基础框架,在这样的框架下,可以极大的释放重复劳动力,实现业务的高效提升;其次,我们也看到一些行业中的其它玩家,他们也是在自己的业务中台基础上进行PaaS化,并通过PaaS化提供的能力不断的孵化自己的创新项目,去减少他们的人力投入,减少他们的投入成本,而且他们还推出了很多用于商用的PaaS化工具,为实现更大的社会价值去创造机会;因此,我们认为PaaS化应当是我们当前会选择的一个比较好的解决问题方法; 如何助力推荐业务能力提升:通过梳理推荐场景下的共性需求,在可变化、可扩展、可复用能力的基础框架内,我们对业务需求进行分类和能力抽象,提供阶梯化的应对策略;针对通用类需求,我们提供一站式个性化推荐能力,满足业务快速接入的诉求;针对定制类需求,通过打造高效易用的PaaS化工具,一方面,减少算法人力的投入,另一方面,缩短业务需求交付的周期;
新增推荐位类业务需求
依据推荐场景划分,大致可以分为首推、我京、商详、购物车、短视频、直播、频道等推荐场景的接入; 依据个性化推荐能力划分,大致可以分为数据接入、召回、排序、过滤/调权、多样性、渲染等推荐算法模块以及AB实验、数据分析能力; 依据运营诉求划分,大致可以分为提权,定投,非定投,定坑等扶持能力;
已有推荐位推荐策略迭代优化类业务需求
效果提升类业务需求:大致可以分为新增商品底池、召回新增数据源、业务标签/特征因子接入模型、扶持类、数据分析等; 用户体验类业务需求:大致可以分为调权/过滤、负反馈、多样性排序、新颖性、多素材穿插等; 可运营类需求:大致可以分为特殊商品流量扶持、赛马机制、提权,定投,定坑等可运营能力;
作为个性化推荐能力的提供者,我们希望通过业务赋能技术,通过推荐算法PaaS化,将推荐系统透明的展示给大家,在重新认识推荐系统的基础之上,更好的推演未来;我们将推荐算法PaaS化分为数据/算法组件/数据分析/算子/场景模板/服务共6个一级能力、20个二级能力,具体如下:
| 一级能力 | 一级能力定义 | 二级能力 | 二级能力定义 |
| 数据复用 | 推荐各个环节的数据复用 | 召回数据直接复用 | |
| 召回数据简单加工复用 | |||
| 排序模型文件复用 | |||
| 代码(算法组件)复用 | 非模型召回 | 冷启召回、画像召回、相似相关召回等(每类召回源之间的区别在于调用的计算脚本不同) | |
| KNN召回 | |||
| 精排模型 | |||
| 数据分析复用 | 基础中间表 | ||
| 项目中间表 | |||
| 算子复用 | 包括算子相关功能的复用,和关联数据复用 | 过滤算子 | |
| 调权算子 | |||
| 置顶算子 | |||
| 去重算子 | |||
| 渲染类算子 | |||
| 多样性算子 | |||
| 场景模板复用 | 全站商品综合推荐
商详 | 为你推荐套餐首页feed流形式功能,基于用户行为偏好和商品相似相关的综合推荐 | 多素材支持(店铺、排行榜、图文、聚合类素材),支持配置knn召回,支持业务调整模型目标,业务自主配置模型特征 |
| 主商品推荐套餐商详、购物车、针对有入参商品的场景 | 支持入参商品的相似相关召回,免运费凑单推荐(价格重量过滤),同店铺商品推荐,支持自营非自营过滤,支持业务指定类目的加购弹窗推荐,支持业务调整模型目标,业务自主配置模型特征,LBS推荐 | ||
| 商品池推荐营销活动(年货节等)、tab排序,tab分类商品推荐,门店+suk推荐,O2O类型推荐 | 支持tab排序,基于tab入参的排序,品牌推荐,新场景的大促需求,秒杀等推荐功能:基于时间召回、过滤功能、特殊底池的创建和召回(kv) | ||
| 服务复用 | 单素材服务单品 单店铺 短视频 好物集市 ... LBS | ||
| 过滤服务 | 已有 | ||
| 精排推理服务 | 已有 |
推荐算法PaaS化能力建设
推荐算法组件化
推荐算法组件化示意图
通用算法能力平台化
平台化的主要目的是简化推荐算法组件使用的复杂度,因此,我们对平台工具的要求是具备可用、可视、可改的特点;值得注意的是,平台化这里我们可以分为两个大类,其一是推荐能力全链路的平台化,目的是能够快速支持新增推荐位这类业务需求;其二是推荐算法模块的平台化,通过这样的平台工具,希望能够快速支持已有推荐位推荐策略迭代优化类业务需求;
针对推荐能力全链路的平台化,我们和产品、架构、平台侧合作,通过打造丰富的推荐场景模板,并提供通用的个性化分发能力,满足业务快速接入的诉求;具体来说,对于业务方对不同推荐场景接入的不同诉求,PaaS化项目组已经建设了诸如全站商品综合推荐、主sku相似相关推荐、业务灵活底池推荐、全渠道门店+商品推荐、小助手商品推荐等多类通用模板,在这些模板上,推荐算法PaaS化依据可变化、可复用的基础逻辑,通过提供丰富的推荐策略供业务方选择使用,覆盖更多新增推荐位需求;
场景模板列表示意图
针对推荐算法模块的平台化,我们计划和平台侧合作,通过建设一批提效工具,提高算法同学的工作效率,缩短需求的交付周期;
通用算法策略配置化
为了提升算法人员支持业务需求的效率,立足目前的推荐系统,同推荐架构合作,完成建设通用算子库,包括常用的取数、召回、排序、过滤、多样性等算子;在未来,这批通用算子可以直接进入小流量实验验证效果,降低算子配置的成本,提高代码的复用度,达到缩短需求交付周期的目标;
实现通用算法策略配置化前后的流程对比
定制化算法策略低代码开发
在支持业务需求的过程中,我们发现一个小小的算子开发也要耗费算法人员大量的时间,包括不限于:前期的开发沟通、策略的开发、环境部署、策略的验证及算子上线等,我们希望将开发流程进行精简,从而达到提效的目标,基于此,同推荐架构、平台达成共识,建设面向算法等专业人员的低代码开发工具,使定制化需求能够快速的通过低代码环节进行快速开发和发布上线;
整体思路,参考大数据的 easy studio 系统
推荐算法PaaS化工具建设 这里我们主要考虑定制类需求,比如召回新增数据源、敏感商品过滤、case排查工具等;对于定制类需求,我们希望提供一些高效易用的PaaS化工具,一方面,解放算法的重复劳动力,另一方面,缩短业务需求交付的周期;
场景模板开发
场景模板开发流程图
全自动召回词表/索引库能力建设
在我们承接业务需求的过程中,大部分情况下,每个业务方都有自己的商品底池,面对不同的商品底池,我们需要根据商品底池的变化动态的调整召回词表或者索引库,假如我们想要个性化分发能力完全自动化,那就需要打造一套新的召回词表/索引库构建工具,基于此,我们联合平台侧共同提出了一键底池/索引库创建落地方案,具体来说,算法人员将模板上所需的所有召回词表/索引库生产脚本进行抽象封装,预留入参及出参,平台侧通过前端界面获取具体召回词表/索引库创建的命令,并将该命令作为入参输入算法人员预先封装好的代码包,为了每天定时更新任务,同时自动创建BDP调度任务,代码包的出参通过DUCC回传给平台侧,作为后续创建词表/索引库的依据,从而完成召回词表或者索引库的全自动化创建;
一键底池/索引库创建落地实施
多业务排序模型支持
为了覆盖更多业务需求,在排序模块我们主要考虑不同业务模式下对排序能力的要求,比如,在下沉场景,更多的是需要提升UCVR指标,而主站的一些业务需求希望提升用户的UCTR指标,因此,为了兼顾多样的业务需求,我们梳理了三个常用的模型,分别是主站的多领域排序模型,特价版的下沉排序模型以及ToB的企业排序模型,将上述三个模型集成到每个模板里,并提供每个模型的介绍及使用说明,业务方可以根据需求的具体内容进行选择;
排序模型选择
需求梳理
啄木鸟的设计及开发
啄木鸟平台提供过滤、释放配置入口,由jrec平台提供; 在平台配置的长期规则可以下沉至离线,降低对线上服务资源的占用; 离线过滤能够灵活配置,且支持离线释放,减少手工操作成本;
啄木鸟落地实施
啄木鸟使用
啄木鸟建设好交付对应的算法人员进行使用,我们也提供了详细的使用手册供新人学习;
作为能力的提供者:通过对业务需求的梳理及PaaS化建设者长期的业务经验,立足现有推荐系统,通过对推荐算法的组件化,重新认识系统,重新规划流程; 作为能力的使用者:从被动到主动,切实感知到工具对效率的提升,善于利用工具,通过PaaS化工具,轻轻松松完成复杂的业务需求,只要想干,就可以自己把握需求交付的节奏
单素材服务能力建设
首先需要阐述一下我们为什么要建设单素材服务能力,一个重要的原因是场景模板仅能支持新增推荐位需求,且该类需求不能很复杂,而对于复杂的新增推荐位需求或者是已有推荐位的迭代优化场景模板无法提供支持;基于此,我们提出了服务复用的概念,具体来说,我们计划将单素材打造成一个一个的服务,算法人员专注的对服务进行全方位优化,而需要进行效果优化的新增推荐位需求以及已有推荐位的迭代优化则通过服务进行赋能,此举不仅可以减少算法人力的投入,还可缩短业务需求交付的周期;
算法组件平台化进一步升级