To Forge or Not to Forge：一项十样本试点的预注册研究

每个微调项目都始于一个没人度量的决策：这个任务到底值不值得微调？通常的回答是凭直觉，或者付出一次完整运行的代价来弄清楚。我想把这个上游决策本身摆上台面，于是我做了这个实验：在一套冻结的协议下——Qwen2.5-1.5B-Instruct、固定的 LoRA 配方与预算、贪心解码、基于执行的验证器——在 61 个任务上把十样本试点运行与全量微调配对，并把实测增益当作真值。

结果是一份技术报告，全文内嵌在本页底部。这篇笔记是短版本，外加论文页边写不下的过程故事。

预注册的问题

假设有两个端点，在剩余的 GPU 时段开跑之前就已提交：一个二元 go / no-go 标签（全量微调到底有没有帮助？），以及一个次级的排序端点（试点的增益能不能给全量增益排序？）。预注册带着一条诚实条款：如果 go / no-go AUC 的 bootstrap 置信区间覆盖 0.5，这个负结果就会被发表，而不是被协商抹掉。

后来证明，这条条款是整项研究里最重要的一句话。

跑出来的结果

**在这个 regime 里，锻造是默认。**微调在 61 个任务中的 53 个（87%）上有效。但有 23 个任务的起点是 pass@1 = 0，这些增益大多数是格式解锁——训练教会的是验证器能解析的答案格式，不是新的推理。

**试点能排序，而且这个排序有预算价值。**试点增益与全量增益之间的 Spearman 为 0.755（CI [0.60, 0.86]）。操作层面的表述是：如果只负担得起 K 次全量微调，按试点排序花掉它们，在 K = 20 时能捕获全部正增益质量的 0.72，随机排序是 0.33，oracle 是 0.74——离完美在三个点以内。

**二元门禁是一个登记在案的负结果。**预注册分类器的留一任务 AUC 为 0.755，置信区间触到 0.50——按诚实条款这是一个负结果，也按负结果刊出。随后一次声明的修订定位了机制：登记的模型过参数化（12 个特征对 8 个负类任务），并非没有信号。一个简约的三特征预决策模型——对一个泄漏特征和一次声明的 bug 修复都不变——在 0.767 上显著（CI [0.65, 0.88]，置换 p = 0.004）。

**二元框架本来就是错误的目标。**在 no-go 任务这么稀少的情况下，一个完美的门禁相对一律全量微调也只值 2.4% 的正增益质量。门禁这个问题基本上不重要；排序这个问题才重要。

**试点还是得跑。**指令嵌入对标签的预测停在随机水平（AUC 0.512）。读多少遍任务描述都替代不了让十个样本真正过一遍训练循环——而这的中位数开销只有完整训练加评测运行的 0.17。

过程故事

报告里的每一个测量都由一套自主的「发现 → 试点 → 决策 → 训练 → 验证」系统产出：一个 LLM coding agent 打包任务束、驱动串行 GPU 队列、诊断失败、执行封存分析，由人类操作员守住一小组 STOP 点。没有这个 harness，61 任务真值表就不会存在——手工跑 61 组试点加全量微调的配对，从来就不可能发生。

真正起作用的是三个设计选择：

• **失效即关闭。**碰到缺失哈希键的校验器会中止任务，而不是打包一个替代品；CUDA OOM 产出「无标签」，而不是一个猜出来的标签。一条为了保住队列全绿而编造数字的护栏，不是护栏。
• **契约禁止那些诱人的动作。**封存之后，加一个特征、扔掉最差的任务、移动 go 阈值——恰恰是预注册排除掉的那些动作。负结果保持首要位置，是因为契约规定它必须如此。
• **把诊断拆开。**agent 负责哈希校验、断点续跑逻辑，以及写下 PARTIAL 而不是一个猜出的增量；人类负责机制裁定与排除——而排除只有在任何标签产生之前才合法。

有一个声明的 bug 修复值得单独一句，因为它正是那种通常会被埋掉的事：一个格式合规特征对两个任务静默返回 1.0，修复在修订契约写好之后才落地，而它单独把一个 headline AUC 移动了 +0.18。报告把每个受影响的数字在两种定义下都印出来，而不是把这一跳折进一个更干净的故事。

论文

完整报告——协议、61 任务表、分解的 AUC 台账，以及关于失效即关闭的 harness 的更广泛影响一节——在这里：

在新标签页打开 PDF ↗

这是独立研究，按一项自成一体的研究来做：试点信号是真的，但它是个排序器，不是盏红绿灯；这个结果的诚实表述，比一个更好看的数字对我更重要。