近年来，搜索/推荐/广告系统在粗排（Pre-ranking）与精排（Ranking）阶段的模型训练中，呈现出一个明确的趋势：从单目标优化转向多目标建模 + 多目标融合。模型目标多、融合公式复杂，给工程维护、算法迭代效率都带来了挑战。

为了明文化直白展示公式全景、方便决策调参方向，直接配公式、线上自动算（既支持精排预估目标融合、也支持业务条件boost）。我们设计并落地了加乘树调参框架。从1.0优化至3.0，我们提供了：一个调参框架（Java版、同时引擎基建同学落地了C++版）能支持不同算法环节“公式即配即用”，一个打通AB实验的一站式产品化平台，支持一站式“辅助配置->调试->开实验->变更管控”。

带来收益：无论是粗排还是精排，“训多目标、融公式” 已成为工业界标准范式。在得物社区搜索、推荐的模型迭代实践中，我们也确实走“模型多目标训练 + 融合公式调参”范式，2025在社区推荐、社区搜索落地了几十次LR（社区推荐内外流精排、粗排，社区搜索精排）、近百次加乘树推全。

二、即配即用：算法爆发的催化剂，工程稳定的绊脚石？

在算法领域，“即配即用”的工程框架多次成为推动算法快速迭代甚至“爆发式增长”的关键基础设施。面对粗、精排“多目标建模 + 多目标融合”这一建模范式，社区算法和工程提出了如下基建目标：

实时调整配置、线上就能自动生效数学逻辑，使算法工程师从过去几天才能完成一次调参，转变为一天内可进行多次迭代，从而将精力集中在模型和融合公式本身。

实验只配要改的几行，降低配错风险。全量配置不动，形成天然降级能力。

粗、精排的融合公式配置量大，数学变换复杂，容易配错。我们提供的DSL让算法同学直接写数学公式/逻辑表达式。明文公式形成策略全景，方便算法同学决策调参方向。

编译校验与降级体系筑牢稳定性防线：

即配即用+数学公式DSL的需求，给工程稳定性带来极大挑战。我们采用“编译语法校验 + 自动用全量配置降级 + 手动切换编译/解释模式”三位一体保障稳定性。

三、可信赖底座：让复杂公式配置既灵活又可靠

传统的KV、JSON 或 YAML等配置格式在面对上百行数学公式时已显乏力：一方面配置体量大、人工修改易出错且缺乏容错机制；另一方面可读性差，难以维护和审查。

我们采用“全量配置+增量配置”的设计，天然解决了使用门槛&自动降级问题：

给一个社区搜索主搜精排的样例：

DSL接近数学公式/逻辑表达式明文

社区搜索、社区推荐的精排融合公式，服务了“多目标融合+业务boost调权”，语义包含：数学变换、逻辑判断、自定义UDF。当算法写下一串sin(log(max(UDF(x), y)))，框架能否接住？框架必须托底，正确校验与执行，杜绝“配错即崩”。

从加乘树1.0到3.0，公式解析统一选用 ANTLR。相比手搓“逆波兰表达式”或“Flex & Bison”，它基于AST校验更可靠，且Java开发门槛低。实际加乘树的配置结构里，公式按KV配置（Key 为结果名，Value 为表达式），支持跨行引用——前序公式的输出可作为后序公式的输入，形成可串联的计算链，直至得出最终结果。

编译校验与降级体系筑牢稳定性防线

即配即用给算法同学迭代提效带来便利，同时给工程维稳带来挑战。尤其加乘树面临的配置是可自由组合、千变万化的数学公式时，绝对不能出现“配错即崩”的情况。我们做了如下一整套安全设计：

四、核心攻坚：加乘树3.0升级编译执行

加乘树2.0在社区搜索落地后，“每次请求3000个item、线程并发拆的多”的情况，暴露出加乘树耗CPU、耗线程的弱点。C++版加乘树替换了计算引擎，没有采用antlr visitor解释执行数学运算的方式，而是用exprtk框架、收获了更高的性能。

受C++版加乘树的启发，我们计划替换Java版加乘树的计算引擎，降CPU消耗、降执行平响。加乘树3.0变成“直接将配置翻译成代码，字节码加载，直接计算”的编译执行形态。

极致性能：配置直译硬代码，零中间损耗 + 最优 JIT

