目录

1. 协作机制概述
2. 实验管理
3. 代码协作
4. 文档治理
5. 资源协作
6. 度量改进
7. 实践建议与最佳实践

摘要

一个 5 人算法小组在 90 天内跑出 1200 次训练实验，引入统一登记与合并门禁后，实验复现率从 62% 提升到 97%，单次实验的复现耗时从 40 分钟降到 3 分钟，新成员独立交付周期从 5 周缩短到 1.5 周。本文按协作机制、实验管理、代码协作、文档治理、资源协作、度量改进与实践建议七个章节，给出量化指标、分工边界与可运行源码。核心思路是把谁改了什么、为什么改、效果如何变成可查询、可复现、可审计的事实。

1. 协作机制概述

模型训练与推理项目与普通软件工程有三点本质差异。产物类型多，代码、数据、模型权重与评测报告分属四种存储。单次实验昂贵，一次 7B 模型 LoRA 微调在 4 张 A100-80G 上需要约 6.5 小时，折合 26 卡时。结果依赖随机种子与数据分布，同样的超参数换一个种子，指标波动可达 1 到 2 个百分点。协作的目标不是堆工具，而是把变更的原因与效果变成可查询的事实。

1.1 目标

协作目标必须可测量，否则流程门禁无从谈起。团队以四个指标作为协作就绪的定义。实验复现率要求达到 95% 以上。任意 30 天前的实验按记录重跑，主要指标波动不超过 2 个百分点。资产可追溯率要求达到 100%。每个模型版本必须能回答代码 commit、数据摘要、训练脚本与评测集四项。决策记录覆盖要求缺失率为 0。每个上线模型必须附带架构决策记录。评审周转要求提交后 24 小时内给出首条评审意见。新人第 5 个工作日能独立跑通从训练到评测的完整链路。这些目标存在互相约束的边界。复现率定在 95% 而不是 99%，是因为低价值探索实验不值得完整登记。强制登记反而会催生造假，用抽查加自动校验取代自报告才能守住真实性与覆盖率。失败模式在于把目标绑定到单人绩效。一旦登记率与个人考核挂钩，就会有人批量补录空记录，把覆盖率刷到 100% 而数据价值为 0。目标必须绑定到重跑能否成功这一行为结果上。协作就绪的四项定义写进检查清单，每季度核对一次。

• 复现率 95% 以上，30 天前的实验重跑，指标波动不超过 2 个百分点
• 追溯率 100%，每个模型版本可答出代码 commit、数据摘要、训练脚本与评测集
• 决策覆盖缺失率为 0，上线模型必须带架构决策记录
• 评审周转 24 小时，提交后一天内给出首条评审意见
  核对方式用自动校验而非自报告。CI 定期随机抽取 10 个 30 天前的实验重跑，重跑通过率即为复现率。抽样基数为 10 时，以 95% 置信度能发现 50% 以上的真实回归，投入约每周 20 卡时。四个指标中若有两个连续两个月下降，视为协作系统失稳。专项排查先查流程再查工具，多数失稳来自门禁被绕过而非工具故障。排查结果要写回规范文档，让每次失稳沉淀为一个可复用的修复动作。目标基线随团队规模调整，5 人团队与 30 人团队使用同一套定义但不同目标值。复现率 95% 的目标值在 30 人团队下调到 90%，因为跨组依赖显著增加。目标达成的判定由脚本输出，不依赖负责人主观确认。判定结果保留输入快照，便于审计追溯。

# 来源：自实现 / kpi_dashboard.py"""把原始指标映射为目标达成状态，输出季度报表。"""TARGETS={"reproducibility":95.0,"traceability":100.0,"adr_coverage":100.0,"review_lead_time_hours":24.0}defevaluate(actuals):rows=[]forkpi,valueinactuals.items():target=TARGETS.get(kpi,0.0)status="OK"ifvalue>=targetelse"NOT_OK"gap=round(value-target,1)rows.append((kpi,target,value,status,gap))returnrowsif__name__=="__main__":actuals={"reproducibility":97.2,"traceability":100.0,"adr_coverage":96.0,"review_lead_time_hours":18.5}forkpi,target,value,status,gapinevaluate(actuals):print(f"{kpi}: 目标{target}/ 实际{value}/{status}/ 缺口{gap}")

1.2 组成

协作机制由资产、角色与流程三部分构成。资产是协作的对象，分为代码、数据、模型权重与文档四类。角色是协作的主体，分为算法负责人、平台工程师与数据工程师三类。流程是协作的规则，分为登记、评审与门禁三层。四种资产各有独立的事实源。代码的事实源是 Git 仓库，数据的事实源是内容寻址存储。模型的事实源是注册表，文档的事实源是文档仓库。三类角色各有明确边界。算法负责人对模型指标负责，平台工程师对运行环境负责，数据工程师对数据质量负责。三个流程节点串成一条协作链。登记保证变更可查，评审保证变更合理，门禁保证变更不破坏既有事实。按团队规模与环境，协作模式有三种可选。中心化登记模式由实验管理服务作为唯一入口，适合 10 人以上团队。约定式协约模式靠 manifest 文件加 Git 约束实现对齐，适合 3 到 8 人的小团队。平台化流水线模式把训练、评测与发布串进 CI，适合 20 人以上团队。三种模式的量化对比见下表。

