Why Traditional Benchmarks Fail Modern AI Models with OpenAI Research Scientist Noam Brown

用 GBT three 时，你没法扩展 test time compute（测试时计算）。比如说，如果你给它一个 $10,000,000 的预算，然后说，好吧，我们来看看 GBT three 能做什么。它其实也做不了太多。那些脆弱的 framework（框架）和 responsible scaling（负责任扩展）政策，并没有真正把 test time compute 的规模考虑进去。

它们只是说，好吧，那这个 model（模型）的 capability（能力）是什么？问题在于，我们现在所处的世界里，model 的 capability 基本上取决于你往里面投了多少钱。如果你给它 $10,000 的预算，它能做的事会比只有 $10 预算时多得多。给它 $10,000,000 的预算，它还能做得更多。那么，你究竟应该在什么预算水平上评估这些 model 呢？

现有的政策其实并没有真正回答这个问题。

大家好，听众朋友们。我是 Sarah Gore，欢迎回到 No Priors。今天和我一起的是 Noam Brown，他是 AI reasoning（AI 推理）领域的奠基者之一。我们聊到了 evaluation（评估）体系如今的失灵状态、超大规模的 test time compute、他如何看待 recursive self improvement（递归式自我改进），以及 frontier（前沿）竞争的下一阶段会是什么。欢迎你。

Noam，我真的特别高兴你能再次来节目。

很高兴再次回来。是的。

你是我们的第一位嘉宾。考虑到 inference time scaling（推理时扩展）如今对整个行业已经变得多么重要，我对自己为这个播客挑选朋友和研究者的眼光感到非常自豪。你也应该为此感到自豪，毕竟你确实开创了

它。算是参与其中了，对，和很多其他人一起。

你刚写了这篇文章，关于大规模 test-time compute（测试时算力）以及为什么行业并没有像应有的那样稳健地评估这些模型，引发了很多共鸣。写这篇文章的动机是什么？

对。动机是我们发布了 5.5，而最初的反应有点怀疑，觉得它并没有实质性地变得更好。公平地说，这种怀疑只持续了几个小时，后来大家有时间自己上手玩一玩、试一试，就发现它实际上确实好了很多。但我觉得，很多怀疑都来自当时发布的 benchmark grid（基准测试表）。基本上，每当有新模型发布时，都会有这么一张 benchmark grid：x 轴列出各种不同的 benchmark（基准测试），y 轴展示不同模型的表现，这样你就可以直接比较不同模型。

它本质上就是“一个模型在一个 benchmark 上的一个单一分数”。如果你从纸面上看，比如 five point five 和 five point four，或者和其他模型之间的差别，确实是有提升，但并不是那种特别巨大的提升。在一些 benchmark 上也就只高了几个百分点。所以人们看了之后，会怀疑它是否真的更好。但一旦他们亲自上手体验，结论就变了。

我认为它在 benchmark 上没有显得好那么多，原因在于 benchmark results（基准测试结果）的呈现方式是错的。它们没有控制每一道 benchmark 题目所使用的 test-time compute（测试时算力）数量。结果发现，5.5 只是“思考”效率高得多。如果你把设置拉到最大，5.4 实际上会思考更久，返回响应的时间也比 5.5 更长。

一旦你控制住思考时间的长短，其实就会发现，5.5 相比 5.4 是一次相当大的跃升。我觉得，这也符合大家日常使用它时的体验。然后当我把这点告诉别人时，典型的反应通常是：好吧，那为什么不让 5.5 也像 5.4 一样思考那么久？而问题在于：那它们到底应该思考多久？

我通常得到的回答是，那就一直到性能进入 plateau（平台期）为止，对吧？也就是说，benchmark 上的表现总会在某个点趋于平稳，那你就评估到那个点。问题是，如今这个进入 plateau 的点其实已经非常靠后了。我的意思是，如果放在 2022 年的 g p d three 那个时代，模型其实还不能持续进行那么长时间的有效思考，所以你确实可以直接让它跑到 plateau 为止。