Antlr翻译&Javassist加载，直接“公式翻译成可执行代码”：

包括多行公式的依赖关系、数学计算&UDF调用，直接拉平成硬代码。硬代码执行效率最高，没有map缓存、递归调用栈等损耗。

多行公式传递中间结果，map换POJO：

每个item维护自己的缓存map，高并发put/resize，造成明显的CPU消耗、youngGC压力。本次会初始化时决策缓存POJO，避免resize、且读写更高效。

核心Javassist管理类借鉴Dubbo写法：

Dubbo的ClassGenerator写法，对内存管理考虑比较完善。本次借鉴ClassGenerator，把动态生成代码收入唯一管理单例类。

晚高峰模块平响、CPU火焰图消耗和内存分配火焰图消耗均显著降低。

动态生成的字节码必须严格遵循JVM 范，平时习惯手写的Java法糖是不容忍的。例如，Float a = (float) b; 在源码中合法，但若b是Double类型，该语句涉及拆箱 + 窄化转换 + 装箱，而字节码层面需显式插入doubleValue() → (float) cast → Float.valueOf() 等指令。若直接按表面类型生成字节码，将触发VerifyError。

Javassist使用不当容易OOM：Javassist 在生成和操作字节码时（如通过 CtClass），因为其缓存机制，需要开发者主动管理资源释放。每次parse字节码的CtClass要及时释放，否则高频生成字节码容易触发OOM。这一点上，加乘树参照了Dubbo的ClassGenerator写法，创建、销毁内聚在同一个类里，即用即释放。

动态生成ClassLoader/Class/Instance要能GC：Instance能GC，ClassLoader/Class能GC吗？答案是能，只有从ClassLoader -> Class -> Instance全链路都GC Root不可达了，这一串才能GC。所以用Spring的ClassLoader这类常驻ClassLoader加载动态生成类是不行的，必须用即用即弃的自定义ClassLoader，并注意全链路的强引用问题。

我们实际验证了动态生成的类确实能被GC掉。

多重护航：防止非法Java字节码引发线上问题

翻译生成的代码，经Javassist生成字节码后，除Javassist .toClass()的自检验，我们还让字节码过了ASM的字节码静态校验（会运行类似JVM的类型推断验证，确保每条指令执行前后，局部变量表和操作数栈的状态是类型安全的）。

我们将加乘树管理平台封装成了一个沙箱，算法同学调试公式点击“校验”，平台会用同一套SDK模拟线上全套加载流程:“AST强校验 -> DAG强校验 -> 真实翻译代码 -> Javassist & ASM 双校验 -> 反射调用构造器创建实例”，一整套无误后才往线上推配置。

线上异步加载，任何问题自动降级：

“可执行代码（执行器）初始化”读写分离，新配置上线是异步刷新，刷新错误只会造成线上流量过来找不到执行器，自动降级走全量配置（并发出告警），不影响效果。

加乘树2.0、1.0的解释执行能力十分稳定、只是性能略差，3.0可以一键回退解释执行。

加乘树管理平台：一站式配置、调试与实验平台

做了一套一站式“辅助配置->校验->实时调试->开实验->变更管控”的使用体验，告别繁琐配置、体感更丝滑。

加乘树管理平台把自己封装成了一个沙箱，如上一个模块所述，一切风险都拦截在沙箱爆炸。

五、稳扎稳打：从1.0到3.0的演进

加乘树1.0: 支持配公式、框架直接算公式，支持UDF，解释执行。加乘树2.0: 少量性能优化，抽象成SDK。加乘树3.0: 升级为编译执行，外观简化为只需要配公式、框架自动解析DAG。

加乘树1.0和2.0都是用的解释执行，antlr visitor遍历AST做“数学/逻辑/if判断”运算。加乘树3.0升级成了编译执行，多行公式解析DAG、每行公式用antlr解析AST时，直接翻译成Java执行代码，用字节码技术把执行代码加载进JVM直接执行。同时加乘树3.0也支持降级至解释执行。

解决：落地即配即用公式，解决手搓硬代码迭代效率低、代码腐化导致生效逻辑不清晰的问题。缺陷：费线程&CPU。

加乘树1.0于2025年1月在社区推荐外流精排落地，配法（使用外观）、降级机制是后续迭代不变的：

