设计抗 AI 的技术评估 | Anthropic

来源: https://www.anthropic.com/engineering/AI-resistant-technical-evaluations 抓取时间: 2026-07-21 16:25:56

作者：Tristan Hume，Anthropic 性能优化团队负责人。Tristan 设计（并重新设计）了帮助 Anthropic 聘用数十名性能工程师的带回家测试。

随着 AI 能力的提升，评估技术候选人变得越来越困难。今天能够很好地区分人类技能水平的带回家测试，明天可能被模型轻松解决——使其对评估毫无用处。

自 2024 年初以来，我们的性能工程团队使用了一个带回家测试，让候选人针对模拟加速器优化代码。超过 1,000 名候选人完成了它，现在有几十人在这里工作，包括构建我们的 Trainium 集群并交付了 Claude 3 Opus 以来每一个模型的工程师。

但是每个新的 Claude 模型都迫使我们重新设计测试。在相同的时间限制下，Claude Opus 4 的表现超过了大多数人类申请者。这仍然允许我们区分最强的候选人——但随后 Claude Opus 4.5 甚至与那些最强的候选人表现相当。在无限时间的情况下，人类仍然可以胜过模型，但在带回家测试的约束下，我们不再有办法区分我们顶尖候选人的输出和我们最强大模型的输出。

我现在已经迭代了三个版本的带回家测试，试图确保它仍然有信号。每次，我都学到了一些新的东西，关于什么使评估对 AI 辅助具有鲁棒性，什么不具有。

这篇文章描述了最初的带回家测试设计，每个 Claude 模型是如何击败它的，以及我不得不采取越来越不寻常的方法来确保我们的测试保持领先于我们顶级模型的能力。虽然我们所做的工作随着我们的模型一起发展，但我们仍然需要更多强大的工程师——只是需要越来越有创意的方法来找到他们。

为此，我们正在发布原始的带回家测试作为开放挑战，因为在无限时间内，最佳的人类表现仍然超过 Claude 能达到的水平。如果你能胜过 Opus 4.5，我们很乐意听取你的意见——详情见本文末尾。

带回家测试的起源

2023 年 11 月，我们正准备训练并发布 Claude Opus 3。我们已经获得了新的 TPU 和 GPU 集群，我们的大型 Trainium 集群也即将到来，我们在加速器上的支出比过去多得多，但我们没有足够的性能工程师来应对我们的新规模。我在 Twitter 上发帖请人们给我们发邮件，这带来了比我们通过标准面试流程能评估的更多有希望的候选人——这个过程占用了员工和候选人大量的时间。

我们需要一种更有效地评估候选人的方法。所以，我花了两周时间设计了一个带回家测试，能够充分捕捉该职位的要求并识别最有能力的申请者。

设计目标

带回家测试的名声不好。通常它们充满了通用问题，工程师觉得很无聊，而且作为过滤器效果很差。我的目标不同：创造一些真正吸引人的东西，让候选人兴奋地参与，并让我们能够在高分辨率下捕捉他们的技术技能。

这种格式在评估性能工程技能方面也比实时面试有优势：

更长的时间范围： 工程师在编码时很少面临不到一小时的截止日期。4 小时的时间窗口（后来减少到 2 小时）更好地反映了工作的实际性质。它仍然比大多数真实任务短，但我们需要在繁重程度上取得平衡。

现实的环境： 没有人观看或期望叙述。候选人在自己的编辑器中工作，没有分心。

理解和工具的时间： 性能优化需要理解现有系统，有时需要构建调试工具。这两者在正常的 50 分钟面试中都很难现实地评估。

与 AI 辅助的兼容性： Anthropic 的一般候选人指南要求候选人在没有 AI 的情况下完成带回家测试，除非另有说明。对于这个带回家测试，我们明确指出否则。

更长时间范围的问题更难让 AI 完全解决，所以候选人可以使用 AI 工具（就像他们在工作中那样），同时仍然需要展示自己的技能。

除了这些格式特定的目标外，我还应用了与设计任何面试相同的原则来制作带回家测试：

代表真实工作： 问题应该让候选人体验实际工作的内容。

高信号： 带回家测试应该避免依赖单一洞察的问题，并确保候选人有很多机会展示他们的全部能力——尽可能少地留给运气。它还应该有广泛的评分分布，并确保足够的深度，即使是强大的候选人也不会完成所有事情。

不需要特定的领域知识： 具有良好基础知识的人可以在工作中学习具体内容。要求狭窄的专业知识不必要地限制了候选人池。

有趣： 快速的开发循环，有趣的深度问题，以及创造力的空间。

模拟机器

我用 Python 为一个具有类似 TPU 特征的虚构加速器构建了一个模拟器。候选人优化在这台机器上运行的代码，使用一个热重载的 Perfetto 跟踪来显示每条指令，类似于我们在 Trainium 上拥有的工具。

这台机器包含使加速器优化变得有趣的功能：手动管理的暂存器内存（与 CPU 不同，加速器通常需要显式内存管理）、VLIW（每个周期多个执行单元并行运行，需要高效的指令打包）、SIMD（每条指令对多个元素进行向量操作）和多核（跨核心分配工作）。

