规则只有几条，也没有审计要求
写在应用里更快。等规则开始分叉、要解释某笔决定时，再迁到决策平台。
COMPARE / DECISION PLATFORM
SMARTS 与规则引擎、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 上标准化的评分卡工厂。