one-model引擎：私域营销推荐自动化解决方案【转载】

文章中就可以闻到当初作者KPI的求生欲，已经是2年前的文章了 本来是私藏，分享出来做这方面的可以参考下，我当初也参与这个项目了，不过不是算法端的同学

1、概述

One-model推荐引擎是为解决推荐模型开发上线的效率问题，在私域营销推荐中可以自动生成baseline模型，同时由于框架良好的扩展性，非常易于分支迭代。整套方案搭建好之后，随着场景和数据的积累，one-model引擎可以不停地进行自我更新和迭代，这就是称之为“引擎”的原因，所有私域营销场景共用一套模型，这就是one-model的由来。要生成1套统一模型，需要有统一的日志，统一的样本，统一的特征，统一的链路，因此可以将这些统一的东西封装成一个的统一服务，供不同场景进行调用。one-model推荐引擎能实现的必要条件是数据的标准化和链路的闭环化，两者缺一不可。只有标准的东西才能实现不同场景适配，只有闭环的东西才能实现自我更新。数据的标准化贯穿链路始终，核心要点是在整条链路中记录下“人+货+场”的关键信息，并且要有字段能唯一标识用户某的一次行为。链路的闭环化核心是特征日志的回流形成闭环，这样可以使得实时特征被记录，线上打分特征和模型训练特征保持强一致性。

2、总体架构

2.1 架构演进

