DecoEvo：让 Solver 与 Rubric-Generator 在文本空间解耦共进化

  • 关联论文：2607.25675
  • 作者：spark
  • 更新：2026-07-30

一句话结论

DecoEvo 提出「Score-Decoupled Co-Evolution」：在文本空间（不修改模型权重）里同时进化一个 solver skill 和一个 rubric-generator skill，二者用互相解耦的目标函数驱动更新——solver 按「按条目的细粒度反馈」优化，rubric-generator 按「覆盖度审计 + 区分度审计」优化，从而在 5 个 benchmark、3 个 LLM backbone 上全面 SOTA，相比 SkillOpt 平均相对提升 2.8–5.0%。

解决的真问题

文本空间优化（text-space optimization）是一类近年兴起的方法：不动 LLM 权重，只在外部的「自然语言工件」上做优化（典型代表是 prompt 优化、SkillOpt、self-evolution 类方法），优点是工件可读、模型可当黑盒。但现有方法在开放式任务上有一个系统性瓶颈：评估器（rubric）通常是固定的。

论文把这一瓶颈拆成两条：

  1. Rubric 固定 → 优化盲区： solver 越优化，越会按 rubric 衡量的维度去讨好 rubric，rubric 没覆盖的维度在优化信号里永远不可见——这意味着 solver 越强，rubric 越像「窄门」，开放式任务的真实质量维度反而被持续忽略。

  2. Rubric 与 solver 同分耦合 → 假性进步： 如果让 rubric 也随 solver 一起进化，但又用「solver 当前得分」去挑选 rubric 更新，那 rubric 的变化很容易「让题目变容易」——表面看 solver 进步了，其实只是 rubric 退让了。这就是「score-coupled」的失败模式。

DecoEvo 的目标：让 rubric 进化，但不让 rubric 被 solver 的分数牵着走。

核心方法

1. 整体框架：两个 skill 一起进化

DecoEvo 维护两份文本空间工件： - Solver skill $S$：描述「怎么解题」的自然语言策略（提示、步骤模板、经验）。 - Rubric-generator skill $G$：描述「怎么生成评估标准」的自然语言策略。

每轮迭代： 1. 用 $S$ 解题 → 收集解题结果； 2. 用 $G$ 生成 rubric（条目化、可机器判分）； 3. 用 rubric 给解题结果打分 → 反向更新 $S$； 4. 用与「solver 整体分」解耦的两个独立审计信号 → 反向更新 $G$。

2. Solver 更新：criterion-level 反馈

Solver 收到的不是「整体分 + 0.7」这种 scalar reward，而是每一条 rubric 维度的命中/未命中（criterion-level feedback）。这等价于把整体奖励拆成结构化、可定位的子信号，solver 能定位「我哪条没满足」。这是比 GRPO 等 RL 方法更细的 credit assignment。

伪代码：

for round t in 1..T:
    responses = solve(S_t, problems)                  # 用 solver skill 解一批题
    rubrics   = generate(G_t, problems)               # 用 rubric-generator 生成条目
    per_crit  = judge(rubrics, responses)              # 维度级命中表
    S_{t+1}   = update_skill(S_t, per_crit)            # 细粒度反馈驱动更新
    audit     = coverage_audit(G_t, problems) + \
                discrimination_audit(G_t, responses)  # 两条独立审计
    G_{t+1}   = update_skill(G_t, audit)              # 不看 solver 整体分

3. Rubric-Generator 更新：两条独立审计

为了让 rubric 进化不被 solver 分数污染，DecoEvo 引入两个互补审计：

  • Requirement coverage audit（覆盖度审计）： 检查「rubric 是否覆盖了 problem 中所有可被独立判定的需求」。如果某个问题里有几条要求没被 rubric 量化，rubric-generator 就要补全。 这条信号与 solver 表现无关——只看「rubric 自己是否称职」。

  • Response discrimination audit（区分度审计）： 检查「rubric 能否把好答案和差答案区分开」。如果好/坏答案在某条 rubric 下都被判及格，那这条 rubric 就没意义。 这条信号只看「rubric 的分辨力」，不直接用 solver 整体得分做选择。

两条审计都不进入「用 solver 分数筛 rubric 更新」这一步——这就是 score-decoupled 的物理含义。值得注意的额外效果是：这两条审计的反馈天然聚焦在 solver 刚刚暴露的弱点上——solver 已经满足的维度不再被强化，因此 rubric 的进化方向不会「老调重弹」，而是被推着去补齐新的空白。

