温度归零并非万能：LLM-as-Judge 安全评估中的可重复性困境
温度归零并非万能：LLM-as-Judge 安全评估中的可重复性困境
在 AI 安全评估中，LLM-as-Judge（以大语言模型作为裁判）组件已成为标准配置，其给出的“通过/不通过”判决直接影响模型是否能够部署。业界普遍认为，将裁判模型的采样温度设为 0 即可保证评分结果确定性。然而，日本 AI 安全研究所（Japan AISI）在开源评估框架 aisev 中的实测发现：这一假设在真实场景中并不成立。
两大层面的“失效”
研究团队对 aisev 框架进行了系统性测试，暴露了温度控制的两层问题：
默认温度陷阱：框架调用裁判模型时，并未显式设置 temperature 或 seed 参数，底层 API 提供商静默使用默认值 1.0。这意味着，对于决策边界附近的样本，多次运行结果可能截然相反——在 20 次重复运行中，单个样本的“通过/不通过”不一致率高达约 50%。
强制贪婪解码仍不完美：即便将 temperature 设为 0，并配合 top_k=1 的强制贪婪解码，在 690 次 API 调用（覆盖两家提供商、三个模型层级、五种采样配置）中，仍有 1-2 个边界样本（共 7 个）无法复现。更棘手的是，Claude Opus 4.7/4.8 已完全弃用 temperature 参数，这意味着针对旧模型的温度控制手段在新模型上根本无从使用。
结构性问题：把噪声当成安全属性
论文指出，当前评估框架存在一个结构性缺陷：仅报告单次运行的判决结果，而不提供方差或裁判分歧度指标。这种做法可能将随机噪声误读为模型的安全属性。例如，同一模型在两次评估中分别获得“通过”和“不通过”，若只看单次结果，就会得出截然不同的安全结论。
行业启示与建议
研究团队建议，评估框架应将裁判分歧度作为与评分同等重要的健康指标。同时，他们开源了包含 690 次调用、7 种条件的复现测试工具，供社区验证。
这一发现对 AI 安全治理具有直接冲击：在模型部署前，若仅依赖单次 LLM-as-Judge 的判决，可能遗漏重大安全风险。温度控制是必要手段，但绝非充分条件——评估流程需要更严谨的统计设计和透明度。