阿里巴巴最新研究：让AI"裁判"变得更公平

这项研究由阿里巴巴Qwen大模型应用团队联合中山大学、香港中文大学、北京大学、苏黎世联邦理工学院及苏黎世大学共同完成，以预印本形式于2026年6月2日发布在arXiv平台，论文编号为arXiv:2606.03980。有兴趣深入了解的读者可通过该编号查阅完整论文。

**当AI给AI打分，这件事比想象中复杂得多**

假设你开了一家餐厅，需要招聘一位评分员来评判厨师做出的每道菜。有些菜需要对照标准食谱来判断是否做对了，有些菜需要品尝味道，有些菜需要检查摆盘规范，还有些菜需要看顾客反馈。如果你的评分员只会用一种方式——比如只会尝味道——那他对需要核对食谱或检查摆盘的菜肴就会束手无策。更麻烦的是，如果你把所有的评判标准一次性塞给他，他也会被信息淹没，不知道从哪里下手。

大语言模型（也就是我们常说的AI）的训练过程，面临着完全相同的困境。训练AI的关键一步，是告诉AI它的回答"好不好"。负责做出这个判断的，就是所谓的"奖励模型"，它扮演的正是那位餐厅评分员的角色。然而，随着AI的能力越来越强，它需要处理的任务也越来越多样：写代码、做数学题、分析文章、遵守安全规范……每种任务的评判标准天差地别，有时候需要运行代码来看结果，有时候需要对照正确答案，有时候需要检查格式是否规范，有时候需要综合考量好几个维度。现有的评分工具要么太死板（只给出一个分数，不解释原因），要么太混乱（把所有标准一股脑塞进同一个提示词里，把评分员搞晕）。

阿里巴巴等机构的研究团队为此提出了一套全新方案，名为**Skill-RM**（技能奖励模型）。它的核心思路，是把"评分"这件事变成一项可以被系统化执行的"技能"，让评分员能够根据每道菜的具体情况，主动调取最合适的评判工具，而不是面对一堆杂乱的材料不知所措。

**一、现有的评分员为何总是力不从心**

回到餐厅的比喻。传统的评分方式大概分两类。第一类是"老派评分员"——他把所有吃过的菜的印象压缩成一种内在感觉，给出一个分数，但他说不清楚为什么这道菜打了7分而不是8分，更换一批菜之后他的标准可能也悄悄变了。这对应的是传统的"标量奖励模型"，它们把复杂的评判标准压缩进模型参数里，输出一个不透明的数字，既难以解释，也难以灵活调整。

第二类是"现代评分员"——他会写一段话解释原因，但他的工具箱是混乱的。他把食谱、摆盘规范、顾客反馈表全都摊在桌上，一古脑儿翻阅，容易遗漏重要信息，也容易被无关内容分散注意力。这对应的是当前流行的"大模型担任裁判"（LLM-as-a-Judge）方式，它依赖把所有评判标准一次性写入提示词，缺乏对资源的系统管理。

当然也有一些研究尝试引入"评分细则"（Rubric）或"工具辅助"（Tool-augmented）的方式，但这些尝试往往只解决一个方面，评分细则有了但执行工具没有，或者工具有了但综合判断的逻辑不清晰。研究团队观察到，当前领域缺少的是一种能把所有评判资源统一管理起来的框架——一种真正的"全能评分员培训方案"。

**二、Skill-RM的核心设计：把评分变成一项可执行的"技能"**

Skill-RM的灵感来自一个近年来在AI智能体研究中兴起的概念——"智能体技能"（Agent Skill）。简单来说，一个"技能"就像一本操作手册加上一个工具箱的组合。手册里写着：遇到什么情况，应该先做什么，再做什么，调用哪个工具，最后如何汇总结论。工具箱里放着各种辅助材料：参考答案、检查清单、代码执行器、评分细则等等。重要的是，工具箱默认是关闭的，只有当你翻到手册里某个对应的步骤时，才会打开对应的抽屉取出相应工具。这样既避免了信息过载，又保证了需要的时候能找到对的工具。

