EvoLM: Self-Evolving Language Models through Co-Evolved Discriminative Rubrics

Paper: arXiv:2605.03871 Code: stellalisy/EvoLM Code reference: main @ d97cac6e (2026-05-18)

1. Motivation (研究动机)

1.1 现有 post-training reward 的共同瓶颈

论文开篇的判断很直接：RL post-training 的上限首先由 reward signal 决定，而当前 reward 大多来自模型外部。常见来源包括人工偏好标注、训练出的 scalar reward model、可验证任务上的 ground-truth verifier、以及闭源 LLM-as-a-judge。

这几类信号各自有效，但都有明确天花板。人工标注的上限是人类审阅能力本身，尤其在长推理、复杂代码、专业写作、开放式研究问答中，人类很难持续提供细粒度、可扩展、低噪声的 supervision。 闭源 API judge 的问题不是“不能用”，而是它把 reward 能力外包给了不可控的外部系统。训练成本、可复现性、接口漂移、隐私与部署依赖都会变成系统级约束。 verifiable reward 的问题更结构化：它只覆盖有标准答案的领域，例如算术、程序测试、形式化约束满足。大量 open-ended generation、instruction following、写作质量、解释完整性，其实没有低成本的 deterministic verifier。 scalar reward model 看起来是一个通用答案，但论文认为它把 evaluation criteria 隐含进参数里，虽然能在 held-out preference benchmark 上表现很好，却未必能在 policy 持续优化时提供稳定可迁移的监督。

1.2 为什么“模型自身的 evaluative knowledge”值得挖

作者的核心观察不是“外部监督不够好”，而是“LM 本来就已经知道很多怎么评答案”。预训练让模型吸收了大量关于好坏回答、结构完整性、事实性、推理习惯、格式要求的知识。

问题不在于模型完全不会评，而在于这种 evaluative knowledge 通常以潜在能力的形式存在，难以直接转成稳定 reward。模型可能“知道”什么回答更好，但不一定能把判断标准显式写出来，更不一定能把它写成一个小 judge 也能稳定执行的评分规约。 因此，本文关心的不是再额外注入一个更强 teacher，而是把模型已有的 evaluative knowledge 从隐式状态提取出来，变成可观察、可训练、可传递的 natural-language rubric。 这个方向的意义在于它具备随模型能力共同扩展的潜力。若 reward 来自模型自己的 evaluative capacity，那么模型能力越强，理论上可挖掘的监督来源也越强，不需要线性增加人工标注或永久依赖外部 API。

1.3 rubric factorization 为什么比直接标量打分更有前景

论文强调在 non-verifiable domain 中，evaluation 可以拆成两个步骤：

1. 先决定“看什么”，也就是 rubric generation。
2. 再决定“打多少分”，也就是 judging。

这一步 factorization 有三个直接好处。 第一，它把评价标准显式化。相比 scalar reward model 把偏好藏在参数里，rubric 把 criteria 写出来，使训练信号本身可检查、可解释、可 debug。 第二，它降低 judge 的要求。一个小 judge 也许自己想不出高质量 criteria，但如果已经拿到一份结构化 rubric，它只需要围绕这些显式 criteria 做局部判断，难度就低很多。 第三，它带来模块化。rubric generator 和 judge 可以解耦：一个 generator 用某个 judge 训练出来后，未来可以换另一个 judge 推理，检验 rubric 是否具有跨 judge 可迁移性。

1.4 已有 rubric-based RL 还差什么

论文并不是第一个把 rubrics 用进 RL post-training 的工作。RAR、RRD、RLCER、Rubric-ARM 都已经在尝试用 rubric 改善 reward 设计。

但作者认为这些方法仍然没有解决两个更根本的问题。 第一，很多方法依赖外部 teacher 或外部标签。RAR 与 RRD 需要 GPT-4.1 一类 proprietary model 来生成或迭代 refinement rubric；RLCER 需要 verifier 过滤 correctness；Rubric-ARM 需要 reference pairs 或偏好标签来共同训练 judge / rubric。 第二，已有方法通常没有把“什么样的 rubric 才算有用”正式定义为一个可训练目标。很多方法把 rubric 当辅助工具，但没有直接端到端地优化 rubric 的 discriminative utility。 论文把这个缺口说得很清楚：rubric 的价值不应以“读起来像不像专家意见”来定义，而应以“它能否帮助 judge 区分 preferred response 与 dispreferred response”来定义。

1.5 本文要解决的精确定义

因此 EvoLM 试图解决的不是泛泛的“self-improvement”，而是一个更具体的问题：

给定没有人工标注、没有外部 teacher、也没有 task-specific verifier 的环境，能否只依赖 policy 自身输出，训练出一套会随 policy 一起演化的 discriminative rubrics，并把它们转成足够有效的 RL reward？ 这个问题包含两个子问题。 第一个子问题是 rubric learning：如何定义 rubric generator 的训练目标，使其输出的 rubric 真正提高 judge 的区分能力，而不是仅仅生成表面上漂亮的 checklist。 第二个子问题是 co-evolution：如何让“生成答案的 policy”和“生成评分标准的 rubric model”相互增强，而不是一个静态 rubric 长时间监督一个不断变化的 policy。

1.6 为什么 temporal contrast 是关键动机之一

如果不依赖人工偏好，就必须自己构造 preference pairs。作者提出的核心直觉是：同一个问题上，较新的 checkpoint 往往比更早的 checkpoint 更强，因此模型自己的时间演化轨迹就能提供偏好信号。

这种 temporal contrast 重要的地方不只是“省标签”，而是它天然会形成 curriculum。早期 checkpoint 和当前 checkpoint 差距大，pair 较容易判别；后期旧 checkpoint 也逐渐变强，pair 会变难，逼着 rubric 从粗糙标准进化到细粒度标准。