任务是并行树遍历，故意没有深度学习风格，因为大多数性能工程师还没有从事过深度学习工作，并且可以在工作中学习领域细节。这个问题的灵感来自于无分支 SIMD 决策树推理——这是一个经典的 ML 优化挑战，作为对过去的致敬，只有少数候选人之前遇到过。

候选人从完全串行的实现开始，逐步利用机器的并行性。热身是多核并行，然后候选人选择是解决 SIMD 向量化还是 VLIW 指令打包。原始版本还包含一个候选人需要首先调试的错误，锻炼他们构建工具的能力。

早期结果

最初的带回家测试效果很好。来自 Twitter 批次的一个人的得分比其他人都高得多。他在 2 月初开始工作，比我们通过标准管道的第一批雇员晚两周。测试证明是具有预测性的：他立即开始优化内核，并找到了一个涉及张量索引数学溢出 32 位的阻塞发布编译器错误的解决方法。

在接下来的一年半里，大约有 1,000 名候选人完成了带回家测试，它帮助我们聘用了我们当前性能工程团队的大多数成员。它对于纸面经验有限的候选人特别有价值：我们的几位最高绩效工程师直接来自本科，但在带回家测试中展示了足够的技能，让我们有信心聘用他们。

反馈是积极的。许多候选人工作超过了 4 小时的限制，因为他们很享受。最强的无限时间提交包括完整的优化小型编译器和几个我没有预料到的巧妙优化。

然后 Claude Opus 4 击败了它

到 2025 年 5 月，Claude 3.7 Sonnet 已经悄悄发展到这样的程度：超过 50% 的候选人如果完全委托给 Claude Code 会更好。然后我在带回家测试上测试了 Claude Opus 4 的预发布版本。它在 4 小时内提出了比几乎所有人类都更优化的解决方案。

这不是我第一次被 Claude 模型击败的面试。我在 2023 年设计了一个实时面试问题，特别是因为我们当时的问题基于早期 Claude 模型有很多知识的常见任务，因此可以轻松解决。我试图设计一个需要更多问题解决技能而不是知识的问题，仍然基于我在工作中解决过的真实（但小众）问题。Claude 3 Opus 击败了该问题的第 1 部分；Claude 3.5 Sonnet 击败了第 2 部分。我们仍然使用它，因为我们的其他实时问题也不抗 AI。

对于带回家测试，有一个直接的修复方法。这个问题的深度远远超过任何人在 4 小时内可以探索的范围，所以我使用 Claude Opus 4 来确定它开始挣扎的地方。这成为版本 2 的新起点。我编写了更干净的起始代码，添加了新的机器功能以增加深度，并移除了多核（Claude 已经解决了这个问题，而且它只会减慢开发循环而不增加信号）。

我还将时间限制从 4 小时缩短到 2 小时。我最初选择 4 小时是基于候选人的反馈，他们更喜欢如果在错误或困惑上卡了一会儿的话风险更小，但调度开销导致我们的管道延迟了数周。两小时更容易适应周末。

版本 2 强调巧妙的优化洞察，而不是调试和代码量。它很好地服务了我们——持续了几个月。

然后 Claude Opus 4.5 击败了那个版本

当我测试预发布的 Claude Opus 4.5 检查点时，我看着 Claude Code 在问题上工作了 2 小时，逐渐改进它的解决方案。它解决了最初的瓶颈，实现了所有常见的微优化，并在不到一小时的时间内达到了我们的通过阈值。

然后它停了下来，确信它遇到了无法克服的内存带宽瓶颈。大多数人类得出了相同的结论。但是有一些巧妙的技巧可以利用问题结构来规避该瓶颈。当我告诉 Claude 它可以达到的周期数时，它想了一会儿并找到了这个技巧。然后它进行调试、调优并实施进一步的优化。到 2 小时的时候，它的分数与该时间限制内的最佳人类表现相当——而那个人类在指导下大量使用了 Claude 4。

我们在内部测试时间计算套件中进行了更严格的测试，并确认它既可以在 2 小时内击败人类，也可以随着时间继续提升。发布后，我们甚至以通用方式改进了我们的套件，并获得了更高的分数。

我遇到了一个问题。我们即将发布一个模型，在这个模型上，我们带回家测试的最佳策略将是委托给 Claude Code。

考虑选项

一些同事建议禁止 AI 辅助。我不想这样做。除了执行挑战外，我有一种感觉，鉴于人们在我们的工作中继续发挥至关重要的作用，我应该能够想出一些方法让他们在有 AI 的环境中脱颖而出——就像他们在工作中那样。我还不想接受这样的观点：人类只在超过几小时的任务上有优势。

其他人建议将门槛提高到"大幅超过 Claude Code 单独达到的水平"。这里的担忧是 Claude 工作得很快。人类通常在开始优化之前花一半的 2 小时阅读和理解问题。一个试图指导 Claude 的人类可能会一直落后，只是在事后才理解 Claude 做了什么。主导策略可能变成坐视不管。