Skill-RM把这个思路直接用于奖励模型的设计。整套系统由三个核心部件构成。

第一个部件是"奖励评估技能"本身，用形式化语言来说，它是一个包含"操作规程说明书（SKILL.md）"和"资源库"的组合包。操作规程定义了整个评判过程的逻辑：该评估哪些方面，什么情况下调用什么资源，需要收集哪些证据，最终如何输出结论。资源库则存放着各类评判材料。在Skill-RM的设计中，这些资源被归纳为五大类：评分细则与评估标准（定义判断维度和优先级）、参考资料（用于核对事实准确性的答案或文章）、检查清单与约束条件（把格式规范等要求拆解成可逐项核对的条件）、验证器与工具（比如Python代码沙箱，能真正运行代码来检验结果）、以及校准与聚合规则（用于在多个评估维度出现矛盾时做出综合判断）。

第二个部件是"技能驱动的判断过程"。当评分员（也就是大模型裁判）拿到一道待评分的题目和几个候选答案时，它会先浏览一下任务说明，判断这道题属于哪种类型。如果它发现这道题涉及代码格式规范，它就打开检查清单抽屉；如果涉及数学计算，它可能需要调用代码沙箱来验证；如果涉及事实核查，它就去查参考资料。整个过程是一系列"行动-观察"的循环：采取一个动作（比如查看某个资源），获得一个观察结果（资源里的内容），再决定下一步怎么做，直到所有必要的证据都收集完毕。

第三个部件是"奖励读取函数"。评分员走完整个评判流程后，会输出一个结构化的判断结果，其中包含每个评估维度的证据和结论。最终的奖励分数是从这个结构化结果中确定性地提取出来的，不是模糊的印象，而是有据可查的推断。更灵活的是，这套机制既可以用于"这个回答打几分"的绝对评分场景（点式奖励），也可以用于"这两个回答哪个更好"的比较场景（成对偏好），统一在同一套框架下。

**三、资源库的构建：不是随手拼凑，而是精心整理**

工具箱里的工具质量直接决定了评分员的水平，因此研究团队在资源库的构建上下了很大功夫。他们通过一套"大模型辅助策划流程"来整理资源：广泛收集来自奖励模型研究文献、标准评判协议、基准测试文档和可验证评估实践中的素材，然后为每项资源定义明确的适用范围，合并重复内容，去除过于特化的启发式规则，最终生成通用化的模块。整个资源库在评估开始前就被冻结，确保实验结果可复现。

研究团队特别强调，这套资源不是"把所有材料都塞进提示词"的做法。资源库在默认状态下是隐藏的，只有当操作规程中对应的步骤被触发时，相关资源才会被加载进入评分员的视野。这种"渐进式披露"的设计，是Skill-RM与传统方法的关键区别之一。

**四、实验验证：Skill-RM的实际表现如何**

研究团队在多个标准测试场景中对Skill-RM进行了全面评估，试图回答五个核心问题。

第一个问题是：在标准评分基准测试上，Skill-RM是否优于传统的"大模型裁判"方案？测试使用了三个公认的评估基准：RewardBench2（测试多维度奖励能力）、RM-Bench（测试对内容细节和风格偏见的鲁棒性）以及JudgeBench（聚焦正确性评估）。结果显示，以Qwen3.5-27B为基础模型，Skill-RM将平均分从83.9提升到了86.2，三个基准全部有所改善。以更大的Qwen3.5-122B-A10B为基础时，Skill-RM在JudgeBench上达到了85.2的最高分。与此同时，Skill-RM的表现也超过了许多专门设计的奖励模型，比如各类基于细则的评分系统和基于智能体的验证评分方案。