也就是说，preference signal 不再是固定数据集，而是随训练动态变化的分布。这正好为 co-evolution 创造条件。

1.7 论文声称的研究价值

论文认为一旦这个问题被解决，会带来几层价值。

一是 reward scaling。reward 不必总由人、API 或 verifier 供给，而可以从模型内部不断挖掘。 二是 interpretability。rubric 让 reward 的来源变成可读文本，而不是一个 opaque score。 三是 transferability。rubric 如果学到的是 evaluation structure，而不是特定 judge 的打分习惯，那么它应当能跨 judge、跨 policy、跨 domain 使用。 四是更可靠地解释一个反直觉现象：高静态 reward-benchmark accuracy 不一定带来高 downstream policy quality。EvoLM 把“静态偏好拟合”和“动态训练中持续提供有用监督”区分开来，这是本文最重要的动机之一。

2. Idea (核心思想)

2.1 核心 insight

EvoLM 的核心 insight 可以浓缩成一句话：模型内部已有的 evaluative knowledge 不是直接拿来打分，而是先显式展开成 instance-specific rubric，再通过固定 judge 把 rubric 变成 reward，并让 rubric 与 policy 交替共同进化。

这里真正新的点不是“用 rubric”，而是把 rubric generator 本身当作 RL 训练对象，并把它的目标定义成 discriminative utility。换句话说，rubric 不是静态提示词，也不是人工编写的评价模板，而是一个会为了更好地区分好坏答案而被持续优化的 latent program。

2.2 与现有方法的根本差别

相比 prompted rubric 方法，EvoLM 不把 rubric 看作一次性 prompt engineering 产物，而是一个可学习模块。GPT-4.1 prompted rubric 和 Qwen3-8B prompted rubric 都能生成看似合理的 criteria，但它们不会随着 policy 变化而更新。

相比 scalar reward model，EvoLM 不把 evaluation criteria 隐含在单个分数函数里，而是先显式写出 criteria，再由 judge 执行。作者认为这种 factorization 让 reward 能在训练过程中持续自我重构，而不是被固定在一组静态权重中。 相比 RAR、RRD 这类 rubric-based RL，EvoLM 不依赖 proprietary API 作为 rubric teacher。相比 RLCER 和 Rubric-ARM，EvoLM 不需要 verifier 或 reference preference labels 来提供外部锚点。 相比 sequential training，EvoLM 的重点也不只是“先训 rubric 再训 policy”的 pipeline，而是让两者在 alternation 中 co-adapt。论文后面最关键的结果之一正是：静态 rubric accuracy 更高的 sequential 方案，并不一定产生更好的 policy。

2.3 论文如何重新定义“好 rubric”

本文对 rubric quality 的定义非常操作化：一个 rubric 是否好，不看措辞是否优雅，也不看是否像人类 checklist，而看在固定 judge 下，它是否能让 preferred response 的得分高于 dispreferred response。

这一定义有两个后果。 第一，rubric 的目标从“符合人类直觉”变成“提高可判别性”。因此很多最终学到的 rubric 会把原本抽象的评价标准改写成带有具体预期值、硬约束、局部可检查项的 criteria。 第二，rubric 的训练目标可以完全脱离人工 rubric annotation。只要有 preference pair，就能直接测量这个 rubric 有没有把 margin 拉开。

2.4 latent variable view 是这篇论文最漂亮的部分

作者没有把 rubric training 写成 ad-hoc heuristic，而是把 rubric 视为解释 observed preference ordering 的 latent variable。

直观地说，题目 $q$ 本身并不直接告诉我们为什么 $a^{+}$ 比 $a^{-}$ 更好；真正缺失的是一份“该如何评价”的中间解释，也就是 rubric $r$。如果给了合适的 $r$，judge 就能更可靠地重建 preference ordering。

因此，rubric generator 在做的事可以理解为近似后验推断：它从题目出发生成一份最能解释当前 preference pair 的 rubric。这个 framing 让后续的 ELBO、KL regularization、policy-gradient optimization 都有了统一解释。

2.5 co-evolution 的工作机制

EvoLM 的训练并非“policy 训练一次，rubric 训练一次”这么简单，而是一个持续交替的双向耦合系统。

当 rubric 暂时固定时，policy 会在这些 rubric 约束下收到 judge score，并据此更新。此时高质量 rubric 能提供更细粒度 reward，帮助 policy 变强。 当 policy 暂时固定时，rubric generator 会看到 policy 产生的 preference pairs，并为了更准确地区分它们而更新。此时更强的 policy 会产出更难区分的 pair，反过来逼迫 rubric 变得更具体、更可验证。 这就是论文所说的 emergent curriculum。不是人为设计难度递增，而是 policy 变强后自动制造更难的评估问题，从而推动 rubric 精化。

2.6 为什么固定 judge 反而重要

EvoLM 的一个反直觉设计是：训练时固定 judge，不让 judge 一起学。这样做表面上减少了可调部分，实际上隔离了“训练信号变好”的真正来源。

如果 judge 也一起训练，就很难分辨是 rubric 学得更好，还是 judge 本身更强了。固定 judge 之后，任何 reward 质量提升都必须来自 rubric generator 提供了更适合 judge 执行的 criteria。

这点与很多 end-to-end reward learning 工作不同。EvoLM 更强调把 evaluation structure 提炼出来，而不是单纯把整个 scoring pipeline 做大做强。

2.7 小 judge 也能工作，体现了方法假设

