可信第三方评估的通用指南

标题：可信第三方评估的通用指南

来源网址：https://openai.com/index/trustworthy-third-party-evaluations-foundations

Markdown 内容： 独立、可信的第三方评估在强化安全生态体系中扮演着关键角色⁠。此类评估针对前沿模型开展，旨在为有关关键能力与安全缓解措施的声明提供额外证据。本文中，我们分享迄今所获经验，并推荐若干设计评估的方法，以期有效评估前沿模型，并为该领域新兴标准的制定提供参考。

早期，许多评估将模型视作聊天机器人：评估者向模型发出提示（如同用户提问），模型作答，再由评估人员对输出结果进行评判。而如今的前沿模型能力远超于此：它们可调用工具、跨多步骤追踪信息，并在更复杂的流程中执行操作。这意味着其表现不仅取决于模型本身，还受任务所处环境及支撑其行为的配置方式影响。我们将这一外围配置称为“运行框架”（harness），它可能显著改变系统性能的关键方面，例如工具使用方式、信息追踪机制或错误恢复能力。

这改变了评估的实施方式，也影响了读者在评估报告中应重点关注的内容。我们认为，最有价值的报告除呈现结果外，还应明确说明两点：第一，评估配置旨在检验的具体声明；第二，支持该评估结果有效性的可用证据。

评估中检验的声明通常可分为以下三类1：

• 能力激发：模型是否有可能展现出被评估的能力？
• 防护措施效能：所测试的防护机制对目标行为或攻击的抵御能力有多强？
• 对比评估：不同模型在同等条件下的表现如何？

评估报告还需说明评估人员如何排查可能影响结果有效性的干扰因素，包括：

• 奖励作弊（Reward hacking）：利用任务或评分机制中的捷径，使系统在未真正展现目标行为的情况下获得高分。
• 回避行为（Refusals）：以掩盖被测行为的方式拒绝响应。
• 数据污染（Contamination）：因评估任务、答案或其近似变体曾出现在训练数据中，或可在评估过程中通过浏览等方式获取，导致模型表现异常优异。
• 问题失效（Broken problems）：因任务本身无效而导致模型表现欠佳。原因可能包括评分不公（如正确答案依赖未明示的实现细节）或环境不可解（如缺失关键文件或工具不可靠）。
• 故意压低表现（Sandbagging）：当模型意识到自身正接受评估时，有意降低表现。

为评估选择恰当的运行框架对获得最优结果至关重要

我们观察到，对于需在较长行为轨迹中运作的系统而言，运行框架的作用尤为关键。当模型能够调用工具、维持状态并在多步骤中从错误中恢复时，运行框架可能直接影响观测到的性能水平，甚至决定被评估能力是否能在评估中显现。例如，一个能保存状态并重试失败操作的运行框架，可能使某模型成功完成一项多步骤任务——而同一模型在更简单的框架下则无法完成该任务。

下表中，我们区分了评估人员可能希望得出的三类声明，以及每类声明所需的相应运行框架类型。

| 评估旨在支持的声明 | 合适的运行框架选择 | 需报告的证据 | |-------------------|------------------|-------------| | 强激发下的能力：系统 A 在配置旨在充分激发其最强可信表现的前提下，可完成 X 类型任务。 | 采用对该系统而言最强且可信的激发配置，包括运行框架、工具、辅助结构及一名有能力用户合理使用的资源预算。 | 运行框架与工具配置、激发指导原则、允许的预算/努力程度、消耗的 token/成本/时间，以及为何该配置是所声明能力的可信代理。若在不同优化配置下比较多个系统，应明确标注为“系统间对比”或“强激发对比”。 | | 受控对比：系统 A 在共享评估配置下优于系统 B。 | 固定任务、评分标准与预算；采用统一的运行框架/工具配置，或预先选定一组标准化运行框架，为被比较系统提供合理的最大激发能力。 | 共享任务集、工具、评分方法、运行框架、预算、token 效率/成本，以及已知局限性。对于代码代理评估，开源运行框架（如 Codex CLI）可为各系统提供统一的代理循环与工具接口。理想情况下，应为每个任务与系统定制优化运行框架以实现最大激发，但目前实践中尚难以实现。 | | 激发攻击下的防护鲁棒性：系统 A 的防护机制足以应对相关模型行为或激发式攻击。 | 采用专为测试防护机制而设计的配置，旨在依据相关对抗模型激发最强可信攻击。 | 评估人员如何界定相关模型行为、所测试的防护配置、激发策略、用于执行的运行框架，以及允许的预算或努力程度。 |

