区分战役、配置与执行
战役承载一个问题,例如将基准与某项调整进行对比。配置描述技术选择。一次运行是该配置的一次执行尝试,带有随机种子、开始时间、结束时间和状态。因此两次相同的尝试保留两个标识符,即使第二次替换了一次被中断的试验。
当同一份产物要在多个数据集上评估,或使用新指标评估时,请添加一个评估标识符。这样可避免把新模型与新一次读取现有模型混淆。把恢复尝试与它之前的那次以及所加载的检查点关联起来。
MLflow 同样围绕运行、参数、指标和产物来组织跟踪。即便在简单的文件目录中,这种区分也很有用。你可以用惯用的工具来实践;起步阶段并不需要特定的跟踪平台。
技术来源: MLflow — 运行、参数、指标与产物
编写实际执行的清单
保留在应用默认值和启动参数之后解析得到的参数。原始配置文件可能省略了某个默认批次大小或某个在运行时被修改的选项。记录下实际使用的内容,附上代码副本或不可变修订版本,以及未保存修改的状态。
清单还关联模型与分词器版本、软件环境、实际使用的 GPU、精度、数据、种子和指标定义。它描述这次试验,而不会变成安装教程。请写明单位:秒、字节、token、分数,或根据度量方式采用 0 到 1 的比例。
启动时状态为进行中;结束时根据你所观察到的情况,它变为已完成、失败或中断。不要事后用当前安装的版本去补全一个已遗忘的版本。请标注未知信息,并限制依赖它的结论。
| 区块 | 应保留的要素 | 所解决的问题 |
|---|---|---|
| 身份 | campaign_id、config_id、run_id,以及可能的 parent_run_id | 这个结果来自哪次尝试? |
| 代码与模型 | 确切的修订版本、本地修改、基础模型和分词器 | 实际启动了哪次计算? |
| 数据 | 版本、划分、预处理、标识符和相关信息顺序 | 基于哪些输入? |
| 参数 | 实际生效的值、种子和单位 | 用哪些设置? |
| 评估 | 被评估的产物、指标/版本、阈值和总体 | 分数意味着什么? |
| 收尾 | 状态、错误、产出的文件和决策 | 这次试验是否可用? |
超越文件夹名称来标识数据
像 donnees/final 这样的路径并不代表某个稳定版本。请保留文件或样本清单、划分方式以及转换流程。如果你修正标签或过滤行,请创建一个新版本并保留与前一版本的关系。旧分数应继续指向它的旧数据。
Hugging Face Datasets 将指纹与数据集状态及其转换关联起来,以便管理缓存。这一机制很有用,但还必须保留数据来源和预处理。尤其是一种不可哈希的转换可能导致随机指纹:缓存标识符本身并不能替代你的来源记录。
对于固定下来的产物,请附上文件大小和指纹。在复制前后各计算一次 SHA-256 摘要,可用来核对字节是否与所保留的参照一致。它既不能证明标签质量,也不能证明使用权利,更不能证明划分之间没有泄漏。
技术来源: Hugging Face Datasets — 指纹与转换 · Python 3.14 — 使用 hashlib 计算文件指纹
将指标、预测与产物关联起来
一行指标应当标明运行、所评估的产物、评估数据集、指标版本及其范围。请明确该数值针对的是中间检查点、最终模型还是某个子组。如果连哪个文件对应最终选定的点都弄不清,仅有一条曲线是不够的。
保留预测及其输入标识符、状态和评估所需的信息。期望的参考答案可以放在单独的分版本管理文件中。对于结构化输出,请区分原始结果、解析后结果和判定结论:修正解析不应当覆盖最初的输出。
MLflow 可以将指标与模型和数据关联起来。使用文件时,请通过明确的标识符应用同样的原则。维护一份可读的产物清单:权重或适配器、生成参数、输出、评估报告和决策记录。不要以为一张截图就能替代这些文件。
技术来源: MLflow — 关联指标、模型与数据集
示例:六次运行和一个掩盖缺失的重复项
以一个包含两种配置和三个随机种子的排序任务为例。它会产出六次预期运行。每次运行都应预测同样的 300 个评估标识:因此完整文件夹中应有 6 × 300 = 1 800 个唯一的(run_id, input_id)组合。这一计算描述的是一份预期清单,而非实际执行过的实验。
假设某个文件包含 300 行,但标识 doc-042 出现了两次,而 doc-117 缺失。总行数看似正确;然而其中只有 299 个唯一标识。在异常得到解释和修正之前,这次运行无法通过覆盖率检查。
如果随后每次运行都在完整语料库及其长文本子组上进行评估,那么对于某一给定指标,你会得到十二行指标。这仍然是六次运行,而不是十二次独立训练。评估键必须包含范围,才能保留这一区分。
| 检查项 | 预期 | 示意性异常 |
|---|---|---|
| 运行次数 | 2 种配置 × 3 个随机种子 = 6 | 一次重新运行会获得新标识 |
| 每次运行的预测数 | 预期 300 个唯一 ID | 300 行,但只有 299 个唯一 ID |
| 运行/输入组合数 | 6 × 300 = 1 800 | 仅凭总计数无法检测出所有重复项 |
| 评估次数 | 6 次运行 × 2 个范围 = 12 | 十二个分数并不会产生十二次运行 |
以一份清晰的决策收尾
在宣布一次运行结束之前,请检查文件是否存在且可打开、标识是否对应、指标是否可重算,以及每个错误的处理状态。一次技术上已完成的尝试仍可能因质量不足而被否决。请将这两种状态分开记录。
决策记录汇集了问题、所比较的变体、预先宣布的标准、所采用的结果以及排除理由。请引用 run_id 和产物路径,而不是“最后一个模型”。还要补充局限性:重复次数少、子组不足、版本无法找回或比较已变得不可能。
后续的修正必须留下痕迹:新的评估、新的报告以及变更原因。请将旧结论作为有标识的历史版本保留,不要让它看起来像是当前决策。最后,请确认导出的副本能从其目标文件夹中打开。
避免无意义的采集与复现承诺
只收集证明所需的字段,而不是所有环境变量或终端历史记录。一个配置或一个 URL 都可能包含令牌;请准备一份不含密钥的可分享版本,并将必须保持私密的数据保留在允许的位置。技术性的试验标识符无需包含个人姓名。
完整的记录有助于重做和理解一项实验。它并不能保证跨平台或跨版本在数值上完全一致:PyTorch 记录了这些可复现性的局限。请区分找回实验方案、重新加载产物和精确复现数值这三件事。
IteraGPU 笔记本可以保存你的目标、参数和决策,以及有用的参考资料。它不会启动运行,也不会自动采集文件或遥测数据。请把它当作你推理过程的索引,并将产物记录保存在你自己的备份中。
实际问题
一个 Git commit 就足以复现一次实验吗?
一个 commit 标识的是某个代码版本,但不一定包含数据、权重、实际生效的参数或未记录的修改。请将它和一份清单以及所产出的工件关联起来。缺少这些关联时,同一个 commit 的两次运行可能对应的是不同的实验。
需要保留所有预测结果吗?
在您的权限和留存限制范围内,保留用于验证结论和重新计算评估所必需的输出。对于一个规模有限的对比语料,标识符和完整预测能让错误可被审计。单纯的聚合分数通常无法让您找回缺失的样本。
恢复运行时是否应复用同一个 run_id?
所提议的方案会让每次尝试获得新的标识符,并将恢复运行与上一次 run 以及所加载的 checkpoint 关联起来。您可以把这些尝试归到同一个逻辑实验之下。这种分离能让中断、成本以及每个阶段实际产出的文件都清晰可见。