2. 基础概念

在金融建模的可重复训练体系中，“版本”不是一个单一概念，而是由数据版本、模型版本、代码版本和环境版本共同构成的四维一致性约束。很多团队在复盘时发现：同一份代码、同一批数据，换一台机器训练出的结果却不同；或者模型上线后表现衰减，却无法判断是数据漂移、代码改动还是依赖升级导致。根本原因往往是把“版本”简单理解为“文件备份”，而忽略了四个维度之间的耦合关系。本节先建立清晰的定义边界，再说明它们在金融建模中的关联机制。

一、核心原理：四类版本的定义与边界

数据版本指训练、验证、回测所用样本集合在某一时点的确定性快照。它不仅包含原始行情、财报、舆情等输入，还包含清洗规则、缺失值填充、特征工程后的结果。数据版本的核心是“可寻址”：给定一个版本号，能够精确还原出当时参与训练的每一行、每一列。在金融场景中，数据版本还必须记录时间边界，例如“截至2024-06-30的A股日频行情，含退市股票”，否则会引入未来函数或幸存者偏差。

模型版本指一次训练产出的参数集合及其结构定义。它包含权重文件、超参数配置、随机种子、训练轮次和评估指标。模型版本回答的是“这个预测能力来自哪次拟合”。在信用评分、量化选股等场景中，模型版本还需要绑定训练时的样本区间和特征列表，否则无法解释模型为何在特定市场状态下失效。

代码版本指生成数据管道、特征逻辑、训练脚本和推理服务的源代码在某一提交点的状态。代码版本的核心是“可追溯”：通过提交哈希可以定位到具体函数、参数默认值和分支逻辑。金融建模中常见的隐患是：特征计算函数被修改后未打标签，导致新旧模型使用了同名但不同义的特征。

环境版本指运行代码所依赖的操作系统、编程语言、库版本、CUDA驱动、硬件型号等运行时条件。环境版本回答的是“在什么条件下执行”。金融计算对数值精度敏感，例如不同版本的NumPy或BLAS库可能导致矩阵运算结果出现微小差异，进而在高频策略中放大为显著的收益偏差。

二、方法流程：从定义到关联的落地路径

理解定义之后，需要把四类版本纳入统一的追踪流程。推荐的做法是：以一次训练任务为单元，生成一个全局唯一的运行标识，并将四类版本信息写入元数据清单。具体步骤如下：

1. 在数据侧，对原始数据和特征表分别生成内容哈希，并记录时间范围、股票池规则和清洗参数。
2. 在代码侧，提交训练脚本和特征工程代码，记录Git提交哈希和分支名，确保工作区无未提交改动。
3. 在环境侧，导出依赖清单，例如使用pip freeze或conda env export，并记录Python版本和关键库版本。
4. 在模型侧，保存权重文件、超参数配置和随机种子，并关联上述三个版本的标识。
5. 将四类版本信息写入统一的运行记录，供回测、审计和线上推理引用。

下面是一个简化的运行元数据示例，展示了四类版本如何在一个配置文件中被同时锁定：

run_id: fin-credit-20240630-001
data_version:
  raw_hash: "a3f9c2..."
  feature_hash: "7b1e04..."
  date_range: "2019-01-01/2024-06-30"
  universe: "A股非ST，含退市"
code_version:
  git_commit: "9d4c1ab"
  branch: "main"
  dirty: false
env_version:
  python: "3.10.13"
  numpy: "1.24.3"
  lightgbm: "4.1.0"
  cuda: "12.1"
model_version:
  algo: "LightGBM"
  params: {num_leaves: 63, learning_rate: 0.05}
  seed: 42
  artifact: "model_20240630.pkl"

这份清单的价值在于：当模型表现异常时，可以快速判断是数据版本变化、代码逻辑改动、环境升级还是模型本身的问题。例如，若feature_hash未变而numpy版本升级，则优先排查数值计算差异；若git_commit变化且涉及特征函数，则优先复核特征定义。

三、案例/场景：四类版本在金融建模中的关联

以某券商的信用评分模型为例。该模型每月重新训练一次，用于预测企业债违约概率。某月上线后，AUC从0.78骤降至0.71。团队按四类版本逐一排查：

• 数据版本：当月财报数据延迟，部分企业使用了上一季度数据，导致特征分布偏移。
• 代码版本：特征工程脚本中，一个缺失值填充逻辑从“行业中位数”改为“全局中位数”，但未在提交信息中说明。
• 环境版本：训练环境从CPU切换到GPU，LightGBM的直方图分箱策略因浮点精度产生细微差异。
• 模型版本：由于上述三者叠加，模型学到了不稳定的特征关系，参数分布与上月显著不同。

最终定位到主因是数据版本和代码版本同时变更。这个案例说明：四类版本不是孤立存在的，任何一类的变动都可能通过训练过程传导到模型版本，进而影响业务指标。在量化交易中，类似问题可能表现为回测收益虚高，实盘却无法复现，根源往往是环境版本中的并行计算库差异或数据版本中的复权处理不一致。

四、误区/复盘：常见错误与纠正

在实际项目中，四类版本的管理常出现以下误区：

误区	表现	后果	纠正方式
只版本化代码	用Git管理脚本，但数据和环境不记录	换机器无法复现，回测结果不可信	将数据哈希和环境清单纳入运行元数据
数据版本用文件名代替	命名为“final_data_v2.csv”	无法判断内容是否变更，易覆盖	使用内容哈希或时间戳+规则描述
环境版本靠“我记得”	不导出依赖清单，口头说明	库升级后结果漂移，难以归因	每次训练自动导出并归档依赖
模型版本与数据脱钩	只保存pkl文件，不记录训练数据版本	无法解释模型失效原因	模型元数据中强制关联data_version

总结来看，数据版本、模型版本、代码版本和环境版本分别锁定了金融建模中的输入、输出、逻辑和运行时条件。它们之间的关联不是简单的并列关系，而是通过训练运行标识形成因果链：代码和环境决定训练过程，数据提供训练素材，模型承载训练结果。只有四类版本同时被记录和校验，金融模型才具备可重复训练的基础，后续的回测复现、线上监控和合规审计才有可靠的起点。