[Practice] Recommendation Algorithm PaaS Exploration and Practice

1. Background

At present, the recommendation algorithm department supports 900+ recommendation scenarios of 20+ business lines such as the main website, enterprise business, and omni-channel. By sorting out the common requirements of the big promotion operation and the recommendation scenarios of each vertical business line, the existing recommendation algorithm capabilities are precipitated and accumulation, and create a general recommendation capability through algorithm PaaS, improve the efficiency of recommendation empowerment in various business scenarios, and efficiently empower business needs.

Why it is PaaS : First of all, we think that PaaS is a better solution and plan, because it provides a basic framework for solving the complex business of super companies that can be changed, expanded, and reusable . In such a Under the framework, repetitive labor can be greatly released to achieve efficient business improvement; secondly, we have also seen other players in some industries, who also implement PaaS on the basis of their own business middle platform, and provide capabilities through PaaS Constantly incubate their own innovative projects to reduce their manpower input and reduce their input costs, and they have also launched a lot of PaaS tools for commercial use to create opportunities for greater social value; therefore, we think PaaS should be a better solution to the problem that we will choose at present;
How to help improve recommendation business capabilities : By sorting out common requirements in recommendation scenarios, within the basic framework of changeable, scalable, and reusable capabilities, we classify business requirements and abstract capabilities, and provide step-by-step coping strategies ; For general needs, we provide one-stop personalized recommendation capabilities to meet the needs of fast access to business; for customized needs, by creating efficient and easy-to-use PaaS tools, on the one hand, reduce the investment in algorithm manpower, on the other hand, Shorten the delivery cycle of business requirements;

2. Scheme design

In the process of sorting out the recommended business requirements, we have summarized the demands of the business side into the following two categories:

Added recommended business requirements

According to the recommendation scenarios, it can be roughly divided into the access of recommendation scenarios such as the first recommendation, my Beijing, store details, shopping cart, short video, live broadcast, and channels;
According to the classification of personalized recommendation capabilities, it can be roughly divided into data access, recall, sorting, filtering/weight adjustment, diversity, rendering and other recommendation algorithm modules, as well as AB experiments and data analysis capabilities;
According to the division of operational demands, it can be roughly divided into support capabilities such as rights promotion, fixed investment, non-scheduled investment, and fixed pit;

Existing recommendation position recommendation strategy iterative optimization business requirements

Effect improvement business requirements: can be roughly divided into new product pools, recall new data sources, business labels/feature factor access models, support categories, data analysis, etc.;
User experience business requirements: can be roughly divided into weight adjustment/filtering, negative feedback, diversity sorting, novelty, multi-material interleaving, etc.;
Operational requirements: can be roughly divided into operational capabilities such as special commodity flow support, horse racing mechanism, right promotion, fixed investment, and fixed pit ;

In order to more efficiently support the above business needs, the recommended algorithm PaaS is built around the six PaaS directions of data/algorithm components/data analysis/operators/scenario templates/services, with the goal of shortening the demand delivery cycle and effectively improving usage perception.

2.1 Classification of Recommendation Algorithm PaaS Capabilities

As a provider of personalized recommendation capabilities, we hope to transparently display the recommendation system to everyone through business enabling technology and PaaS-based recommendation algorithms. Based on a new understanding of the recommendation system, we will better deduce the future; we will The recommended algorithm PaaS is divided into data/algorithm components/data analysis/operators/scene templates/services, a total of 6 first-level capabilities and 20 second-level capabilities, as follows:

The above classification is based on our current understanding of business needs. With the continuous advancement of the recommendation algorithm PaaS, the definition and classification will continue to migrate;

2.2 PaaS capability building of recommendation algorithm

2.2.1 Componentization of Recommendation Algorithms

The componentization of the recommendation algorithm is a pre-step for platformization and configuration. Through componentization, we can visualize the algorithmic capabilities, let some information deposited in the code be displayed to the public, and make the algorithmic capabilities a truly inheritable asset. , to efficiently empower business needs; specifically, we abstract and encapsulate the algorithm capabilities and integrate them into a runnable code package. Users can use "pluggable" applications through the introduction of algorithm components and instructions for use. in their field of business;

The construction of algorithm componentization mainly includes two parts. One is that the recommendation algorithm PaaS capability builder integrates the recommendation algorithm capabilities, and the other is that the recommendation algorithm PaaS capability users apply the algorithm components in any application scenarios they want, and the users themselves You can grasp the rhythm of demand delivery;

Schematic diagram of componentization of recommendation algorithm

2.2.2 Platformization of general algorithm capabilities

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

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

场景模板列表示意图

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

2.2.3 通用算法策略配置化

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

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

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

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

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

2.2.5 推荐算法PaaS化工具建设

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

三、落地实施

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化配置，平台需要具备如下能力：

啄木鸟平台提供过滤、释放配置入口，由jrec平台提供；
在平台配置的长期规则可以下沉至离线，降低对线上服务资源的占用；
离线过滤能够灵活配置，且支持离线释放，减少手工操作成本；

方案设计：

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

啄木鸟落地实施

3.3.3 啄木鸟使用

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

四、实践经验总结

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

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

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

五、未来工作展望

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

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

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

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

5.2.1 单素材服务能力建设

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

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

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

-end-

本文分享自微信公众号 - 京东云开发者（JDT_Developers）。
如有侵权，请联系 [email protected] 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。