DecoEvo co-evolves a solver prompt and a rubric-generator prompt for a frozen LLM, but accepts generator updates only when they pass rubric-blind audits, never when they raise the solver’s own score. This blocks the failure mode where a jointly-trained rubric drifts to become easier to satisfy.
You’ve shipped an LLM feature judged by a rubric (medical-answer safety, writing quality, research-report completeness). To improve it without touching weights, you edit the system prompt and score candidates with an LLM-judge running that rubric. Two problems show up. First, once the solver clears the criteria the rubric measures, the remaining failures live in dimensions the rubric never listed, so scores stop moving. Second, if you also let the rubric evolve and pick the rubric that most raises solver scores, you’re optimizing a proxy against itself. The closest published baseline, SkillOpt, keeps the rubric fixed for exactly this reason. DecoEvo tries to evolve the rubric anyway, safely.
Two natural-language artifacts are edited over time: a solver skill (task strategy text) and a generator skill (principles for writing a per-question rubric). The same frozen LLM plays every role. The inner loop scores solver responses with the current generated rubric and rewrites the solver skill when a candidate beats the incumbent on held-out questions. The outer loop is the contribution: it updates the generator skill without ever looking at the solver’s aggregate score. Two audits drive it. A structural audit reads only the task description and the generated rubric (no response, no score) and flags requirements the rubric omits. A near-tie contrastive audit finds pairs of solver rollouts the rubric scored almost equally, asks the judge which is actually better without showing it the rubric, and then reveals the rubric and asks what distinction it missed. Both audits emit reusable revision suggestions. A candidate generator is accepted under a Pareto rule: at least one audit must improve by a margin, and none may regress beyond a tolerance. Aggregate solver score is banned from the generator’s acceptance test. This is what the authors call a score-decoupled generator update.
for step in range(T):
# Inner loop: improve solver against current rubric
responses = solve(batch, solver_skill)
rubrics = gen_rubric(batch, generator_skill)
scored = judge(responses, rubrics) # criterion-level
cand_solver = rewrite_solver(scored.failures)
if J(cand_solver, generator_skill, V_s) > J(solver_skill, ...) + eps:
solver_skill = cand_solver
# Outer loop: audit and maybe update generator
if stalled or step % K == 0:
omissions = structural_audit(probe, generator_skill)
missed = near_tie_audit(probe, solver_skill, generator_skill)
cand_gen = rewrite_generator(generator_skill, omissions, missed)
if pareto_improves_on_audits(cand_gen, generator_skill, V_g):
generator_skill = cand_gen # NOT gated on solver score
At deployment only the solver skill ships; the generator is training-time scaffolding.
The prevailing move in text-space optimization is to keep the rubric fixed (SkillOpt, DSPy, TextGrad) precisely because letting the judge evolve alongside the policy invites Reward Overoptimization. This paper takes the opposite bet. You can evolve the rubric safely as long as the signal that accepts rubric edits is structurally forbidden from seeing the solver’s score. The load-bearing evidence isn’t the headline lift, it’s that the score-coupled variant, which uses the same audits for proposing rubrics but selects them by solver score, actively hurts performance.
•
The score-coupled baseline SC-CoEvo, identical to DecoEvo except it accepts generator edits by aggregate solver score, falls below the fixed-rubric SkillOpt baseline in 13 of 15 backbone-benchmark cells, and below zero-shot in 7. This is the finding that carries the thesis: jointly evolving rubric and solver without decoupling is worse than not evolving the rubric at all.
•
On the training-dynamics plot, SC-CoEvo’s internal proxy score climbs to 89.1 while its gold-rubric score peaks and then declines. Classic proxy divergence.
•
Headline result: DecoEvo wins all 15 of 15 backbone-benchmark pairs, with 2.8–5.0% relative gain over SkillOpt averaged across five benchmarks and three backbones (GPT-4o, Qwen3-4B, Qwen3-8B).
•
Rubric-alignment analysis: generated rubrics from DecoEvo match held-out gold rubrics ~12 F1 points higher than SkillOpt’s fixed generator, with both precision and recall up. SC-CoEvo drops F1 by 5–6 points, consistent with dropping hard-to-satisfy criteria.
•
Controls rule out the obvious alternatives. Feeding the same structural-audit spec to a fixed generator (Task-Prior) buys only 0.4–0.7 points. Matching DecoEvo’s compute budget on solver-only training buys 0.4–0.6. Routing audit records directly into the solver rewriter recovers about 2.0 of the 3.6 gained points but no more, suggesting persistent generator memory is where the residual gain lives.
Reach for this when you have an LLM-judge-driven eval loop for an open-ended task and you suspect your rubric is under-specified. The pattern to steal: keep two prompts (solver strategy, rubric-generation policy) as your evolving state, and gate rubric edits on audits that never see the solver’s aggregate score, only on whether the new rubric covers previously-missed requirements or resolves pairs your old rubric couldn’t distinguish. The near-tie audit is the practically useful primitive; it turns “my judge can’t tell these two answers apart” into a concrete rubric-repair signal.
The paper does not link a code repository or release the evolved skills. Benchmarks used are all public (HealthBench, WritingBench, ResearchQA, LLMEval-Med, and EQ-Bench Creative Writing v3) but you’d be reimplementing the loop from the method section and supplementary appendix.
If you let your evaluator evolve, forbid it from ever seeing the score of the thing it evaluates. The audits that accept a new rubric must ask “what did the old rubric miss?”, not “does the new rubric make my current model look better?” That single wiring choice is the difference between rubric evolution helping and rubric evolution actively regressing below a fixed baseline.
•
Every role, solver, judge, auditor, rewriter, uses the same frozen backbone. If your auditor is the same model as your solver, its blind spots correlate; a genuinely different judge model might change the picture.
•
Transfer is only tested within-domain (medicine to medicine, writing to writing). Nothing here shows the evolved solver skill generalizes across task families.
•
Roughly 1.89× SkillOpt’s tokens during training. Deployment is free (only the solver skill ships) but development cost roughly doubles, which matters if your judge model is expensive.
•
The Pareto acceptance rule needs thresholds (improvement margin, regression tolerance). The paper puts these in supplementary material; expect real tuning effort on a new task.