第二个问题是：如果给Skill-RM提供针对具体样本的额外资源（比如参考答案、约束条件、验证器输出），表现是否会进一步提升？答案是肯定的。加载样本特定资源后，平均分从86.2进一步提升到89.1，在RewardBench2上达到86.0，超过了使用相同骨干模型的OpenRS系统（OpenRS在JudgeBench上较强，这与其专门优化的评估设置有关）。这说明Skill-RM不仅能在通用场景下表现良好，在资源更丰富的场景下也能充分利用额外信息。

第三个问题，也是最关键的机制验证问题：这些提升究竟来自"技能驱动的资源组织"，还是仅仅因为给了评分员更多信息？研究团队设计了一组精心的对比实验。在同样的Qwen3.5-27B模型上，他们尝试了三种不同的"加料"方式：直接把所有资源文本附加到提示词末尾（不使用技能框架）、把样本特定资源也直接附加进去、以及仅仅给模型加上一个Python工具访问权限。结果令人深思：直接附加资源反而让平均分从83.9下降到了81.0；加上样本特定资源的附加版本也只有82.0，低于无任何补充的基准；仅加Python工具的版本为83.6，几乎没有提升。相比之下，使用技能框架的Skill-RM达到86.2，加上样本特定资源后更是达到89.1。这个对比清楚地说明：提升的关键不在于给了多少信息，而在于如何有组织地管理和使用这些信息。信息过载不仅没有帮助，反而会干扰评分员的判断。

第四个问题涉及"最优N选一"（Best-of-N）场景，即从多个候选回答中选出最好的那个。使用JETTS测试集（由Qwen2.5-72B-Instruct模型生成的10个候选答案池），研究团队测试了Skill-RM在数学、指令遵循、代码等四类任务上的选择准确率。在数学题（GSM8K）上，表现接近满分，基本已经饱和。在指令遵循（IFEval）和代码正确性（HumanEval+）上，Skill-RM的改善最为明显，超过了直接打分的基准方案和Skywork评分模型。复杂代码基准（BigCodeBench）仍然较难，Skill-RM比基准稍有提升，但距离理论上界还有较大差距，说明这类任务仍是未来需要攻克的方向。

第五个问题是：Skill-RM能否被用作强化学习训练的奖励信号，真正帮助提升AI模型的指令遵循能力？研究团队以Llama-3.1-Tulu-3-8B-SFT为起点，使用VerInstruct数据集，以Skill-RM作为奖励信号，通过GRPO算法进行强化学习训练。在IF-RewardBench的Kendall相关系数测试上（该测试衡量奖励模型的排序质量），Skill-RM的平均相关系数达到0.524，高于所有对比方法，包括Gemini-3-Flash（0.513）、GPT-5-mini（0.456）以及各类专门的判别式奖励模型。在单轮对话和多轮对话子集上，Skill-RM分别达到0.619和0.540的成绩，优势明显；在系统提示词子集上，Gemini-3-Flash略胜一筹，说明处理复杂系统提示仍是Skill-RM的一个改进空间。

训练完成后的模型在三个下游指令遵循基准（IFEval、IFBench和AdvancedIF）上的综合表现达到45.9分，超过了使用同类训练数据的VerIF方案（44.7分）和Tulu 3（45.1分），在IFEval和AdvancedIF上的提升最为明显，IFBench上则与VerIF持平。

**五、在不同规模模型上的稳健性验证**

研究团队还在多个不同规模的模型上验证了Skill-RM的有效性。他们分别使用了Qwen3.5系列的9B、27B、35B-A3B和122B-A10B四个版本进行测试。在所有四个规模的模型上，Skill-RM在不使用样本特定资源的情况下，都优于对应的直接裁判基准，说明这套框架并不依赖特定规模的模型能力。

不过实验也揭示了一个有趣的边界：样本特定资源并非对所有规模都有益。对于9B这个较小的模型，加入样本特定资源后平均分反而略有下降（从66.2降至65.7），说明较小的模型在自主筛选和应用外部资源方面能力有限，可能无法可靠地判断"这个资源对当前判断有没有帮助"。研究团队将这个发现作为边界证据，表明资源并不是越多越好，模型的实际能力决定了它能有效利用多少资源。

