跳到正文
北京时间
原文
Anthropic:Newsroom·· 2026-01-21精选AI 评分77

Anthropic 性能工程团队分享如何设计抗 AI 的技术笔试题

Designing AI-resistant technical evaluations

AI 导读

Anthropic 性能工程团队撰文介绍其模拟加速器优化笔试题如何被 Claude Opus 4 和 Opus 4.5 相继击败,并迭代出三版抗 AI 的新笔试题。

推荐理由

作者亲历三代笔试题被 Claude 模型逐个攻破,并给出抗 AI 评测的设计思路与可试玩的开放挑战成绩基线。

正文 · AI 翻译

随着 AI 能力的提升,评估技术候选人变得越来越困难。一份今天能很好区分人类技能水平的 take-home 测试,明天可能就会被模型轻松解决——从而使其在评估中失去作用。

自 2024 年初以来,我们的性能工程团队一直使用一份 take-home 测试,要求候选人为一个模拟加速器优化代码。已有超过 1,000 名候选人完成了该测试,其中数十人现在在这里工作,包括那些搭建起我们 Trainium 集群、并交付了自 Claude 3 Opus 以来每一个模型的工程师。

但每一个新的 Claude 模型都迫使我们重新设计测试。在相同时间限制下,Claude Opus 4 的表现超过了大多数人类申请者。这仍让我们能够区分最强的候选人——但随后 Claude Opus 4.5 连那些人也追平了。在时间不受限时,人类仍能胜过模型,但在 take-home 测试的约束下,我们已无法区分顶尖候选人的产出与我们最强模型的产出。

到目前为止,我已经迭代了三个版本的 take-home 测试,试图确保它仍能承载信号。每一次,我都对什么能让评估对 AI 辅助保持稳健、什么不能,有了新的认识。

本文介绍了最初的 take-home 设计、每个 Claude 模型如何将其攻破,以及为确保我们的测试始终领先于我们最强模型的能力,我不得不采取的越来越不寻常的方法。尽管我们所做的工作随着模型一同演进,我们仍然需要更多优秀的工程师——只是需要越来越有创意的方式来找到他们。

为此,我们将最初的 take-home 作为公开挑战发布,因为在时间不受限时,最佳的人类表现仍然超过 Claude 所能达到的水平。如果你能胜过 Opus 4.5,我们很乐意收到你的消息——详情见本文末尾。

take-home 的起源

2023 年 11 月,我们正准备训练和发布 Claude Opus 3。我们已获得新的 TPU 和 GPU 集群,我们的大型 Trainium 集群也即将到位,我们在加速器上的投入远超以往,但我们的性能工程师数量不足以支撑新的规模。我在 Twitter 上发帖请人们给我们发邮件,这带来的有希望的候选人超出了我们通过标准面试流程所能评估的数量,而该流程会消耗员工和候选人大量的时间

我们需要一种更高效地评估候选人的方式。于是,我花了两周时间设计了一份 take-home 测试,它能够充分体现该岗位的要求,并识别出最有能力的申请者。

设计目标

take-home 测试名声不佳。通常它们充斥着工程师觉得无聊的通用问题,筛选效果也很差。我的目标不同:创造一些真正有吸引力的东西,让候选人乐于参与,并让我们能够以高分辨率捕捉他们的技术能力。

对于评估性能工程技能,这种形式相比现场面试也有优势:

更长的时间跨度:工程师在写代码时很少面对少于一小时的截止时间。4 小时的窗口(后来缩短为 2 小时)更好地反映了工作的实际性质。它仍比大多数真实任务短,但我们需要在这一点与其繁重程度之间取得平衡。

真实的环境:没有人在旁观看或期待你讲解。候选人在自己的编辑器中不受干扰地工作。

理解与工具构建的时间:性能优化需要理解现有系统,有时还需要构建调试工具。这两点在正常的 50 分钟面试中都很难被真实评估。

与 AI 辅助的兼容性:Anthropic 的通用候选人指南要求候选人在没有特别说明的情况下不使用 AI 完成 take-home。对于这个 take-home,我们明确说明可以使用 AI。

更长周期的问题更难被 AI 完全解决,因此候选人可以使用 AI 工具(就像他们在工作中会做的那样),同时仍然需要展示自己的能力。

除了这些针对形式的目标之外,我在设计这个 take-home 时也应用了设计任何面试时使用的相同原则:

代表真实工作:问题应该让候选人体验这份工作实际涉及的内容。

高信号:take-home 应避免依赖单一洞察的问题,并确保候选人有多次机会展示自己的全部能力——尽可能减少偶然性。它还应该有较宽的评分分布,并确保足够的深度,即使是很强的候选人也不会完成所有内容。

不要求特定领域知识:基础扎实的人可以在工作中学习具体细节。要求狭窄的专业知识会不必要地限制候选人池。

有趣:快速的开发循环、有深度的有趣问题,以及发挥创造力的空间。

模拟机器

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

