链载Ai

标题: 火花思维：基于离线标签知识库和实时数仓实现轻量级算法服务的技术方案 [打印本页]

作者: 链载Ai 时间: 3 小时前
标题: 火花思维：基于离线标签知识库和实时数仓实现轻量级算法服务的技术方案

ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;letter-spacing: 1.5px;color: rgb(0, 0, 0);font-size: 14px;text-align: justify;visibility: visible;line-height: 2em;">导读本文介绍了火花思维：基于离线标签知识库和实时数仓实现轻量级算法服务的技术方案。

主要内容包括以下几个部分：

ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;letter-spacing: 1.5px;line-height: 2em;visibility: visible;">1.背景

2.技术框架

ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;letter-spacing: 1.5px;line-height: 2em;">3.关键技术节点

ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;letter-spacing: 1.5px;line-height: 2em;">4.实现案例

ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;letter-spacing: 1.5px;line-height: 2em;">5.总结与展望

分享嘉宾｜茆中尧火花思维

出品社区｜DataFun

背景

火花思维（下称：火花）是一家专注于青少年思维训练及综合素质提升的互联网教育企业，产品包含逻辑思维、中文素养、火花编程等。累计学员已超 70 万，遍布全球 100 多个国家和地区。其主要采用直播、真人互动 AI 的方式进行授课，通过将老师的启发引导和动画、游戏、趣味教具等多种方式立体结合，将能力、思维、训练三者互相连接、层层递进，在互动实践中培养孩子的观察思考、逻辑思维以及自主解决问题等核心基础能力。

随着火花的业务发展，尤其在双减后，基于精细化运营诉求，对用户分层、分群等算法服务的需求越来越多；而与此同时，因降本增效的现实压力，相应算法服务的开发周期逐渐变长、模型线上发布的成本挑战也越来越大；这就导致需求和供给间 gap 逐渐增加。

为解决这一问题，我们设计了一套基于火花自研数据开发平台（Athena 数据工厂https://mp.weixin.qq.com/s/RJZTdEKCgB2SB3f6dBchXg）的轻量级算法服务技术方案，以满足以下要求：

开发周期短，能够在 4 个工作周内完成模型开发和工程部署上线；
迭代敏捷：模型调整与线上环境解耦，能够在若干工作日内完成迭代和发布；
采用成熟技术栈，门槛较低，支持分析师开发，为大型企业中短期运营策略提供支线算法服务，或是为中小企业提供基础算法服务；
能实现多种算法任务（如：分类、聚类），且有较好的模型表现；
整套系统可实现自动化“定期重新训练”，以保持模型对数据动态变化的适应性；
复用性强、延展性好，支持基于同一数据底层和技术底座实现多个算法服务。

技术框架

核心思想：该方案采用“离线预计算+实时特征组合匹配”的双模块设计，离线模块调用模型预测穷举特征组合哈希表，建立离线知识库，并同步至 Doris 中；实时模块采用 Flink+Doris 链路，获取用户线上标签；通过表查询方式，匹配用户预测结果返回生产库。

如上图所示，整个技术框架分为两部分：离线和实时模块；离线模块主要实现：模型训练和“离线预计算”工程化部署；对于大企业的分析、运营部门或者中小企业来说，因权限或资源问题，很难有一个稳定、可靠的模型线上部署和调用环境，而采用训练好的模型离线预测穷举特征组合，将模型输出结果以二维表形式存储实现工程化部署，便可作为一种高性价比的替代方案。

而在实时模块，通过Flink接入生产库数据，Doris 计算获取用户实时标签并对同步到 Doris 中的哈希表进行查询，以实现对目标用户的预测，并最终通过 Flink 回写生产库，或者 Doris 的 API 接口完成整套实时算法服务链路的闭环。

全套技术方案采用 Hive SQL、Python、Flink、Doris 成熟技术栈，且标签知识库是在“离线预计算”好后，再同步 Doris，为整个技术方案带来了以下优势：

