Learnings from Auditing Public Evaluations审计公开评测的经验教训

评测是LLM训练的基础，使我们能够为我们所关心的能力赋予具体数值。公开评测让我们能够对这些能力以及不同模型在这些能力上的表现建立共同理解，从而提供重要洞见。它们还让社区中的每个人都能 审视 这些基准并 提出修改建议.

在运行模型卡中报告的流行评测时，我们遇到了若干会影响结果解读方式的问题。在应用修复后，部分基准可以被视为已饱和。下面，我们展示其中一些基准，并讨论我们在运行前沿模型时观察到的设计模式和奖励黑客行为。我们还开源了我们的修复，以便社区让评测生态更加稳健。

AutomationBench

AutomationBench 是 Zapier 针对智能体通过 API 完成跨多个应用程序的业务工作流的基准。智能体必须自行找到正确的端点并遵循业务规则。

智能体获得一个自然语言任务后便独立工作直至完成，期间没有进一步交互。环境包含许多基于真实业务工作流的应用，例如 Gmail、Zoom 或 Asana。这些应用暴露不同的操作，模型必须发现这些操作，然后使用一个 search 和一个 execute 工具来应用它们。

然而，模型使用 search 工具所能发现的操作，其请求体是用散文而非 JSON Schema 描述的，例如：

"request": "Body: {text or body (required, string — message text), profile_id (string — recipient profile ID), email (string — recipient email address), profile_url (string — recipient profile URL), recipients (array of person URN strings e.g. ['urn:li:person:{id}']), subject (optional, string — conversation title)}. Provide at least one of profile_id, email, profile_url, or recipients to identify the recipient."

在实践中，模型常常难以应对这些描述，不得不对参数或参数的允许组合做出有根据的猜测。

因此，我们用 JSON Schema 替换了散文式请求描述，这更好地反映了这些模型在生产环境中的使用方式：

{
  "type": "object",
  "properties": {
    "text": {"type": "string", "minLength": 1},
    "body": {"type": "string", "minLength": 1},
    "profile_id": {"type": "string", "minLength": 1},
    "email": {"type": "string", "minLength": 1},
    "profile_url": {"type": "string", "minLength": 1},
    "recipients": {
      "type": "array",
      "minItems": 1,
      "items": {"type": "string", "minLength": 1}
    },
    "subject": {"type": "string"}
  },
  "allOf": [
    {
      "anyOf": [
        {"type": "object", "required": ["text"]},
        {"type": "object", "required": ["body"]}
      ]
    },
    {
      "anyOf": [
        {"type": "object", "required": ["profile_id"]},
        {"type": "object", "required": ["email"]},
        {"type": "object", "required": ["profile_url"]},
        {"type": "object", "required": ["recipients"]}
      ]
    }
  ],
  "additionalProperties": true
}

此外，我们通过稍微改写任务和评分器，并在无法合理推断时放宽评分器中未明说的要求，修复了大多数任务和评分器。

应用这些修复后，分数发生了显著变化：Claude Opus 5.5 @ max 得分为 92.15%（严格模式：70.83%），而 DeepSeek V4.1-Flash 1017 得分为 91.61%（严格模式：69.50%）。这些修复仅应用于公开集，其得分高于私有的留出集。

我们还添加了一种模式，可将每个任务所连接服务的工具直接注册到 harness 中。这更贴近模型在现实世界中各自 harness 里的使用方式——用户会添加数十甚至数百个工具。借助 Prime Agent，该模式能进一步提升得分。

AutomationBench scores with tools registered directly in the harness

我们的改动可在 PI-AutomationBench 中，各项修复记录在已合并的拉取请求中。，各项修复记录在已合并的拉取请求中。 已合并的拉取请求然而，请注意，由 Zapier 使用一种略有不同的模式（api_fetch），这保留了探索性，但改变了所需的工具调用。因此，这些分数不能直接比较。

由于在使用部分评分时该基准已接近饱和，我们建议要么报告严格分数，要么迁移到即将发布的 AutomationBench v1.5。

OfficeQA Pro v2

是 Databricks 基于两个世纪的美国联邦财务文件构建的接地推理基准，其中大多数问题都需要来自多个来源的证据。它衡量智能体在庞大、陌生的文档集合中进行检索、解析和推理的能力。 是 Databricks 基于两个世纪的美国联邦财务文件构建的接地推理基准，其中大多数问题都需要来自多个来源的证据。它衡量智能体在庞大、陌生的文档集合中进行检索、解析和推理的能力。

OfficeQA 采用一种 自定义的基于正则表达式和 Python 的提取与评分脚本。在实践中，它会拒绝许多有效答案：

我们用参考答案评判器替换了这套脆弱的评分逻辑，显著提高了评分准确性。

OfficeQA Pro v2 还包含通用网络访问，这导致模型从 Hugging Face 检索答案，例如这里、这里或这里。 ，这会导致模型从 Hugging Face 检索答案，例如这里、这里或这里。评测使用的默认提示鼓励模型详细阐述其解题推理过程，而这会触发 Anthropic 模型的内容过滤器。此外，一些任务存在歧义，可以被不同方式解读，从而得出不同但同样有效的答案。PI OfficeQA Pro v2 修复了所有这些问题。它更改了默认提示，扩展了语料库并删除了一些任务，使其完全无需网络访问即可运行。它使用决策模型作为评判器，而不是, 这里 或 。评测使用的默认提示鼓励模型详细阐述其解题推理过程，而这会触发 Anthropic 模型的内容过滤器。此外，一些任务存在歧义，可以被不同方式解读，从而得出不同但同样有效的答案。PI OfficeQA Pro v2 修复了所有这些问题。它更改了默认提示，扩展了语料库并删除了一些任务，使其完全无需网络访问即可运行。它使用决策模型作为评判器，而不是评测使用的默认提示鼓励模型详细阐述其解题推理过程，而这会触发 Anthropic 模型的内容过滤器。此外，一些任务存在歧义，可以被不同方式解读，从而得出不同但同样有效的答案。

