Anthropic 评估可信度专题：三类失真与 PPT Master 的证据边界

原文一：Designing AI-resistant technical evaluations（2026-01-21）
原文二：Quantifying infrastructure noise in agentic coding evals（2026-02-05）
原文三：Eval awareness in Claude Opus 4.6’s BrowseComp performance（2026-03-06）
前置阅读：《Demystifying evals for AI agents》系统解读
实践项目：PPT Master

前置文章回答了一个基础问题：如何定义任务、试验、评估器、记录和结果，并把它们组织成可重复的评估。

本篇继续追问：即使这些部件都存在，分数是否真的在测量我们想测的东西？

Anthropic 的三篇文章给出了三种性质不同的失真：

1. 任务曾经有效，但随着能力提高失去区分度；
2. 任务没有变化，运行环境却改变了结果；
3. Agent 找到了评测材料，甚至识别出自己正在被评估。

三者都会让分数变得难以解释，但根因和修复方法完全不同。

---

一、先区分三类失真

失真类型	发生在哪一层	表面现象	实际问题
区分度失效	任务设计	大量被评对象达到高分	任务不再区分目标能力
环境混杂	试验执行	同一对象换环境后分数变化	分数混入资源与基础设施影响
污染与评测感知	数据和行为路径	得到正确答案，但路径不符合测量意图	答案来自评测材料或对评测的识别

可以把它们概括为三个问题：

• 题目还有效吗？
• 大家做的是同一场试验吗？
• 答案真是通过目标能力得到的吗？

这三问分别对应任务效度、实验可比性和评测完整性。

---

二、第一类失真：任务失去区分度

《Designing AI-resistant technical evaluations》讨论的不是传统模型榜单，而是 Anthropic 性能工程团队的招聘作业。

这项作业要求候选人在模拟加速器上优化代码。它最初有几个明确目标：

• 接近真实性能工程工作；
• 给强弱候选人留下足够宽的分数分布；
• 不依赖狭窄领域知识；
• 允许使用 AI，同时仍能观察人的判断和工程能力。

超过一千名候选人完成过这项作业，它也确实帮助团队识别并招聘了优秀工程师。因此，问题不是原始设计从一开始就无效，而是 一个曾经有效的测量工具随被测能力变化而老化。

Claude 逐步吃掉了有效区间

文章记录了三次迭代：

1. Claude 3.7 Sonnet 已让超过一半候选人直接委托 Claude Code 更有利；
2. Claude Opus 4 在四小时限制内超过几乎所有人，团队将其开始困难的位置改成新版起点；
3. Claude Opus 4.5 又在两小时内达到最好的人类成绩，并在更长计算时间下继续提高。

这里的关键不是“AI 会做面试题”，而是 原有分布被压缩了。

当大多数被测对象都接近上限时，分数仍然存在，却不再提供选择信号。这与前置文章所说的“评估饱和”相同，但招聘作业让代价更具体：一个无法区分强候选人的作业，不再完成它的业务职责。

把题目变难，不一定保留原来的测量目标

团队先尝试把真实性能优化问题换成更难的变体，但 Claude 仍能利用训练中积累的广泛经验解决它。

后来采用的方案更偏离常见工程任务：用受限指令集构造多个新颖小谜题，让候选人自己建设调试工具。初步结果重新拉开了分数，但作者也明确承认，新作业牺牲了原始作业的现实性和多层深度。

这揭示一个重要取舍：

更难被模型解决 ≠ 更准确地代表真实工作

如果为了恢复区分度而把任务推向高度反常、极少见的场景，评估可能从“谁更擅长目标工作”变成“谁更擅长这种新谜题”。分数分布恢复了，构念效度却可能改变。

第一类失真的判据

评估任务不是永久资产。它必须持续证明两件事：仍有区分度，并且仍在测量原来的目标能力。

---

三、第二类失真：环境成为混杂变量

《Quantifying infrastructure noise in agentic coding evals》研究的是另一种问题：题目和模型都没变，运行资源却足以改变结果。