那个点并不算太远。但我们今天在现代模型上看到的是，5.5 和其他模型如果给它们设计合理的 scaffold（脚手架式提示/流程），甚至可以连续思考几周，在某些 benchmark 上性能才会进入 plateau。所以，它们达到 plateau 的那个点，已经远到无法被合理地测试了。

现在，我们实际上都需要从 token 的角度引入某种 patience limit（耐心上限）或者 budget limit（预算上限），而这在几年前还不是个问题。

没错。所以我认为——我的主张是——现在评估这些模型的正确方式，是你要么给 benchmark 设定某种预算，无论是 tokens、成本、时间还是什么；要么把性能画成一个函数，横轴是投入到模型中的 test-time compute（测试时计算）量。这样一来，比较这些不同模型之间的性能就会清楚得多。

考虑到模型评估周期，以及这样一个事实：对许多任务来说，性能在相当长一段时间内都不会渐近到上限，那么你怎么处理这个问题？也就是说，你想运行的一些 eval（评测）已经超出了在当前模型发布周期下合理的预算或时间范围。

我的意思是，我觉得像 cyber 这类事情上，我们已经看到——实际上 AISI 在他们的评估中也表明——这些模型在 100,000,000 tokens 的规模上仍在持续提升。也就是说，如果你让它们跑到 100,000,000 tokens，甚至超过那个点之后，它们仍然在进步。嗯。而且这可能需要很长时间才能跑完。但你也会看到，性能提升并不只是那种突发性的、不连续的跳跃。

实际上，你可以看到在这 100,000,000 tokens 过程中的提升斜率。所以你大概可以先在某个预算上限内做评估，然后再说，好吧，这就是我们预测的性能表现会是什么样。我认为目前这方面还没有很多研究。实际上，我觉得如果有学者正在寻找研究题目，这会是一篇很值得发表的论文。

你能否预测，在 inference budget（推理预算）比如说 $10,000 的情况下，性能会是什么样子，而你手头只使用了不超过 10、100，或者 10 到 $100 的 inference budget 数据？

那我换个相对正交的问题问你。你是否认为，用户在使用模型解决问题时，系统性地没有让模型“思考”足够久？

你说的“没有思考足够久”是什么意思？

如果你可以构建一个 agent，或者控制所使用的 test-time compute 量，那么这里既有模型自身在做的部分，也有用户可以做的部分。你觉得，行业现在对 test-time compute 的使用量是最优的、严重偏少的，还是说问题出在模型本身——它们只是需要能够更快地完成这种思考？

我觉得这取决于具体问题。我觉得那种想法——模型你就让它思考一周之类的，然后它再回复——听起来不错，而且，是的，benchmark（基准测试）上的结果看起来很亮眼，但在实际工作中并不太实用，因为比如说，你问模型一个问题，然后你就得坐在那里等一周，等它回来答复你。嗯。我觉得人们发现最有效的方式，还是和模型进行快速迭代。

所以我觉得思考时间需要是灵活的。什么时候适合快速回复用户，它就应该快速回复；而当适合长时间思考，并且用户也希望它长时间思考时，那长时间思考就是合理的。我觉得考虑到当下人们要处理的现实约束，他们基本上已经找到了合适的平衡。

你会怎么描述现在的 benchmark（基准测试）格局？现在大家谈很多 benchmark maxing（把基准分数刷到极致）以及在不同 benchmark 上提分的能力。那你会如何概括当下的 benchmark 生态？另外，你有没有一些自己偏爱的 benchmark，觉得它们比其他 benchmark 更能反映真实能力？

