2. 金融模型开发基础
在进入CI测试与CD自动部署之前，必须先理解“被测试、被部署的对象”究竟是什么。金融模型并不是单一形态的代码文件，它可能是一段定价公式、一套风险计量流程、一个机器学习评分卡，甚至是一组需要定期重跑的报表任务。不同类型的模型，其开发方式、依赖环境和交付形态差异很大，这直接决定了后续CI/CD流水线该如何设计。
一、金融模型的常见类型与交付形态
从工程视角看，金融模型可以按“计算特征”和“交付形态”两个维度分类。理解这些差异，有助于判断哪些环节需要单元测试、哪些需要数值回归测试、哪些需要数据质量校验。
| 模型类型 | 典型场景 | 核心计算特征 | 常见交付形态 |
|---|---|---|---|
| 定价与估值模型 | 期权定价、债券估值、衍生品盯市 | 解析公式、数值积分、蒙特卡洛 | Python/C++库、定价服务API |
| 风险计量模型 | VaR、ES、信用敞口、压力测试 | 历史模拟、协方差矩阵、情景重估 | 批处理任务、风险引擎模块 |
| 机器学习评分模型 | 信用评分、反欺诈、客户流失预测 | 特征工程、模型训练、概率输出 | Pickle/ONNX模型文件、推理服务 |
| 规则与决策模型 | 授信审批、交易限额、合规拦截 | 规则引擎、决策表、阈值判断 | 规则配置、DSL脚本、决策服务 |
| 报表与指标模型 | 监管报送、KPI计算、资金头寸 | 聚合、口径映射、时间窗口计算 | SQL脚本、调度任务、数据管道 |
可以看到，金融模型的“代码”往往不只是算法本身，还包括参数配置、数据口径、依赖库版本和运行环境。CI/CD要保障的，正是这些要素组合后的可重复性与可追溯性。
二、金融模型开发的标准流程
一个规范的金融模型开发流程通常包含以下阶段，每个阶段都会产生需要纳入版本管理的产物：
- 需求与口径定义：明确模型目标、输入输出、业务口径和监管要求，形成模型说明书初稿。
- 数据准备与探索：抽取历史数据，进行缺失值、异常值和分布检验，产出数据字典。
- 模型设计与实现：选择算法或公式，编写核心计算代码，同时编写参数配置文件。
- 验证与回测：通过样本外测试、敏感性分析和压力情景验证模型稳健性。
- 上线与监控：将模型部署到生产环境，持续监控数值漂移、性能衰减和异常告警。
关键认知：金融模型的“正确”不仅指代码逻辑正确，还包括数值结果在业务容忍范围内、数据口径与监管一致、以及在不同环境下可复现。CI测试必须同时覆盖这三层。
三、常见工具链与版本管理入门
金融模型开发常用的工具链可以按职责划分为几类。下面是一个典型的Python技术栈示例：
# 典型金融模型项目依赖示例（requirements.txt）
numpy==1.26.4
pandas==2.2.1
scipy==1.12.0
scikit-learn==1.4.1
statsmodels==0.14.1
pytest==8.0.2
pytest-cov==4.1.0
black==24.2.0
mypy==1.8.0
版本管理是CI/CD的基石。对于金融模型项目，Git仓库中通常需要管理以下内容：
- 源代码：模型计算逻辑、工具函数、接口封装。
- 配置文件：参数阈值、数据源连接、环境变量模板。
- 测试用例：单元测试、数值回归测试、边界条件测试。
- 模型产物：训练好的模型文件、校准参数、版本标签。
- 文档：模型说明书、变更日志、验证报告。
实践建议：模型文件如果较大，建议使用Git LFS或制品库管理，避免仓库膨胀。但模型版本号必须与代码提交哈希建立映射关系，确保任何一次生产结果都能追溯到具体代码和参数。
四、案例场景：一个利率互换估值模型的开发切片
假设我们要开发一个利率互换（IRS）估值模型。开发流程大致如下：
# 项目目录结构示例
irs_valuation/
├── src/
│ ├── curve_builder.py # 折现曲线构建
│ ├── swap_pricer.py # 互换定价核心
│ └── cashflow.py # 现金流生成
├── config/
│ ├── curve_config.yaml # 曲线参数
│ └── market_data.yaml # 市场数据映射
├── tests/
│ ├── test_curve.py
│ ├── test_pricer.py
│ └── regression/
│ └── test_irs_npv.py # 数值回归测试
├── models/
│ └── irs_v1.2.0.pkl # 校准后的模型参数
└── docs/
└── model_spec.md
在这个场景中，CI流水线至少需要做三件事：运行单元测试验证现金流计算逻辑；运行数值回归测试，将当前NPV结果与基准值对比，偏差超过阈值则失败；检查配置文件中的曲线参数是否完整且格式正确。这些检查在后续章节会展开为具体的流水线配置。
常见误区：很多团队只对“代码逻辑”做测试，忽略数值回归。金融模型的一个微小重构可能导致结果在小数点后第六位发生变化，如果业务容忍度是万分之一，这种变化可能无害；但如果容忍度是百万分之一，就必须用回归测试锁住数值边界。另一个误区是把模型文件和代码混在一起提交，导致仓库难以维护、回滚困难。
五、复盘：从开发基础到CI/CD的衔接点
回顾本节内容，金融模型开发基础与CI/CD的衔接点可以归纳为三条主线：
- 可测试性：模型代码需要被拆分为可独立调用的函数或类，避免“一坨脚本”无法写单元测试。
- 可配置性：参数、数据源、阈值必须外置为配置文件，便于在不同环境间切换和自动化校验。
- 可追溯性：代码、配置、模型产物、测试报告之间要有明确的版本对应关系，这是CD自动部署能够安全回滚的前提。
只有把这三条主线在开发阶段就打好基础，后续的CI测试和CD自动部署才不会变成“为了自动化而自动化”的空壳流程。