【实践篇】推荐算法 PaaS 化探索与实践 | 京东云技术团队

作者：京东零售 崔宁

1. 背景说明

目前，推荐算法部支持了主站、企业业务、全渠道等 20+业务线的 900+推荐场景，通过梳理大促运营、各垂直业务线推荐场景的共性需求，对现有推荐算法能力进行沉淀和积累，并通过算法 PaaS 化打造通用化的推荐能力，提升各业务场景推荐赋能效率，高效赋能业务需求。

• 为什么是 PaaS 化：首先，我们认为 PaaS 化是一个比较好的解决办法和方案，因为它提供了一种解决超级公司复杂业务的可变化、可扩展、可复用能力的基础框架，在这样的框架下，可以极大的释放重复劳动力，实现业务的高效提升；其次，我们也看到一些行业中的其它玩家，他们也是在自己的业务中台基础上进行 PaaS 化，并通过 PaaS 化提供的能力不断的孵化自己的创新项目，去减少他们的人力投入，减少他们的投入成本，而且他们还推出了很多用于商用的 PaaS 化工具，为实现更大的社会价值去创造机会；因此，我们认为 PaaS 化应当是我们当前会选择的一个比较好的解决问题方法；

• 如何助力推荐业务能力提升：通过梳理推荐场景下的共性需求，在可变化、可扩展、可复用能力的基础框架内，我们对业务需求进行分类和能力抽象，提供阶梯化的应对策略；针对通用类需求，我们提供一站式个性化推荐能力，满足业务快速接入的诉求；针对定制类需求，通过打造高效易用的 PaaS 化工具，一方面，减少算法人力的投入，另一方面，缩短业务需求交付的周期；

2. 方案设计

在对推荐业务需求梳理的过程中，我们将业务方诉求归结为以下两个大类：

• 新增推荐位类业务需求

1. 依据推荐场景划分，大致可以分为首推、我京、商详、购物车、短视频、直播、频道等推荐场景的接入；

2. 依据个性化推荐能力划分，大致可以分为数据接入、召回、排序、过滤/调权、多样性、渲染等推荐算法模块以及 AB 实验、数据分析能力；

3. 依据运营诉求划分，大致可以分为提权，定投，非定投，定坑等扶持能力；

• 已有推荐位推荐策略迭代优化类业务需求

1. 效果提升类业务需求：大致可以分为新增商品底池、召回新增数据源、业务标签/特征因子接入模型、扶持类、数据分析等；

2. 用户体验类业务需求：大致可以分为调权/过滤、负反馈、多样性排序、新颖性、多素材穿插等；

3. 可运营类需求：大致可以分为特殊商品流量扶持、赛马机制、提权，定投，定坑等可运营能力；

为了更高效的支持上述业务需求，推荐算法 PaaS 化围绕数据/算法组件/数据分析/算子/场景模板/服务 6 个 PaaS 化方向进行建设，以缩短需求交付周期为目标进行建设，切实提升使用者感知。

2.1 推荐算法 PaaS 化能力分类

作为个性化推荐能力的提供者，我们希望通过业务赋能技术，通过推荐算法 PaaS 化，将推荐系统透明的展示给大家，在重新认识推荐系统的基础之上，更好的推演未来；我们将推荐算法 PaaS 化分为数据/算法组件/数据分析/算子/场景模板/服务共 6 个一级能力、20 个二级能力，具体如下

上述分类是基于我们现阶段对业务需求的认知，随着推荐算法 PaaS 化的不断推进，定义及分类也会不断迁移；

2.2 推荐算法 PaaS 化能力建设

2.2.1 推荐算法组件化

推荐算法组件化是平台化、配置化的前置步骤，通过组件化，我们可以将算法能力可视化，让沉淀在代码中的一些信息展示在公众面前，让算法能力成为一种真正可传承的资产，高效赋能业务需求；具体而言，我们通过将算法能力抽象及封装，集成在一个可运行的代码包中，使用者通过算法组件的介绍及使用说明，就可以“插拔式”的应用在自己的业务领域；

算法组件化建设主要包含两部分，一是推荐算法 PaaS 化能力建设者将推荐算法能力进行集成，二是推荐算法 PaaS 化能力使用者将算法组件应用在任何想应用的场景中，而且使用者自己就可以把握需求交付的节奏；

推荐算法组件化示意图

2.2.2 通用算法能力平台化

平台化的主要目的是简化推荐算法组件使用的复杂度，因此，我们对平台工具的要求是具备可用、可视、可改的特点；值得注意的是，平台化这里我们可以分为两个大类，其一是推荐能力全链路的平台化，目的是能够快速支持新增推荐位这类业务需求；其二是推荐算法模块的平台化，通过这样的平台工具，希望能够快速支持已有推荐位推荐策略迭代优化类业务需求；