所谓 benchmark maxing 这件事，也是促使我去写那篇文章的原因之一。我认为，要展示“你在 benchmark 上比之前的 benchmark 结果，或者比之前的模型做得好很多”，其实是很容易的。举个例子，你只要把一堆模型用 scaffold（脚手架式组合）方式串在一起就行。比如你说，好，我们不只是把这个模型跑一次，而是跑五次，然后从五个回答里选最好的一个，或者让一个 judge（裁判模型）来判断哪个最好，那你就能拿到比这个模型本身高得多的分数。所以，做出一个在纸面上看起来好很多、但实际上在控制了 test-time compute（测试时算力）之后并没有更好的东西，是非常容易的。这是我对 benchmark maxing 的一个担忧。

我的意思是，我唯一的担心在于，这多少有点误导。至于 benchmark 本身，我觉得始终存在一种风险：大家只是去针对 benchmark 做优化。我当然一直在鼓励我的团队这样做，而且我觉得在 OpenAI，我们在“不去专门针对某些特定 benchmark 优化”这件事上做得还不错。但一旦你把一个 benchmark 发布出去，它就总是有被专门优化的风险。我觉得一个应对办法，是保留一些 held-out private sets（保留的私有测试集），不对外公开。

现在最常见的一条保底建议是：如果你想判断一个模型是不是显著更好了，那就直接上手玩一阵子。除了这个之外，你有没有什么更复杂、更系统的方法会建议大家去做？比如，在 OpenAI，除了 private holdback（私有保留集）之外，你们会不会每次都自己再设计一套新的 evaluation（评估）？

我觉得每个人都会有自己的一套问题，每次有新模型出来时，就会拿这些问题去问它。

嗯。

对我来说，最近我会用它们来做 poker bot（扑克机器人），看看它们能把一个扑克机器人做到多好。我觉得这是个很好的 eval（评估）方式，因为关于如何做扑克机器人，现成的 open source code（开源代码）非常少。相关的论文倒是发表了很多，但你真的得把所有东西自己推理清楚。而且这里面很需要推理和迭代，也有很多细小的坑；这些坑我自己基本都已经踩过了，所以我能看出模型在过程中会在哪里失败。不过它们现在在这方面已经变得非常厉害了。

你能不能大致讲讲，比如结合你们做 poker bot 的经历，在连续几次 model 发布中，你们看到的 reasoning 能力是怎么逐步进展的？

可以。早期的模型在这方面真的很差，基本上什么都做不了。到了 5.2，我已经能和它配合做出一个 reverse solver 了。所以那算是最后一个阶段。嗯。

是在 poker 里。而这件事本身，我觉得已经非常令人印象深刻了。我确实还得和它磨合一下，但我真的很惊讶，因为我做出这个 reverse solver 的速度，大概比我自己单独来快了五倍。中间也有几件事把我卡住了。blockers 一直都是个很大很大的问题。

但总体来说，你知道的，只要稍微温和地引导一下，它就会自己往前推进。我当时的感觉有点像是在带一个 grad student：好，虽然它会遇到问题，但至少我能知道那些问题是什么，也知道该怎么修。我只要给出一些建议，它就会自己去做。然后很快，它实际上就会带回来相当不错的结果。嗯。尤其是在 optimization 上，我觉得非常厉害。

它能把速度做到大概比我自己做的快 10 倍，因为它确实非常擅长优化代码。5.2 的缺点是，我感觉它经常会 gaslight 我，所以我总得非常小心地检查它，确认，好，它到底有没有真的做到它声称自己做了的事？有没有什么很明显的问题，它自己没意识到，或者干脆假装那不是问题？我记得有一次，我在玩其中一个模型，不是 5.2，我有点像是在做一个 unit test，我跟它说，好。

那假设底池里有 100 美元，而我弃牌了。我会亏多少？那个模型回答说是 92 美元。我当时就想，这也太离谱了。我有 100 美元在底池里，然后我直接弃牌。

我怎么可能不是亏掉 100 美元？然后它说，哦，你知道，是 92。已经很接近 100 了。没关系，不是什么大问题。

我当时就想，这显然是个问题。对吧？所以这些模型确实有这种问题，它们经常会 gaslight 你。嗯。但到了 5.5，我确实觉得它好多了。

