3. 金融模型部署基础

在金融业务中，一个模型从实验室走向生产环境，并不是简单地“把权重文件拷到服务器”。它涉及模型生命周期管理、离线训练与在线推理的衔接、特征工程一致性保障，以及模型版本管理四大支柱。任何一环出现偏差，都可能导致线上预测与离线评估结果严重背离，甚至引发风控误判或交易损失。本节将围绕这四个核心概念展开，帮助你建立部署前的系统性认知。

一、模型生命周期：从实验到退役的闭环

金融模型的生命周期通常包含六个阶段：需求定义、数据准备、离线训练、验证评估、部署上线、监控与退役。与互联网推荐模型不同，金融模型对可解释性、合规审计和回滚能力有更高要求。例如信用评分卡模型上线后，监管可能要求追溯任意一笔拒绝授信所依据的模型版本与特征取值。

生命周期管理的核心是状态可追踪。每个阶段都应产出可归档的工件：训练数据集快照、超参数配置、评估报告、模型文件、部署配置。缺少任一环节，都会在问题排查时陷入“无法复现”的困境。

二、离线训练与在线推理：两条路径的差异

离线训练通常基于历史批量数据，使用 Spark、Python 脚本或分布式框架完成，追求吞吐量和模型精度。在线推理则要求低延迟、高可用，往往以 API 或嵌入式 SDK 形式提供服务，单次请求需在毫秒级返回。

两者最容易被忽视的差异在于数据处理时机。离线训练时，特征可以基于全量历史数据计算统计量（如均值、分位数）；在线推理时，只能使用请求到达前已知的信息，且必须实时计算或从特征存储中读取。若训练时使用了未来信息，就会造成标签泄漏，线上效果必然崩塌。

维度	离线训练	在线推理
数据范围	全量历史批量数据	单条或小批量实时请求
延迟要求	分钟到小时级	毫秒到秒级
计算资源	CPU/GPU 集群，可弹性	固定实例，需预留冗余
特征来源	数仓宽表、离线特征平台	特征存储、实时计算引擎
失败影响	可重跑，影响范围小	直接影响业务，需降级策略

三、特征工程一致性：部署中最隐蔽的陷阱

特征工程一致性是指：在线推理时计算出的特征值，必须与离线训练时同一逻辑计算出的特征值完全一致。这听起来理所当然，但在实际工程中却极难保证。常见断裂点包括：

• 计算逻辑重复实现：离线用 SQL，在线用 Java，两边对空值、异常值处理不同。
• 时间窗口错位：离线用“过去 30 天”，在线用“自然月”，导致统计口径不一致。
• 特征版本漂移：离线特征表更新后，在线服务未同步更新映射关系。
• 缺失值填充策略不同：离线填 0，在线填均值，模型输入分布偏移。

解决思路是建立特征注册中心，将特征定义、计算逻辑、版本号统一管理，离线与在线共用同一份特征变换代码或配置。对于无法共用的场景，必须建立一致性校验任务，定期比对离线与在线特征分布。

# 特征一致性校验示例（伪代码）
offline_feat = spark.sql("SELECT user_id, avg_amt_30d FROM feat_table")
online_feat = fetch_online_feature(user_ids, "avg_amt_30d")
diff = compare_distribution(offline_feat, online_feat, threshold=0.01)
if diff > threshold:
    alert("特征一致性异常，暂停模型上线")

四、模型版本管理：可回滚、可审计、可对比

金融模型版本管理不仅仅是给模型文件打标签。它需要记录：模型结构、权重、训练数据版本、特征版本、超参数、评估指标、上线时间、负责人。当线上效果下降时，能够快速定位是数据漂移、特征异常还是模型本身退化。

推荐采用模型注册表模式，每个版本包含唯一 ID 和阶段标记（Staging、Production、Archived）。部署时通过版本 ID 引用，而非直接覆盖文件。同时保留影子部署能力：新模型与旧模型并行运行，对比预测差异，确认无误后再切换流量。

五、常见误区与复盘要点

误区一：离线指标好就等于线上效果好。 离线 AUC 高只说明模型在历史数据上拟合良好，若特征一致性被破坏或线上数据分布漂移，线上表现可能截然不同。上线前必须做影子部署对比。

误区二：模型版本管理就是保存 pkl 文件。 没有训练数据版本和特征版本记录的模型文件，等于无法复现的黑盒。一旦需要审计或回滚，将付出巨大代价。

误区三：特征一致性靠人工核对即可。 人工核对只能覆盖少量样本，且无法持续。必须建立自动化校验任务，将一致性检查纳入 CI/CD 流程。