一、背景与挑战
业务背景
随着保险互联网化的进程，相关的产品、权益和资讯也越来越多，如何给用户在合适的场景下推送合适的内容成为运营的难点和痛点，依赖人工规则+圈人的方式在海量item的场景下难以做到item和user的精准匹配，基于大数据和算法的个性化推荐方案应运而生，相比人工方案，基于数据智能的个性化精准营销方案不仅在业务效果（点击和转化）上有明显的提升，在运营效率也有巨大提升。由于保险的推荐场景较多，碎片化较严重，每接到新需求重新搭建模型链路的成本较高，因此我们亟需沉淀一套通用的模型链路框架，提升开发上线的效率。
技术挑战
团队较新，相关经验积累较少，搭建通用模型链路框架，我们面临4个方面挑战：
- 挑战一、场景的复杂性：推荐的场景多样化，面临推荐物料异构，内容参差不齐，如何抽象一套通用的模型特征框架？
- 挑战二、链路的复杂性：推荐的链路更加复杂，涉及系统更多，如何打通各个系统链路？
- 挑战三、模型的复杂性：推荐的模型多为深度神经模型，相比传统机器学习模型开发部署的难度更大，周期更长，如何沉淀一套高效的模型开发部署框架？
- 挑战四、协同的复杂性：复杂链路带来的是协同的复杂性，需要多方协同，如何建立良好的多方协同流程机制？
二、目标架构
首先，对推荐模型框架的目标进行思考，我们需要什么样的模型框架；其次，对目标能力进行了拆解，需要什么样的子能力才能达到最终的目标架构。
目标架构
打造一套“体系化、标准化、自动化”推荐模型框架方案，支持轻量级场景推荐算法的快速上线和迭代。
目标能力拆解
- 快速上线能力：能够通过这套框架高效地搭建baseline模型并完成上线，方案易于上手，使这套通用模型链路成为推荐算法工程师的起手式。
- 场景复用能力：同一套框架支持多场景，纯新场景仅需少量代码改动，同类场景无需新模型开发，仅需通过增加埋点配置，自动完成模型更新。
- 快速迭代能力：支持特征的增删和模型的快速迭代，无需走发布流程，让算法工程师更foucs在算法本身。
三、“4+N”推荐模型架构
总体架构设计
- 模型流程闭环化：常规的模型开发部署调用链路只有5个环节：样本准备、特征工程、模型训练、模型部署、模型调用，并不能形成闭环，需要增加日志回流的环节，将特征日志记录并回流，形成闭环。形成闭环的意义在于记录在线打分特征，便于样本和特征数据的生成，同时保证数据的强一致性。
- "4+N"架构思路：核心是标准化的套路解不同场景的问题，通过样本标准化，通用特征的建设，通用的特征处理和建模方案，通用的推荐链路搭建，目标是以“1套样本、1套特征、1套模型、1条链路”的方案解决N个场景的问题。
工程链路设计
推荐的工程链路复杂，涉及系统较多，主要分为三大流程：
- 召回流程，目前支持的业务系统直接召回和搜索引擎+grail统一召回两种方式，核心系统是海王星（蚂蚁推荐平台）、德鲁伊平台（保险智能运营平台）、千鲟（蚂蚁搜索引擎）和grail（蚂蚁统一召回服务），item较少的情况下德鲁伊平台直接从业务系统召回，流程上更加简洁；
- 排序流程，从ODPS的数据准备，到PAI平台的特征处理和模型开发，再到ARKS平台的模型部署上线，核心系统是ODPS、PAI和arks，线上模型供海王星调用打分；
- 重排流程，核心是流量控制和打散规则，主要在德鲁伊上通过前台配置实现，核心系统是德鲁伊。
四、方案落地与业务效果
1套特征
构建基于保险场景的通用特征大宽表，其中user特征整合了中台自然人相关特征，包含自然人属性特征、会员基础特征、财富特征、地理位置特征、线下支付特征等特征，整合保险域各个页面板块的流量特征，分险种勾勒相关用户画像，形成1100多个字段的大宽表，并通过模型特征重要性和IV对特征进行特征压缩，得到200多维的用户基础特征基础表。基于流量日志设计item特征和u2i特征的标准格式，易于新item的拓展。
1套样本
基于浏览点击转化日志和特征日志拼接形成训练样本集合，核心是日志埋点的标准化工作，需要前端同学在埋点中记录itemId、itemType和traceId，在特征日志中也需要记录traceId，以此关联形成数据样本，由此保证了线上特征和线下训练样本特征的一致性。由于item数较多，但是透出的item有限，因此在记录特征日志时，需要进行截断，只记录高概率透出item的特征。
1套模型
由于当前场景中item数目较少，基本上是业务规则召回的方案，所以模型层面主要是rank的模型。鉴于深度学习模型对特征良好的表征能力，目前主要采用的是深度学习的模型，baseline以wide&deep为主，后续可以尝试deepFM,AFM,DIN等其它深度推荐的模型。算法工程师上手深度模型比较困难，一个核心的点是特征抽取，另一个是模型的调试，下面介绍我们如何解这两个问题。
- 特征抽取
传统的特征抽取方案，依赖于人工经验，特征抽取配置文件生成效率较低，我们对这个步骤进行了简化，基于PAI上的全表统计和分箱组件，对不同的特征类型适配相应的特征算子，例如对所有的特征进行direct抽取，对数值型特征进行分箱抽取，对自定义特征进行笛卡尔积交叉抽取，主要通过sql实现了特征抽取配置文件的自动化生成，大大提升了特征抽取的效率。
- 模型调试与分布式训练
在模型调试和分布式训练模型上，和PAI团队进行合作，提出了notebook调试和yarn分布式训练的双分支架构、，利用toy数据集在notebook上调试网络结构，同时通过tensorflow on yarn组件实现分布式的训练，当前已经实现了tensorflow estimator的封装，单机和分布式代码使用同一套代码，同时对数据处理和模型评估模块进行封装，让算法工程师只关注核心的网络结构，大大简化了开发的复杂性。由于要支持分布式训练，目前只支持原生tensorflow的网络结构，待tensorflow 2.0发布后，可以支持到tf.keras，定义网络结构更加的随心所欲。
1条链路
链路方案上通过德鲁伊统一对接外部系统，完成整理链路的串接和闭环，让算法工程师更加关注推荐流程本身。
-
模型部署
深度学习的模型的部署通过arks进行部署，为提升部署效率，主要使用了特征抽取组件（支持特征抽取config tar包导出）和tensorflow on yarn组件（模型oss地址自动生成），同时通过PAI上的自定义SQL组件mock测试数据，提升模型部署效率。 -
推荐链路
推荐主要在推荐平台上实现，之前是race系统，后面逐渐往海王星迁移，当前推荐系统已经很好集成了特征视图配置、召回配置、arks调用、特征查询、特征日志回流、达尔文分流等核心集成，写不多的代码便可以搭建完整的推荐流程。特征视图支持了多个场景共用一份线上特征，复用性大大增强。对arks调用进行封装和优化，使得几行代码就可实现arks的调用，并且在性能上做了并行优化。特征日志插件的引入，使得特征日志的回流更加顺畅，同时支持额外的特征的扩展。达尔文实验方面，可以自动关联推荐场景，通过方案中定义的AB分流字段进行分流。整体链路搭建完后，模型的迭代只需要修改达尔文实验配置，高效便捷。 -
召回链路
在社区评论排序项目中，我们引入了搜索引擎能力，搭建了业务系统->Dump->搜索引擎->海王星->业务系统的链路，为多item场景下的多路召回打好基础。
N个场景+业务效果
“4+N”架构已经在保险平台的2个场景上完成了落地，未来将覆盖更多的场景，主要是首页每日一看卡片推荐场景和福利页面的权益推荐场景，新场景模型的开发和上线时间从原先的2周缩短至2天，效率大幅提升。
业务效果
每日一看场景，相较对照组uvctr提升19.69%。
福利tab权益推荐场景，相较对照组top1权益uvctr提升55.21%，全量权益uvctr提升3.86%（由于只有5个权益，且全量透出）。
五、总结与展望
阶段总结
从2019年2月中旬开始着手个性化推荐架构探索，中间也走过不少弯路，也曾迷茫过彷徨过，4+N建模框架0到1的落地，在业务场景上取得一定的效果，增强了团队的信心。新的财年，新的团队，新的场景，我们还在路上。0到1的路只是基础，1到N的路上才是真的挑战，未来还有很多的地方值得去改进，无论工程上还是算法层面，尤其是推荐规则配置化演进，统一召回池建设，实时特征的建设，深度推荐模型池建设，多目标学习算法的尝试等等，需要协同各方一起努力来完善这个体系，更好的服务业务，发挥价值。
保险推荐体系展望
与此同时，团队也在思考如何搭建面向未来的保险营销推荐体系？保险场景的推荐相对于电商场景和其它金融场景，业务复杂性更大，流程链路更长，用户参与频次更低。鉴于保险业务产品形态的特殊性，我们下一步将打造基于“两图一网”的保险推荐体系。
保险知识图谱
很多场景下不仅仅是user和item单纯的match，追求的不是short-term value点击和转化，更加关注用户长期的价值(long-term value)，因此保险的推荐体系也肩负着保险心智启蒙和引导的重任。如何解？借助知识图谱的力量，将保险的专业知识抽取成保险知识图谱，通过领域知识赋能推荐体系。
社群关系图谱
随着相互宝的发展，相互制社群的存在，如何基于社群做推荐？是摆在我们面前的问题，我们的解法是采用关系图谱，将用户的关系关系抽取成社群关系图谱。
多目标优化网络
在推荐过程中永远存在着“既要、也要、还要”的多项指标，不仅关注short-term指标，同时也关注long-term指标，因此如何在神经网络设计中增加相关目标，并且获得最优的求解方案，也是下一步需要探索的点。
664
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