它基本上已经能做到 zero-shot（零样本）了。事实上，我最近一直在做一个完整规模的 poker solver，而它基本已经能在我稍微引导一下的情况下把整件事做出来。六个月或一年之后，如果这个 model 能够 zero-shot（零样本）一次性完成整个 poker solver，基本相当于把我的整篇 PhD thesis 一口气做完，我一点也不会意外。

我们来谈谈一个更大的影响：在评估这些 model 时，需要结合它们的推理速度，或者效率与 token 数量、美元预算，或者不管你用什么 scaler（衡量尺度）之间的关系来看，对吧？你能不能讲讲你文章里提到的一些更广泛的影响，包括 safety evaluations（安全评估）方面的内容？

对。关于 safety evaluations（安全评估）这件事，它有点像一个 inconvenient truth（令人不舒服的事实）。我先交代一下背景：现在很多，或者说所有 lab 都有一些东西，叫 responsible scaling policies，或者 preparedness frameworks，它们名字各不相同。但核心思路是，每当一个 model 要发布时，都会经过一系列评估，来衡量它是否具备危险能力。

这些 model 会不会做到一些我们不希望 bad actor（恶意行为者）去做的事情？如果 model 能力不强，那问题不大。但如果它非常强，比如说它可能被用来制造 bioweapons（生物武器），那你就会希望针对这种风险加入一些 mitigations（缓解措施）。

嗯。

但问题在于，好，那你要怎么评估一个 model 是否具备这种能力？他们确实有各种 protocol（流程规范）来说明如何做这些评估。但很多这类 framework 都是在 ChatGPT 那个时代前后形成的，当时 test-time compute scaling（测试时算力扩展）还并不是一个特别重要的东西。嗯。

而这在当时是说得通的。比如 GPT-3，你没法对它做 test-time compute scaling（测试时算力扩展）。如果你给它 $10,000,000 的预算，然后说，好，我们来看看 GPT-3 能做到什么，它其实并不会比你只花 $10 或 $1 时强出太多。现在这些 preparedness frameworks 和 responsible scaling policies，其实都没有真正把 test-time compute 的规模考虑进去。

它们只是说，好，这个 model 的能力是什么。问题在于，我们现在所处的世界里，model 的能力基本上是你往里面投入多少钱的函数。

嗯。

如果你给它 $10,000 的预算，它能做的事会比只有 $10 预算时多得多。如果你给它 $10,000,000 的预算，它还能做得更多。所以问题是，你到底应该在什么预算水平下评估这些 model？今天现有的这些 policy，其实并没有真正回答这个问题。

嗯。

有些做得比另一些更好，但总体而言，这其实并不是一个被认真纳入考量的因素。至于是否无论如何都应该发布，我不想卷入这个问题。我认为，怎么说呢，双方都有各自的论点。但我觉得重要的是要认识到，这是一个并没有被真正讨论的问题——我们某种程度上只是，像是在假装这个问题不存在。我认为重要的是，无论怎样，至少要把它算进去、正面处理。

对，这其实是能力问题的镜像：如果这些 model（模型）在非常大的 budget（预算）下，能在某些任务上持续做得越来越多，而不是趋于平缓，那么它们也应该同样能够在那些作为社会我们并不希望它们去做的任务上表现出这种能力。对吧？所以，对这类能力进行测试，以及为此分配多少 budget，这看起来也和 model 的发布周期本身并不同步。对吧？

现在已经出现了这种加速：你会得到一个新 model，有时按如今的节奏是每隔几天、几周，而不是过去的六个月。你在那篇文章里有一句话，大意是，要真正评估一个 agent（智能体）在某种超长周期任务上的表现，唯一的方法可能就是让它跑上一年，而且无论是有用的任务还是负面的任务，这一点都成立。对吧？那么你怎么看待这一点与 model 发布周期之间的关系？

