修改小模型权重，减少反复校验耗费

小模型已经算出答案，却还在反复「Wait」「Hmm」，直到耗光 token。作者围绕这个问题做了两种改造：Focused 通过修改权重减少重复复核，Focused-Honest 再通过训练，让模型在卡住时主动报告无法完成。

结果有取舍：后者明显减少了超预算运行，也会提前放弃原本能解的题，整体正确率从 27% 降到 20%。这篇值得读的地方，是它把「少想一点」和「知道何时停止」拆成了两个可以分别验证的问题。

改掉反复复核，不一定需要重新训练

作者使用的底座是 saidutta69/Qwen3.5-2B-heretic，由 Heretic 处理而来。两个衍生模型都已放到 Hugging Face，采用 Apache-2.0 许可，支持 llama.cpp。

初始测试中，100 道题有 34 道无法在 4000-token 预算内完成，部分完成的题也在重复检查。作者猜测：模型在输出「Wait」前，内部已经形成了重新验证的倾向，可以从残差流（residual stream）里识别出来。残差流可以理解为各层不断读取、补充的中间状态。

他们从 33 条推理轨迹中，分别采集复核短语和普通句子出现前的激活，用两组差异提取第 18 层的「重新验证方向」。用「Let's check」训练的探针也能识别「Wait」，两个方向的 AUC 为 0.74、0.79。这支持它捕捉到了跨短语的共同信号，但还不足以证明找到了通用的复核机制。

随后，作者对第 13 至 18 层写入残差流的权重做方向削弱，涉及 ffn_down、attention output、DeltaNet 层的 ssm_out，以及第 15 层的 attn_output：

W <- W - 0.75 * d (d^T W)

要看的是 0.75：它控制削弱力度。作者试过 1.0，发现有用的自检也被压掉，模型开始自信地答错；0.75 是其测试中的折中。

总共只改了 12 个张量，每个变化约 1.6%，不做梯度训练、不增加新层，之后重新量化为 Q8_0。原文称「no data」，准确理解应是没有额外训练数据，因为方向提取仍使用了那 33 条轨迹。

在 100 道新题、每题采样一次、4000-token 预算、代码核验答案的测试里，两版未完成的仍是同样的 34 道题，日历题仍为 0/15。提供的原文没有完整结果表，无法据此量化它到底节省多少 token。

减少重复复核，并不会自动补上模型缺失的解题能力。

教模型认输，最难的是别教它轻易放弃

Focused 仍会在解不出的题上耗尽预算。于是作者加入 LoRA，得到 Focused-Honest。

训练素材是 Claude Haiku 生成的 440 道合成数学、逻辑题，覆盖 12 个题型，答案由代码计算。logic_grid、word_rate 两类完全留作评估。底座每题尝试 4 次，用来区分不会、会做和表现不稳定的题。

关键步骤是验证「死路」：从候选停止点继续生成 8 次，每次最多 3000 tokens，只有全部答错才视作死路。否则，模型可能把「暂时卡住」学成「应该放弃」。

最终的 757 条训练样本包含：

• 304 条 solve：截取模型自己的正确轨迹至 1000 至 3000 tokens，再接上后续完成过程。
• 179 条 keep going：看起来卡住，但继续尝试后成功的节点。
• 274 条 give up：经过验证的死路，接简短收尾，并以 UNSOLVED: <reason> 结束。

收尾由看不到答案的 Gemini Flash 模型编写；轨迹已包含正确答案却仍宣布放弃的样本会被过滤。题目提示只提到 ANSWER:、CONTRADICTION:、INSUFFICIENT:，没有 UNSOLVED:。因此，这个输出格式来自训练样本，而非题目提示。

训练采用 QLoRA（nf4），基于 bf16 权重，rank 16、alpha 32，作用于第 8 至 23 层；训练 1 epoch，学习率 1e-4，cosine decay，batch 8。单张 L40S 约需 10 分钟，之后合并权重并量化为 Q8_0。

评估每题使用 4 个随机种子，预算仍为 4000 tokens。在底座不会解的留出题型上，UNSOLVED 从 0% 升至 86%，超预算运行从 88% 降至 7%。但在可解的留出题上，它有 29% 的概率放弃；训练覆盖题型的对应比例为 10%。整体正确率因此从 27% 降到 20%。

我的判断

这项实验最有价值的，是同时训练「继续」和「放弃」。只奖励及时退出，很容易得到一个省 token、却不愿解决难题的模型。

不过，8 次续写全部失败，只能说明这些采样没有成功，不能证明问题无法解决。作者也明确说，UNSOLVED 后面的理由是教师模型风格的摘要，没有验证它是否准确诊断了失败原因。

ARC-Challenge 的 zero-shot、4-bit 测试中，准确率从 35.67% 升至 36.86%，McNemar p = 0.038。但作者做过多项比较，自己也只把它当作线索。评估集中于合成数学、逻辑题，包括 425 道英语题、15 道俄语题，以及 ARC-Challenge；MMLU、GSM8K 尚未测试，Focused 也只验证过一个底座。

与直接限制输出长度相比，主动报告失败更方便后续处理；与继续重试相比，它可能减少无效消耗。原文没有给出这些方案的对照成本，也没有前端或 Node 编程评估。作者建议优先正确率时选 Focused，但这属于当前窄评估下的选择，不能直接推广成团队选型结论。

能拿来做什么

• 如果本地小模型经常反复检查，可以用自己的任务同时记录正确率、超预算率和提前放弃率，避免只凭输出变短判断改造有效。原文提供了评估题、原始输出、校验和，以及复现权重编辑的 apply_edit.py 和方向文件。
• 如果业务能接受明确失败，可以把 UNSOLVED: 作为转交更强模型或人工处理的信号；它后面的理由仍需核验。
• 如果要试跑作者模型，可保留下面这组参数作为复现起点，再用实际任务决定是否调整。

llama-cli -m Qwen3.5-2B-Focused-Honest-Q8_0.gguf \
  --temp 1.0 --top-p 0.95 --top-k 20 --presence-penalty 1.5

要留意最后一行的 --presence-penalty 1.5：它也是运行配置的一部分，比较模型时应保持参数一致。