论文默认使用 Qwen3-1.7B 作为 frozen judge，而不是更大的 8B 或 14B judge。这里不是算力妥协，而是方法假设的检验。

作者想验证：只要 rubric 足够 discriminative，一个小 judge 也能在显式 criteria 的帮助下给出有效 reward。换言之，signal quality 的决定因素不一定是 judge 自身有多强，而是 rubric 是否把复杂评价转译成 judge 可执行的局部检查。

这也是后文 qualitative analysis 的结论来源：trained rubrics 会把抽象评价转成 pattern matching 风格的具体条件。

2.8 这篇论文最重要的经验性主张

EvoLM 并不声称“我们的 rubric accuracy 一定最高”，而是提出一个更强的经验性主张：静态 preference benchmark 上的高 accuracy 不等于训练时更有用的 reward。

最典型的对比就是 Skywork-RM-V2。它在 RewardBench-2 和 JudgeBench 上显著领先，但训练出的 policy 却最弱。EvoLM 认为真正重要的是 reward 是否能随着 policy distribution 变化而持续保持 discriminative，而不是是否在固定 benchmark 上达到最高分。

这一主张把论文的概念闭环补齐了：为什么要自进化 reward，不是因为 rubric 在静态测试集上更漂亮，而是因为它们在动态优化过程中更能跟上 policy 的变化。

3. Method (方法)

3.1 Overall framework

Figure 1 解读：图中最关键的不是三模块并列，而是它们之间的信息流方向。EvoLM 先让 rubric generator 为每个问题生成 instance-specific rubric，再让 policy 在 rubric 条件下产生回答并交给固定 judge 打分；另一侧则用 policy 自己构造出的 preference pairs 回头训练 rubric generator。也就是说，policy 决定“会写什么”，rubric generator 决定“看什么”，judge 只负责“按 rubric 执行打分”。这种分工把 reward 构造拆成了可解释、可替换、可迭代演化的链路，而不是单个黑盒 reward model。

给定 question $q$，rubric generator ${\rho }_{\varphi }$ 生成 rubric $r$，judge $J$ 对 response $a$ 打分：

$$r={\rho }_{\varphi }(q),s=J(q,r,a)\in [0,1].$$

论文把整个系统描述成单模型 parameter-sharing 配置：Qwen3-8B 同时承担 policy 与 rubric generator，两种角色通过不同 prompt 切换；judge 默认是冻结的 Qwen3-1.7B。这样做的目标不是极致性能，而是验证“同一个模型能否同时学会回答与评价标准生成”。

和传统 RLHF pipeline 相比，这里 reward 不再是直接的 $R(q,a)$，而是经由可见中间变量 $r$ 完成：

$$R(q,a)=J(q,{\rho }_{\varphi }(q),a).$$

这一步 factorization 让 reward function 具备两层自由度。policy 更新时可以把 rubric 固定，关注回答质量；rubric 更新时则把 policy 当前产出的 pair 视作数据，关注如何重写 criteria 才能让 judge 更稳定地区分好坏。 方法上最重要的设计边界有三条。 第一，judge 全程冻结。 第二，rubric generator 与 policy 使用同类 GRPO 风格更新。 第三，preference signal 完全来自 policy 自身输出，不依赖人工偏好或 verifier。 这三条共同保证 EvoLM 的 improvement 来源确实是“利用模型自身 evaluative capacity”，而不是偷偷引入了额外 teacher。

3.2 Rubrics as latent variables

论文把 rubric 当作 latent variable：它不是人工写死的监督标签，而是解释 preference ordering 的隐变量。目标是让 rubric 在 judge 下重建“preferred > dispreferred”的顺序，所以 rubric 的质量被定义成 discriminative utility，而不是表面可读性。

更具体地说，对于一个观测到的 preference pair $(a^{+},a^{-})$，作者认为真正缺失的是“为什么 $a^{+}$ 更好”的解释。这个解释不是一个抽象分数，而是一份自然语言 rubric。于是 preference generation 被写成： $p(a^{+}\succ a^{-}\mid q,r)=\sigma (J(q,r,a^{+})-J(q,r,a^{-})),$ 其中 $\sigma$ 是 sigmoid，judge score 差值越大，表示当前 rubric 越支持“$a^{+}$ 应优于 $a^{-}$”。

联合分布写成： $p(a^{+},a^{-},r\mid q)=p(r\mid q)\pi (a^{+}\mid q)\pi (a^{-}\mid q)p(a^{+}\succ a^{-}\mid q,r).$ 这里有两个值得强调的点。 第一，论文明确说这个形式推广了 Bradley-Terry 式 preference generation，但不再假设潜变量是一个 hidden scalar reward，而是假设潜变量是一段自然语言 rubric。 第二，$\pi$ 在理论上只表示 response distribution，可以是 policy，也可以是 offline preference dataset；在本文具体实验中，$\pi ={\pi }_{\theta }$，也就是当前 policy。 由于真实后验 $p(r\mid a^{+},a^{-},q)$ 不可 tractable，作者用 amortized variational inference，令 rubric generator ${\rho }_{\varphi }(r\mid q)$ 作为 variational distribution，优化 ELBO： $ \log p(a^+,a^- \mid q)\ge \mathcal{L}

\mathbb{E}{r\sim \rho\phi(r\mid q)} \big[\log p(a^+ \succ a^- \mid q,r)\big]

\mathrm{KL}\big(\rho_\phi(r\mid q)|\rho_{\mathrm{ref}}(r\mid q)\big). $ 这个目标的含义很清楚：

• 第一项鼓励生成能正确重建 preference ordering 的 rubric。
• 第二项把学习到的 rubric distribution 约束在 reference model 附近，防止 generator 完全漂移到不可读、不可解析或过度投机的文本空间。