对。这也是一种很有意思的动态变化：基本上，随着这些 model 变得更强，它们也越来越能够在更长的时间跨度上运作。

嗯。

所以，还是拿 g p d three 来说，如果你想让它运行一周，实际上你几乎没法通过搭 scaffold（脚手架式封装/工作流）把它变成一个真正有用、并且能连续跑上一周的东西。但我们现在看到，借助最新的 model，你实际上已经可以搭出这样的 scaffold，比如让 5.5 去执行一系列实验，而且这些实验可以持续跑上几周、几个月。

你有没有给你的 poker solver 任务分配过那种近乎无限的 budget？

我还没有真正搭出一个系统，然后直接告诉它，像是，好，就让这个连续跑上几周。我觉得我可以，我……直到它具备

某些类型。

可能只要给它 /goal，然后，差不多就是，嗯，告诉它放手去做就行了。但我觉得以现在这个阶段，如果我只是给它 /goal，它已经 100% 能做 reverse solver 了。我觉得它还没到那种程度：如果我只给它 /goal，然后告诉它，嗯，去跑一个月，它就能做出完整的 poker solver。不过很快我们应该就会到那个点：我大概可以直接告诉它，比如，嗯，去把这个做一个月，然后回来给我一个完整、全面、state of the art（最先进）的 PokerSolver。问题在于，如果你想评估一个模型的能力，想知道它在连续运行一个月之后能做到什么，那么唯一能完全确定的方法，就是真的让它跑一个月。

如果你想知道六个月之后会怎样，唯一能完全知道的方法，就是让它跑六个月。这个问题我之后会讲到一些可以稍微缓解的办法，但重要的是要认识到，目前的模型发布周期是这样的：我们现在基本上每两三个月就会发布一个新模型。所以一个模型出来后，要花两三个月才能把它逼到能力极限，然后下一个模型又出来了。因此，实际上没有人真正知道这些模型的能力上限在哪里，因为根本没有人让它们持续运行足够久，来真正看清这一点。

比如说，当 /goal 刚出来的时候，人们开始让它跑一些任务，而这些任务要一个多星期它才会完成，所以大家其实直到一周后、也就是它发布一周之后，才意识到这是一件大事。嗯。我觉得这种情况会越来越普遍。我认为这里面的含义很有意思，因为这就引出了一个问题：这些 labs（实验室）在发布模型之前，到底要怎么才能充分评估它们的模型？这其实非常困难，因为，没错，如果你真的要做这种评估，那么唯一真正可行的办法就是推迟模型发布周期。

而你也知道，现在有很大的竞争压力，促使大家不要这么做。

你觉得，在已经发布的这些模型里，是否存在一些令人兴奋的 latent capability（潜在能力），只是因为时间线的限制，人们还没有把它们充分探索出来？

我觉得绝对有。其实一个非常好的例子就是 Erdos unit distance problem。给不了解的观众解释一下：几周前，我们在 OpenAI 用了一个内部模型，推翻了 unit Erdos unit distance conjecture。虽然我不是数学家，但这看起来似乎是一件相当大的事。在数学界，这好像是第一个有很多数学家真正花了大量时间研究的问题，而这个模型做到了他们没能做到的事，而且它完成这件事的方式，对数学家来说也确实是有趣且有用的。

说实话，它做到这件事的 budget（预算）低得离谱。我的意思是，我们并没有为此投入很多精力。我们只是训练了一个新模型，然后单纯想看看它能做什么，于是就让它去跑一些问题。这个问题在相当低的预算下，它就像是，哦，对，我觉得我有一个 disproof（反证）了，然后我们也验证了，没错，这个反证是正确的。

在我们公布结果之后，很多人发现，其实用 5.5 也能得到这个答案。当然，这并不是说你只要直接问 5.5：“嘿，这里有个 neural unit distance conjecture。它的 disprove 是什么？”就行了。你还是得稍微给它搭个 scaffold（脚手架式流程）。

