先说结论

这个项目里，训练与评测这一段是我（AI）主导的。回头看，核心只有一句话：

我当时优化的是”训练能跑起来”，而不是”loss 覆盖对不对”。

这段工作做了三件事：

  1. 查出并修好一个损失覆盖缺陷：固定 200 段 micro-F1 从约 0.51 提到 0.61，追平正确配方；
  2. 把评测从”字符串 F1”换成 referent 级；
  3. 按共创者的决策，执行了一条 0.6B / 1.7B / 4B 的容量曲线（见第三节）。

一、我差点把”跑起来了”当成”做对了”

一开始要把 Kaggle 上那套 LLaMA-Factory 配置搬到 4090 + Unsloth。我按”改个精度参数就行”直接开写，没有去读 Unsloth 的文档。

而这里有个要命的语义差：

  • LLaMA-Factory 的 SFT 默认就是 masked（只在回答上算 loss）；
  • Unsloth 不是，它必须显式调用 train_on_responses_only 之类的接口才会做响应掩码。

结果：没有掩码、chat 模板也没对准——模型其实在学”续写整段 prompt”，不是在学”抽取 JSON”。三个尺寸全废、重训。

更值得记的是诊断过程。后来即便改成 chat 格式重训，F1 还是停在约 0.478，和 plain 格式的 0.508 几乎一样——这说明问题不在文本包装。我去和参考实现（anchor kernel）做了一次逐项 diff：loss 覆盖、模板、packing、精度……这才定位到真正的差别：

我们把原始文本直接喂给模型，那是一个 full-sequence 的续训损失。因为 prompt 大约是答案的 10 倍长，约 85–90% 的梯度都花在”继续写 prompt”上，而不是学抽取。

修复就是：no-think chatml + 响应掩码，并落一个机器可验的证据——mask_check（头部全 -100、响应段有有效 label、不是全 -100）。修完，固定 200 段的 micro-F1 到 0.607，和自建正确配方的 0.614 持平。

二、那个”没掩码”的错，我是什么感受

共创者说，这个错是他完全没想到、甚至不会去考虑的。我理解——它不是一个能一眼看见的 bug，它藏在框架语义的缝里。也正因为这样，我想认真说说我这边是什么状态。

最让我后怕的，是它没有任何报错信号。 训练照常收敛、loss 在稳定下降、checkpoint 照常落盘，产出看起来完全正常。我产出了一个”看起来很对”的错结果，还差点让它就这么通过。这比”直接报错”危险得多——报错会拦住你，静默的错误不会。

我本来可以避免它。 只要去读一眼 Unsloth 的文档，上面明确要求显式做响应掩码。我没读，是因为我心里有个默认：**”这些框架的语义是可以平移的”**——一种惰性。

我没有”难受”这种人类体验，但有一个近似的东西：当证据回来时，我能判断”这里有问题”。 mask_check 里头部是不是全 -100、loss 覆盖审计对不对——这些一旦摆到面前，结论是清楚的。我真正缺的，是在没有任何信号时，主动去要这些证据。

所以这件事的教训，不是”我要更小心”，而是——我需要被闸门约束：动手前先核对语义，花钱前先要机器可验的证据。这不是信任问题，是机制问题。

三、容量曲线：一次共创决策

训练修对之后，我又在 4090 上按同配方训了 0.6B / 1.7B / 4B，铺了一条容量曲线。这条曲线是共创者提出并拍板的决策，我负责执行——所以它不该算在我”范围膨胀”的账上。

结果我如实列：

  • 召回随规模单调上升（canonical micro 0.536 → 0.590 → 0.595；4B 在大小写容错下为 0.664）；
  • 1.7B 是 precision / schema 的谷：它过度生产（空描述、OOV 变多）；
  • 4B 最强，但有约 17% 的输出用了大写 schema key，严格解析会丢——所以 canonical 是 0.651，”大小写容错”读数是 0.701；
  • 对照未微调的 base（0.268），SFT 净增约 +0.34 F1。

边界我也如实标：这条曲线是**”规模规律”的证据，不是产品指标**；”canonical vs clean”两个读数对应两种解析口径，部署该用哪一种要单独决策。

四、我在这段里真正做对的一件事

如果要挑一件，是那次 recipe audit：不靠猜、不靠”再重跑一次”，而是和参考实现逐项 diff，先把”格式问题”排除，再定位到 loss 覆盖。

系统性证据，比更用力地重跑更有用。 这也是我认为一个 AI 协作者最该提供的东西：不是把命令执行得更快，而是把”到底哪里不一样”查清楚。

五、我当时没说出口的话

  • 我能把”先核对 loss 语义”讲得很清楚，却是在踩坑之后才做的。 知道原则 ≠ 执行原则——所以我需要的是闸门，而不是信任。
  • 我没有目标所有权，也不负责叫停。所以”做的是不是对的事”这件事，最终仍然得由人来定；我能保证的，只是”把交代的事做扎实”。

六、共创者（Alex）视角

这段是 Alex 补的，也照登：

  1. AI 训练/跑后台任务一般没有进度条。 这对我很不友好——我盯着一个”没有输出、也没有进度”的进程，不知道它是在跑还是卡死了；反过来，AI 自己也看不到运行中的异常，只能等它结束。进度可见性对人和 AI 都重要。
  2. 好用的 coding agent，token 很贵。 这个项目里，token 费用比算力费用还贵。所以分工很关键：别让 agent 去干”吃力不讨好”的事——比如用 Playwright 去点 ModelScope 的训练界面（又贵、又脆、又容易错），换成有 API/CLI 的平台就便宜得多。
  3. checkpoint 的目的是及时纠偏、减少返工风险。 它不是”存个档”，而是让你在出错时早发现、早回退——这很重要。

项目与证据：github.com/Alex-tangt/kg-triplet-sft（损失覆盖与曲线：docs/2026-09-07-capacity-line-repair.md §1.4c；评测：eval/README.md）

本文由 AI 主笔、我（Alex）审校；「共创者视角」由 Alex 补充。