1. 实时交易风控概述
1.1 风控在金融交易中的重要性
金融交易的核心是信任与安全。每一次支付、转账或交易请求背后，都潜藏着欺诈、盗刷、洗钱、账户盗用等风险。风控系统的作用就是在毫秒级的时间内，判断当前交易是否可信，并决定“放行”、“拒绝”或“人工审核”。
关键数据： 据行业统计，全球每年因支付欺诈造成的损失超过 400 亿美元。实时风控系统每拦截一笔欺诈交易，平均可挽回 150-300 美元的损失，同时避免品牌声誉受损。
实时交易风控的核心目标可以概括为三个维度：
- 准确性： 精准识别欺诈交易，同时最大限度降低误杀（误拒率），避免影响正常用户。
- 时效性： 交易决策必须在毫秒级（通常 < 100ms）内完成，否则影响用户体验或导致交易超时。
- 可扩展性： 支持高并发（如双十一峰值每秒数万笔交易），并能快速接入新的风控规则和模型。
1.2 实时风控与传统风控的区别
传统风控（如批量事后分析）与实时风控在架构、处理方式和决策时效上存在本质差异。下表从多个维度进行对比：
| 对比维度 | 传统风控（离线/批量） | 实时风控（在线/流式） |
|---|---|---|
| 决策时效 | 分钟级 ~ 天级（T+1） | 毫秒级（< 100ms） |
| 数据处理 | 批量处理（Hive/Spark离线ETL） | 流式处理（Kafka/Flink） |
| 模型部署 | 离线训练，定期更新（日/周） | 在线 Serving，实时推理 |
| 特征计算 | 全量历史数据，宽表 | 滑动窗口 + 实时特征 |
| 典型场景 | 反洗钱报告、逾期分析 | 支付拦截、盗刷检测 |
| 系统架构 | 离线数仓 + 报表 | 规则引擎 + Model Serving |
架构演进趋势： 现代风控体系普遍采用“实时+离线”混合架构。实时层负责拦截高风险交易，离线层负责模型迭代和深度分析。两者通过特征存储和模型版本管理进行联动。
1.3 Model Serving 在风控中的角色
Model Serving（模型服务）是连接离线训练与在线推理的桥梁。在实时交易风控中，它承担着将训练好的机器学习模型（如 XGBoost、神经网络）以低延迟、高可用的方式暴露给线上决策引擎的核心职责。
Model Serving 在风控架构中的具体角色包括：
- 实时推理引擎： 接收风控决策引擎发来的特征向量，加载模型进行前向计算，返回风险评分（0~1）或分类结果。
- 模型版本管理： 支持 A/B 测试、金丝雀发布、回滚，确保模型更新不影响线上稳定性。
- 特征工程服务化： 部分 Model Serving 平台（如 Triton、TorchServe）支持在服务端执行特征预处理，减少客户端负担。
- 性能与资源隔离： 通过 GPU/CPU 混合部署、自动扩缩容、请求排队等机制，保障高并发下的推理延迟。
下图展示了 Model Serving 在实时交易风控链路中的核心位置：
1.4 实时风控的典型技术栈
一个生产级的实时交易风控系统，通常由以下组件构成：
| 层级 | 技术组件 | 职责 |
|---|---|---|
| 数据接入 | Kafka / Pulsar | 接收交易事件流，提供高吞吐、低延迟的消息队列 |
| 实时计算 | Flink / Spark Streaming | 滑动窗口特征计算、实时聚合、规则匹配 |
| 特征存储 | Redis / Aerospike | 存储用户画像、设备指纹、历史行为等实时特征 |
| 规则引擎 | Drools / 自研规则引擎 | 执行确定性规则（如黑名单、金额阈值） |
| Model Serving | Triton / TorchServe / Seldon | 加载 ML/DL 模型，提供实时推理 API |
| 决策引擎 | 自研决策流引擎 | 编排规则与模型评分，输出最终决策 |
常见误区： 很多团队将 Model Serving 与规则引擎混为一谈。实际上，规则引擎处理的是“确定性逻辑”（如：金额 > 10000 则拒绝），而 Model Serving 处理的是“概率性推理”（如：模型判断欺诈概率为 0.92）。两者需要协同工作，而非互相替代。