从阅读角度看，这里的 latent-variable framing 很重要，因为它解释了为什么 rubric 并不是简单“辅助说明”。在 EvoLM 里，rubric 是 preference reconstruction 所必需的中介变量。

3.3 Rubric reward: discriminative utility 的实际形式

理论上，rubric reward 来源于对数似然： $R(r;q,a^{+},a^{-})=\log \sigma (J(q,r,a^{+})-J(q,r,a^{-})).$ 如果某个 rubric 让 judge 对 preferred answer 给出更高分，那么这个 reward 就更大。此时 rubric generator 学到的不是“如何写更像 rubric 的文字”，而是“如何写出能扩大 score margin 的 criteria”。

但论文没有停留在纯理论形式。实际实现里，他们把 reward 改成 margin reward 加 format reward： $ R(r;q,a^+,a^-)

\alpha\cdot \big(J(q,r,a^+)-J(q,r,a^-)\big) + (1-\alpha)\cdot R_{\text{format}}(r), $其中$\alpha=0.7$。 这个设计背后的直觉很务实。 margin term 提供连续梯度方向：preferred 与 dispreferred 的分差越大越好。 format reward 则保证 rubric 至少是 judge 能 parse 的结构化 JSON，而不是一段失控的自由文本。论文在 appendix 和代码里都强调格式约束很关键；否则 rubric validity 会显著下降，训练 signal 会因为 parse failure 直接塌掉。 代码里的 is_valid_rubric_format 也能看出这一点。它检查 rubric 是否能解析成 JSON、是否包含 criteria 列表、criteria 数量是否至少为 2、各项是否具有正权重、并要求总权重接近 1.0（容忍误差约 0.15）。 这说明格式奖励不是 cosmetic choice，而是 reward pipeline 的基础设施。没有可解析格式，judge 无法稳定执行 rubric，后续的 discriminative utility 也就无从谈起。

论文公式与 released code 实现差异：论文主线是 rubric generator 和 policy 交替 co-train；代码里 RubricTrainerActor 还支持 multi_judge、api_rubric_generator、rlcer_evolving_cached_generations 等分支，说明 release 版比正文更像通用训练框架。

3.4 Joint training

两边都用 GRPO 风格更新，但 reward 来源不同。policy 侧用 rubric-based judge score；rubric 侧用 preference pair 的 ranking accuracy。judge 参数固定，训练通过 alternation 进行。

policy 的 loss 写成： $ \mathcal{L}_{\text{policy}}(\theta)

\mathbb{E}{q,a\sim \pi\theta} \left[A(q,a)\log \pi_\theta(a\mid q)\right]. $ 其中 advantage 来自同一个问题下多条 response 的相对 judge score，也就是标准 GRPO 的 group-relative normalization 思路。核心不是学一个 critic，而是直接根据组内相对 reward 做更新。rubric generator 的优化在形式上是对称的：同一个问题上采样多份 rubric，比较它们在同一 preference pair 上带来的 reward，再做相对优势更新。因此，EvoLM 并没有为 rubric generator 发明一套全新 optimizer，而是把“文本生成一个 rubric”也视作 policy optimization 问题。训练过程分成两个阶段交替进行。

在 policy phase，固定 rubric generator ${\rho }_{\varphi }$，为每个问题生成 rubric，policy 采样若干回答，judge 评分后得到 reward，用于更新 policy。在 rubric phase，固定 policy，用 policy 自身构造 preference pairs，再让 rubric generator 采样若干候选 rubric，judge 分别评估这些 rubric 是否把 $a^{+}$ 与 $a^{-}$ 拉开，用分差作为 rubric reward。作者把 alternation frequency 记为 $K$，表示每个 phase 连续更新多少步再切换。主配置中 $K=50$。

论文把它解释为 coupling strength：$K$ 太小意味着两边频繁切换，可能不稳定；$K$ 太大意味着一边长时间对另一边的旧分布过拟合，co-evolution 变慢。

3.5 为什么 alternation 会形成 emergent curriculum

论文对 alternation 的解释不是普通的 coordinate descent，而是 curriculum 机制。

当 policy 还弱时，temporal contrast 构成的 preference pairs 差异很大，rubric 只需要抓住粗粒度标准就能把分数拉开。 随着 policy 变强，当前回答和旧回答的差距缩小，pair 变得更难区分。此时抽象 rubric 不再够用，generator 会被迫写出更具体、更局部、更可检查的 criteria 才能保持 margin。 反过来，当 rubric 变得更具体后，policy 接收到的 reward 也会更 sharp，不再只被鼓励“整体上看起来更好”，而是被鼓励满足一系列更明确的要求。 因此，co-evolution 的价值不只是两个模块都在变，而是在于每一方的进步都会改变另一方面临的学习难度与奖励几何。

3.6 Preference pairs 的三种构造方式

rubric generator 的训练离不开 preference pairs。EvoLM 完全不使用人工偏好，而是从 policy 输出中构造三类 pair，默认配置把三种方法都纳入候选，并在 rubric 训练时均匀采样。

3.6.1 Temporal contrast

Temporal contrast 是论文最核心的 preference source。对问题 $q$，在当前 step $t$ 采样回答 $a^{+}$，再从旧 checkpoint $t^{\prime }<t$ 中抽一个更早的回答作为 $a^{-}$。作者把较新的回答视作 preferred answer。

步长差 $t-t^{\prime }$ 很关键。gap 大，pair 容易区分；gap 小，pair 更难、但更有价值。论文主配置用的 step gap 是 $[20,100]$，代码配置对应 scripts/configs/replay_buffer_gap/gap20_100.sh。