**六、坦诚面对的局限与未来方向**

研究团队在论文中直接点出了Skill-RM目前的三个局限，而不是回避它们。

第一，当前的评估范围仅限于文本形式的指令遵循和标准奖励基准。将这套框架扩展到多模态（图片、音频等）内容、长周期智能体任务或高度主观的偏好对齐场景，是一个有挑战性但值得探索的方向。

第二，目前的奖励评估技能依赖人工策划。虽然这保证了精确性和可解释性，但如何自动生成和持续更新技能文件，仍是一个开放问题。如果这个过程能够自动化，将大大降低在新任务上部署Skill-RM的门槛。

第三，技能驱动的评判过程相比传统的单次前向计算，需要更多的推理步骤，带来了额外的计算开销。未来在自适应提前终止、证据缓存和高效资源剪枝等方向上的研究，将是平衡评判质量与计算效率的关键。

说到底，Skill-RM做的事情并不神秘，它只是把一件大家都在做但做得比较随意的事情，用一套严谨的框架规范了起来。评判一个AI的回答质量，原本就需要参考不同的标准、调用不同的工具、综合不同维度的证据——只是以前大家都把这些事情塞进一段提示词里，让AI自己凑合着解决。Skill-RM的贡献在于，它让这个过程变得有序、透明、可以被检验，就像把一个经验丰富但毫无章法的老厨师，变成了一个有操作手册、有工具架、每道菜都能说清楚为什么打这个分的专业评审。

对于普通用户而言，这项研究最直接的意义在于：你使用的AI助手未来将变得更可靠，不只是在简单问答上表现更好，在遵循复杂指令、处理代码和数学、以及在各种专业场景下的表现都会更贴近你真正的需求。而这种改善的背后，正是因为训练AI的"裁判"本身变得更公平、更准确了。

对研究者来说，一个值得深思的问题是：当"如何使用信息"比"拥有多少信息"更重要时，我们在AI系统设计中是否过于关注扩大模型的参数规模和上下文窗口，而忽视了对信息组织方式的设计？Skill-RM的实验数据给出了一个明确的提示：结构比体量更重要。感兴趣的读者可以通过arXiv编号2606.03980查阅完整论文，代码也已在GitHub的Qwen-Applications/Skill-RM仓库公开发布。

**Q&A**

Q1：Skill-RM和普通的大模型评分方式有什么本质区别？

A：普通大模型评分是把所有评判标准一次性塞进提示词，让模型自己处理。Skill-RM则提供一套操作规程加工具库的组合，模型根据当前任务类型，主动选择调用哪些评判工具，比如代码沙箱或参考答案，收集有据可查的证据后再给出结论，整个过程有明确的逻辑顺序，而非一次性模糊判断。实验表明，直接堆砌更多信息反而会让评分质量下降，而有组织地管理信息才能真正提升准确率。

Q2：Skill-RM为什么把更多资源直接加进提示词反而会变差？

A：这是实验中最反直觉的发现之一。原因在于信息过载会分散评分模型的注意力，大量无关资源混在一起时，模型难以判断哪些内容对当前任务真正有用，容易被干扰。Skill-RM的资源库默认隐藏，只有操作规程触发对应步骤时才加载相关资源，有效过滤了噪音，让模型专注于真正相关的证据。

Q3：Skill-RM在代码评测上表现有限，原因是什么？

A：在复杂代码基准BigCodeBench上，Skill-RM相比基准有小幅提升，但距离理论上界仍有较大差距。研究团队认为这类任务本身难度更高，不仅需要代码执行判断，还涉及复杂的功能语义理解，仅靠当前资源库中的Python沙箱工具尚不足以充分覆盖所有评判维度。这也是研究团队指出的未来改进方向之一。