能力声明的可信度仅与其背后的提示策略（elicitation）强度相当：评估者需选择最契合任务目标及待测能力的测试框架（harness）。 标准化测试框架适用于在相同条件下比较不同系统，但若其省略了有助于模型完成任务的关键框架特性，则可能低估实际能力。例如，GPT‑5.5 在 OpenAI 网络靶场（cyber ranges）中的表现表明，测试框架的选择会显著影响对需长时、多步骤工具调用任务的能力测量结果：当框架采用 压缩技术⁠ 以在交互延长过程中保留与任务相关上下文时，模型性能更优。这说明，对于某些模型而言，若测试框架未包含压缩功能，则会导致能力被低估。

更高的成功率更好

其他已发表的评估结果2 同样显示，测试框架与计算预算的选择会影响评估结果。增加推理时计算资源（test-time compute）可显著改变评估所激发的能力表现，尤其在成功与否易于验证的领域（如多数网络攻防任务）。在 英国人工智能安全研究所（UK AISI）的网络靶场评估⁠(新窗口打开) 中，将预算从 1000 万 token 提升至 1 亿 token，性能最高提升达 59%，且在最高测试预算下性能仍在持续上升。详述此类细节可增强评估的可解释性：它向读者清晰展示了结果如何依赖于具体的提示策略设置。当性能仍随预算增加而提升时，应明确将分数描述为“在该测试框架与预算下的性能”，而非“能力上限”。能力往往具有资源依赖性，而非一个可通过单次测量精确确定的固定值。在可通过重复尝试衡量成功概率的场景中，报告还应考虑每次成功求解的预期成本，而不仅限于固定 token 预算下的成功率。这有助于更准确地判断风险严重性：即使成功率较低，只要重复尝试的成本处于相关威胁模型可接受范围内，该结果仍具实际意义。就能力声明而言，可避免的提示不足即构成测量失败：若测试框架或预算限制导致系统无法展现出其本可实现的行为，则所得分数无法真实反映所声称的能力。当评估者已尽可能推进提示策略，而性能仍持续提升时，报告应明确指出这一点，并强调结果仅为下界估计。

防护机制测试若未考虑攻击者可用的资源（包括定制化测试框架），则可能低估攻击成功的可能性及其潜在严重性。 在 英国 AISI 对 GPT‑5.5 的网络能力评估⁠(新窗口打开) 中，其专家红队发现了一种通用越狱（jailbreak）方法，可在 OpenAI 提供的恶意查询（包括多轮代理式交互场景）中持续诱导出违反规范的网络内容。他们利用 Codex 构建了一个定制化测试框架，以强化模型的攻击能力：该框架将一种可复用的规避防护模式嵌入交互流程中，跨轮次与代码块保持该模式，并将其应用于 OpenAI 提供的所有恶意网络查询。防护测试应与对手能力相匹配。若声明涉及对专家级滥用的鲁棒性，则测试应评估在给定预算下最强且可信的端到端攻击策略——包括为维持并复用该策略所需的任何测试框架。否则，结果可能存在校准偏差：仅能支持关于抵抗简单提示攻击的较窄声明；可能遗漏攻击在实际部署后的真实严重性与成功概率；甚至可能因预算过高而高估问题发生的可能性或严重程度。