这种方法的优点在于完全不依赖外部标签，并且随着训练推进会自动形成 harder pairs，因此最能体现 self-evolving 的味道。

3.6.2 Inferred question (IQ)

给定一个 preferred response $a^{+}$，让 policy 自己反推“它看起来是在回答什么问题”，得到 $\hat{q}$，再针对 $\hat{q}$ 生成一个 dispreferred response $a^{-}$。

这个信号主要考察 rubric 是否能捕捉“回答是否真正对题”的维度。若 rubric 足够关注 query relevance、task alignment、约束遵从，那么它应当更容易把原始问题上的好回答与“回答了另一件事”的回答区分开。

3.6.3 Rubric-conditioned (RC)

先为问题 $q$ 生成 rubric $r$，再令 policy 在 $(q,r)$ 条件下生成 $a^{+}$，同时在只给问题 $q$ 而不显式给 rubric 的条件下生成 $a^{-}$。

这个构造测量的是 rubric 的 actionable utility。如果把 rubric 提供给 policy 真的能改善回答质量，那么好的 rubric 应该系统性地让有-rubric 条件下的回答优于无-rubric 条件下的回答。 从机制上看，IQ 更像 relevance signal，RC 更像 usefulness signal，Temporal contrast 更像 evolution signal。三者合起来构成了较完整的无监督偏好来源。 训练逻辑可以概括为：

def policy_phase(policy, rubric_generator, judge, prompts):
    rubrics = [rubric_generator.generate(q) for q in prompts]
    groups = [policy.sample_group(q, rubric=r, n=8) for q, r in zip(prompts, rubrics)]
    scores = [judge.score_group(q, r, answers) for q, r, answers in zip(prompts, rubrics, groups)]
    advantages = normalize_within_group(scores)
    loss = grpo_loss(policy, prompts, groups, advantages)
    return loss
 
 
def rubric_phase(rubric_generator, policy, judge, prompts, pair_builder):
    pairs = [pair_builder.make_pair(policy, q) for q in prompts]
    candidate_rubrics = [rubric_generator.sample_group(q, n=8) for q in prompts]
    rewards = []
    for q, (a_pos, a_neg), rubrics in zip(prompts, pairs, candidate_rubrics):
        row = []
        for r in rubrics:
            margin = judge.score(q, r, a_pos) - judge.score(q, r, a_neg)
            row.append(0.7 * margin + 0.3 * format_reward(r))
        rewards.append(row)
    advantages = normalize_within_group(rewards)
    loss = grpo_loss(rubric_generator, prompts, candidate_rubrics, advantages)
    return loss

这段伪代码比原笔记更接近论文与代码共同表达的真实逻辑：两边都按 group 采样、group 内相对归一化、冻结 judge、交替切 phase，而不是一个单步 scalar loss。

3.7 关键组件伪代码

3.7.1 rubric generation and scoring

def generate_rubric_and_scores(rubric_generator, judge, question, answers):
    rubric = rubric_generator.generate(question)
    scores = []
    for answer in answers:
        score = judge.score(question, rubric, answer)
        scores.append(score)
    return rubric, scores

这一步看似简单，但决定了 EvoLM 的基本假设：judge 不需要自己发明 criteria，它只需要执行 rubric。

3.7.2 temporal contrast pair construction

def temporal_contrast_pair(current_answer, replay_buffer, current_step, min_gap=20, max_gap=100):
    candidates = []
    for item in replay_buffer:
        gap = current_step - item.step
        if min_gap <= gap <= max_gap:
            candidates.append(item)
    rejected = sample_one(candidates)
    return {
        "accepted_answer": current_answer.text,
        "rejected_answer": rejected.text,
        "rejected_step": rejected.step,
        "current_step": current_step,
        "step_gap": current_step - rejected.step,
    }

这对应代码中 ReplayBufferAnswerPair 一类字段：rejected_step、current_step、step_gap 都被显式记录，说明 temporal gap 不是论文里的抽象概念，而是 release 代码中会被追踪与分析的训练变量。

3.7.3 format checking

def is_valid_rubric_format(rubric_json):
    if "criteria" not in rubric_json:
        return 0.0
    criteria = rubric_json["criteria"]
    if not isinstance(criteria, list) or len(criteria) < 2:
        return 0.0
    total_weight = 0.0
    for item in criteria:
        if "criterion" not in item or "weight" not in item:
            return 0.0
        if float(item["weight"]) <= 0:
            return 0.0
        total_weight += float(item["weight"])
    if abs(total_weight - 1.0) > 0.15:
        return 0.0
    return 1.0

这个伪代码基本反映了 open_instruct/search_rewards/rubric_judge_rewards.py 的结构。它揭示了一个重要事实：EvoLM 学的并不是任意自由文本 rubric，而是带 schema 的结构化 rubric。

3.8 intuition：为什么这种方法会奏效

从人类视角看，EvoLM 的有效性不是因为它让模型“更会批改作文”，而是因为它改变了评价问题的表述方式。

一个小 judge 直接判断开放式回答质量时，往往需要做整体语义判断，容易不稳定。trained rubric 则把复杂任务拆成数个更明确的局部要求，例如是否包含某个关键步骤、是否满足特定格式、是否给出预期数值、是否覆盖必要约束。这样 judge 实际上不再做高层 holistic judgment，而是在执行一系列 pattern matching / local verification。

论文后面的 qualitative analysis 也支持这一点：随着训练，rubrics 会从抽象标签式 criteria 逐渐转向包含 expected values、明确约束与可检查条件的 criteria。换句话说，generator 学到的不是“更会写 rubric 文风”，而是“更会把评价任务转译成 judge 易执行的检查单元”。

