3. 决策引擎基础概念
在额度模型与决策引擎集成体系中，决策引擎是连接数据输入、模型计算与业务决策的核心中间件。本章从定义出发，厘清规则引擎与模型引擎的本质差异，并梳理当前主流的决策引擎产品。
3.1 决策引擎的定义
决策引擎（Decision Engine）是一种将业务逻辑、数学模型与实时数据组合起来，自动输出决策结果的软件系统。在信贷场景中，它接收申请信息、征信数据、行为数据等输入，经过规则校验与模型评分，最终输出额度、利率、通过/拒绝等决策变量。
核心能力： 决策引擎必须具备 实时性（毫秒级响应）、可配置性（业务人员可调整规则）、可观测性（全链路日志与监控）三大特征。
行业共识： 决策引擎 ≠ 规则引擎。现代决策引擎通常同时包含规则引擎与模型引擎两个子系统。
3.2 规则引擎与模型引擎的区别
规则引擎与模型引擎是决策引擎的两大核心组件，它们在决策逻辑、维护方式、适用场景上存在显著差异。
| 对比维度 | 规则引擎 | 模型引擎 |
|---|---|---|
| 决策逻辑 | 基于显式规则（if-then-else） | 基于统计/机器学习模型 |
| 维护方式 | 业务人员可直接修改规则 | 需数据科学家重新训练与部署 |
| 解释性 | 高（每条规则可追溯） | 低（黑盒模型需额外解释工具） |
| 计算复杂度 | 低（布尔逻辑运算） | 高（矩阵运算/树模型推理） |
| 典型场景 | 黑名单拦截、反欺诈规则、准入校验 | 信用评分、额度定价、行为预测 |
| 变更频率 | 高（可随时调整） | 低（通常按月/季度迭代） |
常见误区： 不要试图用规则引擎实现复杂模型逻辑（如逻辑回归、XGBoost），这会导致规则数量爆炸且难以维护；也不要将模型引擎用于高频变动的简单规则判断，模型部署成本远高于规则。
3.3 规则引擎与模型引擎的协作架构
下图展示了一个典型的决策引擎内部架构，规则引擎与模型引擎以管道模式协作，共同完成一次完整的决策流程。
架构要点： 规则引擎在前、模型引擎在后的顺序不可颠倒。规则引擎快速拦截明显不合格的请求，降低模型引擎的计算压力；模型引擎则对通过规则校验的请求进行精细化评分。
3.4 常见的决策引擎产品
当前市场中的决策引擎产品可分为商业闭源与开源社区两大阵营，下表梳理了主流产品的核心特征。
| 产品名称 | 类型 | 核心特点 | 适用场景 |
|---|---|---|---|
| FICO Blaze | 商业闭源 | 规则引擎成熟，金融行业标准，支持复杂规则集 | 银行、保险、大型信贷机构 |
| IBM ODM | 商业闭源 | 企业级决策管理，与IBM生态深度集成 | 大型企业、政府项目 |
| Drools | 开源 | Java生态，RETE算法，社区活跃 | 中小型金融科技公司、规则复杂度中等 |
| EasyRules | 开源 | 轻量级，API简洁，适合微服务集成 | 规则简单、需要快速嵌入的场景 |
| PMML/ONNX Runtime | 开源/标准 | 模型引擎专用，支持跨平台模型部署 | 模型推理、模型与规则分离架构 |
| 自研决策引擎 | 定制化 | 完全可控，可深度适配业务与模型 | 头部金融科技公司、有自研团队 |
3.5 产品选型建议
在选择决策引擎产品时，建议从以下四个维度进行评估：
- 规则复杂度： 规则数量超过 500 条时，优先选择支持规则集分层管理的产品（如 FICO Blaze、Drools）。
- 模型集成方式： 若需要频繁更新模型，选择支持 PMML/ONNX 标准的产品，避免每次模型变更都需重新部署引擎。
- 实时性要求： 毫秒级决策场景（如线上信贷审批）需选择低延迟引擎，避免使用重量级规则引擎。
- 团队技术栈： Java 团队优先考虑 Drools/EasyRules；Python 团队可考虑自研或基于 ONNX Runtime 构建。
实战建议： 对于大多数金融科技公司，推荐采用 Drools（规则引擎）+ ONNX Runtime（模型引擎） 的组合方案，兼顾成本、灵活性与性能。
3.6 规则引擎与模型引擎的集成模式
在实际额度模型中，规则引擎与模型引擎并非孤立运行，而是通过以下三种集成模式协同工作：
选型建议： 额度模型场景通常采用 串行模式（规则前置过滤 + 模型评分），兼顾效率与精度。并行模式适用于需要多维度独立决策的复杂场景，嵌套模式则常用于模型结果的后处理修正。