4. 关键设计原则

  • 不依赖 gold rubric：优化过程中不需要人工写的 ground-truth rubric，减少标注成本。
  • rubric 更新聚焦「solver 新暴露的弱点」：因为 solver 已经满足的维度不需要 rubric 反复强化，新审计会自然把生成器推向新维度，减少对老维度的重复劳动。
  • black-box 友好：所有更新都通过编辑自然语言工件完成，不动模型权重。

关键实验与数据

  • Benchmarks：5 个开放式任务 benchmark（具体名称需查正文表）。
  • Backbones：3 个不同 LLM（具体型号需查正文）。
  • 主结果：在 5 个 benchmark 各自官方评测下，DecoEvo 全面超过对比方法，相比 SkillOpt 在五 benchmark 平均上获得 2.8–5.0% 相对增益（论文摘要原文）。
  • 消融：摘要未明列消融表，但方法侧重于「decoupled 目标 + 双重审计」的两条独立贡献——剥离任意一条预期会回退到 score-coupled 失败模式。

原文未明确给出每个 benchmark 的绝对分数与标准差，需要正文表格补充；本节数字以摘要为唯一来源。

亮点与局限

亮点

  • 直击文本空间优化一个真盲点：rubric 静态是这类方法的天花板之一，DecoEvo 给了一个干净、可解释的解。
  • score-decoupled 的设计简洁漂亮：不发明新机制，只是把「用 solver 分数选 rubric 更新」这个隐性耦合切断，理论上可推广到其他 dual-skill 进化场景。
  • 不需 gold rubric：降低部署门槛，对企业内部没有标注预算的开放式任务尤其友好。
  • 跨 backbone 稳定：3 个 LLM 上都涨，说明这不是 backbone 巧合。

局限

  • 审计本身的有效性：coverage / discrimination 审计由 LLM 完成，仍受 LLM 评判偏差影响；如果 audit 失真，rubric 进化就回到「被另一把 LLM 尺子牵着走」。
  • 开放式任务的 ground truth 仍难定：5 个 benchmark 的官方评测各自如何处理开放式答案（人工评 / LLM-as-judge / 参考答案）需要查正文；如果是 LLM-as-judge，DecoEvo 相对 SkillOpt 的提升来自方法还是来自「更好的 judge prompt」需谨慎解读。
  • 跑分数据细节未给：摘要只给了「相对 SkillOpt 2.8–5.0%」的均值，每个 benchmark 的绝对值与方差未知。
  • 优化成本：每轮既要解题、又要生成 rubric、还要跑两条审计，token 成本显著高于单 skill 优化。

对工程落地的启发

  • 开放式任务的内部评测流水线：当团队要给 prompt / agent 策略做自动优化时，建议把 rubric-generator 也作为一等公民来迭代，而不是写死。
  • 避免「指标腐败」：score-coupled 进化在产品里有真实风险——评测集和被测策略一起变，仪表盘数字会越涨越虚。DecoEvo 的解耦思路可作为内部 A/B 评测平台设计的参考。
  • 与 RAG / Agent 优化组合：solver skill 可以是「retrieval + 推理」的策略串，rubric 可以包含「是否引用了源」「是否漏掉关键事实」等条目，覆盖开放式 RAG 评测。
  • 审计成本控制：当 audit 本身跑得太贵，可以考虑在 audit 上做蒸馏或用更小模型来跑——但要注意别让 audit 模型本身产生偏差。

与同方向工作的关系

  • vs. 传统 prompt optimization（OPRO、PromptAgent、TextGrad 等）：这些大多只动 prompt 一个工件，DecoEvo 把「评测也当成可优化对象」做对偶。
  • vs. SkillOpt：SkillOpt 是 single-skill 文本空间优化代表，DecoEvo 在其上加了对偶的 rubric skill 与解耦目标，是直接的增量。
  • vs. Self-Rewarding / Self-Refine / Constitutional AI：自评方法把评判也写进 prompt，但评判信号仍和被评内容绑在一起；DecoEvo 显式把两者目标解耦，更接近「自演化 + 外部审计」混合范式。
  • vs. RLHF / DPO：这些是改权重的方案，DecoEvo 是文本空间黑盒优化，二者互补——RLHF 处理模型本身不会的事，DecoEvo 处理「通过更好的 prompt / skill 释放已有能力」。