3.9 released code 暗示的工程细节

README 与配置脚本表明 release 代码已经把 EvoLM 做成一个较通用框架，而不只是 paper main setting 的最小实现。

例如 scripts/configs/qwen3_8b_8nodes_singlemodel.sh 明确声明 single model mode，policy 与 rubric actor 共享 vLLM engines；该配置同时给出 VLLM_NUM_ENGINES + RUBRIC_JUDGE_NUM_ENGINES = 32 的合并推理容量。 再如 scripts/rubric_data_provider.py 里，data provider 不止支持 replay buffer / temporal contrast，还支持 inferred question、rubric-conditioned、以及组合式 provider。说明论文正文的三路 preference signal 在代码中确实被模块化实现。 另外，reward parser 还支持 multi_judge aggregation、reasoning 清洗、JSON 抽取等逻辑，这些都说明要让 rubric-based reward 真正可训练，文本解析与推理后处理是不可忽视的工程组成部分。

3.10 Code-to-paper mapping

Code reference: main @ d97cac6e (2026-05-18) — pseudocode and mapping based on this commit

Paper Concept	Source File	Key Class/Function
Joint training loop	scripts/train_rubric_policy_joint.py	RubricTrainerActor, BaseTrainerActor.start_training_threads
Rubric pair generation	scripts/rubric_data_provider.py	MultiPolicyFrozenDataProvider.create_answer_pair, create_data_provider
Rubric reward parsing	open_instruct/search_rewards/rubric_judge_rewards.py	is_valid_rubric_format, parse_rubric_items, parse_rlcer_rubric_items_with_scores
GRPO optimization	open_instruct/grpo_fast.py	PolicyTrainerRayProcess.train, one_training_step, make_reward_fn
Shared alternating script args	scripts/train_rubric_policy_joint.py	ScriptArgs, rubric_temperature, policy_temperature, api_rubric_generator
Replay-buffer preference metadata	scripts/rubric_data_provider.py	ReplayBufferConfig, ReplayBufferAnswerPair, step_gap
Rubric sampling params	scripts/rubric_data_provider.py	build_rubric_sampling_params, build_judge_sampling_params
Reward-format validation	open_instruct/search_rewards/rubric_judge_rewards.py	_remove_redacted_reasoning, _extract_json_rubric, is_valid_rubric_format
Main experiment config	scripts/configs/qwen3_8b_8nodes_singlemodel.sh	ALTERNATING_CYCLES, ALTERNATING_STEPS_PER_PHASE, NUM_UNIQUE_PROMPTS_ROLLOUT
Temporal contrast gap	scripts/configs/replay_buffer_gap/gap20_100.sh	REPLAY_BUFFER_MIN_AGE, REPLAY_BUFFER_MAX_AGE
Rubric-conditioned provider	scripts/configs/data_provider/rubric.sh	REJECTED_ANSWER_METHOD, rubric-conditioned chosen/rejected setup

4. Experimental Setup (实验设置)

4.1 训练数据

• Datasets used and scale: prompts 来自 Tulu 3 preference mixture，去重后约 271K prompts。论文明确提到其覆盖 general-purpose chat（如 UltraFeedback、WildChat）、instruction following、math、code、scientific literature understanding、persona-driven synthetic instructions。
• Preference labels: EvoLM 主训练阶段不依赖人工 preference annotation；rubric generator 的 pair 来自 policy 自身输出构造的 temporal contrast、IQ、RC 三类信号。

4.2 模型配置

• Policy / rubric generator: 主实验使用 Qwen3-8B，并采用 parameter-sharing 的 single-model 配置，即同一模型通过不同 prompt 承担 policy 与 rubric generator 两种角色。
• Frozen judge: 默认使用 Qwen3-1.7B。论文把它当作方法假设的直接测试：如果 rubric 足够 discriminative，即使 1.7B judge 也应能提供有效 reward。
• Ablated alternatives: appendix/ablation 里还测试了更大 judge（4B、8B、14B）与 two-model configuration，但主 setting 是 single-model + 1.7B judge。

4.3 训练超参数

• RL optimizer: 两边都基于 GRPO。
• Main RL hyperparameters from paper: learning rate $10^{-6}$，KL coefficient 0.001，8 response samples per question。
• Alternation: $K=50$，即每个 phase 连续训练 50 步后切换；这一点在论文正文和 scripts/configs/alt/alt50.sh 中一致。
• Temporal contrast gap: 主配置用 $[20,100]$，对应 scripts/configs/replay_buffer_gap/gap20_100.sh。

4.4 released code 中能定位到的具体实现配置

• scripts/configs/qwen3_8b_8nodes_singlemodel.sh：single model mode，policy 与 rubric workload 共享 vLLM engines；脚本注释写明 combined engine count 为 32。
• 同脚本还声明 NUM_UNIQUE_PROMPTS_ROLLOUT=64、single-model alternating training、以及 shared engine capacity 的工程设置。
• scripts/configs/data_provider/rubric.sh：指定 rubric-conditioned data provider，并说明 chosen answer 由 question + rubric 条件生成，rejected answer 由 question-only 生成。
• scripts/configs/paper_output.sh：paper experiments 的输出目录、checkpoint、generated rubrics、evaluation results 的保存逻辑。

4.5 SFT warm-up 与运行资源

• 现有 note 中记录的 warm-up / RL 资源配置为：SFT warm-up 使用 4×H20、3 epochs、batch size 1、grad accumulation 8、lr $10^{-5}$、max length 8192；RL 使用 8×H20、120 steps、32 prompts/batch、8 rollouts/prompt、effective batch size 256、mini-batch 16、lr $10^{-6}$、KL 0.001、clip 0.2。
• 这些值与代码脚本命名和 paper setting 是一致方向的，但论文正文对其中部分资源细节展开有限，因此这里应视作“paper + released config 的综合记录”，而非全部都来自 main text 单一表格。