当时是从手搓硬代码做公式融合，无DIFF迁移过来，解决了如下2个迭代痛点：

纯item维度（请求维度的公式也会每个item重复计算）。consts->paramBranch->formulas串行计算。antlr解析单行公式成AST，框架递归解析树依赖，antlr visitor解释执行。

我们需要一种配置设计，能尽可能简洁地表征模型融合公式（支持逻辑判断/复杂数学变换/UDF）——接近Java语法&数学公式的DSL（当时有对标字节的配置外观）。我们需要准确校验DSL配置正确、并正确解析DSL配置——在antlr、手搓逆波兰表达式、flex&bison里，选了用antlr校验、解析DSL（用AST校验原理可靠，Java上手难度低）。

依靠AST解析计算是一种可靠的计算逻辑。我们需要稳定靠谱的计算引擎，因为算法同学大规模使用后、会出现大量千变万化的公式组合——依靠AST解析计算是一种可靠的计算逻辑。

antlr解析AST非常耗时，必须一次parse多次复用，不能在item维度重复parse。一般用antlr visitor做线上实时计算，性能是不可接受的。我们采用了一种类SIMD的代码写法，使落地性能可接受——类SIMD的设计，一次antlr visitor算一批item。最终落地的性能、没有因为antlr visitor拖过多后腿，性能比旧版硬代码融合公式还要好。

antlr visitor如何通过访问AST计算1行公式

解决：抽象成SDK；执行计划自动识别请求维度公式、便于序融合等逻辑写UDF。缺陷：受限于解释执行，仍然比较耗线程。

加乘树2.0于2025年9月在社区搜索落地。优化点如下：

解决：升级为编译执行，性能大幅提升。

加乘树3.0于2026年1月在社区搜索落地。之前“核心攻坚”模块有提到，高并发&计算量大的情况下，暴露出加乘树耗CPU、耗线程的弱点（类SIMD设计虽然能让性能可接受，但毕竟antlr visitor计算方式需要升级）。

加乘树3.0替换了执行引擎。我们观察火焰图发现“按公式逻辑直接裸写的java代码”性能最高效，但是迭代效率最低。加乘树为了即配即用公式，性能却打了折扣。为了平衡“即配即用”的迭代效率问题和“性能”，我们“将配置公式直接翻译成可执行代码，用字节码技术加载到JVM中直接计算”，这让加乘树从解释执行升级为编译执行。

加乘树有Java版，同时有C++版，是引擎同学创新实现的另一个高性能版本。支持多种业务场景及模块（如粗排、精排），可灵活接入 Java 业务引擎或 C++ 高性能引擎。欢迎其他场景和模块接入。

重点打磨“加乘树管理平台沙箱拦截 -> 线上容错降级 -> 失败监控告警发现 -> 解释执行托底” 的有效性，定期演练降级、验证算法效果。增强“加乘树管理平台”DIFF能力，扩展展示“调试DAG”、“可DIFF动态生成的代码”，打通实时debug平台，可以“DAG展开看计算的中间结果”。

配置生成的可执行代码做DIFF（建设中）

 在加乘树这里打通精排模型调用，对精排模型的调用也高度抽象，一配即用、一配即可加入公式融合。

1.深入剖析Spark UI界面：参数与界面详解|得物技术

2.Sentinel Java客户端限流原理解析｜得物技术

得物社区搜推公式融合调参框架-加乘树3.0实战

在粗排、精排多目标建模成为行业标配的今天，研发团队面临 “公式难调、迭代太慢、线上易崩” 的挑战。得物加乘树调参框架从 1.0 解释执行升级到 3.0 编译执行，通过全量 + 增量配置、数学公式 DSL、AST/DAG 强校验和多级自动降级，实现了即配即用、高性能与高稳定的平衡。

技术运营

后端

架构设计

算法

加乘树调参框架助力搜索推荐系统多目标融合，从解释执行升级为编译执行，提升性能50%+。支持即配即用公式、自动降级机制，已在得物社区搜索推荐场景落地验证，实现算法快速迭代与工程稳定双赢。

内存管理

编译器

JSON

Java

2026新春采购季

oceanus

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

得物社区搜推公式融合调参框架-加乘树3.0实战

得物社区搜推公式融合调参框架-加乘树3.0实战

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