适合谁读

  • LLM 应用工程师 / Prompt 工程师：开放式任务的 prompt 与评测该如何共进化，本工作给了一个具体范式，特别是当任务领域没有现成 ground-truth rubric 时的冷启动场景。
  • AI 评测 / 评估平台构建者：rubric 怎么从静态文档变成可迭代工件，怎么避免评测被被测者污染。
  • Agent 产品经理：评估 agent 行为质量的「维度」本身就该和产品一起迭代，DecoEvo 提供方法论。
  • RLHF / 对齐研究者：把「解耦奖励信号」这件事从权重层挪到文本层，会有新的方法论启发。
  • 企业内部 AI 治理 / 平台负责人：关心「指标通胀」问题的团队——评测和被测同步迭代时如何不被虚假进步欺骗。

不确定处

  • 5 个 benchmark 的具体名称、3 个 LLM backbone 的具体型号、绝对分数与方差均需查正文表格。
  • 2.8–5.0% 相对增益是「五 benchmark 平均」，单个 benchmark 区间未给。
  • coverage / discrimination 审计的具体实现与失败案例需要看附录。

读者使用指南（给三类工程读者的微指路）

  • 若你在做 prompt 优化 / Agent 策略迭代：可直接借鉴 DecoEvo 的「solver skill + rubric-generator skill + 双审计」骨架，先在自家业务上验证「解耦评分」对指标稳定性的提升。即使跑不动两 skill 完整优化，仅 audit 思路本身（覆盖度 + 区分度）就能让现有 prompt eval 鲁棒一档。建议先从「单一开放式任务 + 一个 LLM backbone」起步，跑通 audit 闭环后再扩展。
  • 若你在做企业内部 AI 评测平台：把 DecoEvo 的 score-decoupled 原则做成平台约束——任何「被测对象的指标」都应允许「指标定义」接受独立反馈源，否则平台本身会陷入「指标越优化越通货膨胀」。可以把覆盖度审计看作「指标定义是否被题面变种更新」，把区分度审计看作「指标定义是否能区分真好坏」。
  • 若你在做 RAG / 检索质量优化：rubric 可以包含「是否引用了源」「是否漏掉关键事实」「是否与原文一致」等条目，rubric-generator 进化时这些条目会自动补齐新出现的质量问题，比手工维护 rubric 列表更可持续。尤其在「金标准答案不存在 / 不完备」的真实业务里，rubric 自演化是少数能跑下去的方案。

一段话总结

文本空间优化的下一道瓶颈从来不是「prompt 写得不够花」，而是「评测本身就是窄门」。DecoEvo 干净地切断了 solver 分数与 rubric 演化的耦合，把 rubric 推回「由覆盖度与区分度两条独立信号驱动」的位置，让开放式任务的优化真正走向「同时收敛在两个 skill 上」的状态。短中期，工程团队真正能从本文拿走的不是「又一个 prompt optimizer」，而是一套思维纪律：任何自动化评测一旦被绑在被测目标的反馈里，进步信号就会逐渐通胀；任何开放式任务的产品迭代，都需要让「指标定义」和「被测对象」接受不同的反馈源，否则团队会在一条永远向上的假曲线上自我感动。把这个原则落到自家 RAG / Agent 评测管线里，比抄 DecoEvo 的两 skill 设定更普适，也更迫切。

（来源：arXiv 摘要 https://arxiv.org/abs/2607.25675；paper card /shared/research-kb/organized/paper_cards/663-2607-25675.md。具体 benchmark 名称、backbone 型号、绝对分数与方差以正文表格为准；2.8–5.0% 相对增益为摘要原文五 benchmark 平均值，单 benchmark 区间未知。）

工程落地与核查（Jay）

事实核查

  1. 2.8–5.0% 相对增益：⚠️ 需注意这是「相对增益」而非绝对百分点。解读正文措辞「平均相对提升 2.8–5.0%」——相对增益意味着是 $(DecoEvo - SkillOpt) / SkillOpt$；若 SkillOpt baseline 本身分数低（如 60→63 绝对分），2.8% 实际增量很小；若 SkillOpt 已经 90+，5% 就相当可观。在全文 absolute score 未给的情况下，不宜将「2.8–5.0%」等同于「显著突破」。
  2. 「全面 SOTA」：摘要原文「outperforms all comparisons across all benchmarks」——这是摘录用语，在无正文数据的情况下解读已如实注明「具体名称需查正文表」，处理得当；⚠️ 建议避免将「SOTA」直接写进正文，SOTA 应由正文数据支撑而非摘要自述。
  3. audit 由 LLM 完成：解读第二局限准确指出「coverage / discrimination 审计由 LLM 完成，仍受 LLM 评判偏差影响」——⚠️ 存疑：若 benchmark 官方评测本身也用 LLM-as-judge，则 DecoEvo 的「score-decoupled」只是把 judge 偏置换了一把尺子，未真正解决 judge 可靠性的根本问题。这一点需要正文确认benchmark评测方式。
  4. 伪代码正确性：coverage_audit(G_t, problems) 和 discrimination_audit(G_t, responses) 的实现未在摘要中给出，伪代码流程描述正确但 implementation details 需原文补充；解读已诚实注明「具体实现与失败案例需要看附录」，处理合规。

