你给模型练的题，可能正在帮它"作弊"｜DecoEvo 这篇论文戳了一个真问题

做 prompt 优化或者搭 agent 工作流的人，大概都遇到过这个场景：一轮轮改下来，benchmark 跑分确实在涨，但实际用起来，模型碰到没见过的场景还是犯同样的错。更让人犯嘀咕的是——改的是解法，但测试题没变过，怎么知道模型是真进步了，还是单纯把测试题背得更熟了？

这个问题在学术界有个正式名字：评估瓶颈。用固定 rubric（评分标准）去优化 solver，等 solver 把 rubric 里列的标准都啃下来之后，优化信号就断了。solver 在 rubric 没覆盖到的维度上烂成什么样，反馈里完全看不见。这是 7 月 28 号挂到 arXiv 上的一篇新论文直接点出来的问题，论文叫 DecoEvo，全称是 Score-Decoupled Co-Evolution of Solver and Rubric-Generator Skills in Text Space。

可能会想，那把 rubric 也一起进化不就行了？让 solver 和 rubric-generator 互相追着跑。论文里试了这个方向，但发现一个问题：如果 rubric 的更新也依赖 solver 的打分，那 solver 有一条容易走的捷径——让 rubric 变简单。表面上看分数在涨，实际上是评分标准在放水，solver 的真实能力并没有提升。

DecoEvo 的做法是把这两个进化过程解耦。solver 这边，反馈不再是总分，而是拆到 criterion 级别，它知道自己具体在哪一条上不行。rubric-generator 的更新则不看 solver 的总分，而是通过两个独立的审计来驱动：一个是需求覆盖度（requirements coverage），检查 rubric 有没有漏掉重要的评估维度；一个是回答区分度（response discrimination），看 rubric 能不能把不同水平的回答真正拉开差距。这两个审计都不需要人工标注的 gold rubric，完全自动运行。

这个设计的直觉是：rubric-generator 要持续去抓 solver 新暴露出来的薄弱环节——反馈信号才能保持干净，两个技能的进化方向也才更明确。

效果方面，论文在五个 benchmark 上用三个不同的 LLM backbone 做了对比，DecoEvo 在官方评估下都超过了所有对比方法，相对 SkillOpt（当前比较主流的方法）的平均提升是 2.8%-5.0%。这个数字放在论文里不算特别炸，但它解决的是一个结构性问题——评估信号衰减，而且是在纯文本空间操作、不动模型权重、保持黑盒可观测的前提下做到的。

尤其对于正在搭评估 pipeline 的团队来说，这篇论文相当于给了一个新思路：别只盯着 solver 怎么改，手里的评分标准本身也需要一个独立的、不受 solver 分影响的迭代机制。否则优化得越卖力，越可能只是在帮模型适应测试题，离真实问题越来越远。

论文末尾没有给出一个漂亮的收场，它停在了一个更实际的问题上：解耦进化的两个审计目前还是基于 embedding 空间的相似度来做的，在某些需要严格逻辑推理的场景下，这个近似可能不够精确。怎么把审计做得更硬、更可解释，是接下来的方向。对于习惯在真实部署里反复调试的人而言，这种承认边界的态度，可能比一个完美的结论更有用。