• 针对推荐能力全链路的平台化，我们和产品、架构、平台侧合作，通过打造丰富的推荐场景模板，并提供通用的个性化分发能力，满足业务快速接入的诉求；具体来说，对于业务方对不同推荐场景接入的不同诉求，PaaS 化项目组已经建设了诸如全站商品综合推荐、主 sku 相似相关推荐、业务灵活底池推荐、全渠道门店+商品推荐、小助手商品推荐等多类通用模板，在这些模板上，推荐算法 PaaS 化依据可变化、可复用的基础逻辑，通过提供丰富的推荐策略供业务方选择使用，覆盖更多新增推荐位需求；

场景模板列表示意图

• 针对推荐算法模块的平台化，我们计划和平台侧合作，通过建设一批提效工具，提高算法同学的工作效率，缩短需求的交付周期；

2.2.3 通用算法策略配置化

为了提升算法人员支持业务需求的效率，立足目前的推荐系统，同推荐架构合作，完成建设通用算子库，包括常用的取数、召回、排序、过滤、多样性等算子；在未来，这批通用算子可以直接进入小流量实验验证效果，降低算子配置的成本，提高代码的复用度，达到缩短需求交付周期的目标；

实现通用算法策略配置化前后的流程对比

2.2.4 定制化算法策略低代码开发

在支持业务需求的过程中，我们发现一个小小的算子开发也要耗费算法人员大量的时间，包括不限于：前期的开发沟通、策略的开发、环境部署、策略的验证及算子上线等，我们希望将开发流程进行精简，从而达到提效的目标，基于此，同推荐架构、平台达成共识，建设面向算法等专业人员的低代码开发工具，使定制化需求能够快速的通过低代码环节进行快速开发和发布上线；

整体思路，参考大数据的 easy studio 系统

2.2.5 推荐算法 PaaS 化工具建设

这里我们主要考虑定制类需求，比如召回新增数据源、敏感商品过滤、case 排查工具等；对于定制类需求，我们希望提供一些高效易用的 PaaS 化工具，一方面，解放算法的重复劳动力，另一方面，缩短业务需求交付的周期；

3. 落地实施

3.1 案例一 场景模板个性化推荐能力建设

3.1.1 场景模板开发

场景模板作为承接新增推荐位需求的一种工具，直接开放给业务方使用，针对不同推荐场景，我们建设了丰富的模板供业务方选择使用，包括：全站商品综合推荐、商详、购物车、直播、短视频等，在每个模板上，我们配置了基础的推荐分发策略，业务方可以根据自己的需求选择使用哪些推荐策略；下面以商品聚合 tab 推荐为例，介绍模板个性化推荐能力的落地实施情况；

首先，在模板建设的前期，我们会和产品共同确认类似需求的量级，作为评估是否建设模板的依据；比如说，我们评估商品聚合 tab 推荐这类需求在每个季度平均会存在 3-4 个，且该类需求对算法能力的要求基本相似，因此，我们认为商品聚合 tab 推荐是属于通用类且比较频繁的一类需求，需要建设模板高效承接该类需求；

其次，作为算法人员，我们需要针对该类需求进行算法能力的梳理，通过过去十几个类似需求对推荐能力的要求，大致可以整理出一版功能完善，覆盖度极高的算法方案；以商品聚合 tab 推荐为例，在数据接入时，大部分需求中，业务方提供的数据是包含商品池(did)、虚拟类目/品牌(vcateid)及真实类目/品牌(cate_id)的底池数据，而在召回时，往往通过冷启和画像两路召回完成虚拟类目/品牌及真实类目/品牌的召回，再通过一个线性排序模型完成 rank 阶段的打分，辅以过滤、调权及多样性策略完成整个推荐分发能力的搭建，通过上述描述不难发现，如果大部分需求都是按照上述流程推进，那我们就可以设计完善的算法方案高效承接类似需求；

然后，在算法方案评审完成的基础上，由架构侧完成功能的开发，由平台侧完成前端页面的开发；

最后，当再存在类似业务需求时，我们对业务方开放模板能力，业务方自己就可以通过点选式的页面完成需求，且这个过程的进度均由业务方自己把控；

场景模板开发流程图

3.1.2 全自动召回词表/索引库能力建设

在我们承接业务需求的过程中，大部分情况下，每个业务方都有自己的商品底池，面对不同的商品底池，我们需要根据商品底池的变化动态的调整召回词表或者索引库，假如我们想要个性化分发能力完全自动化，那就需要打造一套新的召回词表/索引库构建工具，基于此，我们联合平台侧共同提出了一键底池/索引库创建落地方案，具体来说，算法人员将模板上所需的所有召回词表/索引库生产脚本进行抽象封装，预留入参及出参，平台侧通过前端界面获取具体召回词表/索引库创建的命令，并将该命令作为入参输入算法人员预先封装好的代码包，为了每天定时更新任务，同时自动创建 BDP 调度任务，代码包的出参通过 DUCC 回传给平台侧，作为后续创建词表/索引库的依据，从而完成召回词表或者索引库的全自动化创建；

一键底池/索引库创建落地实施

3.1.3 多业务排序模型支持