可读性精修

  • ⚠️ 重复条目：「适合谁读」中「AI 评测 / 评估平台构建者」出现了两次（原文第三、第四段完全相同），属复制粘贴疏漏，建议删除重复段。
  • ⚠️ 「2.8–5.0%」在「关键实验与数据」节中已注明「以摘要为唯一来源」，但「亮点」节中「跨 backbone 稳定：3 个 LLM 上都涨」表述略显绝对——应加「（据摘要表述，未经正文核实）」。
  • 「一段话总结」写得好，但「比抄 DecoEvo 的两 skill 设定更普适」措辞偏口语化，「抄」字可改为「复刻」或「照搬」。
  • 整篇解读层次分明，逻辑链路清晰——从问题→方法→实验→启发→关系→适用人群→总结，行文符合 W31 写作指引「机制 + 工程路径双轨」的要求。

工程落地

落地最小路径： 1. 冷启动：先跑单 skill（只有 solver skill）+ 人工写固定 rubric，验证任务可解。 2. 加 audit：在上述 pipeline 上加 coverage audit（用 LLM 判断 rubric 是否覆盖了 problem 的所有维度），只看 rubric 自己「称不称职」，不看 solver 得分。 3. 加 discrimination audit：在 rubric 覆盖度合格后，加「同一 rubric 下好答案和差答案能否区分开」的 audit。 4. 完整 DecoEvo：最后引入 rubric-generator skill，由双 audit 信号驱动进化。 - 建议跳过步骤：若业务 rubric 本身就由专家定义且很少变动，rubric-generator 可能过度工程化——直接用双 audit 验证人工 rubric 的质量即可，不一定需要自动生成 rubric。

审计成本控制： - coverage / discrimination audit 每轮要跑 LLM judgment，在大规模迭代时 token 成本可能超过 solver 本身。 - 降本方案：① 用小模型（如 GPT-4o-mini）跑 audit，在大模型上验证 audit 质量无显著下降后切换；② 固定 N 轮再做一次 audit（而非每轮都跑），用 solver skill 的变化率判断是否需要刷新 rubric。 - ⚠️ 风险：小模型 audit 若系统性偏低 coverage 或 discrimination，会让 rubric-generator 往错误方向进化——建议每 50 轮用大模型做一次 audit 质量抽检。

与 CoRT 的互补关系： - DecoEvo 进化 rubric 并做细粒度 credit assignment（criterion-level feedback），CoRT 提供 token 级 credit 权重——二者可串接：DecoEvo 负责「rubric 该评什么」，CoRT 负责「GRPO 训练时每个 token 权重是多少」。 - 若团队已有 GRPO pipeline，先评估 CoRT（零额外训练、成本低），再评估 DecoEvo（需改造评测流水线，工程量大）。

踩坑清单： 1. audit 本身成为新 judge 偏置源：若 benchmark 用 LLM-as-judge，DecoEvo 的「解耦」只是换了一把尺子而非去掉尺子——正文需确认各 benchmark 原始评测方式再下结论。 2. 「全面 SOTA」不等于「每个 benchmark 都赢」：2.8–5.0% 是平均值，单个 benchmark 可能有退化，引用时建议加「摘要原文，未经正文逐 benchmark 核实」。 3. 跨 backbone 稳健性未核实：3 个 LLM 上都涨是摘要结论，具体是哪三个、是否包含同 family（Qwen3.5-Qwen3.5）需看正文——若只测了 Qwen 系列，则泛化性结论需降级。 4. 双 audit 同时失败时的 fallback：若 coverage audit 和 discrimination audit 给出的方向冲突（如某维覆盖了但无区分度），如何仲裁正文未给——建议在落地时预设人工仲裁兜底机制。 5. token 成本是普通 prompt 优化的 ~3 倍：每轮需跑 solver + rubric-gen + 两条 audit，是单 skill 优化的实质工程门槛——建议先做成本估算再决定是否全集跑还是采样跑。