4.6 Baselines

• Prompted rubrics: GPT-4.1 prompted、Qwen3-8B prompted。
• Scalar reward model: Skywork-RM-V2，用来隔离“rubric factorization 是否优于强 scalar reward signal”。
• Rubric-based RL baselines: RAR、RRD、RLCER、Rubric-ARM。
• Internal training-regime baselines: Sequential (IQ) 与 Sequential (RC)，用于和 co-evolving EvoLM 比较。

4.7 Evaluation metrics

• Rubric quality: RewardBench-2 与 JudgeBench 的 discriminative accuracy。它们测试的是 rubric-conditioned evaluation 是否能正确恢复 preferred over dispreferred ordering。
• Downstream policy quality: OLMo3-Adapt 12-benchmark average。
• OLMo3-Adapt tasks: GSM8K、MATH、HumanEval+、MBPP+、BBH、MMLU、IFEval、PopQA、GPQA、ZebraLogic、AGI-Eval、AlpacaEval v3。

4.8 对比设计的公平性

论文说明所有方法统一训练 500 policy update steps，以尽量做 apples-to-apples 比较；但每步计算成本并不完全一致，尤其 RRD 与 RLCER 会因 recursive refinement 或 per-rollout rubric generation 带来更高 per-step overhead。

这点值得记住，因为 EvoLM 的优势不是简单靠“训练更久”得到，而是在统一 step budget 下体现出来的。

5. Experimental Results (实验结果)

5.1 主结论

EvoLM 的主结论有两层。

第一层是 rubric generator 层面：Qwen3-8B 训练得到的 rubric generator 在 RewardBench-2 上相对 GPT-4.1 prompted rubric 高 25.7%。 第二层是 downstream policy 层面：co-trained policy 在 OLMo3-Adapt 12-benchmark average 上达到 69.3%，高于 GPT-4.1 prompted rubric 训练出的 66.7%，也高于 Skywork-RM-V2 训练出的 59.7%。 这两层结论共同支撑论文主张：reward 是否“可自我进化”比它在静态 benchmark 上是否高分更重要。

5.2 主表中的精确数字

5.2.1 Rubric quality

• GPT-4.1 prompted: RewardBench-2 avg 36.6，JudgeBench avg 41.3。
• Qwen3-8B prompted: RewardBench-2 avg 26.2，JudgeBench avg 36.6。
• Scalar RM (Skywork-RM-V2): RewardBench-2 avg 86.4，JudgeBench avg 80.8。
• RLCER: RewardBench-2 avg 45.0，JudgeBench avg 49.2。
• Rubric-ARM: RewardBench-2 avg 56.1，JudgeBench avg 51.5。
• Sequential (IQ): RewardBench-2 avg 47.2，JudgeBench avg 48.6。
• Sequential (RC): RewardBench-2 avg 46.0，JudgeBench avg 42.2。
• EvoLM: RewardBench-2 avg 46.0，JudgeBench avg 44.4。

这里最反直觉的点是：EvoLM 不是 rubric benchmark 上的绝对第一，甚至 Sequential (IQ) 在 RB2 上还略高于 EvoLM（47.2 vs. 46.0），但最终 policy 反而不如 EvoLM。这正是论文要强调的“static rubric accuracy 与 downstream utility 并不等价”。

5.2.2 Downstream policy quality

• GPT-4.1 prompted: 66.7 average。
• Qwen3-8B prompted: 67.5 average。
• Scalar RM (Skywork-RM-V2): 59.7 average。
• RAR: 67.5 average。
• RRD: 67.6 average。
• RLCER: 66.7 average。
• Rubric-ARM: 67.5 average。
• Sequential (IQ): 68.0 average。
• Sequential (RC): 68.3 average。
• EvoLM: 69.3 average。

EvoLM 的领先幅度虽然不是十几分的大差距，但在一个已经很挤的强 baseline 列表中仍然是 clear best。

5.3 EvoLM 赢在什么任务

主表里最亮眼的单项是 HumanEval+。EvoLM 达到 86.2，而 next best 是 RLCER 的 80.5。这也是论文正文特别点出的结果。

作者据此认为 trained rubrics 尤其擅长在 code generation 这种需要细粒度 criteria 的场景提供 sharper signal，因为 rubric 可以明确要求函数行为、边界条件、格式与关键逻辑，而不是给一个笼统“代码质量好不好”的分数。

除此之外，EvoLM 在 MATH 上 94.5、MBPP+ 上 68.5、AGI-E 上 86.4、AlpacaEval 上 42.2，也都处于强竞争水平。虽然不是所有子项都单独第一，但 aggregate 最强。

5.4 与 sequential training 的比较

Sequential (RC) 的 downstream average 是 68.3，Sequential (IQ) 是 68.0，均低于 EvoLM 的 69.3。

但在 rubric accuracy 上，Sequential (IQ) 的 RewardBench-2 average 是 47.2，高于 EvoLM 的 46.0。也就是说，先把 rubric 训好、再冻结去训 policy，并不能取代 co-evolution。

这说明 EvoLM 的增益不只是来自“学到了一个还不错的 rubric generator”，而是来自 rubrics 与 policy 持续对齐当前 policy distribution。static rubric quality 更高，不代表它对正在变化的 policy 更有训练价值。

5.5 与 scalar reward model 的对比最能说明论文观点

Skywork-RM-V2 在 rubric benchmark / judge benchmark 上几乎碾压所有方法：