你确实得稍微“引导”它一下。于是有人发现，哦，明白了。你去问 5.5：列出一堆你可以如何处理这个问题的方法。然后它在这些方法里，会列出其中一条实际上很有希望走到 disproving（证伪）的路径。

然后你再告诉它，比如说，好，继续更深入地探索这个方向。要是你这样做足够多次，它实际上最后确实会走到 disprove（证伪）。这意味着，原则上你可以让 5.5 作为一个通用 scaffold（脚手架），先列出一堆不同策略，然后针对每个策略，再让它去调查那个策略。这样的话，它大概率就能靠一个通用 scaffold 走到 disprove（证伪）。

当然，那个 scaffold 会非常昂贵。我是说，我粗略估计一下，成本大概会在一千到十万、甚至十万美元左右。但这是可行的，而且在我们之前，理论上就可能有人用一个通用模型去证伪 Erdosia to disc distance conjecture。只是一直没有人充分探索过：如果我往 5.5 里投入价值 10 万美元的 compute（算力），它到底能做到什么？

而答案是，对，你大概确实能从它那里得到这类结果。

所以，人们应该更多地拿当前这一代模型来做实验，看看它们在……方面到底能做到什么。

不过，我觉得这里有个很有意思的问题：这样做值不值得去实验？因为，还是那句话，模型发布周期基本上每隔几个月就是一轮，我们会推出一个更强的新模型。所以，去证伪那个 air to ocean at distance congestion 的成本，几乎会随着每一轮模型发布下降 10 倍或 100 倍，在某些情况下甚至更多。

所以你肯定见过那个 meme（梗图）：哦，好吧，那我为什么还要做任何 engineering（工程）工作？我还不如直接等下一次——

model release（模型发布）呢？去度个假，两个月后再回来，到时候你知道的，成本就便宜一千倍了。所以你同意这种说法吗？我是说，这是吗？

你现在在 OpenAI 做的事情，就是等着下一个 model 发布吗？

我想，我是说，我们现在正处在一个进展非常快的时期，而且，没错，models 正在变得越来越有能力。我可以说，在 OpenAI，我们正在主动避免做的一件事是——你看，我们有很多数学家，也有很多物理学家。大家都对这些 models 目前能做到什么感到非常兴奋，嗯哼。

尤其是，你知道，内部 models。我们在努力鼓励大家不要把所有时间都花在，比如，把各种数学未解问题、物理问题过一遍，然后不断把 models 推到它们的极限，看看它们能证明什么、证伪什么。因为我们真的认为，重点应该放在：我们如何做出能力更强的 models，如何尽可能快且安全地把它们交付给全世界，这样全世界所有的科学家都能用这些 models 自己去解决问题。所以，对，在某种意义上，我们确实在想这件事：没错，把我们所有精力都投入到扩展这些 models、看看它们在当前极限下能做什么，这确实非常诱人；但真正的重点应该是，我们如何用这些 models 去造出更强大的 models、能力更强的 models，并且让它们以高得多的成本效益去完成各种事情。

鉴于你对这种超大规模 test time compute（测试时计算）的影响的看法，在你看来，研究方向或资源分配正在发生什么变化？这又如何与 recursive self improvement（递归式自我改进）这样的想法相互作用？比如说，你知道，这一直被认为是任何实验室获得最强 capability model（能力最强的模型）的主导性思路。

所以，有一件事我应该先澄清：我不认为我们已经到了这样一个阶段——就是，好吧，你只要给它任意的、极高的 inference budget（推理预算），它就会在各个方面都变得超级智能。

斜杠目标

对。基线。好吧。G p d seven 之类的，然后，就是，没错，直接放开干。

那么，我们距离那种状态之间还差什么？