这台机器包含一些让加速器优化变得有趣的功能:手动管理的暂存器内存(与 CPU 不同,加速器通常需要显式内存管理)、VLIW(多个执行单元每个周期并行运行,需要高效的指令打包)、SIMD(每条指令对多个元素进行向量操作)以及多核(将工作分配到多个核心)。

任务是并行树遍历,刻意不带有深度学习色彩,因为大多数性能工程师当时还没有做过深度学习,可以在工作中学习领域细节。这个问题受到无分支 SIMD 决策树推理的启发,这是一个经典的 ML 优化挑战,作为对过去的致敬,只有少数候选人以前遇到过。

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

早期结果

最初的 take-home 效果很好。来自 Twitter 批次的一位候选人得分远高于其他人。他在二月初开始,比我们通过标准流程招聘的第一批人晚了两周。测试证明具有预测性:他立即开始优化内核,并找到了一个启动阻塞编译器 bug 的解决方法,该 bug 涉及张量索引数学溢出 32 位。

在接下来的一年半里,大约有1000名候选人完成了这项带回家作业,它帮助我们招聘到了目前性能工程团队的大部分成员。事实证明,它对纸面经验有限的候选人尤其有价值:我们有几位表现最出色的工程师直接来自本科,但他们在带回家作业中展现出的技能足以让我们放心录用。

反馈是正面的。许多候选人超出了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小时是基于候选人反馈,他们更希望降低因在某个 bug 或困惑上卡住一段时间而陷入困境的风险,但排期开销导致我们的流程出现数周延迟。两小时更容易安排进一个周末。

版本2强调巧妙的优化洞见,而非调试和代码量。它为我们服务得很好——持续了几个月。

然后 Claude Opus 4.5 击败了它

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

然后它停了下来,确信自己遇到了无法逾越的内存带宽瓶颈。大多数人类也会得出同样的结论。但有一些巧妙的技巧可以利用问题结构来绕过那个瓶颈。当我告诉 Claude 可能达到的周期数时,它思考了一会儿并找到了技巧。随后它进行调试、调优并实现了进一步的优化。到2小时节点时,它的得分与人类在该时限内的最佳表现相当——而那个人类大量使用了 Claude 4 并加以引导。

我们在内部的测试时计算框架中进行了试验以求更严谨,并确认它既能在2小时内击败人类,又能随时间继续攀升。发布后我们甚至以通用方式改进了框架,并获得了更高的分数。

我遇到了一个问题。我们即将发布一个模型,而在我们的 take-home 测试中,最佳策略将是委托给 Claude Code。

考虑各种选项

一些同事建议禁止使用 AI 辅助。我不想这么做。除了执行上的困难之外,我还有一种感觉:既然人在我们的工作中仍然扮演着至关重要的角色,我就应该能够找到某种方式,让他们在有 AI 的环境中脱颖而出——就像他们在工作中会遇到的那样。我还不想就此屈服于那种想法,即人类只在耗时超过几小时的任务上才有优势。

其他人建议把门槛提高到“显著超越 Claude Code 单独所能达到的水平”。这里的顾虑在于 Claude 工作得很快。人类通常要花两个小时中的一半时间来阅读和理解问题,然后才开始优化。一个试图引导 Claude 的人很可能始终落后,只能在事后才理解 Claude 做了什么。主导策略可能会变成坐在一旁观看。

如今,Anthropic 的性能工程师仍然有很多工作要做,但工作内容更像是艰难的调试、系统设计、性能分析、弄清楚如何验证我们系统的正确性,以及弄清楚如何让 Claude 的代码更简单、更优雅。不幸的是,如果没有大量时间或共同的背景,这些事很难用客观的方式测试。设计能代表实际工作的面试一直很难,但现在比以往任何时候都更难。

但我也担心,如果我投入精力设计一个新的 take-home,要么 Claude Opus 4.5 也能解决它,要么它会变得太难,人类无法在两小时内完成。

尝试 1:一个不同的优化问题

我意识到 Claude 可以帮我快速实现我设计的任何东西,这促使我尝试开发一个更难的 take-home。我选择了一个基于我在 Anthropic 做过的一个较棘手的内核优化的问题:在 2D TPU 寄存器上进行高效的数据转置,同时避免存储体冲突。我把它提炼成一个在模拟机器上的更简单的问题,并让 Claude 在不到一天的时间里实现了这些改动。

Claude Opus 4.5 找到了一个我甚至没想到的绝佳优化。通过仔细分析,它意识到可以转置整个计算,而不是去想办法转置数据,并相应地重写了整个程序。

在我的真实案例中,这行不通,所以我修改了问题以移除那种方法。Claude 随后取得了进展,但找不到最高效的解决方案。看起来我有了我的新问题,现在只需希望人类候选人能足够快地解决它。但我有些挥之不去的疑虑,于是我用 Claude Code 的“ultrathink”功能以更长的思考预算进行了复核……结果它解决了。它甚至知道修复存储体冲突的技巧。

事后看来,这不是一个适合尝试的问题。许多平台上的工程师都在数据转置和存储体冲突上挣扎过,所以 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 的带回家作业。我们很好奇它能坚持多久。

来源:Anthropic:Newsroom · anthropic.com