• RewardBench-2 avg 86.4。
• JudgeBench avg 80.8。

但它训练出的 policy average 只有 59.7，是整张主表里最差的。 EvoLM 则相反：RB2 只有 46.0，JudgeBench 44.4，却得到 69.3 downstream average，比 Skywork-RM 高 9.6 分。 这个对比是整篇论文最有说服力的证据之一。它表明“静态偏好排序能力强”并不等于“训练中 reward 有用”。作者把原因归结为 reward overoptimization 与静态 criteria 无法适应 policy-induced distribution shift。

5.6 OOD rubric alignment

在完全 out-of-distribution 的 deep research tasks 上，EvoLM 也表现出更强的 rubric transfer。

HealthBench 上：

• EvoLM 58.4 Acc，59.0 Acc@0.1。
• Qwen3-8B prompted 53.0 / 55.0。
• GPT-4.1 prompted 52.5 / 53.6。

ResearchQA 上：

• EvoLM 59.3 Acc，68.7 Acc@0.05。
• Qwen3-8B prompted 57.2 / 59.0。
• GPT-4.1 prompted 51.0 / 65.3。

这组结果很重要，因为它表明 EvoLM 学到的不只是某一组训练 prompts 上的专用 rubric，而是某种更可迁移的 evaluation structure。

5.7 Cross-model transfer

论文还测试了把冻结的 EvoLM rubric generator 用到其他 policy family 上。

在 Qwen3-4B 上，EvoLM rubrics 训练出的 policy average 为 65.2，高于 GPT-4.1 prompted rubrics 的 64.4。 在 Llama-3.1-8B 上，EvoLM rubrics 训练出的 policy average 为 46.9，高于 GPT-4.1 prompted rubrics 的 45.7。 这说明 rubric generator 没有完全 overfit 到训练时的 policy family，至少在 reward-signal 层面还能转移到未见过的 policy 上。

5.8 Cross-judge transfer

论文进一步冻结同一个 EvoLM rubric generator，换不同 inference-time judges。

最强结果出现在 Qwen3-8B judge 上：trained rubrics 相对 prompted rubrics 在 RewardBench-2 上提升 +22.7 点（62.4 vs. 39.7），在 JudgeBench 上提升 +15.7 点。

对 OLMo-3-7B-Instruct 与 Mistral-7B 的 cross-family judge，也观察到整体正增益。作者据此认为：rubric generator 训练出的 evaluation structure 不是死绑训练 judge 的，而是具有 judge-agnostic 的可迁移性。

5.9 消融实验

论文在 Table 7 中消融了七个维度：reward design、alternation frequency、model configuration、preference signal、judge size、temporal step gap、cross-architecture transfer。

几个最值得记的结论如下。

• Reward design：main prompt + margin + format 是主配置，RB2 46.0、policy 69.3；去掉 format 时，main prompt + margin 只有 66.9 policy。说明格式奖励对最终训练质量很关键。
• Alternation frequency：$K=50$ 给出最佳 policy 69.3；$K=100$ 虽然 RB2 更高（48.5），policy 却降到 68.7，再次证明静态 rubric accuracy 不等于最好 policy。
• Model config：single-model 与 two-model 的 policy 都是 69.3，但 two-model 需要更多资源，因此 single-model 更划算。
• Preference signal：temporal contrast 主配置给出 69.3 policy；Combined(all 3) 虽然 RB2 最高 49.3，但 policy 只有 67.8。
• Judge size：1.7B judge 就能达到 69.3 最佳 policy；更大的 14B judge 虽然 RB2 高达 67.6，但 policy 为 69.0，仍未超过主配置。
• Step gap：$[20,100]$ 最优 policy 69.3；更小 gap 或更大 gap 在 policy 上都略差。

这组消融的总体结论非常统一：很多设定都能把 rubric benchmark 做高，但未必能把 downstream policy 做到最好。真正关键的是 self-evolving loop 是否健康运转。

5.10 质性分析

论文对 rubric 演化的描述也很有启发。

随着训练推进，criteria 会从简短抽象标签逐渐变成包含 expected values、约束条件、局部检查项的更具体 rubric。统计上，label-only criteria 从 21.9% 降到 0.3%，包含 specific expected values 的 criteria 从 6.9% 升到 19.3%，constraint-type criteria 从 7.7% 升到 20.3%。

平均 criterion 长度也从 59 characters 增长到 112 characters，而 criterion 数量仍大致稳定在 3 到 4 个附近。作者把这一变化解释为：rubric 正在把 holistic judgment 转译成小 judge 也能执行的 pattern matching。

5.11 局限性

论文本身和 released code 仍有一些边界。

• 主文把理论、主配置和主要结论讲清楚了，但很多 prompt 模板、解析细节、multi-judge / API-based 变体都放在 appendix 或代码中。
• 主配置结果非常强调 Qwen3 family；虽然论文展示了跨模型迁移，但跨架构性能仍有明显落差，例如 Llama-3.1-8B 的整体分数远低于 Qwen3-8B setting。
• 论文证明了 rubric accuracy 与 downstream utility 不一致，但尚未完全建立一套更好的 offline proxy metric 来提前预测“哪种 rubric 更适合训练 policy”。

5.12 总结

EvoLM 最重要的结论不是“rubric 比 scalar reward 更高分”，而是“会随 policy 一起进化的 discriminative rubric，比静态高分 reward 更适合拿来训练 policy”。它把 self-improvement 的来源从外部监督转移到模型自身可结构化的 evaluative capacity 上，并用理论、代码和实验共同说明：真正有价值的 reward 不是静态最准确，而是动态最能持续地区分当前 policy 分布中的好坏答案。