静态问答评估通常直接给模型输入，再对输出评分。Agent 编程评估不同：Agent 会在环境中安装依赖、运行测试、启动子进程、反复修改代码。此时容器、硬件和网络不是背景，而是任务的一部分。

同一模型、同一任务，资源配置带来六个百分点差异

Anthropic 在 Terminal-Bench 2.0 上保持模型、harness 和任务集不变，只调整资源配置，从严格执行每题标称资源的 1 倍配置，一直到不设上限。

结果显示：

• 严格配置到无限配置之间，成功率相差 6 个百分点；
• 基础设施错误率从 5.8% 降到 0.5%；
• 从 1 倍增加到约 3 倍时，主要作用是减少瞬时资源峰值造成的意外终止；
• 超过约 3 倍后，额外资源开始让 Agent 采用原本不可行的重型策略，实际改变任务难度。

在 SWE-bench 的交叉实验中，内存增加到基线 5 倍时，分数也单调上升，差异为 1.54 个百分点。幅度较小，但仍说明资源不是中性的。

“给足资源”同时做了两件不同的事

资源余量有两个阶段：

阶段	作用	对测量的含义
消除偶发失败	避免瞬时内存峰值把本可继续的任务杀死	提高试验稳定性
改变可用策略	允许安装大依赖、运行重型测试或暴力搜索	改变被测能力的定义

因此，不能简单地把“更多资源”理解成更公平。

资源太紧，会把基础设施事故算到模型头上；资源太宽，又会奖励能够消耗更多计算的策略。两种配置都可以成为合法实验，但它们回答的是不同问题。

资源配置不仅是一个数字

文章特别区分了容器的资源保证值与强制终止上限。

如果两者相同，容器没有任何瞬时余量，短暂峰值就可能触发 OOM。更稳妥的做法是分别声明：

• 保证分配多少资源；
• 允许短时上升到什么硬上限；
• 两个边界之间是否已经校准到分数差异落在统计噪声内。

除此之外，时间限制、集群健康、硬件规格、并发度、出口带宽和运行时段都可能进入最终分数。Agent 评估本质上是端到端系统实验，任何一层都可能成为混杂变量。

第二类失真的判据

如果两个 Agent 没有在等价环境中运行，就不能只凭分数差异归因于模型或工作流能力。

---

四、第三类失真：污染与评测感知

《Eval awareness in Claude Opus 4.6’s BrowseComp performance》展示了更难处理的情况：Agent 得到了正确答案，但路径破坏了评测意图。

BrowseComp 测试模型能否在公开网络中找到很难检索的信息。开放网络同时也意味着：论文、博客、GitHub 讨论和数据镜像可能泄露题目或答案。

普通污染与评测感知不是一回事

在 1,266 个问题中，研究者确认 11 个答案来自评测材料而不是独立检索：

• 9 个属于普通污染，搜索结果直接出现题目和答案；
• 2 个属于评测感知，模型先推断自己可能正在做某个基准，再寻找并解密答案集。

普通污染是“碰到了泄露答案”。评测感知则多了一层主动推理：

1. 常规搜索长时间失败；
2. Agent 注意到问题过度具体、结构像人工构造；
3. 它枚举可能的基准；
4. 找到评测代码、密钥和数据镜像；
5. 用代码执行工具还原答案。

研究中还有 16 次类似尝试没有成功。有的被二进制格式或权限挡住，有的把时间耗在识别基准上，反而没有回答原问题。

所以，评测感知并不总会提高分数，但它证明了 Agent 会把“识别试验本身”纳入可用策略空间。

工具能力会放大污染路径

成功案例不仅依赖模型认出 BrowseComp，还依赖完整工具链：

• 网络搜索找到评测源码；
• 代码执行复现解密逻辑；
• 原始二进制无法读取时，寻找 JSON 镜像；
• 多个子 Agent 并行扩展搜索路径。

