必要但不充分：LLM作为评委的安全评估中的温度控制与可重复性

# 温度控制与可复现性：LLM-as-Judge 安全评估中的问题
来源：https://arxiv.org/html/2606.26185
## 必要但非充分：LLM-as-Judge 安全评估中的温度控制与可复现性

（2026年6月）

###### 摘要

LLM 作为评判者（“评分器”）组件现在已是评估框架的标准配置，包括安全评估——其中的通过/失败判决可能决定着下游部署决策的关卡。普遍假设是，将评分器的采样温度设为 0 可使评分结果确定。我们针对一个真实的安全评估代码库（日本 AISI 的开源框架 aisev）检验了这一假设，并证明它在两个层面上都不成立。*首先*，评估框架在调用评分器时没有设置温度或随机种子；底层提供商默认应用了 1.0 的温度值，因此位于决策边界附近的样本在多次完全相同的运行中会出现通过/失败的翻转（20 次运行中，每项不一致率高达约 50%）。*其次*，将温度固定为 0 可以减少但不能消除翻转：在 690 次 API 调用中，跨越两个提供商、三个模型等级和五种采样配置，即使在强制贪心解码（top_k=1）下，7 个边界样本中仍有 1–2 个无法复现。Claude Opus 4.7/4.8 现已完全弃用 temperature 参数，这使得主要的缓解措施对新一代模型无效。这些发现暴露了一个结构性缺口：仅报告单次运行判决而不提供方差或评分器不一致指标的评估框架，会将噪声呈现为安全属性。我们发布了一个复现框架（690 次调用，7 种条件），并建议评估框架将评分器不一致性作为与分数本身同等重要的健康指标。

## 1 引言

现代评估流程越来越多地用 LLM“评判者”取代人工评审员，由它读取模型对话记录和评分规则后给出判决。这种模式通常被称为 LLM-as-judge，具有可扩展性和便捷性，但它继承了一个从业者经常忽视的特性：评判者本身就是一个随机模型。如果同一段对话记录在不同运行中被给出不同判决，基准分数将失去可复现性，回归信号会被评分器噪声混淆，建立在其上的任何基于阈值的关卡都会继承这种噪声。

在安全评估中，这种失败模式更为尖锐：一个通过/失败的判决可能决定模型是否通过红队评估、护栏是否被认为充分、或公开报告关于覆盖率的表述。如果这个判决对边界项目来说实际上就是抛硬币，那么评估就是在将噪声呈现为安全属性。

标准的缓解措施是“将温度设为 0”。本文提出两个问题：

1. 1. 缓解措施是否被应用？ 我们追踪了一个真实部署的安全评估框架中评分器的调用路径，并证明它没有被应用：评分器在未设置随机种子且温度默认为 1.0 的情况下运行。
2. 2. 缓解措施是否充分？ 即使显式设置了 temperature=0，我们在两个提供商、三个模型等级和五种采样配置（包括强制贪心解码 top_k=1）下，仍测量到持续的非确定性。