绕开了模型线上部署的环境要求，规避了实时推理的计算压力，而 Doris 高效的列式存储和压缩技术，又以较低的成本存储了大量哈希表数据，显著降低了在线服务资源消耗情况，确保了方案的低门槛、低负载、低成本优势；
全链路技术风险可控，Hive SQL + Python 技术栈成熟稳定；而 Flink + Doris，也是最近市面上实时数仓的主流实现方式，虽然为控制 Doris 服务器成本，一般会有 3-5min 左右延迟（伪实时），但对于火花大部分业务场景来说，已然够用；
离线与实时解耦，保证了系统的灵活性和稳定性，与传统复杂的 MLOps 流程不同，该方案离线与实时部分功能明确，互不依赖；既可实现二者的故障隔离，增强了系统的鲁棒性，又因模型优化调整在离线部分完成，不影响实时服务的连续和稳定，提高了迭代的敏捷性；
同时，依托 Athena 数据工厂的周期调度功能，可实现日/周/月维度的模型自动化“重新训练”，以较低的运维成本实现了对业务变化和数据漂移的自适应，确保模型性能持续稳定；
具备良好的复用性和扩展性，基于同一技术底座，可支持多种算法任务（如分类、聚类等）的并行构建，便于支持不同场景的业务需求；而随着业务发展，增减特征或调整模型，无需对整体框架进行调整，具有较好的扩展性；且该技术框架可与其他系统和平台轻松集成，满足企业级应用对系统兼容性的要求。

当然，该技术方案在带来了这些优势的同时，也不可避免的产生了一些局限性，其中最大的问题便是：哈希表过大将带来读写的技术困难和成本增加，削弱该方案的使用价值；而过小将限制特征和标签数量，影响模型表现；所以，如何在控制哈希表大小的情况下，保证模型效果便成了整个方案中的关键点。

关键技术节点

为了能在有效压缩哈希表规模的前提下，提高模型表现，以分类任务为例，我们做了以下工作：①特征离散化、②标签筛选、③逐层“打印”哈希表、④采用历史“字典”代替哈希“字典”。

①特征离散化：以有限的哈希表作为模型部署载体，必然要求所有特征都是分类变量，而对于连续数值型特征就要采用分箱等方法对其进行离散处理，这一步我们可以通过本地实验，选好合适的分箱方法（等频/等宽/聚类/决策树等），提炼相应的分箱阈值，将该处理同时封装到离线 Hive SQL 和实时 Doris 中（保证离线、实时两环节特征处理逻辑一致），以实现特征离散化。

②标签筛选：从机器学习的角度来说，不是所有特征和标签都蕴含有价值信息，对于低价值特征我们已在本地实验时，通过 RFE、SHAP 值等方法进行剔除；而对于样本量过少或信息价值较低的标签，可将其归入对应特征的‘其他’标签，从而减少标签数量压缩哈希表体积；但随着业务变动，标签样本量和所携带信息价值可能会在短期内出现波动，所以我们设计了一套自动化流程，以实现标签筛选的自适应。

整个自动化标签筛选分为两步，先通过 Hive SQL 对初始训练集各特征下标签，最近 n 个月的样本量进行统计；一般经验来说，对于集成树模型（如随机森林、 XGBoost、LightGBM），一个特征下的单个标签所需的最小样本量要 >= 30；这里还可结合具体的业务场景，对于样本量绝对值（>=30 情况下）较小或占比较低的标签，我们认为其未来出现概率较低，没必要为其浪费哈希表空间资源，直接予以剔除；
随后，关联初始训练集和标签样本量筛选表（上述筛选结果），对于筛选结果中过滤掉的标签，全部合并到该特征下的“其他”标签中，生成过渡训练集，对该训练集在 one-hot 编码后，进行模型训练，继而打印 SHAP 值或树模型特征贡献度，通过贡献度绝对值或者其占总贡献度比值，进一步筛选有价值标签，在样本量筛选的基础上生成最终各特征下标签筛选表；
将最终的将标签筛选表与过渡训练集关联，同理：对过滤掉的标签，全部合并到对应特征下的“其他”标签中，生成最终训练集；同时，将标签筛选结果同步到 Doris 中，按同样的方式进行标签合并，以实现离线和实时模块，标签“减枝”处理逻辑一致；
通过上述两个步骤，在每次模型自动化“重新训练”时，就同时完成了标签筛选工作，并将标签合并逻辑同步到实时环境中。

