J-Zero：从零数据统一挑战者-求解者-裁判共同进化

TL;DR J-Zero 让 Challenger、Solver、Judge 从零数据协同进化，用预定义偏好对训练 Judge，在可验证与不可验证领域平均提升 4.2/8.0 分，且迭代十轮持续提升，而基线两轮即退化。

问题

问题背景 自进化语言模型（self-evolving LLMs）被视为减少人工监督成本、迈向超级智能的可行路径。当前研究聚焦于通过闭环自我对弈生成训练任务，使模型在可验证与不可验证任务上持续提升。

现有方法局限 主流的自进化方法（如 SPIN、Self-Rewarding）在可验证领域（数学、代码）取得进展，依赖客观奖励信号（编译器、单元测试）驱动优化。然而在不可验证领域（创意写作、开放域问答），缺乏可计算的标量反馈，难以判断响应质量。部分方法引入 LLM-as-a-Judge 提供奖励，但 Judge 的训练数据往往来自其自身评分，容易形成确认偏置 与 分布漂移，导致生成器与评判器同步退化。此外，同时训练 Challenger 与 Solver 的对抗框架在迭代后期常出现模式坍塌，生成任务多样性下降，性能在约两轮迭代后不升反降。

为什么这个问题难/重要 不可验证任务在真实部署中占比极高，如对话、摘要、指令跟随，人工标注成本随任务复杂度指数增长。自我进化的核心挑战在于：在无外部监督信号下，如何构建可靠的偏好标签 来同时更新生成器与评判器，同时避免自我强化偏差。J-Zero 利用生成过程的结构先验——Solver 的回答优于 Challenger 的回答、分解重组回答优于一次性回答——构造偏好对，绕开 Judge 自我评分循环，类似于从生成过程中提取隐式排序信号，而非依赖外部奖励。这一思路对工程实践有直接启发：可以利用系统内部的排序关系生成训练数据，降低对人工标注的依赖。

行业类比 这类似于自动驾驶中训练规划器与安全评估器——在缺乏真实事故数据时，通过对抗模拟生成场景，并利用逻辑规则（如碰撞严重性）自动标注偏好，从而持续改进策略网络。

核心洞察

• J-Zero 的核心创新在于通过构造“生成顺序即偏好标签”的偏好对，使 Judge 在零外部数据下实现协同适应。与依赖 LLM-as-a-judge 或外部奖励的现有自进化方法不同，J-Zero 的偏好对排序来自响应生成方式：Solver 的回答优于 Challenger 的回答，分解重组回答优于一次性回答。这种排序先验不依赖 Judge 自身评分，从根本上避免了自举偏差，使非可验证领域的自进化成为可能。
• J-Zero 将 Challenger-Solver 对抗生成与 Judge 协同适应统一在同一框架内，同时覆盖可验证和非可验证领域，解决了以往方法在开放式任务上迭代两次后即退化的瓶颈。Challenger 持续生成更难任务，Solver 学习高质量响应，Judge 同步更新评判标准，三者形成闭环。实验显示 J-Zero 在两类领域平均提升 4.2 和 8.0 分，且至少十轮迭代持续改善，而基线两轮后性能下降。这为构建无需人类监督的通用自进化系统提供了工程可行路径。

方法

输入与初始化

• 仅使用一个初始 LLM 作为种子，不依赖任何外部标注数据（zero data）。
• 该模型同时实例化为 Challenger（任务生成器）、Solver（解答器）和 Judge（评分器）。

关键模块：三层协同进化

1. Challenger-Solver 对抗交互

   • Challenger 持续生成难度递增的任务，覆盖可验证与不可验证领域。
   • Solver 解答这些任务，通过对抗反馈更新自身，形成能力与难度的螺旋上升。

2. Judge 协同适应

   • 使用 偏好对 训练 Judge，但偏好标签来自 预设顺序，而非 Judge 自身打分：
     • Solver 的回答优于 Challenger 的回答（因 Solver 经过专门优化）。
     • Solver 的 分解-重组回答 优于其一次性回答（分解重组通常更稳定）。
   • 这种预设偏好避免了 Judge 自我确认偏差，使不可验证领域的评分成为可能。

3. 响应生成策略

   • Solver 同时生成一次性回答与分解-重组回答，为 Judge 提供天然对比样本。

输出与迭代

• 每轮迭代更新三个组件：Challenger 生成更难任务，Solver 提升解答质量，Judge 校准评分能力。
• 实验表明至少 10 轮迭代仍稳定提升，而基线方法两轮后即退化。

与同类方法的差异点

• 现有自进化方法多局限于可验证领域，依赖外部校验器或规则；J-Zero 通过 预设偏好对 让 Judge 在不可验证领域自主适应，实现了可验证与不可验证的统一自进化。

实验

实验设计

J-Zero 在两类领域上评估：可验证领域（数学推理、通用知识、指令遵循）与不可验证领域（开放式生成）。基线包括同类自进化方法。Challenger 与 Solver 通过对抗互动生成越来越难的任务；Judge 利用预先已知偏好的偏好对进行适配。实验从零数据启动，通过迭代训练评估模型能力与可持续性。