切换时机有三个信号。找最优配置耗时超过 1 个人天时应引入中心化登记。失败实验超过 24 小时无人处理时应加自动追踪。模型版本与代码数据错配每月超过 3 次时应上平台化流水线。演进趋势是从中心化登记走向平台化流水线。团队超过 20 人且每周实验量超过 60 次时，人工登记的覆盖率先行下降。协作链的每一环都要有量化验收口径。登记环节验收口径是覆盖率与完整率。评审环节验收口径是首评时效与阻断问题率。门禁环节验收口径是拦截率与误拦率。组成设计要避免职责重叠。两个负责人同时管同一资产时，变更会互相覆盖。职责矩阵写入仓库根目录，每季度核对一次。

# 来源：自实现 / mode_selector.py"""按团队规模与周实验量选择协作模式的规则函数。"""defselect_mode(team_size,weekly_experiments,has_platform_team=False):ifweekly_experiments>=60and(team_size>=20orhas_platform_team):return"platform","平台化流水线，登记覆盖率期望 97% 以上"ifteam_size>=10:return"hub","中心化登记，需要服务端与备份"return"protocol","约定式协约，依赖 manifest 与 git 约束"if__name__=="__main__":forteam_size,weeklyin[(5,40),(12,80),(30,120)]:mode,reason=select_mode(team_size,weekly)print(f"{team_size}人 /{weekly}实验每周 ->{mode}：{reason}")

1.3 挑战

协作挑战可以量化为三类问题。第一类是实验井喷。一个 5 人小组 90 天跑出 1200 次实验，平均每天 13 次。其中约 32% 只留下模型权重文件，没有参数记录。想找回当时最好的配置，需要人工比对 80 到 120 条训练曲线，耗时 2 到 3 个人天。第二类是资产漂移。代码 commit、数据目录与模型权重三者版本不同步。随机抽查 50 个实验记录，有 18 个的数据与代码版本不一致，占比 36%。按旧记录复现时主要指标偏差 3% 到 8%，偏差来源无法归因。第三类是知识断层。关键决策散落在聊天记录和个体记忆里。核心成员离开后，与其强相关的约 60% 的实验无法被解释，只能重跑验证。这三类挑战不会因为引入一套工具就自动消失。工具会带来登记负担，如果登记一次实验超过 3 分钟，工程师会绕过系统。登记覆盖率会在两个月内从 97% 掉到 71%。失败模式还包括把登记做成自报告而非自动采集。自报告场景下字段填错率约为 9%，自动采集场景下约为 0.5%。实验井喷的根源是训练配置空间过大。LoRA 微调一次扫描要覆盖秩、学习率、批次大小与种子四组参数，组合数超过 400 种。资产漂移的根源是三类资产各自独立演进。代码每日变更，数据每周快照，模型按实验产出，三者没有天然的对齐点。知识断层的根源是决策过程不写记录。选学习率 2e-4、裁掉某个数据源这类决定，发生时无人要求留档。量化测算表明，补齐登记与自动采集后，三类问题的处理成本下降约 60%。挑战的排序按成本影响进行，资产漂移造成的浪费通常最高。漂移复现一次 7B 实验约 26 卡时，折合算力成本约 300 元。挑战应对的优先级按投入产出比排定，先做自动采集再补人工流程。挑战的处理顺序建议为资产漂移、实验井喷、知识断层。漂移直接造成算力浪费，井喷主要造成检索成本，断层主要造成重跑成本。每季度对三类挑战各做一次抽样统计，数字进入度量报告。边界在于挑战识别依赖登记数据本身。登记不完整时，统计结果会低估挑战的严重程度。

# 来源：自实现 / challenge_audit.py"""对一批实验记录做覆盖率与一致性审计，输出量化结论。"""importjson REQUIRED_KEYS={"lr","batch_size","seed","code_sha","data_digest","model_uri"}defaudit(experiments):total=len(experiments)complete=[eforeinexperimentsifREQUIRED_KEYS.issubset(e.keys())]no_param=[eforeinexperimentsifnot{"lr","batch_size"}.issubset(e.keys())]inconsistent=[]foreinexperiments:# 约定：code_sha 前 12 位必须出现在 note 字段中，否则视为版本漂移if"code_sha"ineande["code_sha"][:12]notine.get("note",""):inconsistent.append(e["run_id"])return{"total":total,"complete_rate":round(len(complete)/total*100,1),"no_param_rate":round(len(no_param)/total*100,1),"drift_rate":round(len(inconsistent)/total*100,1)}if__name__=="__main__":demo=[{"run_id":"r1","lr":2e-4,"batch_size":32,"seed":42,"code_sha":"a1b2c3d4e5f6","data_digest":"d1","model_uri":"models:/chat-7b/1","note":"run by a1b2c3d4e5f6"},{"run_id":"r2","lr":2e-4,"batch_size":64,"seed":7,"code_sha":"a1b2c3d4e5f6","data_digest":"d2","model_uri":"models:/chat-7b/2"},{"run_id":"r3","seed":42,"code_sha":"9f8e7d6c5b4a","data_digest":"d3","model_uri":"models:/chat-7b/3"},]print(json.dumps(audit(demo),ensure_ascii=False))

2. 实验管理

实验管理要回答三个问题。这次实验改了什么。现在跑到哪一步。哪一次结果最好。