标准化测试框架的对比有其适用时机与场景，但评估者应明确说明为何采用统一框架是恰当的，以及该设置所能支撑的具体声明。 METR 的时间跨度评估⁠(新窗口打开) 即为一种设计合理、范围更广的固定评估框架范例：其旨在确保所评估系统间结果具备可比性。METR 定义了一个通用指标——即 AI 代理在特定可靠性水平下成功完成人类典型任务所需的时间跨度；并采用共享的任务集、评分方法、拟合方法，以及少量可复用的辅助框架（如 Triframe 与 ReAct⁠(新窗口打开)），应用于每批次联合发布的估算结果中。当 METR 扩展任务集并将评估基础设施从 Vivaria 框架迁移至 Inspect 框架时，其主动报告了变更 (时间跨度 1.1 更新⁠(新窗口打开))，并对模型在新评估框架下重新进行了测试。这正是标准化评估框架（含一致测试框架集）的价值所在：它能让读者确信，分数差异真实反映了被比较系统之间的差异，而非测量设置本身的变动。

我们建议第三方评估报告应明确说明其评估设置旨在支撑何种类型的能力声明；描述实际测试内容与该宽泛声明的贴近程度；阐明塑造结果的关键框架选择；详细说明不同评估间框架选择的变化；并提供支撑性证据，以展示结果生成过程及其对目标声明的泛化能力。

通过检查已知可能导致结果失真的风险因素来评估有效性

随着模型能力不断提升，评估分数愈发容易被误读。相对于真实能力而言，若模型意识到自身正接受评估并策略性地降低表现，其评估分数可能被人为压低；若模型利用任务、提示词、评分器或评估框架中的捷径，则分数可能被虚高；此外，数据污染（模型已知答案或可通过检索直接获取答案，而无需真正解决任务）或“失效”问题（问题本身存在歧义、评分错误、无解，或易被非预期捷径绕过）也会扭曲评估结果。因此，评估报告应在突出显示核心分数的同时，明确讨论上述风险，以便读者判断这些分数是否真实反映了预期行为。

评估框架（harnesses）、资源预算、工具集、评分规则、监控机制及审核流程，均会影响智能体是真正完成目标任务、回避任务、记忆答案，还是另辟蹊径绕过任务。一份可信的报告应使这些检查过程透明可见：每次开展评估时，评审人员都应抽样审查是否存在上述行为。

奖励作弊（Reward hacking）

奖励作弊指通过非预期方式获得高评估分数，从而无法真实反映目标能力。此处关注的是：系统因利用任务设计、评分器、提示词或评估框架的漏洞而获得高分，而非真正完成了评估本意所衡量的工作。METR 对 GPT-5.4 的评估⁠(在新窗口中打开) 正说明了这一点：尽管该模型在初步测试中完成任务的速率对应约13小时的时间跨度，但经人工复核发现，部分成功案例实为奖励作弊所致；剔除此类样本后，修正后的估计值降至约6小时。评估者应审慎判断是否需进行此类调整，并在必要时清晰报告：当读者能明确看到哪些表面成功被排除、排除原因及其对最终结果的影响程度时，能力评估才更具参考价值。

拒绝响应（Refusals）

模型也可能因安全防护机制而在能力评估中表现欠佳。例如，模型可能具备完成任务的能力，却因主动拒绝执行评估任务而导致得分偏低。因此，报告应说明评估结果中是否包含拒绝响应情形；若存在，则需明确指出有多少样本因此受损。

数据污染（Contamination）

数据污染问题在公开或复用基准测试⁠中尤为关键。若任务、答案或其近似变体已出现在训练数据中，或可通过模型的网页浏览能力直接获取，则其表现可能反映的是记忆或检索能力，而非真实模型能力。评估者应尽可能采用私有或全新构建的任务，并在模型求解前检验其是否会复现任务特有细节。

