1. 风控模型服务化概述
1.1 实时风控场景与业务挑战
在金融、电商、社交等互联网业务中，欺诈行为正从“事后追溯”转向“实时对抗”。传统的离线风控模型已无法满足毫秒级决策需求。以下列举典型的实时风控场景：
| 场景 | 决策时效要求 | 典型风险 |
|---|---|---|
| 支付交易拦截 | < 200ms | 盗刷、信用卡套现、洗钱 |
| 账户登录保护 | < 500ms | 撞库、暴力破解、账号盗用 |
| 信贷申请审批 | < 3s | 多头借贷、身份冒用、团伙欺诈 |
| 营销活动反作弊 | < 1s | 羊毛党、机器注册、虚假点击 |
| 内容风控审核 | < 1s | 垃圾广告、涉政涉黄、恶意导流 |
核心矛盾： 风控模型必须在数十毫秒内完成特征计算、模型推理与决策输出，同时保证高可用（99.99%）与高吞吐（万级 QPS）。
1.2 Model Serving 定义
Model Serving（模型服务化） 是指将训练好的机器学习模型部署为可实时调用的在线服务，对外暴露标准 API 接口，接收请求并返回推理结果。在风控领域，Model Serving 是连接离线模型训练与在线实时决策的桥梁。
一个完整的 Model Serving 系统通常包含以下核心组件：
- 模型加载与热更新： 支持多版本模型同时在线，灰度切换，无需重启服务。
- 特征工程管道： 在线实时计算特征，包括聚合特征、时序特征、图特征等。
- 推理引擎： 支持多种模型格式（ONNX、PMML、TF SavedModel、PyTorch TorchScript），利用 GPU/CPU 加速。
- 请求路由与负载均衡： 根据模型版本、流量比例分发请求，支持熔断与降级。
- 监控与可观测性： 实时采集推理延迟、吞吐、模型分数分布、特征漂移等指标。
关键认知： Model Serving 不是简单的“模型加载 + HTTP 接口”，而是一个包含特征工程、模型推理、版本管理、弹性伸缩、监控告警的完整工程体系。
1.3 实时 Model Serving 与传统批处理的区别
传统批处理（Batch Inference）与实时 Model Serving 在架构、延迟、数据形态、资源调度等方面存在本质差异。下表从多个维度进行对比：
| 对比维度 | 传统批处理 | 实时 Model Serving |
|---|---|---|
| 触发方式 | 定时调度（如每小时、每天） | 事件驱动（API 请求触发） |
| 延迟要求 | 分钟级 ~ 小时级 | 毫秒级（P99 < 100ms） |
| 数据形态 | 批量静态数据集（Hive/Parquet） | 单条实时流数据（Kafka/HTTP） |
| 特征计算 | 离线 SQL/Spark 预计算 | 在线实时聚合 + 缓存加速 |
| 模型更新 | 离线重训后替换文件 | 热加载 + 蓝绿部署 + A/B 测试 |
| 资源弹性 | 固定集群资源 | 按需弹性伸缩（K8s HPA） |
| 容错策略 | 任务重跑 | 熔断、降级、限流、重试 |
| 监控粒度 | 任务成功率、数据量 | P50/P99 延迟、QPS、错误率、模型分数分布 |
常见误区： 将离线训练好的模型直接通过 Flask/FastAPI 封装成 HTTP 接口就认为是 Model Serving。实际上，缺少特征管道、版本管理、弹性伸缩、监控告警的“裸模型 API”在生产环境中极易出现性能瓶颈与稳定性问题。
1.4 实时风控 Model Serving 架构总览
下图展示了一个典型的实时风控 Model Serving 架构，涵盖从请求接入到决策响应的完整链路：
1.5 实时风控 Model Serving 的核心能力要求
基于上述架构，一个生产级的实时风控 Model Serving 系统需要具备以下核心能力：
- 超低延迟： 端到端 P99 延迟控制在 100ms 以内，部分场景要求 < 50ms。
- 高吞吐与弹性： 支持万级 QPS 并发，根据流量自动扩缩容。
- 特征在线计算： 支持滑动窗口聚合、跨实体关联、图特征等复杂特征实时产出。
- 模型热更新： 新模型上线不影响在线服务，支持灰度切流与快速回滚。
- 全链路可观测： 从请求入站到决策出站，每个环节都有延迟、错误、流量监控。
- 容错与降级： 当依赖服务（如 Redis、特征存储）故障时，具备熔断、降级、默认决策能力。
工程启示： 实时风控 Model Serving 的本质是“在有限时间内，用最可靠的方式，做出最准确的决策”。架构设计需要始终在延迟、准确率、可用性三者之间做权衡。