2. 证据链的基本构成

在模型生命周期中，证据链不是一条简单的“数据→模型→结果”直线，而是一张由多个关键证据节点串联而成的有向图。每个节点都承载着特定类型的可追溯信息，节点之间的连接则记录了“谁由谁产生、谁依赖谁、谁验证谁”的关系。理解证据链的基本构成，首先要识别这些节点在模型研发流程中的真实位置与作用。

一个完整的模型证据链通常包含六类核心节点：数据节点、特征节点、模型结构节点、参数节点、超参数节点和评估结果节点。它们并非孤立存在，而是通过版本、哈希、配置文件和实验记录相互绑定。下面逐一说明每类节点的证据含义与记录要点。

数据节点：证据链的起点

数据节点记录的是“模型看到了什么”。它至少应包含：数据集名称与版本号、采集时间范围、样本量、字段列表、缺失值比例、标签分布、数据划分方式（训练/验证/测试的比例与随机种子）。例如，一个信贷违约预测项目的数据节点可以记录为：dataset=credit_2024Q1, version=v3.2, rows=128,450, train_ratio=0.7, val_ratio=0.15, test_ratio=0.15, seed=42。这些信息决定了后续所有证据的可复现边界——如果数据版本变了，整个证据链必须重新建立。

特征节点：从原始数据到模型输入的转换证据

特征节点描述的是“数据经过了怎样的加工”。它需要记录特征工程脚本的版本、特征名称列表、每个特征的变换方式（标准化、分箱、独热编码、目标编码等）、特征选择方法及被剔除的特征。例如，某特征节点可以记录：feature_set=v5, scaler=StandardScaler, selected=32/48, dropped=['raw_id','timestamp_raw']。特征节点与数据节点之间是“派生”关系，与模型节点之间是“输入”关系。当模型效果异常时，特征节点往往是第一个需要排查的环节。

模型结构节点：算法与拓扑的证据

模型结构节点记录的是“用了什么算法、什么网络拓扑”。对于传统机器学习，它记录算法类型与关键结构参数，如model=XGBoost, n_estimators=500, max_depth=6；对于深度学习，它记录网络层数、每层类型、激活函数、连接方式等。模型结构节点通常与代码仓库的某个commit哈希绑定，确保结构定义可回溯。它是参数和超参数的“容器”——没有结构节点，参数和超参数就失去了归属。

参数节点与超参数节点：必须分开记录的两类证据

这是证据链中最容易被混淆的一对概念。参数是模型从数据中学习得到的内部变量，如神经网络权重、线性回归系数、XGBoost的叶子节点分值；超参数是研发人员在训练前设定的配置，如学习率、正则化系数、树的数量、batch size。在证据链中，它们必须作为两个独立节点记录，因为它们的来源、变更方式和验证逻辑完全不同。

参数节点的证据形式通常是检查点文件（checkpoint）及其哈希值，例如params_hash=sha256:9f2c...e1a7, epoch=50, best_val_loss=0.184。超参数节点则以配置文件或实验管理平台的参数记录形式存在，例如lr=0.001, batch_size=64, weight_decay=1e-4, optimizer=AdamW。将两者混在一起记录，会导致“模型效果变化时无法判断是数据问题、结构问题还是调参问题”的追溯困境。

评估结果节点：证据链的终点与验证锚点

评估结果节点记录的是“模型在什么数据上、用什么指标、得到了什么结果”。它必须包含：评估数据集标识（与数据节点中的测试集对应）、评估指标名称与数值、评估时间、评估脚本版本。例如：eval_on=test_v3.2, metrics={AUC:0.873, F1:0.791, Recall:0.824}, eval_script=v2.1。评估结果节点是证据链的“验证锚点”——它向上游追溯，可以依次定位到参数、超参数、模型结构、特征和数据。如果评估结果不可信，整条证据链就失去了意义。

上图展示了六类节点之间的主要依赖关系。数据节点通过特征工程派生特征节点，特征节点作为输入进入模型结构节点。模型结构节点在训练过程中产生参数节点，而超参数节点则从外部控制训练过程，影响参数的生成。参数节点和超参数节点共同决定评估结果节点。评估结果节点通过虚线回溯到数据节点，形成验证闭环——这意味着当评估结果不达标时，可以沿着虚线路径逐级向上排查。

证据节点的绑定方式与版本管理

在实际工程中，这些节点不能只靠人工记录，而应通过实验管理工具（如MLflow、Weights & Biases、DVC）自动绑定。每个节点应至少包含三个要素：唯一标识（如哈希或版本号）、生成时间、上游依赖引用。例如，一次完整的训练运行可以记录为：

run_id: exp_20240612_003
data: credit_2024Q1@v3.2 (hash: a1b2c3)
features: feature_set=v5 (hash: d4e5f6)
model: XGBoost (commit: 7a8b9c)
hyperparams: {lr:0.001, n_estimators:500, max_depth:6}
params: checkpoint_epoch50.bin (hash: 9f2c...e1a7)
eval: test_v3.2 → {AUC:0.873, F1:0.791, Recall:0.824}

这样的记录使得任何一次评估结果都可以被完整复现：从run_id出发，可以找到对应的数据版本、特征版本、模型代码commit、超参数配置和参数检查点。如果某次评估的AUC从0.873下降到0.841，通过对比两个run的节点记录，可以快速定位是数据版本变化、特征集变化还是超参数调整导致的。

证据链的完整性检查

在模型交付或上线前，应对证据链进行完整性检查。一个可用的检查清单如下：

• 数据节点是否包含版本号、划分比例和随机种子？
• 特征节点是否记录了变换脚本版本和被剔除特征列表？
• 模型结构节点是否与代码仓库的commit哈希绑定？
• 参数节点是否有检查点文件及其哈希值？
• 超参数节点是否以配置文件形式独立保存？
• 评估结果节点是否明确标注了评估数据集和评估脚本版本？
• 所有节点是否通过run_id或实验编号相互关联？

只有这六类节点全部可追溯、可关联，证据链才具备真正的验证能力。缺少任何一环，都会在模型审计、问题排查或合规检查中形成断点。例如，如果只有评估结果而没有参数检查点，就无法复现该结果；如果只有参数而没有超参数记录，就无法解释参数为何是当前取值。因此，证据链的构建应从项目第一天开始，而不是等到需要审计时才补录。

从数据到评估结果，每一类节点都承担着不可替代的证据角色。数据节点界定边界，特征节点记录加工，模型结构节点定义容器，参数节点保存学习成果，超参数节点记录人为决策，评估结果节点提供验证锚点。理解这六类节点的构成与依赖关系，是后续建立自动化证据追踪和验证机制的基础。