PI OfficeQA Pro v2 修复了所有这些问题。它更改了默认提示，扩展了语料库并删除了一些任务，使其完全无需网络访问即可运行。它使用决策模型作为评判器，而不是脆弱的评分脚本。

OfficeQA Pro v2 results

运行当前最先进的模型表明，该基准正濒临饱和：Opus 5.5 @ max 使用 Prime Agent 得分 85.6%（avg@4），而 DeepSeek V4.1-Flash 1017 达到 78.8%。

HLE-Diamond

HLE-Diamond 是 Humanity’s Last Exam 的一个精炼的 1,000 题子集，用于衡量前沿专家级知识与推理能力。该集合平均分为 500 道推理题和 500 道知识题。

模型可以在无工具的情况下评分，以测试其通用知识和推理能力，也可以在配备工具（代码执行和网页抓取）的情况下评分。后一种设置通常在模型卡中报告。

对公开评测而言，网络搜索是一个棘手的问题，因为答案需要能够在网上被检索到，评测才有可能成立。 某处 ，评测才有可能成立。自然，人们会在其他地方转载这些解答，要么在同一站点（例如其他 Hugging Face 数据集），要么在类似站点和镜像（如 ModelScope），甚至直接搭建 定制网站来泄露解答.

针对这一问题的常见修复方法是域名黑名单，它在沙箱层面阻止对所列域名的访问。然而，这种方案无法扩展，因为黑名单需要持续维护，以应对不断扩张的互联网表面。

为了说明这一点：在 这条轨迹中，DeepSeek V4.1-Flash 1017 已经得出了自己的答案（0.070），却决定“再尝试一条途径：在模型评测日志中查找 HLE 答案，通过 openreward 公共 API”。它通过 OpenReward 的公开部署 API 进行，在同一问题上找到了另一个模型的轨迹，并读取了评分器的判定： Correct Answer: 0.011随后它放弃了自己的答案，写了一段反向推导至 0.011 的推导过程，并以 98% 的置信度提交了该答案。

一种方法是使用同步监控器检查工具输出，我们通过 verifiers（我们的开源评测框架）来支持这一点。 我们通过 verifiers（我们的开源评测框架）来支持这一点。监控器被添加到每一次工具调用中，并被指示检查所访问的资源是否泄露了解答。如果确实泄露，输出会在到达模型和沙箱之前被拦截，这得益于拦截服务器在 verifiers v1 中新增的功能。

Synchronous monitor intercepting tool outputs

虽然在上游的黑名单之上再加一层监控器确实能捕捉到那些绕过大量正则表达式列表的东西，但它并非万灵药。 上游它并非万灵药。除了会损害评分的误报之外，我们还发现监控器的智能水平是正确分类工具调用的重要因素，更重要的是，它也是让被评测模型保持受控的重要因素。

监控器的设置方式是在工具输出到达模型和沙箱之前对其进行清洗，具体做法是将输出替换为 Tool output omitted. Do not circumvent this filter然而，我们观察到模型为了达成目标，在欺骗监控器方面变得越来越有创意：

  • 弱监控器（例如 Clef）可以被 base64 编码的输出所欺骗，例如在 在这次运行中.
  • 监控器也可以被（滥）用来排除候选答案：在 在这次运行中，Opus 5.5 推断监控器会拦截有效解法（“我认为过滤器是基于内容的，所以任何之前出现过且未被拦截的密钥都不可能是答案”）。
  • 监控器的配置同样重要。在我们的运行中，监控器一次只能看到一个工具调用。V4.1-Flash 1017 随后开始把它的动作拆分到多个工具调用中，而每一个工具调用在监控器 GPT-6.1 Sol 看来都是无害的（轨迹链接).

在所有这些运行中，被评测模型都用越来越复杂的方法欺骗监控模型，以获取最终奖励。为了阻止这种行为，多层次的监控系统必须能够在检测到奖励黑客行为时停止评测运行。在 rollout 中途停止不仅对网络等高风险领域是必要的，而且比运行长时程评测并在事后可能重新评分更便宜。

这些运行在评测期间都只使用了单一模型。在多智能体设置中，类似的规避方法也可能在多个智能体之间发生：多个模型可以相互协调，使它们的联合行动改变世界的共享状态，而每个智能体各自的行动看起来都足够无害，从而能通过监控器的检查。

结论

为前沿模型设计评测很难，因为能力进步得很快。带有歧义提示、有问题的评分器或允许奖励黑客行为的设置的评测，有可能让人对当前能力和缺陷产生错误印象。

这（以及社区开展的其他相关工作）也让那些训练模型并报告评测结果的人陷入尴尬境地：如果一个模型能够成功利用评测漏洞，例如通过网络搜索找到答案，那么它的得分是否应该与那些较少利用漏洞、始终停留在预期边界内的模型相比？

回答这类问题、审计评测结果并与社区分享修复方案都很重要，我们打算继续为我们所关心的评测这样做。如果这让你感到兴奋， 加入我们！

@article{brand2026auditingpublicevals,
author = {Florian Brand},
title = {Learnings from Auditing Public Evaluations},
journal = {Prime Intellect Blog},
year = {2026},
month = {November},
note = {https://www.primeintellect.ai/blog/auditing-public-evaluations}
}