关键发现

• J-Zero 在可验证领域平均领先基线 4.2 分，在不可验证领域平均领先 8.0 分。
• 至少 10 轮迭代仍持续提升，而基线在 2 轮后即退化。
• 自生成偏好标签可靠，Judge 适配无需外部标注。

与基线对比

J-Zero 的核心差异在于 Challenger–Solver–Judge 三者协同进化，而不是仅 Challenger–Solver。Judge 的偏好对来自响应产生方式的先验顺序（Solver 回答优于 Challenger，分解重组优于一次性回答），避免了自我评分偏差。这种设计在不可验证领域带来更大增益（8.0 vs 4.2），说明 Judge 适配对开放任务尤其关键。基线因缺乏可靠的信号源而在早期退化。

行业影响

落地场景

• 智能客服与对话系统：在不可验证领域，如客服回复质量评估，J-Zero 的 Challenger 可自动生成更复杂的用户咨询场景，Solver 学习更优回答，Judge 基于预设偏好自动标注偏好对，适用于电商客服机器人、企业 IT helpdesk 等场景。
• 代码辅助与自动评测工具：在可验证领域，Challenger 生成新算法题或编程任务，Solver 提升解题能力，Judge 利用测试用例自动验证，可用于在线编程教育平台、IDE 智能补全/纠错插件。

商业价值

• 显著降低人工标注成本：J-Zero 从零数据启动，无需外部人类标注，通过对抗自我生成偏好数据训练 Judge，减少 >80% 的标注预算。
• 延长模型服务生命周期：模型部署后仍能通过闭环自我迭代持续改进，避免频繁重新训练，降低 MLOps 成本。
• 快速冷启动新领域：对于缺乏标注数据的新业务（如新兴垂直领域问答），J-Zero 可快速构建自我进化能力，缩短产品上线时间。

与现有产品/工作流的接口

• 嵌入微调流水线：将 J-Zero 作为持续进化循环，集成进现有 LLM 微调栈（如 DeepSpeed、Hugging Face Trainer），定期或触发式运行 Challenger-Solver 对抗与 Judge 更新。
• 替换静态 LLM-as-a-Judge：现有工具如 LangSmith 或自建评测器往往是静态的，J-Zero 的 Judge 可与其对接，提供动态适应任务分布的评分模块。
• 对接推理服务：训练后的 Solver 可直接部署到 vLLM 或 Triton 等推理框架，通过标准 API 提供服务，无需改变前端调用方式。

具体用例

1. 电商产品问答系统：用户咨询商品规格、退换货政策、组合优惠等，属于不可验证场景。J-Zero 的 Challenger 生成更复杂的咨询组合，Solver 优化回答，Judge 根据“Solver 回答优于 Challenger 生成”的已知偏好自动更新，持续提升客服机器人满意度，减少人工质检工作量。
2. 在线编程教育平台：平台需要不断扩充题库和自动批改。J-Zero 的 Challenger 生成新编程题，Solver 提供参考解答，利用测试用例自动验证正确性，同时 Judge 评估代码风格等软性指标，实现题库自动扩充和教学质量提升。

局限

• **模型规模与资源开销未充分论证**：论文未明确报告实验所用基础模型的参数规模，但 J-Zero 需要同时维护 Challenger、Solver 和 Judge 三个角色并反复迭代，计算开销显著高于单模型自进化方法。若基础模型较小，结论能否迁移到大规模模型仍存疑；若较大，则训练成本可能限制其在实际工程中的可复现性。与仅需 Solver 自我对弈的基线相比，J-Zero 的额外 Judge 适配和分解-重组操作会成倍增加推理与微调资源，但论文未给出与性能提升相匹配的效率分析。
• **偏好对构造的领域适用性有限**：J-Zero 的 Judge 适应依赖‘Solver 回答优于 Challenger 回答’和‘分解重组回答优于一次性回答’这两类先验偏好对。在数学推理等可验证领域，这种排序或许合理；但在开放写作、创意生成等不可验证领域，Solver 的回答未必总优于 Challenger，分解重组也可能破坏语义连贯性。该方法隐式假设了分解-重组总能带来质量提升，这一假设在需要整体风格一致性或长程逻辑的任务上可能失效，从而引入有偏的偏好标签，削弱 Judge 的可靠性。
• **评估与基线对比存在局限**：论文声称在可验证和不可验证领域分别提升 4.2 和 8.0 点，但未详细列出所对比基线的具体实现细节（如是否采用相同的数据生成预算、迭代次数和模型规模）。此外，不可验证领域的评估往往依赖 LLM-as-a-Judge，而本文的 Judge 本身也在自进化，存在自我强化偏差的风险。与同时期其他 zero-data 自进化框架（如 SPIN、Self-Rewarding 等）的横向对比不足，难以判断性能优势是来自 Judge 协同设计还是其他工程因素。