4. 模型部署架构设计：离线训练与在线推理的架构差异、实时推理与批量推理场景、模型版本管理与灰度发布
4.1 离线训练与在线推理的架构差异
信用评分模型的生命周期包含两个核心阶段：离线训练与在线推理。两者在数据访问、计算资源、延迟要求、更新频率等方面存在本质差异。理解这些差异是设计可靠部署架构的前提。
| 维度 | 离线训练 | 在线推理 |
|---|---|---|
| 数据来源 | 历史全量数据仓库、HDFS、特征存储快照 | 实时请求参数、实时特征管道、缓存特征 |
| 计算资源 | 大规模分布式集群（Spark、Flink） | 轻量级容器、Serverless、GPU/CPU 均衡 |
| 延迟要求 | 分钟级 ~ 小时级 | 毫秒级（P99 < 100ms） |
| 模型更新 | 周期性批训练（日/周/月） | 热加载、版本切换、A/B 测试 |
| 特征工程 | 全量特征计算、回溯、分桶 | 实时特征拼接、缺失值兜底、预计算查表 |
| 容错策略 | 任务重试、Checkpoint 恢复 | 降级、熔断、默认分数兜底 |
架构原则：离线与在线应共享同一份特征定义和模型元数据，但执行引擎完全隔离。离线侧重吞吐与数据完整性，在线侧重延迟与可用性。
4.2 实时推理与批量推理场景
信用评分模型在实际业务中需要同时支持两种推理模式，分别对应不同的触发机制和性能要求。
4.2.1 实时推理场景
- 申请评分（Application Scoring）：用户提交贷款申请后，系统在 1~2 秒内返回信用评分，直接影响审批决策。
- 交易反欺诈：每笔支付请求触发模型推理，要求 P99 延迟 < 50ms，支持高并发（数千 TPS）。
- 客户交互评分：客服对话、提额申请等实时交互场景，需要即时输出评分用于下一步策略。
4.2.2 批量推理场景
- 存量客户评分更新：每日/每周对全量存量客户重新计算评分，用于贷后管理、额度调整。
- 模型回测与监控：使用历史数据批量推理，对比模型输出与真实表现，生成 PSI、KS 等监控指标。
- 离线报表与审计：生成评分分布报告、拒绝推断数据、监管报送所需统计量。
架构建议：实时推理使用独立部署的模型服务（如 TensorFlow Serving、Triton Inference Server），批量推理则复用离线训练管道的批处理引擎，避免抢占实时服务的资源。
4.3 模型版本管理与灰度发布
信用评分模型的迭代不能采用“一刀切”的全量替换方式。版本管理与灰度发布机制确保新模型在风险可控的前提下逐步上线，同时支持快速回滚。
4.3.1 模型版本管理核心要素
- 版本号规范：采用语义化版本（Major.Minor.Patch），例如 v2.1.0。Major 变更表示模型架构或特征集重大调整，需重新备案。
- 模型注册中心：使用 MLflow Model Registry 或自建元数据服务，存储每个版本的模型文件、特征依赖、训练数据时间窗口、性能基准（KS、AUC、PSI）。
- 版本生命周期：开发 → 验证 → 预发布（Staging）→ 生产（Production）→ 退役（Deprecated）。
- 不可变存储：模型制品（pickle、ONNX、SavedModel）存入对象存储（S3/MinIO），版本号作为路径的一部分，禁止覆盖。
4.3.2 灰度发布策略
| 阶段 | 流量比例 | 验证指标 | 回滚条件 |
|---|---|---|---|
| Canary（金丝雀） | 1% ~ 5% | 评分分布漂移、延迟、错误率 | PSI > 0.1 或错误率 > 1% |
| 小范围 | 10% ~ 30% | 审批通过率、坏账率短期跟踪 | 通过率波动 > 5% 或坏账率上升 |
| 大范围 | 50% ~ 80% | 业务指标显著性检验 | 统计显著负向偏移 |
| 全量 | 100% | 持续监控 7 天 | 任何异常触发自动回滚 |
关键风险：灰度发布期间，新旧模型可能对同一用户给出不同评分，导致策略不一致。建议在灰度期间保持“评分输出”与“最终决策”解耦，灰度仅影响评分输出，决策策略保持不变。
4.4 架构设计要点总结
- 离线与在线分离：训练管道与推理服务使用不同的技术栈，通过模型制品和特征存储解耦。
- 实时与批量互补：实时推理服务处理高并发低延迟请求，批量推理用于全量更新和监控回测。
- 版本管理自动化：模型注册中心 + 不可变存储 + 灰度路由，实现一键发布与秒级回滚。
- 可观测性优先：每个推理请求携带模型版本号，监控系统按版本聚合延迟、评分分布、错误率，为灰度决策提供数据支撑。
生产级建议：灰度发布初期，新旧模型同时输出评分但仅使用旧模型评分做决策，观察评分分布差异至少 24 小时后再逐步切换决策逻辑。这是信用评分领域最稳妥的“影子测试”模式。