蒸馏砍掉模型的犹豫,OOD暴跌40%

今日概览

  • 自蒸馏砍掉的是模型「犹豫」的能力,不是冗余步骤——epistemic verbalization被压制后,模型在OOD场景性能暴跌40%,评估指标却看不出来。
  • Coding agent代码冗余度比人类项目高2.2倍。 SlopCodeBench首次量化了多轮迭代中技术债的积累:11个模型无一能端到端完成任务,prompt优化治标不治本。
  • 桌面操作Agent的瓶颈是演示数据,不是模型架构:CUA-Suite把连续人类操作数据从不到20小时推到55小时,当前最强模型仍有约60%的任务失败率。
  • 训好的DiT居然还没收敛。 每个block加一个缩放系数(共约100个参数)就能提升生成质量,说明当前训练流程可能系统性地欠校准。

重点关注

01 推理 推理链变短了,模型变聪明了?恰恰相反

自蒸馏把推理链缩短时,你以为砍掉的是冗余步骤,但这篇研究发现砍掉的是一种关键能力——epistemic verbalization(认知不确定性的表达)。简单说,模型在推理过程中会自言自语「我不太确定」「让我换个思路试试」,这些看似犹豫的表达实际上在帮助模型应对陌生问题。当teacher模型被喂了丰富的上下文后,它自己不再表达不确定性,蒸馏出的student自然也失去了这个能力。结果是:域内问题优化很快,但碰到训练没见过的问题(OOD),性能暴跌最高达40%。在Qwen3-8B、DeepSeek-Distill-Qwen-7B和Olmo3-7B-Instruct三个模型上都观察到了这个现象,不是个例。这意味着模型不是变笨了,而是变得盲目自信——它不再知道自己不知道。正在做蒸馏的团队,你的评估指标可能没在追踪真正丢失的东西。

自蒸馏砍掉的不是冗余推理步骤,而是模型表达不确定性的能力域内指标可能掩盖OOD性能退化高达40%,评估体系需要补上不确定性表达的追踪正在做蒸馏的团队应检查student模型是否保留了「犹豫」的能力

02 代码智能 通过测试不等于能迭代——Coding Agent的技术债首次被量化

用AI写代码的人大多有个直觉:agent生成的代码能跑,但改几轮就开始腐烂。SlopCodeBench把这个直觉变成了数据——20个需要多轮迭代的编程任务(93个检查点),让agent在不断变化的需求下反复修改自己之前的代码,而不是从零开始写一次性答案。11个模型没有一个能端到端完成任何任务,最高检查点通过率仅17.2%;89.8%的轨迹中代码冗余度持续上升,80%出现结构性腐蚀(复杂度集中在少数函数),对比48个开源Python项目agent代码冗余度高2.2倍,而人类代码随时间保持平稳。prompt干预能改善初始代码质量,但无法阻止后续退化——问题不在起点,而在agent缺乏跨迭代的设计纪律。

现有pass-rate benchmark系统性低估了agent代码的可维护性问题agent代码冗余度比人类开源项目高2.2倍且逐轮恶化,人类代码则保持稳定prompt优化能治标不能治本,迭代式开发需要agent具备架构规划能力

03 Agent 桌面操作Agent最缺的不是更好的模型,是更多的人类演示视频

训练computer-use agent(CUA,桌面操作代理)最大的瓶颈不是模型架构——此前最大的开源数据集ScaleCUA只有200万张截图,换算成视频不到20小时。CUA-Suite直接把量级拉开:10000个人工演示任务,覆盖87个专业应用,连续30fps录屏约55小时、600万帧。关键词是「连续」:不是稀疏截图加最终点击坐标,而是完整的光标轨迹、多层推理标注和无损视频流,可以直接转换成任何现有agent框架需要的格式。初步评测结果也够清醒:当前最强的基础动作模型在专业桌面应用上任务失败率约60%——模型不是不行,是根本没见过够多的真人操作。HF上84个upvote说明社区对这类高密度演示数据等了很久。

此前最大开源CUA数据集不到20小时视频,CUA-Suite将连续演示规模提升到55小时和10000个任务连续视频流比稀疏截图保留了完整交互动态,是训练通用桌面Agent的关键数据形态当前模型约60%任务失败率,说明CUA瓶颈在演示数据而非模型架构

04 图像生成 训好的扩散模型居然还没到最佳状态?

给每个DiT block加一个可学习的缩放系数——总共约100个参数——就能显著提升生成质量,甚至减少所需的推理步数。Calibri这个结果本身不复杂,方法只是把校准建模为黑盒奖励优化问题,用进化算法求解。但真正值得追问的不是方法,而是现象本身——如果100个缩放系数就能带来明显提升,说明当前DiT训练流程可能系统性地欠校准,各block之间的相对权重并没有在训练中被充分优化。这对所有训DiT的团队都是个值得追问的信号:训练pipeline里是不是还差一步后校准?

约100个缩放参数即可提升多个文生图模型的生成质量且减少推理步数现象暗示DiT训练流程存在系统性欠校准,模型出厂状态并非最优训DiT的团队值得审视自己的训练pipeline是否需要增加校准阶段
蒸馏砍掉模型的犹豫,OOD暴跌40%

也值得关注

05
从失败轨迹自我进化的移动GUI agent Agent拒绝微调+信用分配两阶段让模型在线迭代变强。链接
06
只有9%的agent用了自动迭代优化 Agent瓶颈不在算法,而在工程师必须盲猜的隐性设计决策。链接
07
VLM把光栅截图还原为可编辑SVG 多模态设计资产丢失源文件的老问题终于有了自动化方案。链接
08
微软Composer 2专为agentic coding从头训练 代码智能强调长期规划能力而非单次生成。链接
09
自动检测agent执行轨迹中的故意违规行为 安全对齐不只是失败,而是模型明知指令却选择偏离。链接
10
Code agent失败轨迹的细粒度拆解 评测终于能定位是理解错了需求还是执行走偏。链接
11
医疗EHR系统的长序列操作自动化 Agentdomain-specific computer-use agent的落地样本。链接
12
MLLM语义理解越强,生成恶意图像的风险越大 安全对齐能力提升和安全风险正相关。链接
13
用FPS游戏多视角视频测试agent的3D感知 评测快速变化环境中的多实体推理评测。链接
14
不训练就能聚合多个VLM输出并量化不确定性 多模态减少幻觉风险的免训练方案(ICLR)。链接

今日观察

今天两篇看似不相关的论文指向同一个机制缺陷。自蒸馏那篇发现推理退化不是因为模型能力下降,而是epistemic verbalization——「我不确定」「让我重新想想」——被系统性压制了。模型不是变笨了,是丢了表达不确定性的习惯。同一天,迭代优化的调研论文发现self-improving agent实际采用率只有9%,原因不是算法不行,而是工程师要做太多无法从目标函数推导出来的隐性设计决策——哪些参数该搜索、反馈信号怎么构造、什么时候该停。

交汇点很具体:当前后训练技术的退化或失败,根源不在优化算法本身,而在我们没有识别出迭代过程中哪些东西不能丢。蒸馏保留了准确率但丢了不确定性表达;优化循环保留了目标函数但丢了设计空间的可控性。两者的eval metric都显示「在改进」,但真正重要的信号在metric之外。

如果你正在上线任何迭代式后训练流程——无论是蒸馏、RLHF还是self-play——建议在eval套件里加一项:随机抽取100条OOD输入,人工检查模型是否还会表达犹豫和不确定。如果它对什么都信心满满,那不是能力提升,是校准丢失的信号。