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

LLM-as-judge（大语言模型作为裁判）组件已成为评估框架的标准组成部分，尤其是在安全评估中，通过/失败判定可能直接影响部署决策。一个普遍且看似合理的假设是，将采样温度设为0即可使评估结果具有确定性。然而，日本AISI（人工智能安全研究所）的研究人员通过对真实安全评估代码库aisev的测试，揭示了这一假设的局限性。该论文于2026年6月24日提交至arXiv，作者为Hiroki Tamba，共7页并包含2张表格。

研究发现，问题涉及两个层面：首先，评估框架在调用裁判时未设置温度或随机种子，而底层API提供商会静默地应用默认温度1.0。这导致接近决策边界的项目在相同输入下结果反复翻转——在20次运行中，每个项目的分歧率高达约50%。换句话说，同一安全测试用例在不同运行时可能得出截然不同的结论，这对于依赖安全评估结果的部署决策来说是一个严重隐患。

其次，即使将温度明确设置为0，翻转现象也只是减少而非消除。在针对两个提供商（包括Anthropic和另一个未具名提供商）、三个模型档次（涵盖不同规模和能力）以及五种采样配置进行的690次API调用中，7个边界项目中有1-2个即使在强制贪婪解码（top_k=1）下仍然无法复现。这表明，即使采用最为确定性的解码策略，LLM裁判的判决仍然存在不可忽略的随机性。

值得关注的是，Claude Opus 4.7/4.8版本已完全弃用了温度参数，使得主要的缓解措施对新一代模型不再适用。这一变化意味着，研究人员无法通过设置温度=0来尝试稳定新模型的行为，进一步凸显了问题的紧迫性。这些发现揭示了一个结构性缺陷：仅报告单次运行结果的评估框架，若不提供方差或裁判分歧度量，可能会将噪声误报为安全属性。研究人员强调，如果一个评估框架只汇报一次运行的结果，监管机构和开发者可能会被误导，认为模型表现出稳定的安全性，而实际上结果可能只是偶然。

为此，研究人员发布了包含690次调用、7种条件的复现测试套件，并建议评估框架将裁判分歧作为与分数同等重要的一等健康指标。这一工作对于依赖LLM判断的系统（如自动内容审核、模型行为评估等）具有重要的警示意义。具体而言，他们推荐评估框架不仅应报告平均分数，还应报告每个项目上的裁判分歧率，并在决策阈值附近特别标注不确定性。这种方法类似于在机器学习中报告置信区间，而不是仅靠点估计。总之，该研究打破了温度=0即确定性的神话，并为设计更可靠的AI评估流程提供了实证基础和具体建议。