如今，Anthropic 的性能工程师仍然有很多工作要做，但它看起来更像是困难的调试、系统设计、性能分析、弄清楚如何验证我们系统的正确性，以及弄清楚如何使 Claude 的代码更简单、更优雅。不幸的是，这些事情很难在没有大量时间或共同背景的情况下以客观的方式进行测试。设计代表工作的面试一直很难，但现在比以往任何时候都更难。

但我也担心，如果我投资设计一个新的带回家测试，要么 Claude Opus 4.5 也会解决它，要么它会变得如此具有挑战性，以至于人类不可能在两小时内完成。

尝试 1：不同的优化问题

我意识到 Claude 可以帮助我快速实施我设计的任何东西，这激励我尝试开发一个更难的带回家测试。我选择了一个基于我在 Anthropic 做过的一个更棘手的内核优化的问题：在 2D TPU 寄存器上进行高效数据转置，同时避免存储体冲突。我将其提炼成一个在模拟机器上的更简单的问题，并让 Claude 在不到一天的时间内实现更改。

Claude Opus 4.5 找到了一个我甚至没有想到的很棒的优化。通过仔细分析，它意识到它可以转置整个计算，而不是弄清楚如何转置数据，并且它相应地重写了整个程序。

在我的真实案例中，这行不通，所以我修补了问题以移除该方法。Claude 随后取得了进展，但无法找到最有效的解决方案。看起来我找到了我的新问题，现在我只希望人类候选人能足够快地解决它。但我有一些挥之不去的疑虑，所以我使用 Claude Code 的"超思考"功能进行了双重检查，使用更长的思考预算……然后它解决了。它甚至知道修复存储体冲突的技巧。

事后看来，这不是正确的尝试问题。许多平台的工程师都在数据转置和存储体冲突上挣扎过，所以 Claude 有大量的训练数据可以借鉴。虽然我是从第一原理中找到我的解决方案的，但 Claude 可以利用更大的经验工具箱。

尝试 2：走向更奇特

我需要一个人类推理可以胜过 Claude 更丰富经验基础的问题：一些足够脱离分布的东西。不幸的是，这与我的目标——即看起来像真实工作——相冲突。

我想到了我喜欢的最不寻常的优化问题，最后想到了 Zachtronics 游戏。这些编程益智游戏使用不寻常的、高度受限的指令集，迫使你以非常规的方式编程。例如，在 Shenzhen I/O 中，程序被拆分到多个通信芯片上，每个芯片只能容纳约 10 条指令，带有一个或两个状态寄存器。巧妙的优化通常涉及将状态编码到指令指针或分支标志中。

我设计了一个新的带回家测试，由使用微小的、受到严格限制的指令集的谜题组成，以最小指令数为目标优化解决方案。我实现了一个中等难度的谜题，并在 Claude Opus 4.5 上测试了它。它失败了。我补充了更多的谜题，并让同事们验证不像我那么深入了解问题的人仍然可以胜过 Claude。

与 Zachtronics 游戏不同，我有意不提供可视化或调试工具。起始代码只检查解决方案是否有效。构建调试工具是测试内容的一部分：你可以插入精心设计的打印语句，或者让编码模型在几分钟内生成交互式调试器。关于如何投资工具的判断是信号的一部分。

我对新的带回家测试相当满意。它的方差可能比原始的更低，因为它包含更多独立的子问题。早期结果很有希望：分数与候选人过去工作的水平相关性很好，我最有能力的同事之一的得分高于迄今为止任何候选人。

我仍然为放弃原始的真实性和多样深度而感到难过。但真实性可能是我们不再拥有的奢侈品。最初的版本之所以有效，是因为它类似于真实工作。替代版本之所以有效，是因为它模拟了新颖的工作。

开放挑战

我们正在发布原始的带回家测试，供任何人在无限时间内尝试。人类专家保持优势超过当前模型在足够长的时间范围内的能力。提交的最快人类解决方案大大超过了 Claude 即使使用大量测试时间计算也能达到的水平。

发布的版本从零开始（如版本 1），但使用版本 2 的指令集和单核设计，因此周期计数与版本 2 相当。

性能基准（以模拟机器的时钟周期衡量）：

• 2164 周期：Claude Opus 4 在测试时间计算套件中运行数小时后
• 1790 周期：Claude Opus 4.5 在随意的 Claude Code 会话中，大约与 2 小时内的最佳人类表现相当
• 1579 周期：Claude Opus 4.5 在测试时间计算套件中运行 2 小时后
• 1548 周期：Claude Sonnet 4.5 在测试时间计算超过 2 小时后
• 1487 周期：Claude Opus 4.5 在套件中运行 11.5 小时后
• 1363 周期：Claude Opus 4.5 在改进的测试时间计算套件中运行数小时后

在 GitHub 上下载它。如果你优化到低于 1487 个周期，击败 Claude 在发布时的最佳性能，请给我们发送电子邮件至 performance-recruiting@anthropic.com，附上你的代码和简历。

或者你可以通过我们的典型流程申请，该流程使用我们（现在）抗 Claude 的带回家测试。我们很好奇它能持续多久。