网站做短信验证需要多少钱,wordpress头部加导航,企业手机网站建设行情,建p2p网站作者#xff1a;京东零售 崔宁
1. 背景说明
目前#xff0c;推荐算法部支持了主站、企业业务、全渠道等20业务线的900推荐场景#xff0c;通过梳理大促运营、各垂直业务线推荐场景的共性需求#xff0c;对现有推荐算法能力进行沉淀和积累#xff0c;并通过算法PaaS化打造…作者京东零售 崔宁
1. 背景说明
目前推荐算法部支持了主站、企业业务、全渠道等20业务线的900推荐场景通过梳理大促运营、各垂直业务线推荐场景的共性需求对现有推荐算法能力进行沉淀和积累并通过算法PaaS化打造通用化的推荐能力提升各业务场景推荐赋能效率高效赋能业务需求。
为什么是PaaS化首先我们认为PaaS化是一个比较好的解决办法和方案因为它提供了一种解决超级公司复杂业务的可变化、可扩展、可复用能力的基础框架在这样的框架下可以极大的释放重复劳动力实现业务的高效提升其次我们也看到一些行业中的其它玩家他们也是在自己的业务中台基础上进行PaaS化并通过PaaS化提供的能力不断的孵化自己的创新项目去减少他们的人力投入减少他们的投入成本而且他们还推出了很多用于商用的PaaS化工具为实现更大的社会价值去创造机会因此我们认为PaaS化应当是我们当前会选择的一个比较好的解决问题方法如何助力推荐业务能力提升通过梳理推荐场景下的共性需求在可变化、可扩展、可复用能力的基础框架内我们对业务需求进行分类和能力抽象提供阶梯化的应对策略针对通用类需求我们提供一站式个性化推荐能力满足业务快速接入的诉求针对定制类需求通过打造高效易用的PaaS化工具一方面减少算法人力的投入另一方面缩短业务需求交付的周期
2. 方案设计
在对推荐业务需求梳理的过程中我们将业务方诉求归结为以下两个大类
新增推荐位类业务需求 依据推荐场景划分大致可以分为首推、我京、商详、购物车、短视频、直播、频道等推荐场景的接入 依据个性化推荐能力划分大致可以分为数据接入、召回、排序、过滤/调权、多样性、渲染等推荐算法模块以及AB实验、数据分析能力 依据运营诉求划分大致可以分为提权定投非定投定坑等扶持能力
已有推荐位推荐策略迭代优化类业务需求 效果提升类业务需求大致可以分为新增商品底池、召回新增数据源、业务标签/特征因子接入模型、扶持类、数据分析等 用户体验类业务需求大致可以分为调权/过滤、负反馈、多样性排序、新颖性、多素材穿插等 可运营类需求大致可以分为特殊商品流量扶持、赛马机制、提权定投定坑等可运营能力
为了更高效的支持上述业务需求推荐算法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化配置平台需要具备如下能力 啄木鸟平台提供过滤、释放配置入口由jrec平台提供 在平台配置的长期规则可以下沉至离线降低对线上服务资源的占用 离线过滤能够灵活配置且支持离线释放减少手工操作成本
方案设计
整体方案设计如下图所示通过平台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化能力使用者的使用体验我们计划将部分通用的算法能力平台化以摆脱目前仍然需要算法人员手动复制的操作工作真正实现点选式的操作方法因此后续我们也会联合平台侧共同打造这样的平台能力进一步释放算法人员的重复劳动力