哈希表方案的核心矛盾是表大小和模型性能无法同时取到最优，故需要通过标签“剪枝”去对抗这个矛盾，通过合并价值较低的标签，在信息损失有限的情况下，压缩哈希表大小，所以具体采用什么自动化标签筛选方案视具体的业务场景来定。

③逐层“打印”哈希表：经过上述步骤后，虽有效压缩了标签数量，但当特征超过一定量后（> 6），哈希表大小仍处于一个无法接受的量级（> 30^6）；所以，我们设计了一套类似 stacking 思路的逐层“打印”哈希表方案：将一个模型拆分成若干子模型，将一个大哈希表拆分成若干子表，每一层子模型大概采用 5-6 个特征进行训练，训练完成后对相应子哈希表进行预测，同时对训练集进行预测，并与下一层特征构建新的训练集，进入下一层模型训练，如此循环，直到所有特征训练完毕；该方案的本质是：将每一层（5-6 个特征）的信息降维成多个离散的标签（10-100 个），传递给下一层进一步训练，在信息损失有限的情况下，完成了整个模型的工程化部署。

以一个两层“打印”的哈希表为例：第一层采用 5 个特征（x1-x5）进行训练（Python 任务），并构建对应的哈希表，在同一 Python 任务中，同时完成模型训练、训练集预测（y1’）、哈希表预测（y1）和结果写入的流程（注意：这里 y1’和 y1 的都是经过离散处理后的标签值）；
在第二层中，以第一层的训练集预测结果（y1'）和另外 5 个特征（x6-x10）构建一个新的训练集，同时根据上一层哈希表预测结果（y1'）和这 5 个特征构建一个新的哈希表，在训练完第二层模型后对哈希表完成预测并写入 Hive SQL 中；最终将离线标签知识库 1 和 2（哈希表预测结果）同步到 Doris 表中，完成整个模型工程化部署。
逐层“打印”哈希表方案理论上可无限延伸，但考虑到工程链路过长、复杂性过高影响该方案的使用价值，以火花的经验来看，建议控制在 5-6 层左右，覆盖 20-30 个左右的特征，基本可保证一个较好的模型效果。
虽然通过拆表的方式，解决了哈希表过大带来的读写困难和成本挑战，但是以损失一定的模型效果为代价：对于集成树模型来说，其一大优势是：能够学习到特征间的非线性关系，而分层打印的方式，使得层与层间特征的非线性关系学习不充分或者无法学习，未能充分发挥树模型的优势，损失了一定的模型效果；不过，我们在前期对标签筛选的越充分，则每一层可容纳的特征量越多，通过 SHAP 值分析特征间的交互作用，尽量在同一层中放入交互作用明显的特征，以保证非线性关系能尽量充分学习，保证模型效果。

④采用历史“字典”代替哈希“字典”：离线标签知识库相当于一个“字典”，提前打印好我们所需特征组合的预测值（y），同步到实时环境后，实时查询这个字典，以获取预测结果。而采用穷举哈希字典的部署方式，一定会存在某些特征组合未来永远不会被查询到，造成较大的资源浪费；所以，对于某些业务场景，我们可采用穷举过去出现过的特征组合，构建历史“字典”的方式代替哈希“字典”；

历史“字典”较哈希“字典”有如下明显优势：

表更小，往往不需要采用逐层“打印”的方式，工程链路更短、部署方案更简单，更能发挥出“轻量级”的技术方案优势；

