[ICLR 2025] Critic Rubrics：打破 Benchmark 幻象，从真实世界轨迹中炼就最强编程评价器

TL;DR

当前的 Coding Agent 研究正面临一个尴尬的断层：在学术榜单（如 SWE-bench）上靠单元测试刷分的模型，由于缺乏真实世界的评估信号，在实际开发任务中往往表现不佳。本文提出了 Critic Rubrics 框架，通过将 24 种细粒度的行为特征作为“评价量表”，在稀疏的真实反馈（PR Merge/Code Survival）中引入稠密的监督信号。该方法不仅让 4B 规模的小模型在评价能力上超越了 70B 巨兽，更在推理时节省了 83% 的算力支出。

痛点深挖：为什么单元测试不是万能药？

在学术实验室里，判定逻辑很简单：Tests Pass = Success。但在现实生产中：

1. 反馈极其稀疏：只有不到 4% 的段落拥有明确的代码存活记录。
2. 信用分配困难：用户最终合并了 PR，但中间哪一轮对话起了关键作用？哪一轮是在帮倒忙？
3. 评价维度单一：单元测试无法识别代码的可维护性、意图对齐以及是否过度设计（Scope Creep）。

作者敏锐地发现，真实轨迹中隐藏着大量“隐式反馈”。例如，如果用户在 Agent 执行完后说“不对，用 DESC 排序”，这就是一个精确的评价信号。

核心方法：构建行为评价量表 (Critic Rubrics)

1. 轨迹片段化 (Segmenting)

为了解决长对话中的 Credit Assignment 问题，作者将对话切分为 Segments。每个 Segment 从用户的请求开始，到 Agent 调用 finish 结束。这使得每一个动作序列都能关联到一个明确的意图。

2. 24 维行为特征

作者通过迭代，定义了 24 个行为维度，分为三类：

• Agent 行为问题：如“分析不足 (Insufficient Analysis)”、“循环报错 (Loop Behavior)”。
• 用户反馈模式：如“修正请求 (Correction)”、“挫败感 (Frustration)”。
• 基础设施问题：区分是环境崩溃还是 Agent 玩坏了硬盘。

图 1：从生产环境轨迹到 Deployable Critic 的训练流程

3. 半监督多任务学习

这是本文的精华所在。模型（基于 Qwen3-4B）不仅要预测这个 Segment 是否最终导致了代码合并（稀疏信号），更要预测那 24 个 Rubric 特征（稠密信号）。即便一个 PR 最终没被合并，Agent 在过程中的“分析不足”仍然是确定性的负面教学材料。

实验与洞察：真实世界监督的必要性

跨领域泛化能力的缺失

实验给出了一个扎心的结论：仅在 Benchmark 数据上训练的 Critic 几乎无法识别真实世界的成败（AUC 仅 0.45-0.48）。这意味着学术数据与工业代码之间存在巨大的分布偏移（Distribution Shift）。

代码存活率 (Code Survival) 的优越性

相比于“PR 是否合并”这种二元信号，Code Survival（Agent 写的代码有多少行留到了最后）提供了更细粒度的监督。实验显示，基于存活率训练的 Critic 在各种指标上均显著占优。

图 2：不同 Rubric 特征对成功率的影响：Benchmark（下）与 真实世界（上）的显著差异

核心战绩：推理时扩展 (Inference-time Scaling)

1. Best-of-N 重排序：在候选的 8 个结果中，Critic 能精准挑出真正正确的那个，在全量测试集上相比随机选择提升了 15.9%。
2. 早期停止 (Early Stopping)：如果 Critic 判定当前尝试注定失败，则直接熔断。这让推理成本狂降 83%，而性能依然优于全量采样。
3. 跨模型鲁棒性：无论底层是 Claude Sonnet 还是 Opus，Critic 都能提供稳定的评价分数，避免了对特定 backbone 的过拟合。

总结与局限性

Critic Rubrics 证明了：对于复杂的软件工程任务，“怎么做”过程比“做成没”结果更关键。通过将定性的 Rubric 定量化为监督信号，该模型成功从 96% 的“无用”数据中提取了价值。

局限性：

• 目前高度依赖强模型（如 o3）进行离线标注。
• 对特定领域（如前端 UI）的细微审美偏好仍难以捕捉。

这篇工作为未来的 Agent 训练指明了方向：不要死磕测试用例，去观察真实的用户交互，那里才是 AI 进化的金矿。