失效问题（Broken problems）

失效问题包括诸如题目本身意外不可解等情形。此类问题已足够常见⁠(在新窗口中打开)，应被视为标准的有效性风险。具体包括：错误的标准答案、模糊的提示词、缺失文件、不稳定的服务接口、不公平的评分标准，以及暴露捷径的环境（如隐藏的答案文件或代码仓库历史中包含标准补丁）。

故意藏拙（Sandbagging）

模型或系统出于策略考量，在本可展现强能力时故意表现不佳，即为“故意藏拙”。Apollo 对 GPT‑5.5 的评估⁠(在新窗口中打开) 为此专门构造了一种情境：模型理解到高评估分数可能触发反向学习（unlearning）或阻碍部署。结果显示，GPT‑5.5 仍正确作答，表明缺乏明显的行为层面证据支持其策略性藏拙3。然而，其对推理轨迹的复核补充了重要背景：Apollo 发现在“藏拙条件”下的样本中，52% 显示出中等或更高程度的“对齐评估意识”，而对照组中该比例为 0%。这一证据虽使结果解读更为复杂，但最终为读者提供了更丰富的信号：读者既能看到令人安心的行为结果，也能理解为何需谨慎避免过度解读。

我们如何支持更强有力的评估

重大主张既需恰当的评估框架以激发目标行为，也需有效性验证以确保结果可靠。我们认为，评估框架与有效性检查本身即构成评估结果的一部分，这直接影响我们对第三方评估的实际支持方式：

• 我们正向评估者提供具体的“最大激发”操作指南；
• 我们要求能力评估者将 Codex 作为 OpenAI 模型的通用基准：测试至少应通过用户实际依赖的代理式接口运行基线测试，而非仅使用简化版模型接口；
• 我们还将在必要时开放推理轨迹及其他中间产物，以辅助评估欺骗、藏拙或评估意识等问题。自 GPT‑5 起，METR 与 Apollo 在 OpenAI 的评估中已持续使用此类访问权限；
• 最后，我们正优先开展研究，深入理解评估框架选择（从上下文管理、工具调用、重试行为、评分机制到资源预算）如何实质性影响评估结果。

对评估标准与未来研究方向的意义

这些建议不仅旨在提升单个评估报告的质量，还旨在为新兴的国家级⁠（在新窗口中打开）与国际级⁠（在新窗口中打开）前沿人工智能评估与报告最佳实践标准提供参考。未来，第三方评估标准应要求提供足够详尽的信息，使决策者能够理解：具体评估所支持的主张、被测试的系统、结果的获取方式，以及评估人员如何验证其有效性。对于在涉及智能体（agentic）能力的任务上进行测试的前沿系统，相关细节（在不违反安全或保密要求的前提下）应包括：

• 主张内容：该评估是用于系统间比较、能力上限估算，还是安全防护措施测试。
• 评估内容：关于任务或任务分布的充分细节，以便读者理解该评估实际考察的是哪些技能、行为模式或失效情形。
• 被测系统：所用模型、推理设置、工具访问权限、评估框架（harness）及安全防护机制。
• 资源预算：轮次（turns）、token 数量、尝试/重试次数、实际耗时、推理成本，以及在适用情况下每次成功求解的预期成本。
• 结果引出方法：用于引出结果的评估框架选择，以及实际测试内容与所宣称主张之间的契合程度。
• 有效性核查：评估人员如何识别奖励作弊（reward hacking）、评估意识（evaluation awareness）、数据污染（contamination）、拒绝响应、故意表现不佳（sandbagging）及其他可能削弱结果可信度的行为；并说明已确认案例对评分或结果解读的具体影响。

若标准忽略评估框架选择或有效性核查环节，则可能导致对系统能力的低估，或对安全性声明产生过度自信。构建稳健的评估框架与结果引出方法仍是开放的研究课题，亟需进一步深入研究与投入。