一次性完成所有特征的模型训练和知识库“离线预计算”，充分发挥树模型学习非线性关系的优势，避免逐层学习带来的信息损失。
但同时，历史“字典”的局限性也非常明显：可能存在相当一部分用户，无法进行有效预测；对于一个标签组合，如果其所有标签或者大部分标签都在训练集中出现过（没出现过的标签已封装成了“其他”），但这个组合没有在历史“字典”中出现过，那么便不能在历史“字典”中查到，但能在哈希“字典”中查到其对应概率值，且能获得较准的预测结果；另外，历史“字典”的特征承载量也有一定上限天花板，如果特征越多，其历史“字典”查询成功率也会逐步下降，按火花的经验来看，对于可用历史“字典”的的业务场景，其特征上限在 40 个左右，超过这个范围，其查询成功率会低于业务可接受阈值（<70%）；
所以，我们需要根据具体的业务场景和特征分布情况选择适用的“字典”部署方案，对于预期未来大部分的特征组合都在过去出现过的业务场景，我们便可选用“历史”字典方案；反之，则需要选用“哈希”字典；注意：选用“历史”字典时，一定要先回测历史查询成功率情况，并在上线后对该指标进行密切监控，当查询成功率明显低于某一业务可接收阈值时，需要及时迭代为“哈希”字典方案。

实现案例

火花基于该技术方案，在新签获客侧搭建了数套算法服务（如下图），取得了较好结果：

分析师团队通过构建标签集市层和宽表层，搭建了新签获客侧用户画像体系，沉淀了在分析探查等日常工作中积累的各生产环节用户特征，尤其生产加工了一批重业务逻辑的标签，为后续模型提供了约 100+个有价值的特征，并在设计上着重考虑了其泛用性和复用性，减少了后续训练集开发的难度和成本；

在用户画像体系的基础上，通过上述技术方案，分析师联同数仓为业务方提供了多个轻量级算法服务，包括：reshuffle（试听课出席用户与试听课老师匹配策略）中用户分层和试听课老师评分算法服务和公海推荐系统（历史未成交用户电销外呼排序）等，上述算法服务模型表现较好，分类模型线上 AUC 能保持在 0.7-0.8 左右；

经过 AB-test 检验，上述算法服务共为公司带来年化近千万 GMV 收益；而在成本方面，模型开发&部署成本约：20 万，全年服务器成本约：40 万（32 万实时成本 + 8 万离线成本），全年总成本在 60 万左右，ROI 远高于 10，为公司以较低的成本带来了可观的收益；另外：整个系统多个算法服务全年 BUG 次数在 5 次以内，可靠性表现较好，维护成本较低。

总结与展望

整体来说，该方案通过“离线预计算”的工程部署方式，避免了实时推理的计算压力，降低了部署门槛，使得整个方案具备：低门槛、低负载和低成本优势；而采用成熟技术栈，降低了开发门槛；并通过离线和实时解耦的方式，在提高了迭代敏捷性的情况下还保证了系统的鲁棒性；另外：通过周期性任务调度实现了“定期重新训练”，保证了模型长期的有效性和准确性；且还有较好的复用性和扩展性；

同时，该方案发挥了分析师在日常分析探查等工作中积累的业务理解优势，充分挖掘了过往积累的用户画像资产的业务价值，且模型“降维打印”的方式从另一个角度来看，也是一种另类的“可视化”方案，能为业务方展示各类标签组合在模型中的排序位次，提高了模型可解释性，降低了理解成本，帮助模型更好的落地应用；

需注意的是，该方案在特征承载量上存在明确上限，以火花的经验来看，哈希“字典”能承载的特征量在 20-30 个左右，历史“字典”可使用的特征数量约 40 多个，虽能获得较好的模型表现，但其潜力有限，无法承载更多的特征，限制了模型效果上限；所以其使用场景有一定局限性，对于大型企业来说，能够支持分析师为中短期运营策略提供敏捷的算法服务，而对于中小企业来说，该方案提供了一种实现算法功能的可行性技术框架

欢迎光临链载Ai (https://www.lianzai.com/)