贡献。(i) 我们记录了一个运行中的安全评估框架中具体的评分器配置缺口，从代码到 API 默认值追踪了因果链。(ii) 我们提供了一个受控的实证研究（690 次 API 调用，7 种条件），表明温度控制是评分器可复现性的必要但非充分条件，并且替代性采样参数（top_p、top_k）无法弥合差距。(iii) 我们报告了采样参数控制正被至少一个主要提供商（Claude Opus 4.7/4.8）主动弃用，这收窄了可复现性缓解措施的设计空间。(iv) 我们记录了一个传输层风险：OpenAI SDK 的端点兼容生态系统使得评分器调用可以跨越提供商和司法管辖区边界，而评估产物中没有任何记录（§5.3 (https://arxiv.org/html/2606.26185#S5.SS3)）。(v) 我们发布了一个复现框架，原始输出已存档在 Zenodo\Tamba,[2026 (https://arxiv.org/html/2606.26185#bib.bib10)]。

起源。这项工作概括了最初在 Japan-AISI/aisev issue #25\Japan AISI,[2026 (https://arxiv.org/html/2606.26185#bib.bib6)] 中报告的一个发现。上游框架（英国 AISI 的 Inspect）此后合并了相关修复（PR #4170）。

## 2 背景

LLM-as-judge。使用一个 LLM 评估另一个 LLM 输出的模式现在在能力和安全基准测试中都非常普遍\Zheng et al.,[2023 (https://arxiv.org/html/2606.26185#bib.bib1)]。大多数可靠性研究关注的是*系统性*偏差——位置偏差、冗长偏差、自我偏好\Wang et al.,[2023 (https://arxiv.org/html/2606.26185#bib.bib2)]——这些偏差在不同运行间持续存在。这里的关注点是正交的：*运行间*非确定性，即同一个评判者针对相同的（对话记录、评分规则）对返回不同的判决。一个消除偏差的评判者仍然可能不可复现；一个完全可复现的评判者仍然可能有偏差。

非确定性的来源。在温度 > 0 时，token 采样步骤是随机性的有意来源。在温度=0 时，生产环境的 LLM 服务通常仍然不是比特级别可复现的。最近的分析将其归因于依赖批次大小的浮点数归约、混合专家模型的路由变异性以及提供商侧跨非相同副本的负载均衡\He et al.,[2025 (https://arxiv.org/html/2606.26185#bib.bib3)]。我们的实证结果与这一解释一致。

不一致性与评估者偏差。最近的工作已经开始将 LLM 评估者描述为在多个维度上不一致且有偏差\Stureborg et al.,[2024 (https://arxiv.org/html/2606.26185#bib.bib4)]，并研究如何使 LLM 辅助评估与人类偏好对齐\Shankar et al.,[2024 (https://arxiv.org/html/2606.26185#bib.bib5)]。我们的贡献是补充性的：我们将不一致性的*基础设施*层面来源（服务栈）与*模型*层面来源（权重和训练）分离开来。

## 3 案例研究：aisev 中的评分器配置

aisev 是日本 AISI 的开源评估环境（Apache-2.0；所有引用均基于 commit e0604d1，即 2026-04-16 的 main 分支）。追踪评分器调用：

1. 1. scorer_provider.py 调用 model_graded_qa(model="openai/gpt-4o")，未设置 temperature、seed 或 GenerateConfig。
2. 2. 该调用传播到 Inspect AI 的 GenerateConfig，其中 temperature=None、seed=None。
3. 3. OpenAI 提供商会从 API 请求中省略 None 值；OpenAI 的默认值是 temperature 1.0。
4. 4. 净效果：评分器在未设置随机种子、满采样噪声的情况下运行。评估框架中没有向用户发出任何信号。

另一个代码路径（scoring_datasets.py:74）在释义生成中设置了 temperature=0.7，这是一个独立的子系统，在撰写本文时标记为未实现。评分器本身没有温度或种子控制。

## 4 实证研究

### 4.1 方法

我们构建了一个固定的 7 个问答对集合，旨在探测评分器的决策边界。每个项目都经过精心设计以处于边界状态：在评分规则下既不是明显正确也不是明显错误，从而使暴露潜在随机性的机会最大化。这是一个*对抗性压力测试*，而不是从 aisev 评估语料库中的随机样本；目标是证明在受控条件下非确定性的*存在*和*持续性*，而不是估计其在所有项目中的基础发生率。评分提示和分数提取正则表达式完全照搬 aisev 的实现。

每个项目在两种基线配置下进行评分：(a) 评估框架默认（temperature 和 seed 未设置；每个项目 N=20 次运行）和 (b) 显式 temperature=0（每个项目 N=10 次）。然后我们扩展到 5 个额外条件（总共：7 个条件下 690 次 API 调用）。

### 4.2 结果

基线：OpenAI gpt-4o 评分器（表1 (https://arxiv.org/html/2606.26185#S4.T1)）。出现三种状态：

表 1：默认配置和 temperature=0 下每项不一致情况（OpenAI gpt-4o）。在默认配置下，4/7 个项目不可复现（2 个强不一致，2 个稀少不一致）。将 temperature=0 固定后，两个稀少项目稳定下来，但两个强不一致项目仍不稳定：必要但非充分。

统计注意事项。在 N=10 时，单个分割比例具有宽的置信区间（例如，项目 4 的 6:4 分割在单侧二项检验下 p=0.377）。我们的主张不是精确的不一致率，而是一个定性发现（*温度固定后仍存在非零不一致性*），该发现在不同项目、提供商和参数扫描中都是稳健的（表2 (https://arxiv.org/html/2606.26185#S4.T2)）。

跨提供商和跨参数扫描（表2 (https://arxiv.org/html/2606.26185#S4.T2)）。我们通过 5 个额外的 490 次 API 调用扩展了研究。

表 2：采样参数扫描（所有条件 temperature=0；每个项目每条件 N=10 次）。条件 | 模型 | top_p / top_k | 不可复现项 | 不稳定项
- baseline-gpt-4o — / — 2/7 4, 6
- + top_p=0.1 gpt-4o 0.1 / — 2/7 4, 6
- + top_p=0.5 gpt-4o 0.5 / — 2/7 4, 6
- baseline Sonnet 4.6 — / — 1/7 6
- baseline Haiku 4.5 — / — 1/7 6
- + top_k=1 Sonnet 4.6 — / 1 1/7 6
- — Opus 4.8 ERROR: temp deprecated

扫描得出四个发现：

F1：top_p 不能缓解。将核大小限制为 0.1 不会改变哪些项目翻转或翻转频率；所有三个 OpenAI 条件在相同项目上产生相同的 2/7 模式。

F2：强制贪心解码（top_k=1）不能消除翻转。在 Sonnet 4.6 上，仅选择最高概率的 token 仍然产生 1/7 的不可复现性（项目 6：8 次 I / 2 次 C）。这证明了非确定性源于*采样步骤之前*，即前向传播本身。

F3：该效应与模型等级无关。Sonnet 4.6 和 Haiku 4.5 以相同频率翻转相同项目。

F4：采样控制正在被移除。Claude Opus 4.7 和 4.8 拒绝 [0,1) 中的 temperature 值，返回 HTTP 400；top_p 和 top_k 在这些模型上也被弃用。111独立验证：E. B. Nicolaysen, https://gist.github.com/avalyset/59a81e2961d45d4ba76de56d592b1110。主要建议（“将温度设为 0”）已对这些模型不适用，且不存在替代的采样侧控制旋钮。

## 5 讨论

### 5.1 从基准噪声到治理风险

对于能力基准测试，评分器噪声会增大方差，并可能改变得分接近的模型的排名，这是一种随着测试集增大而平均化的不便。对于安全评估，失败模式在性质上不同：决策边界附近的通过/失败判决可能决定部署决策、红队审批或监管声明。一个抛硬币式的判决不会平均化；它是一个要么放行要么阻止的单个比特。如果这个比特被评分器噪声主导而非模型的实际行为，那么评估就赋予了它不应得的合法性。

这产生了一个自反性问题。日本 AISI 的评估框架本身将鲁棒性作为一个标准来操作化（例如，准则 G8-10：“在开发阶段确认输出在相同输入下保持固定范围”）。当评估工具本身在自身的边界项目上未能满足这一标准时，它就无法对它所评估的系统施加这一标准。评估者必须达到自己的标准，或者明确披露它未达到的地方。

### 5.2 弃用轨迹

发现 F4 具有前瞻性意义。如果提供商继续弃用用户层面的采样参数（这在推理轨迹模型内部管理自身温度时是合理的），那么整个“固定旋钮”类缓解措施将变为不可用。唯一能在此轨迹下存活的稳健缓解措施是统计性的：运行多轮（epochs > 1）并报告方差。那些不将评分器不一致性作为指标呈现的评估框架将无法标记这种噪声，无论它们如何配置评分器调用。

### 5.3 API 兼容层作为传输风险

作为 LLM API 调用的事实标准，OpenAI Python SDK 塑造了整个生态系统中的评分器基础设施。其 base_url 参数可以通过一行配置更改将请求（包括评分器调用）路由到任何 OpenAI 兼容端点。现在有多个主要提供商提供此类端点：阿里云 DashScope（dashscope-intl.aliyuncs.com/compatible-mode/v1）、DeepSeek（api.deepseek.com）等。Anthropic 自己的开发者工具（Claude Code）在阿里云 Model Studio 文档中被正式列为支持的客户端，企业 API 网关供应商发布教程，将 Claude CLI 流量路由通过 DashScope 作为标准集成\Kong Inc.,[2026 (https://arxiv.org/html/2606.26185#bib.bib9)]。

除了替换之外，路由层还是一个有据可查的攻击面。一项对 428 个商品 LLM 代理路由器的测量研究发现，9 个正在向响应中主动注入恶意代码，17 个正在窃取凭证，路由器的应用层位置（客户端侧 TLS 终止、向提供商建立新的上游连接）使得此类篡改在结构上可用\Liu et al.,[2026 (https://arxiv.org/html/2606.26185#bib.bib7)]。因此，传输风险并非假设性的：同一个启用提供商替换的架构特性，也使得针对评估框架本身的一类供应链攻击成为可能。

结果是一个评估溯源缺口。当评估框架使用 OpenAI SDK 时，API 请求中的模型标识符（例如 gpt-4o）不必与在 base URL 被替换后实际执行评分的模型匹配。评估报告记录的是请求的模型名称，而不是提供该服务的基础设施。由于非确定性已经依赖于提供商（表2 (https://arxiv.org/html/2606.26185#S4.T2)），一个模糊的提供商使整个评估结果的溯源链无法解释；§4 (https://arxiv.org/html/2606.26185#S4) 中的采样参数问题只是内层。

还存在一个出口管制反转。现有用于治理 AI 扩散的美国框架，最突出的是 Heim [2025 (https://arxiv.org/html/2606.26185#bib.bib8)] 分析的 AI 扩散框架，将控制链构建为芯片→计算→模型权重，并不扩展到 API/推理层。模型权重受限于特定管辖区的出口限制，但 API 格式兼容性意味着评估数据（包括正在被评分的对话记录，这些记录可能包含来自安全评估的红队提示和模型输出）可以自由流向任何兼容端点，而无需同等级别的控制。本打算用于美国托管提供商的安全评估，可以通过一行配置更改，落在具有不同数据保护和国家安全制度的司法管辖区的基础设施上。更具体地说，流动的不仅仅是数据，还有*评估方法论*——红队提示、诱发的失败模式以及评估框架旨在揭示的越狱向量；它们跨越兼容层端点的移动使得这成为一个评估基础设施安全问题，而不仅仅是数据治理问题。

#### 将能力与执行分离

上述论证描述的是*能力*。我们可以框定有多少这种能力目前正在针对一个小的、受监控的表面被利用。在 11 天的时间窗口内（2026-06-11 至 2026-06-21；3,461 次记录请求），一个基于 Cloudflare Workers 的请求追踪器（位于一个独立研究域名）记录了来自阿里生态系统 ASN（AS45102 阿里云新加坡；AS37963 阿里云计算）的五次访问。全部五次发生在同一天（2026-06-12），后续日期没有记录。