1. 课程导入
在金融行业，一个模型从实验室走向生产环境，往往比训练本身更具挑战。许多团队在离线评估中获得了优秀的AUC、KS或夏普比率，却在真实业务中遭遇延迟超标、特征漂移、版本混乱、合规审计困难等问题。这些问题的根源，通常不在于算法本身，而在于Serving端——即模型对外提供推理服务的工程体系。本章作为课程导入，将帮助大家建立对金融模型Serving的整体认知，明确端到端项目实战的学习目标，并给出贯穿全课程的知识框架与实战路线图。
一、什么是金融模型Serving
金融模型Serving，是指将训练完成的模型（如信用评分、反欺诈、量化选股、利率预测等）封装为可被业务系统调用的在线或离线服务，并保证其低延迟、高可用、可解释、可审计、可迭代的一整套工程实践。它横跨机器学习工程、后端服务、数据工程与金融合规四个领域。
与通用互联网推荐或广告模型不同，金融Serving有三个显著特征：
- 强监管与可解释性：信贷拒贷、保险定价等场景必须能给出拒绝原因，模型输出需可追溯至具体特征与版本。
- 特征时效性敏感：交易反欺诈要求毫秒级响应，而风控评分可能依赖近30天行为序列，特征计算必须与训练时严格一致。
- 稳定性优先于极致性能：金融业务对故障容忍度极低，Serving系统需要灰度发布、熔断降级与影子流量。
核心结论：金融模型Serving不是“把模型包成API”这么简单，而是围绕特征一致性、版本可追溯、服务可观测、合规可审计构建的生产级工程体系。
二、端到端项目实战的学习目标
本课程以“一个真实的金融风控评分模型上线”为主线，贯穿数据、训练、部署、监控、迭代全流程。学完本课程，你应当能够独立完成以下任务：
- 将离线训练好的模型（如XGBoost、LightGBM或PyTorch模型）导出为标准化推理格式（ONNX、PMML或TorchScript）。
- 设计并实现特征服务层，保证训练与推理特征计算逻辑一致，避免训练-服务偏差（Training-Serving Skew）。
- 使用FastAPI、Triton或TensorFlow Serving搭建高性能推理接口，并完成压测与调优。
- 建立模型版本管理、灰度发布与回滚机制，支持A/B测试与影子模式。
- 搭建监控体系，覆盖延迟、吞吐、特征分布漂移、模型性能衰减与业务指标。
- 输出符合金融合规要求的模型文档、审计日志与可解释性报告。
三、整体知识框架与实战路线图
课程知识框架分为五层，自下而上依次为：数据与特征层、模型与格式层、服务与接口层、发布与治理层、监控与迭代层。每一层都对应金融Serving中的关键风险点。下图展示了端到端数据流与各层核心组件的关系。
实战路线图按周推进：第1周完成环境搭建与数据准备；第2周训练基线模型并导出ONNX；第3周实现特征服务与推理API；第4周接入版本管理与灰度发布；第5周搭建监控看板与漂移检测；第6周完成压测、复盘与合规文档。每一周都产出可运行的代码与可验证的指标。
四、常见误区与复盘视角
在过往金融Serving项目中，以下误区反复出现，值得在课程开始前建立警觉：
| 误区 | 典型表现 | 后果 | 正确做法 |
|---|---|---|---|
| 训练-服务特征不一致 | 离线用SQL算特征，线上用Python重写 | 线上AUC大幅下降 | 统一特征定义，使用Feature Store |
| 忽视模型版本管理 | 直接覆盖生产模型文件 | 无法回滚，审计失败 | Model Registry + 不可变版本 |
| 只监控系统指标 | 只看CPU、QPS，不看特征分布 | 模型衰减数周后才被发现 | 加入PSI、KS漂移监控 |
| 一次性全量发布 | 新模型直接替换旧模型 | 故障影响全部用户 | 灰度+影子流量+快速回滚 |
金融Serving的故障代价远高于互联网场景：一次错误的拒贷可能引发监管问询，一次延迟抖动可能阻断交易。因此，本课程始终强调“先可观测、再可发布、最后才谈优化”。
五、环境与工具准备
课程实战将使用以下工具链，建议提前安装并验证版本：
# 基础环境
python==3.10
pip install fastapi uvicorn onnxruntime scikit-learn xgboost lightgbm
pip install mlflow evidently prometheus-client
# 推理服务示例启动
uvicorn serving.main:app --host 0.0.0.0 --port 8000 --workers 4
# 模型导出为ONNX
python export_onnx.py --model model.pkl --output model.onnx --opset 13