JudgeArena：可复现的LLM裁判评估统一框架

# JudgeArena：一个可复现的LLM裁判评估统一框架

来源：https://arxiv.org/html/2608.02620

Erlis Lushtaku
弗莱堡大学
& Bora Kargi
ELLIS Institute Tübingen
& Ali Elganzory
弗莱堡大学
& Fabio Ferreira
Microsoft AI
& Alejandro R. Salamanca
Cohere Labs
& Julia Kreutzer
Cohere Labs
& David Salinas¹¹footnotemark:¹²²footnotemark:²
ELLIS Institute Tübingen, Prior Labs

*共同贡献。通讯作者：[email protected], [email protected]*
*在弗莱堡大学期间完成的工作。*

###### 摘要

LLM即裁判（LLM-as-a-judge）评估已成为对语言模型进行排名的主流范式，但目前的生态仍然支离破碎：大多数基准测试自带独立的代码库、硬编码特定的闭源模型裁判，并且只支持单一的评估协议。这种碎片化使得我们难以研究设计选择——基准测试、裁判模型、提示词、推理后端——如何影响我们关于模型质量的结论。我们引入了 **JudgeArena**，一个开源框架，将主要的LLM裁判基准测试（AlpacaEval、Arena-Hard、MT-Bench 和 m-Arena-Hard）统一到单一接口之下，支持可替换的裁判，并提供全面的元数据记录，以提升报告和可复现性的透明度。它支持对裁判选择的系统性研究，因为任何可通过 vLLM、llama.cpp 或 OpenRouter 访问的模型都可以同时作为候选模型和裁判。此外，JudgeArena 内置了针对开放模型的调优裁判配置，这些配置在英文和多语言环境中的人类偏好数据集上经过验证，能够匹配甚至超越闭源模型裁判，从而减少对不透明闭源模型的依赖。最后，通过将现有的人类标注与目标模型的LLM裁判评估相结合，JudgeArena 可以高精度地模拟 LMArena Elo 分数，为大规模人类标注活动提供一种实用、开放且低成本的替代方案。

## 1 引言

对大型语言模型（LLM）的指令微调进行评估具有挑战性，因为生成模型会以自由文本形式回答通常开放或模糊的问题。黄金标准是人类标注，包括所谓的众包*竞技场*，用户在其中针对给定的提示在两个模型之间标注他们更偏好的输出（Chiang et al., 2024；Termignon et al., 2026）。由于标注成本高昂且周期漫长，这种方法在LLM开发的早期阶段或需要大规模评估的项目（例如，跟踪多种语言和任务的质量）中不太实用。另一种替代方案是部署一个LLM裁判作为人类代理（Zheng et al., 2023）。其关键优势在于能够实现自动化和更便宜的基准测试，并且可以随时运行。

许多依赖LLM裁判的基准测试已被提出。其中最著名的包括 AlpacaEval（Li et al., 2023；Dubois et al., 2024）和 Arena-Hard（Li et al., 2024），它们建议在一组固定的指令上对候选模型进行标注。生成的回答随后与基线（如最近的GPT模型）进行比较，胜率被用来构建排行榜。也有研究探索了不同的设置，例如在 MT-Bench 中考虑多轮对话而非单轮对话（Zheng et al., 2023），或者通过将 Arena-Hard 的指令从英文自动翻译成23种语言，在 m-Arena-Hard 中考虑多语言场景（Dang et al., 2024）。

如表1所示，当前LLM裁判基准测试明显缺乏统一性和可复现性。例如，每个基准测试都自带独立的代码库，并且很少记录足够的元数据以确保可复现性。此外，它们大多默认使用闭源权重的裁判，如 GPT-4。虽然LLM裁判无论是否开源都存在自我偏好偏差（Panickssery et al., 2024；Wataoka et al., 2025），但闭源权重裁判使这种偏差难以审计，并使基准测试容易受到静默更新和弃用的影响，导致许多评估失效且无法复现¹¹¹例如，GPT-4o 是 Alpaca-Eval、Arena-Hard、m-Arena-Hard 中使用的模型，目前正在被弃用 https://openai.com/index/retiring-gpt-4o-and-older-models/。。因此，研究人员使用来自不同包（或自行编写）的基准测试，这使得结果有时无法比较（Laskar et al., 2024），并且与引入 Eval Harness（Gao et al., 2024）或 Lighteval（Habib et al., 2023）等包之前的*静态*评估状态极为相似。