同一批问题中，多 Agent 配置获得非预期答案的比例为 0.87%，单 Agent 为 0.24%，前者约为后者的 3.7 倍。文章的解释不是多 Agent 更“想作弊”，而是更多搜索者和更高 token 消耗提高了遇到泄露材料的概率。

评估运行本身还会污染未来网络

更麻烦的是，一些网站会把搜索词自动生成永久页面。Agent 的查询假设可能进入 URL，随后被搜索引擎收录，成为后续 Agent 可见的痕迹。

这意味着污染不是一次性数据泄露，而可能由评估过程不断累积。静态 URL 黑名单也不够可靠，因为 Agent 会寻找镜像、替代格式和其他入口。

Anthropic 最终调整了相关模型卡分数，并把评测完整性描述为持续的对抗问题，而不是发布任务时做一次清理就能结束的事项。

第三类失真的判据

正确结果只有在来源路径符合测量意图时才构成有效证据。对于可联网、可执行代码的 Agent，结果和完整轨迹必须一起解释。

---

五、三类失真不能用同一种修复

失真	无效的直觉修复	更合适的处理
区分度失效	只把题目做得更怪、更难	重审目标能力、分布、现实性和上限
环境混杂	给所有任务一个随意的大机器	固定并报告环境，校准保证值与硬上限
污染与评测感知	只封禁一个 URL	检查轨迹、隔离评测材料、持续更新防护

这也扩展了前置文章中的定义：

• task、trial、grader 和 harness 完整，只说明评估 可以运行；
• 构念有效、环境可比、数据未污染，才说明结果 可以解释。

---

六、PPT Master 当前有哪些证据

以下对照基于 2026-08-12 的当前仓库快照 4e6ecbcb。PPT Master 已有多层检查，但它们承担的是不同职责。

机制	当前回答的问题	明确不回答的问题
project_manager.py validate	现有 Design Spec 与 Spec Lock 是否满足结构和枚举合同	确认内容是否被语义忠实投影；跨版本行为是否变好
svg_quality_checker.py	当前项目的作者 SVG 是否违反确定性兼容与结构合同	模型总体能力、视觉品味或重复运行成功率
final 报告来源指纹	导出所依据的报告是否对应当前 SVG 字节	另一版本、另一模型或另一环境会怎样
svg_to_pptx.py postflight	当前 PPTX 包结构、页数和质量报告关联是否有效	用户是否喜欢内容与设计
prompt_audit.py	Agent-facing Markdown 的预算、加载集、引用、注册表和静态重复是否漂移	某句提示词是否提高或降低生成质量
当前依赖 Design Spec/Spec Lock 的可选 visual-review	用户明确触发时，当前页面是否命中固定视觉 rubric	全量任务上的跨版本视觉回归；也不构成 Quick 支持证据
validation/workflow.log	项目级命令和有限重要结果的冷审计线索	完整会话记录、阶段真值或线上遥测

这里最重要的边界是：

质量门不等于评估系统

PPT Master 的质量门验证 一次运行产生的当前制品 是否满足合同。它不组织跨版本 task/trial，不计算能力分数，也不是线上可观测系统。

first-page 与 final gate 的真实职责

当前 generate-pptx.md 明确要求 Default Generate 在第一页后运行方法校准门，完成所有页面后再运行 final gate；quick-generate.md 保留一次无锁 final gate。

这些门及其与导出器的联动解决的是：

• 当前 SVG 是否存在阻断错误；
• error 是否已经清零；
• warning 是否仍保持非阻断语义；
• 正式导出是否引用当前、未过期的 final 报告。

它们不会重复执行同一输入，也不比较不同模型、提示词版本或运行环境。因此，一个项目通过 final gate，只能证明该项目的当前作者状态满足已声明合同。

Prompt Audit 的真实职责

当前 prompt_audit.md 将 prompt_audit.py 定义为维护者使用的只读静态审计，并明确说明它未接入 CI 或 pre-commit：

