规则只有几条，也没有审计要求
写在应用里更快。等规则开始分叉、要解释某笔决定时，再迁到决策平台。
COMPARE / DECISION PLATFORM
SMARTS 与 Drools、自研规则系统对比
选型团队常把「规则引擎」和「决策管理平台」混为一谈。下面按谁改规则、变更如何上线、审计能否追溯当时版本来核对差异。对比基于各产品公开文档的通用用法，不针对特定版本；Drools 等开源方案也提供决策表等业务人员可参与的编写方式，具体以所用版本为准。
SMARTS 是决策管理平台，不只是规则执行引擎。Drools 适合 Java 团队把规则当代码维护；自研 if-else 或配置中心适合规则很少、没有审计压力的阶段；SMARTS 适合业务要自己改规则，并且需要版本、审批、模拟运行，以及把模型和分析放进同一条决策链。
MATRIX
对照：维护者、上线方式、审计追溯、模型协同
| 谁改规则 | 变更如何上线 | 审计与追溯 | 模型如何协同 | 更适合何时 | |
|---|---|---|---|---|---|
| 自研 if-else / 配置中心 | 开发人员为主 | 跟随应用发版 | 多为日志，难以查到当时生效的规则 | 模型和规则通常分系统 | 规则很少、变化慢、没有审计压力 |
| Drools 等开源规则引擎 | Java 团队把规则当代码或 DRL 维护 | 随代码仓库构建发布 | 取决于自己补的版本与审计能力 | 需要另行接入模型与分析 | 已有 Java 工程能力、规则量可控 |
| 大型传统 BRMS | 专业规则团队 | 成熟但往往重 | 审计能力强 | 适合大规模评分卡作业 | 已标准化在某一家引擎上的大型评分卡作业 |
| SMARTS 决策管理平台 | 风控与策略人员在决策表、树和流程中维护 | 版本、审批、灰度、回滚 | 记录当时规则版本，可追溯；上线前可用历史数据模拟运行 | 模型分数进入同一条决策链 | 业务要改规则，且要治理和解释 |
自研 if-else / 配置中心
适合起步。规则变多或需要应对审计检查时，维护成本会明显上升。
Drools 等开源规则引擎
执行层很强。缺的是业务可维护的编写、模拟、审批和开箱即用的生命周期治理。
大型传统 BRMS
若核心作业已是大规模、标准化的评分卡作业，不必为更换产品而替换。SMARTS 面向还要把规则、模型、分析和发布收拢到业务可操作平台的团队。
SMARTS 决策管理平台
执行仍然用规则引擎，但产品边界是整条决策生命周期，并由上海信数在国内和东南亚交付。
FIT
什么时候不该选 SMARTS
团队就是要把规则当 Java 代码管理
Drools 或自研引擎更贴这个习惯。SMARTS 的前提是业务人员参与改规则。
想把同一套阈值套到所有出海市场
不建议未经本地验证就把同一套阈值直接用到各市场。SMARTS 可以共享流程模板和治理方式，各国数据、阈值和原因码建议分市场维护并分别验证。
FAQ
常见问题
- 规则引擎和决策管理平台差在哪？
- 规则引擎执行规则。决策管理平台还要管谁来写、如何测、如何发、如何模拟运行，以及模型和规则如何一起用。SMARTS 属于后者。
- SMARTS 能替代 Drools 吗？
- 如果痛点是业务改不了规则、缺少版本审批和模拟运行，可以评估替代。如果痛点只是 Java 规则执行性能，Drools 可能已经够用。
- 和 FICO Blaze Advisor 是什么关系？
- SMARTS 创始团队曾定义 BRMS 理论并创建 Blaze Advisor，该产品后来被 FICO 收购。这段技术背景说明的是团队的决策管理经验，并不意味着 SMARTS 适合替换每一套已在 FICO 上标准化的评分卡作业。