3. 实验数据采集与实验记录规范

实验优化工程中，最容易被低估却最致命的环节不是算法，而是数据采集与记录。一次主动学习循环通常包含“设计实验—执行实验—采集数据—更新模型—再设计”五个阶段，如果数据表结构混乱、元数据缺失、日志不可复现，那么后续的模型训练与优化决策都会建立在不可靠的基础上。本节聚焦三个核心问题：数据表如何设计才能同时容纳输入参数、输出响应与实验条件；元数据如何管理才能让每条记录“自解释”；实验日志与版本控制如何配合才能实现真正的可复现。

一、数据表结构：宽表、长表与混合结构的选择

实验数据最常见的两种组织方式是宽表（wide table）与长表（long table）。宽表以“一次实验一行”为原则，每一列是一个变量，适合变量数量固定、每次实验都测量全部响应的场景。例如在催化剂配方优化中，一次实验记录一行，列为：实验编号、温度、压力、配比A、配比B、转化率、选择性、收率、操作人、时间戳。长表则以“一个观测值一行”为原则，适合响应变量数量多、测量频率不一致或存在缺失的场景，列为：实验编号、变量名、变量值、单位、测量时间。两种结构并非互斥，实践中常采用“宽表存设计变量+长表存响应”的混合结构。

设计数据表时，建议遵循以下字段分层原则：第一层是标识字段，包括实验ID、批次号、样本号，必须全局唯一且不可复用；第二层是设计变量字段，即主动学习算法建议的输入参数，需记录名义值与实际值，二者不一致时以实际值为准；第三层是响应字段，记录测量结果及其单位；第四层是条件字段，包括环境温湿度、设备编号、试剂批号等可能影响结果的协变量；第五层是管理字段，包括操作人、时间戳、数据版本号。字段命名应使用英文小写加下划线，避免中文、空格和特殊字符，单位统一采用国际单位制并在字段名或元数据中显式声明。

二、元数据管理：让每条记录自解释

元数据是“关于数据的数据”，它回答的是：这个数值是在什么条件下、用什么设备、按什么方法测得的。没有元数据的实验数据，三个月后连实验者自己都无法解释。元数据可分为三类：描述性元数据（实验目的、项目名称、负责人）、结构性元数据（字段含义、数据类型、单位、量程）、管理性元数据（创建时间、修改时间、版本号、权限）。

落地时，推荐采用“实验级元数据+记录级元数据”双层结构。实验级元数据描述整个实验批次，例如：项目编号、实验目标、设计方法（如拉丁超立方、贝叶斯优化）、变量空间范围、设备清单、校准记录。记录级元数据描述单次实验，例如：实际执行时间、操作人、设备状态、环境条件、异常备注。两层元数据通过实验ID关联，既避免重复存储，又保证可追溯。

一个可直接使用的元数据模板如下（以催化剂筛选为例）：

experiment_id: EXP-2024-0312-001
project: 催化剂配方优化
design_method: BayesianOptimization
variables:
  temperature: {unit: K, range: [300, 500], type: continuous}
  pressure: {unit: MPa, range: [0.1, 2.0], type: continuous}
  ratio_A: {unit: mol/mol, range: [0.5, 2.0], type: continuous}
responses:
  conversion: {unit: %, method: GC, precision: 0.1}
  selectivity: {unit: %, method: GC, precision: 0.1}
equipment: {reactor: R-01, GC: GC-03, calibration_date: 2024-03-01}
operator: 张三
timestamp: 2024-03-12T09:30:00+08:00
notes: 第3次重复，环境湿度偏高

三、可复现实验日志：从“记录结果”到“记录过程”

可复现实验日志的核心要求是：任何人在相同条件下，依据日志能够重现实验并得到一致结果。因此日志不能只记录最终数值，还必须记录操作序列、参数设置、中间观察和异常处理。日志建议采用结构化文本格式（如 YAML 或 JSON Lines），每行一条记录，便于程序解析和版本比对。

日志内容应包含：时间戳（精确到秒，带时区）、事件类型（开始/参数设置/测量/异常/结束）、事件描述、关联实验ID、操作人。例如：

{"ts":"2024-03-12T09:30:00+08:00","event":"start","exp_id":"EXP-2024-0312-001","operator":"张三"}
{"ts":"2024-03-12T09:32:15+08:00","event":"set_param","exp_id":"EXP-2024-0312-001","param":"temperature","value":423.15,"unit":"K"}
{"ts":"2024-03-12T09:45:30+08:00","event":"measure","exp_id":"EXP-2024-0312-001","response":"conversion","value":78.3,"unit":"%"}
{"ts":"2024-03-12T09:46:00+08:00","event":"anomaly","exp_id":"EXP-2024-0312-001","desc":"GC基线漂移，已重新校准"}

日志与数据表的关系是：数据表存储“结果”，日志存储“过程”。两者通过实验ID关联，缺一不可。日志应实时写入，避免事后补记；补记的内容必须标注“补记”及补记时间。

四、版本控制：数据、代码与模型的协同管理

版本控制不仅用于代码，也应覆盖数据、元数据和模型。推荐采用 Git 管理代码与配置文件，采用 DVC（Data Version Control）或 Git LFS 管理大数据文件，采用 MLflow 或 Weights & Biases 跟踪模型训练与实验结果。核心原则是：任何一次实验的数据、代码、配置和模型都应能通过一个版本号或提交哈希完整还原。

具体操作上，建议为每个实验批次创建一个 Git 分支或标签，提交内容包括：数据表快照、元数据文件、实验日志、采集脚本、分析脚本、模型文件。提交信息应包含实验ID和简要说明。对于无法纳入版本控制的大型原始数据，记录其存储路径、校验和（如 SHA-256）和访问权限。

五、实操检查清单

在每次实验批次启动前，建议逐项核对以下内容：数据表是否已定义全部字段及单位；元数据模板是否已填写实验级信息；日志文件是否已创建并测试写入；版本控制仓库是否已初始化并配置好忽略规则；数据、代码、模型是否已建立关联标识。批次结束后，检查数据表是否有缺失值、日志是否完整、版本是否已提交并打标签。