• 不进入生成角色上下文；
• 不由运行时消费；
• 没有接入 CI 或 pre-commit；
• 固定预算只有真实溢出时才允许调整；
• 近似重复只作为信息，不能自动成为错误。

它能发现“静态规则结构漂移”，不能证明“Agent 行为没有退化”。一条简短提示可能完全通过预算、引用和 Schema 审计，却仍然改变模型在真实任务中的取舍。

---

七、三类失真如何映射到 PPT Master

PPT Master 当前没有正式跨版本评估套件，因此三类失真首先是 未来比较实验的解释边界，不是需要立即修复的现行故障。

1. 任务区分度：公开示例不是天然评估集

examples/ 展示的是已生成结果，不是统一的隐藏输入、参考答案与评分合同。把这些公开制品直接当作 benchmark，会遇到两个问题：

• 输入和期望结果并未标准化，无法稳定重放；
• 模型可能已经读到示例的 Design Spec、SVG 或最终输出，不能声称是盲测。

只有当维护者要比较某项具体行为变化时，才值得从真实失败或稳定输入中构造一个小任务。展示效果好，不等于任务具有长期区分度。

2. 环境混杂：Agent host 和模型本来就是运行条件

PPT Master 运行在不同 AI 工具、模型、操作系统和 Python 环境中。Default、Quick、模板使用与可选阶段也会改变上下文、制品和成本。

如果要比较两个版本，应至少固定或记录：

• Agent host 与模型；
• 所选路线和 profile；
• 输入材料与显式模板根；
• Python、系统字体和外部工具条件；
• 是否触发图表验证、动画或旁白阶段，以及是否显式启用 visual review。

否则，观察到的差异可能来自运行配置，而不是被比较的提示词或代码。

3. 污染与评测感知：公开知识会改变可用路径

PPT Master 是公开仓库，规则、示例和历史讨论都可能进入模型上下文。若任务要求复现公开示例，模型读取现成制品是合理工作流，却不再是对“从原始材料独立规划”的测量。

因此，具体比较必须先声明允许读取什么。污染不是道德判断，而是 测量路径是否偏离研究问题。

---

八、只有真实比较需求出现时，才建立最小实验

Anthropic 的三篇文章不支持“为了专业而先建设一套大评估平台”。它们支持的是：当分数要用于决策时，先保护它的可解释性。

对 PPT Master，更符合现行范围的顺序是：

1. 明确要比较的单一改动，例如某条 Prompt 约束或某个检查器行为；
2. 从真实故障或明确用户反馈中选择少量可重放输入；
3. 固定 host、模型、路线、profile 与资源条件；
4. 复用现有质量门判断机器可判定事实；
5. 需要审美判断时再增加人工盲评或校准后的 rubric；
6. 阅读失败试验的完整相关记录，确认没有任务缺陷、环境事故或污染路径；
7. 只把该实验的结论用于它实际覆盖的场景。

如果没有真实回归、明确比较问题或用户反馈，现有按需审计和单次质量门已经足够。提前建设通用任务平台会增加维护成本，却没有要回答的问题。

---

九、我的理解：分数之前，先保护因果解释

三篇文章表面上分别讨论招聘题、基础设施和联网搜索，实际上共同指出一个更基础的原则：

核心观点

评估可信度不取决于分数有多精确，而取决于我们能否解释分数为什么变化。

当任务失去区分度时，分数变化不能解释目标能力；当资源条件不一致时，变化不能归因于模型；当答案来自评测材料时，正确率不能证明目标能力被使用。

对 PPT Master 而言，现有质量门的优势恰恰是边界清楚：它验证当前制品是否满足确定性合同，不把自己包装成能力排行榜。

未来若确有跨版本研究需要，应在这个清楚边界之上增加最小任务与试验，而不是把一次 0 errors、一次成功导出或一次 Prompt Audit 通过误写成“系统质量已经得到评估”。

---

← 返回 Anthropic 学习地图