本文描述了 **JudgeArena**，一个解决这些问题的开源库。具体而言，它做出了以下贡献（见表1）：

- • 在统一API下提供对最常用LLM即裁判基准测试的标准化访问，支持可替换的裁判和对推理后端的广泛支持。
- • 经过调优的开源权重裁判配置，能够匹配或超越闭源模型裁判，同时成本更低、更加透明。
- • 全面的元数据记录，确保每次运行的完全可复现性。
- • 由该库支持的广泛元评估，覆盖英语和33种语言。
- • 一个新的LLM基准测试，用于在保留模型上以较小误差估计 Elo 评分——使得无需参与在线竞技场即可进行模型性能估计。

总之，JudgeArena 统一了对主要基准测试的访问，同时暴露了每个元评估组件，以便进行受控研究和持续改进。

表1：支持LLM裁判的库的比较。大多数仅支持单一基准测试，除了 Lighteval 和 Evalchemy。“vLLM”表示对进程内本地 vLLM 推理的内置、编排支持，适用于候选模型和裁判。

| 框架 | MT-Bench | AlpacaEval | Arena-Hard | m-Arena-Hard | 调优裁判 | vLLM | 元数据 |
|---|---|---|---|---|---|---|---|
| FastChat | ✓ | × | × | × | × | × | × |
| AlpacaEval | × | ✓ | × | × | × | × | × |
| Arena-Hard | × | × | ✓ | × | × | × | × |
| Lighteval | ✓ | × | × | × | × | ✓ | ✓ |
| Evalchemy | ✓ | ✓ | × | × | × | × | ✓ |
| JudgeArena | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |

## 2 相关工作

#### LLM即裁判基准测试。

基于成对比较的LLM即裁判基准测试已成为人类偏好排名的默认廉价替代品，是众包平台（Chiang et al., 2024）和静态基准测试集合（Ni et al., 2024）的替代方案。成对比较范式由 MT-Bench 和 Chatbot Arena 推广（Zheng et al., 2023；Chiang et al., 2024），研究表明，当使用强LLM作为裁判时，尽管存在已知的偏差（如自我偏好（Panickssery et al., 2024）和冗长性偏差），它们与人群偏好具有良好的一致性。AlpacaEval（Li et al., 2023）将805个单轮指令与一个固定的 GPT-4 裁判配对，并针对固定参考模型进行评分；其长度控制变体（Dubois et al., 2024）沿着冗长性轴对同一裁判进行去偏。Arena-Hard（Li et al., 2024）筛选了500个更难的英文提示，这些提示是从 Chatbot Arena 对话中自动挖掘的。多语言覆盖主要通过翻译来实现：m-Arena-Hard（Dang et al., 2024；Khairi et al., 2025）自动将 Arena-Hard 翻译成23种语言，并再次利用单一的闭源裁判，而英语以外的母语偏好数据仍然很少（Termignon et al., 2026），并且基于翻译的自动评估已知需要仔细的元评估（Kreutzer et al., 2025；Fu and Liu, 2025）。

#### LLM裁判框架。

大规模运行LLM裁判评估面临不小的工程挑战，例如管理API调用、解析裁判输出以及记录运行日志，这导致 FastChat（Zheng et al., 2023）、AlpacaEval 和 Arena-Hard 等基准测试提供了与专有API紧密耦合的特定于基准测试的实现。虽然用户可以通过手动将请求路由到本地 OpenAI 兼容服务器（例如，独立的 vLLM 进程）来间接规避这一点，但这种分离式设置容易出错，并且无法捕获关键的推理元数据，从而损害可复现性。这种架构上的锁定在历史上促使了对闭源权重模型的依赖，这些模型容易受到静默更新的影响，并表现出系统的自我偏好（Panickssery et al., 2024）。此外，跨不同基准测试评估模型需要管理具有不兼容接口的不同代码库。像 Eval Harness（Gao et al., 2024）和 Lighteval（Habib et al., 2023）这样的通用框架统一了各种任务，但针对静态评估（例如，Open LLM Leaderboard（Fourrier et al., 2024））进行了优化，需要自定义逻辑来支持动态的成对裁判。Evalchemy（Raoof et al., 2025）包装了现有代码库并支持用于候选生成的 vLLM，但其裁判流程仍然依赖于间接API调用，因此它仍然专注于固定的专有裁判，并且缺乏轻松集成其他基准测试（如 Arena-Hard）所需的抽象。如表1所总结的，这种碎片化的生态阻碍了可复现性。