我觉得，在实际上手玩过这个 model 之后，情况大概是这样的。首先，有一些 benchmark，即使给 model 更多 inference budget（推理预算），它们也不会变好。所以我认为，很多事实检索类问题都属于这一类：如果你问一个人 Abraham Lincoln 是哪年出生的，而他不知道这个日期，那他可以坐在那里想。他就算想一周，如果没有电脑之类的工具可查，也不可能比想五秒钟时更会回答这个问题。

model 也是一样。实际上，很有意思的是，如果你给 model 这种事实检索类问题，再给它一点思考时间，它确实会做得更好一些；但如果你给它一周时间，它也不会突然更擅长记住日期。所以，有些 benchmark 会随着更多 test-time compute（测试时算力）而明显提升，也有些不会。另一方面，在另一个极端，也有一些 benchmark 很显然会随着更多 test-time compute 持续提升，几乎没有上限。我最喜欢举的例子是 sudoku。

解 sudoku 其实有一个非常简单的策略：就是尝试很多组不同的随机数字，然后看它是否符合要求、是否满足所有约束。如果不满足，那就换一组随机数字继续试。很显然，只要时间足够长，用这个策略你最终能解出任何一个 Sudoku 谜题。所以你几乎可以很直观地看出来：只要给更多 test compute，任何 model 都可以不断做得更好。所有这些 benchmark，基本都分布在这两个极端之间的某个位置。

这些 model 还没有达到这样一种程度：只要给足够多的 test-time compute，它们就能完成我们所有人的工作。因为，没错，确实有一些 benchmark 它们不会提升；有些事情它们就是不会变得更好。尤其在 research 上，我看到的一个问题是，它们现在还没有很好的 research taste（研究品味/判断力）。所以我认为，它们实际上是 researchers 很好的补充工具。特别是，就我自己的体验来说，使用这些 model 之后，我的效率高了很多；但它们还不能完整替代整个 research cycle（研究周期）。以后这会不会改变？大概会。

我的意思是，我认为这些 model 在各个方面都在进步。有些方面进步得比另一些更快，但它们还没到这样一个点：只靠足够多的 test-time compute，就能完全取代 researchers。

你能不能举一两个例子，说明让 model 就这样直接去做 research task（研究任务）为什么会是个糟糕主意？

我的意思是，回到我之前那个 poker solver 的例子，我对 model 优化我在 PhD 期间开发出的那些算法的能力印象非常深刻。说实话，事后回头看，我当时的低效程度简直让人震惊，而它们居然能把速度提升到大概 1,000x。然后我就想，好，那你能不能提出一种比我想出来的、或者比其他任何人想出来的都更好的算法？你去看看所有已发表的工作，把它们综合起来，然后试着提出一些新的东西。但它做不到。

而且我就算给它很多时间，它还是做不到。现在也不是说完全不可能；如果我给它搭一个 scaffold（脚手架式流程），再多加一些约束，也许它最终可能会提出更好的东西。但这需要做很多额外工作，并不是简单地说一句“好，请想出一个更好的算法”就可以。

你觉得这要怎么改进？

我看到的是，每一轮 model 发布周期，它在这类事情上确实都会变得更好。按我的看法，它现在依然还是做得不好，但已经没有以前那么糟了。而且我不会惊讶于某个时刻会出现类似 coding、类似 math 的情况——就像出现一个拐点，突然之间它已经好到足够有用了。如果我们在 research taste（研究品味）上也遇到那个点，我也不会意外。

即便如此，你会怎么看，你对今天的 RSI 的框架是什么？也就是说，我们应该怎样理解它？

这些 model 的确在加速研究人员在 labs 内部能做的事情。但我认为，它们是在加速某些事情，而不是所有事情。现在我们所处的阶段是：如果某件事快了 100 倍，你就会被那些没有快 100 倍的事情卡住。随着时间推移，我们当前受限的那些瓶颈会逐渐缩小，我认为，从这个角度看，会出现一种渐进式的起飞。但就目前而言，这更像是在改变研究人员做事的方式，而不是完全替代研究人员。

所以这其实意味着，你认为我们现在并不接近一次非常快速的起飞。