one-model推荐引擎是从"4+N"推荐架构(https://www.atatech.org/articles/140875)演进而来，“4+N”指的是1套样本、1套特征、1套模型、1条链路，解决N个场景的问题，"4+N"的架构每个场景仍然需进行特征开发，模型开发和分场景的部署，只是通过这套架构实现场景间通用能力和链路的复用，还是属于分场景开发的范畴。one-model对中间的1套样本、1套特征、1套模型、1条链路进行进一步封装，形成统一的服务，样本特征无需重新开发，让AI能力服务化，屏蔽模型和链路的复杂性，上层调用更加方便。

2.2 分层架构图

根据功能不同将one-model架构从下至上拆解形成日志层、样本层、特征层、模型层和应用层，日志样本特征的架构目标和能力是标准化，模型层通过模型工厂实现分场景建模，核心能力依赖于自动化能力，包含自动特征抽取，自动样本抽样，自动模型训练和部署等一整套的pipline，应用层核心能力是配置化，在海王星上实现通过一份代码串联所有场景的worker，长尾场景上线无需编码，仅仅通过在推荐平台的配置修改实现。当前one-model架构实现的关键是数据的标准化和链路的闭环，建模流程的自动化和应用的配置化能力。

3、数据标准化

基于“人+货+场”的推荐逻辑，在流程的各个环节记录核心信息，是数据标准化的记录。需要在日志、样本、特征三个层面推荐数据标准化的建设。由于标准化工作分散在各个业务系统，因此能有一个统一的运营平台来触发标准化信息的下发，是整条链路的关键，在保险私域运营场景中，智能运营平台（德鲁伊）作为各个运营活动配置的入口，是相关信息标准化的起点，因此我们以德鲁伊为切入点推进数据标准化。

3.1 日志层标准化

日志层标准化包含两个部分：埋点日志标准化和特征日志标准化。

3.1.1 埋点日志标准化

埋点日志标准化最为重要，由于涉及系统较多，整体难度更大。埋点日志标准化包含如下重点：

1. 埋点格式标准化，意味着新加内容无需重新申请埋点。
2. 埋点信息标准化，意味着日志中包含“人货场”的关键信息，便于样本和特征的生成，保险公域和私域推荐的埋点规范和海豚平台保持一致，采用相同的scm规范。
3. 信息源头标准化，意味着德鲁伊在运营活动配置时需要加入场景信息和内容类型字段。

3.1.2 特征日志标准化

特征日志标准化，主要依赖于推荐系统对特征日志回流功能的支持。埋点日志标准化包含如下重点：

1. 如何每次都能记录到用户的打分特征？即便用户不走模型打分的模式。
2. 在特征较多的情况下如何进行item粒度的截断？
3. 打分特征日志如何和样本进行关联？通过trace_id

3.1.3 核心字段设计

核心字段设计：

• 人：user_id（用户编号）
• 货：item_id,item_type（内容、权益、产品、消息、活动等）
• 场：plan_code（推荐场景编码，德鲁伊提供）

全链路串联字段（用户单次访问唯一）：trace_id

3.2 样本层标准化

样本层标准化，根据不同本模型准备不同的样本，主要是CTR模型和CVR模型

3.2.1 CTR模型样本准备

CTR模型主要关注用户的曝光点击，主要通过traceId,contentId来关联曝光和点击表，进行样本的组装，单次曝光行为点击为1，不点击为0。

3.2.2 CVR模型样本准备

保险私域的CVR，主要是保险的出单，由于各个险种的出单链路各异，难以追溯和统一，目前通过二跳的点击来表示CVR的样本。

3.3 特征层标准化

3.3.1 线上特征标准化

【离线特征部分】
离线特征包含三部分的特征，user特征，u2i特征，item特征。

• 用户特征——采用保险域通用用户特征，主要是用户的静态属性特征（自然属性、财富、位置、活跃、保险画像等）和公域活跃特征，特征设计原则，由于用户量较大，且后续调用较多，特征数量上尽量保持精简，更加贴近保险的用户属性。

• u2i特征——u2i特征表征的是用户对item的历史行为，有无曝光点击，主要通过不同时间窗口进行聚合获得，例如N天内在该场景下的曝光点击次数等，通过对样本表的聚合操作获得。itemId是planCode和contentId组合的字段，因为存在多个场景中用到同一contentId的情况。

• item特征——item特征表示的是item维度的信息，包含item的基本信息和点击曝光的聚合信息。存储格式上以kv格式存储，在odps开发好之后，通过海王星的特征视图配置实现，可以通过item_id进行查询,itemId是planCode和contentId组合的字段，item特征中冗余planCode字段。

【实时特征部分】

目前只用到了海王星提供的实时特征，主要是LBS，天气，时间相关的特征。

3.3.2 模型训练特征标准化

模型训练特征采用标准化样本和线上特征日志的拼接的方式，有两个好处，一是保证线上打分特征和模型训练特征的一致性，模型训练不受特征回流时间的影响；二是在模型训练时，加入实时特征，实时性更好，模型效果更佳。

4. 模型自动化

4.1 模型工厂架构

经过充分的实验数据论证，分场景多模型的方案相较统一的模型有性能上明显优势，因此模型层的架构采用分场景建模的方案，模型采用同一份数据集，根据场景code进行路由，分别建模，依赖于aistudio的自动化能力，核心包含自动抽样，自动特征，自动训练，自动部署等全套自动化能力。整体方案如下：

模型训练pipeline，主要包含数据筛选，特征抽取，模型训练，模型部署等几个步骤，所有步骤已经组装成PAI组件，新场景接入只需修改数据筛选组件，模型开发的pipeline如下所示。

4.2 自适应特征工程

自适应特征工程包括两个维度：

• 维度1：适配Odps表的schema做特征工程，例如：
  若Odps表中列类型为string，当做category特征，直接取签名
  若Odps表中列类型为bigint、double类型等，当做numeric特征，做分桶或标准化
• 维度2：自动分桶和自动标准化
  传统的特征工程例如feature column，对于分桶操作需要用户设置分裂点，对于标准化需要用户提前计算出平均值和方差
  pyfe(更多信息参考链接)提供Auto类算子，只要输入Odps表，便可自动分桶(支持等频、等宽分桶)以及自动标准化
  自适应特征工程流程如下图。特征工程下一目标是AutoFE，输入Odps表自动挑选收益最大的特征。

4.3 模型训练自动化

为了让用户能直接在PAI GUI平台上调用分布式tensorflow算法，将wide&deep和deepFM等模型封装成了PAI组件。由于不同深度学习算法对特征的要求不一样，比如wide&deep算法需要有wide和deep的稀疏特征，deepfm需要有不同field的稀疏特征，所以针对每种算法我们提供了对应的特征抽取组件，如“wide_deep二分类”对应的“wide_deep特征抽取”，“deepFM二分类”对应的“deepFM特征抽取”。

wide_deep自动化训练流程图

PAI上的“wide_deep特征抽取”组件会分析odps表的schema，并将数字型特征抽取成dense型特征，并bucket抽取成sparse型特征，字符型类特征做hash成sparse型特征，其中sparse列的特征会分别给wide层和deep层模型，利用tensorflow estimator API实现的wide_deep模型

deepfm自动化训练流程图

在deepfm特征抽取里，数值型特征同样会被抽取成dense型特征，同时稀疏型特征会被随机划成多个field，在deepfm模型了不同的field会做fm。利用tensorflow estimator开发的。

4.5 模型部署高可用

核心思路是同一场景生成多套模型：startup模型（T+1兜底模型和新场景baseline模型）、准online模型（基于离线和在线特征的模型）和解释性模型（用于重要变量筛选和增强分析 ）。startup模型是新场景上线的baseline模型，通过T+1的离线特征和样本生成，主要用于模型的第一次上线和线上兜底；准online模型是基于准实时的样本和线上回流特征进行建模的模型，可以基于增量学习的方式更新模型；解释性模型，主要用于重要变量的筛选和后续模型可解释性的应用。为了保证高可用，线上会有startup和准online两个版本的模型，可解释性模型视应用场景部署。

4.6 深度推荐模型库

依托于AIstudio和tensorflow的Estimator能力，我们开发了deep&wide，deepFM，ESMM等模型，可以支持CTR和CVR为优化目标的各种场景。

deep&wide

wide&deep模型的核心思想是融合线性模型的记忆能力（memorization）和 DNN 模型的泛化能力（generalization），在训练过程中同时优化 2 个模型的参数，记忆的分支为wide分支，是简单的LR，泛化的分支是deep分支，是个DNN的网络。

deepFM

deepFM模型的核心是通过FM(因式分解机）获得更多的低阶特征组合，通过DNN挖掘高阶特征组合，从而提升模型的性能。

ESMM

ESMM模型的核心是多任务学习，解决了全链路预估分阶段独立建模的两个问题（样本选择偏差和数据稀疏性），同时输出pCTRpCTR，pCVRpCVR以及 pCTCVRpCTCVR，大大方便了应用。

5. 应用配置化

应用层的配置能力主要在海王星上实现，目前是通过配置化实现新场景的上线，无需从头开始开发代码。

核心功能

推荐除了排序阶段，还需要召回和重排的能力，依赖于海王星（推荐平台）已有能力，目前我们已经深度定制了适用于私域的相关能力，召回阶段，有适用于各种场景的召回数据处理worker，包含了接口召回，hbase召回等能力，排序阶段支持了MAB排序/Ucb排序等多种冷启动算法，以及单模型打分和多模型打分等算法排序能力，重排阶段，能够支持多种特殊业务规则的排序，以及item和用户维度的疲劳度降权机制。

one-code实现

我们通过一份code实现各种场景的应用，将所有的worker串联在一起，不同场景通过前台配置选择不同的worker，实现pipeline的动态流程编排，每个worker在执行时需判断本worker是否在pipeline的list当中，如果在列表中则执行当前worker的具体逻辑，否则就不执行，直接跳过。

6. 总结与展望

【阶段总结】

多场景、大流量夯实one-model能力
从年初整个保险2个推荐场景，到目前的十多个场景（还在持续增加），服务的场景QPS从原来的几百QPS到目前上万QPS，除了业务发展的诉求，更多的也是业务方对AI助力业务的信任，因为相信，所以简单，one-model引擎初衷有AI普惠的成分，能让看起来复杂的推荐能够嵌入寻常业务，是它的使命。如此之多的场景和流量进一步夯实了保险推荐的硬实力，one-model推荐引擎能力除了作为保险营销的底盘，除了横向服务保险各种业务之外，也纵向切入到具体的业务线（健康金业务），打造覆盖全链路的营销推荐能力，真的做到让业务先赢。

【未来展望】

从0开始建设推荐能力，架构从“4+N”升级到“one-model”，我们对营销推荐的认识不断深入，对未来有了更多实的和虚的思考，主要聚焦于推荐可解释性和面向未来的营销推荐体系思考。

推荐可解释性落地方案思考

用户和item的匹配用的是深度学习模型，类似于黑盒模型，没法解释为什么给这个用户推荐这个item，属于“暴力相亲”的模式，如果引入了媒人介绍的模式，媒人会介绍双方各有什么特点，于是模型可解释性就派上了用场，可以在推荐的时候显示地表达用户的特点和item的特点，让用户有更好的体验，进而提升业务的价值。

我们将推荐模型可解释性和智能文案相结合，落地方案如下：1、通过模型可解释性的全局解释能力提供用户洞察，给UED同学创做标签的灵感；2、UED同学生成紧贴业务的用户标签和item标签，形成标签素材库；3、通过毕加索和海豚的能力在投放时组合素材；4、通过one-model引擎的可解释能力，输出最优的用户标签和item标签，和素材的最优组合；5、组装成最优文案和素材组合，透出给用户。

"E&E"智能营销模型体系思考

前面的工作主要是优化流量的运营效率，利用场景内已有的数据来建模（exploit），达到“人+货+场”的匹配，优化空间较为有限，如何通过数据算法层面获得启发性的洞见，探索更多货和场的可能性(explore)，也是营销面临的一大挑战。后面可以尝试以top-down视角寻求更大优化空间，未来将尝试以Exploit和Explore为思路，提升既有运营效率和探索更多优化空间，发挥更大的业务价值。