为了覆盖更多业务需求，在排序模块我们主要考虑不同业务模式下对排序能力的要求，比如，在下沉场景，更多的是需要提升 UCVR 指标，而主站的一些业务需求希望提升用户的 UCTR 指标，因此，为了兼顾多样的业务需求，我们梳理了三个常用的模型，分别是主站的多领域排序模型，特价版的下沉排序模型以及 ToB 的企业排序模型，将上述三个模型集成到每个模板里，并提供每个模型的介绍及使用说明，业务方可以根据需求的具体内容进行选择；

排序模型选择

3.2 案例二 打造高效易用的 PaaS 化工具

工具的合理使用，不仅可以提高我们的工作效率，还可以使我们的工作变得更加轻松；这里以我们在用户体验中打造的啄木鸟为例，为大家讲解 PaaS 化工具在业务中的应用；（名词解释之啄木鸟：支持离线过滤/解禁自主配置的平台化工具）

3.2.1 需求梳理

在用户体验模块，常常有业务需求需要对商品、类目、敏感词等进行过滤，或者在某一段时间内进行过滤，时间过后要求再释放出来；在没有打造啄木鸟之前，我们接到类似需求后，会手动将商品、类目或者是敏感词写到一个文本中，然后再将文本 push 到 hdfs 的某一个路径下，第二天的 BDP 调度任务执行时，会更新数据表，达到过滤或者释放的目的；观察上述流程不难发现，手动修改文本极易导致出错，无心的删除或者增加可能就会导致第二天的调度任务挂掉，不稳定；另外，有新人接手这样的需求后，培训成本极高，需要手把手教几遍才敢把这样的工作交给他，操作难度大；

为了解决这样的难题，我们计划打造一款高效易用的 PaaS 化工具，这样的工具可以提供稳定的增删改查，而且还要操作简单，最好是一看就知道怎么操作，基于这样的想法，我们联合平台一起打造了啄木鸟；

3.2.2 啄木鸟的设计及开发

设计思路：

通过 jrec 平台，能够将所有的离线过滤/释放进行 paas 化配置，平台需要具备如下能力：

1. 啄木鸟平台提供过滤、释放配置入口，由 jrec 平台提供；

2. 在平台配置的长期规则可以下沉至离线，降低对线上服务资源的占用；

3. 离线过滤能够灵活配置，且支持离线释放，减少手工操作成本；

方案设计：

整体方案设计如下图所示，通过平台 WEB 界面配置后，数据经 DUCC 流转到离线计算任务部分，待离线计算任务完成后，导数到 jimdb 进行缓存，线上配置过滤服务或者 ps 的过滤算子后即可完成商品、类目或者是敏感词的过滤与释放；

啄木鸟落地实施

3.3.3 啄木鸟使用

啄木鸟建设好交付对应的算法人员进行使用，我们也提供了详细的使用手册供新人学习；

4. 实践经验总结

在推荐算法 PaaS 化探索与实践的过程中，我们作为能力的提供者和能力的使用者，一方面从能力提供者的角度出发，总结梳理出需要提供的 PaaS 化工具，另一方面，从能力使用者的角度出发，去评估工具是否高效易用；

作为能力的提供者：通过对业务需求的梳理及 PaaS 化建设者长期的业务经验，立足现有推荐系统，通过对推荐算法的组件化，重新认识系统，重新规划流程；

作为能力的使用者：从被动到主动，切实感知到工具对效率的提升，善于利用工具，通过 PaaS 化工具，轻轻松松完成复杂的业务需求，只要想干，就可以自己把握需求交付的节奏；

5. 未来工作展望

我们希望在长期主义的复利下，将推荐算法 PaaS 化积累成一个奇迹；基于我们目前对业务需求的认知，未来，我们将从如下几个方面不断深耕：

5.1 场景模板分层个性化推荐能力建设

在未来一段时间里，我们会针对模板的个性化能力进行升级，基于现在基础版的现状下，提供进阶版及高阶版能力，满足业务更多样的诉求；

5.2 打造高效易用的 PaaS 化工具

5.2.1 单素材服务能力建设

首先需要阐述一下我们为什么要建设单素材服务能力，一个重要的原因是场景模板仅能支持新增推荐位需求，且该类需求不能很复杂，而对于复杂的新增推荐位需求或者是已有推荐位的迭代优化场景模板无法提供支持；基于此，我们提出了服务复用的概念，具体来说，我们计划将单素材打造成一个一个的服务，算法人员专注的对服务进行全方位优化，而需要进行效果优化的新增推荐位需求以及已有推荐位的迭代优化则通过服务进行赋能，此举不仅可以减少算法人力的投入，还可缩短业务需求交付的周期；

5.2.2 算法组件平台化进一步升级

为了提升推荐算法 PaaS 化能力使用者的使用体验，我们计划将部分通用的算法能力平台化，以摆脱目前仍然需要算法人员手动复制的操作工作，真正实现点选式的操作方法，因此，后续我们也会联合平台侧，共同打造这样的平台能力，进一步释放算法人员的重复劳动力；