JudgeArena 通过将指令集与评估器配置解耦来解决这些限制。通过提供一个统一的API，为候选模型和裁判提供原生的本地推理，优化提示模板，并为每个生成的样本进行严格的元数据跟踪，JudgeArena 使得主权、开源权重的评估能够实现端到端的可复现性。

#### LLM裁判的元评估与调优。

元评估评估裁判的可靠性，以确定LLM裁判在何时以及对于哪些指令类型适合作为人类偏好的替代品。元评估通常考虑两类指标：*全局*指标，衡量排名相关性——即裁判排名与人类竞技场 Elo 评分之间的 Spearman 秩相关（Li et al., 2023, 2024；Ni et al., 2024）——以及*局部*指令级一致性指标，如准确率或 Cohen's Kappa（Zheng et al., 2023；Wang et al., 2024；Zeng et al., 2024；Fu and Liu, 2025）。最近的研究进一步沿着特定轴探察裁判：硬编码和数学指令（Tan et al., 2025；Lai et al., 2026）、位置和冗长性偏差（Lai et al., 2026），或多语言能力（Kreutzer et al., 2025；Fu and Liu, 2025）。能够衡量LLM裁判的质量促使通过提示优化（Fernando et al., 2023）或对裁判设计选择进行系统超参数搜索（Salinas et al., 2025）来进行调优。尽管有这些活动，经过调优的开源权重裁判很少与评估基准测试捆绑在一起；JudgeArena 通过在单一兼容框架中整合元评估例程和有竞争力的基准测试，直接解决了这一差距。

## 3 JudgeArena 框架

### 3.1 架构与设计

JudgeArena 通过单一命令行接口暴露，见图1。基准测试和裁判通过 CLI 选项选择，而不是嵌入到特定于基准测试的脚本中。运行的其他每个方面，如截断预算、聊天模板和推理引擎选项，都通过同一接口控制。包含可复现性所需的所有信息的元数据以 JSON 格式存储，类似于 Eval Harness（Gao et al., 2024）。要执行评估，来自所选基准测试的指令通过公共接口加载，并可选择性地子采样到指定数量的指令。对于每个被评估的模型，JudgeArena 会复用基准测试自带的预生成补全（如果可用），否则生成它们，并通过确定性的磁盘缓存持久化新生成的补全。然后，两个补全和裁判提示被馈送给裁判，其输出被解析为 [0,1] 范围内的数值偏好，并为下游分析写入一个每次运行的标注文件夹、聚合胜/负摘要和元数据描述符。

```
judgearena --task alpaca-eval --model_A LlamaCpp/./path/llama-3.2-3b-q8_0.gguf --model_B VLLM/utter-project/EuroLLM-9B --judge_model OpenRouter/google/gemma-3-4b-it --n_instructions 10 run
1. 拉取任务
2. 生成补全
3. 生成裁判标注
4. 存储元数据和结果
```

图1：一次 JudgeArena 运行的剖析。单个 CLI 调用（左）将任务、两个模型和裁判选择为正交标志；该工具拉取任务，生成或重用缓存的补全，收集裁判标注，并将所示结果（右）连同版本化的元数据包（包版本、结果 JSON、CLI 参数、运行日期）一起写入，以供事后可复现。

### 3.2 推理后端

模型推理被封装在一个统一的后端抽象之后，将每个被评估的模型和每个裁判路由到适当的运行时。后端通过统一的 {Backend}/{ModelPath} 命名约定来寻址；本地后端在进程内运行推理，而托管后端通过 LangChain 分派到相应的提供商 API。覆盖范围包括 vLLM（本地 GPU）、llama.cpp（CPU 和 Apple Silicon）以及 OpenRouter 或 Together AI 等托管提供商。JudgeArena 同时处理使用聊天模板的指令模型和纯补全的预训练基础模型。对于支持推理 token 预算的思考型裁判，会遵守可选的推理 token 预算，并在所有后端记录每次请求的 token 使用量。引擎级选项，如张量并行或量化，可以为对战模型和裁判独立配置，因此大型裁判可以在同一 GPU 上以与评估模型不同的规模或精度运行。

### 3.3 支持的基准测试与竞技场

每个基准测试都遵循一个通用的指令接口。这种共享