AI 能自动化 AI 研究吗？Jerry Tworek 谈还缺什么
Can AI Automate AI Research? Jerry Tworek on What's Still Missing
这是一场关于 outer research 的活动。所以，我想聊聊 outer research。不过首先，对于还不认识我的人，简单做个自我介绍。我大概在八年前加入 OpenAI，当时我相信强化学习是我们通往 AGI 的必经之路。我想此刻所有人都知道事实的确如此。所以我认为，自己在某种意义上已经完成了这一使命。今年年初我离职，准备开启下一段冒险——下一个版本的方向，聚焦于 test time training，以及如何让模型在测试阶段有效学习。
公司名叫 Coral Automation。如果你想了解更多，之后可以联系我。但说到今天的活动，由于过去八年我一直在 LLM 上做强化学习，我很可能是最早做 outer research 的人之一。关于这一点，我有些有趣的东西可以分享。而整个故事都始于这张图——虽然我私心觉得有点自卖自夸——但我认为它是过去几年机器学习领域最重要的图表之一。它说明了两个问题。左边是大家在做机器学习系统 scaling 时都想看到的常规 scaling 曲线：你在训练模型上投入的算力越多，得到的结果就越好。
这就是 scaling law，Dario 用 GPT-2 和 GPT-3 展示了这一点。人人都想做到，但以前没人能在强化学习上做到这一点。而我们 OpenAI 的团队最终找到了一种可 scale 的强化学习配方。这正是我们当时苦苦寻找的东西，而且我们找到了。
右边的情况则多少是意外发生的。我们并没有专门去设计它。某种程度上我们是偶然发现的，但从很多方面来看，这是一件更深刻的事情。它表明，模型的性能会随着你花费更多 token 而提升。对于同一个模型，你让它思考得越多，结果就越好。这在很长一段时间里都是研究的圣杯，但我认为以前至少在有意义的真实世界应用、非常通用的场景、相当规模的场景下，没人能做到这一点。每个看到这张图并能思考其后果的人都会说：这意味着很多。有重要的事情正在发生。我们可以开始 scale inference，不断获得更好的结果。如今 token 消耗量飙升的原因也与这张图有关。我认为整个故事就是从那里开始的。
Noam 有一种倾向，喜欢一遍又一遍地提醒人们：一旦你开始看到这张图，再谈论 eval 数字就没什么意义了。因为如果你看着这张图，然后问：这个模型的性能是什么？或者，这个点——因为这是我们现在最高的点——如果你再花多一点 test time compute，它会到哪里？模型会达到 100% 吗？还是会在某个地方进入平台期？又或者这只是 eval 上的噪声？没人知道。所以现在没有单一的方法可以评估模型。
甚至很难做比较。更有意义的图，是至少把性能看作某个变量的函数。我们越来越多地以 token 数量或推理成本的形式来做评估。这两种比较都有意义。但只是把一个模型的数字和另一个模型的数字放在一起，却不考虑这个模型思考了多少，那其实说明不了什么。我有点难过的是，人们发布模型时仍然只是丢出一个数字说：哦，这个数字比那个大。但他们完全不告诉你这个数字是怎么来的，以及为了得到这个数字花了多少成本。所以我认为，能让你看到类似这样曲线的发布才是好的。
这才是当今你应该呈现模型的方式，因为它们都能 scale inference。你在一个任务上花的算力越多，得到的性能就越好。这就是我们现在所处的世界。它已经是现实了。我强烈建议，做任何评估时都要考虑成本——也就是这里的 x 轴代表什么。
那么回到 outer research，什么是 outer research？在很多方面，outer research 就是把 test time compute 越推越远，在很多时候超越单个 context 所能做到的事。所有 outer research 的问题都是模型不太擅长的问题。outer research 在很大程度上意味着我们有一个相当难的任务，然后我们对模型说：嘿，去做吧，去解决它。
它做得不太好。但接着我们让它再做一次，试着让它花越来越多时间去思考，花越来越多 token，直到最终达到我们满意的性能。这在很多方面就是 outer research 的本质。其余的问题则是：我们如何工程化它？如何能够高效地花费大量 token 来达成目标？这是一个有趣的想法。我试着把它总结成一个观点。很多关于 scale inference 的任务都是从 A 点到 B 点。而从 A 点到 B 点，你能做的推理是有限的。
存在某种状态：你给 Codex 一个 prompt，嘿，帮我实现这个函数。它实现了这个函数。之后你能做的只是迭代——写更多测试、自我验证、双重检查、三重检查、四重检查。但 outer research 在很多方面是要把这个过程变成一个 loop。把它包装起来。设定一个非常困难但又足够可验证的目标，这样你就可以瞄准这个目标，验证距离某个非常遥远、非常困难的地方有多远。试着重新评估下一步该怎么做。再次尝试那个目标，继续前进。
只要能把它包装成一个 loop，你就可以不断花费越来越多的 test time compute，因为你总是有路可走，总是有越来越多的事情可以做。这在某种程度上就是 outer research 的构造原理，也是它为什么有效、为什么能带来提升的原因。
这里还有一点来自 Peter Steinberger 的俏皮补充。每个人都喜欢那个人。他说：除了 loop 之外，现在是否还有其他构建 test time compute 的方式？是否存在其他方式？但 arguably，draft 要稍微难一点做成 loop，从而能够持续地花费越来越多的 test time compute。不过我非常欣赏那个洞见。
那么，我们有哪些 loop，又观察到了什么呢？最早被所有人观察到的 loop 之一是关于编写 GPU kernel 的。这也是我们在 Coral Automation——我的新公司——经常思考和迭代的东西。
这里有一个例子：我们曾举办过一场比赛，要求为一个或许并非最主流、但在许多二阶优化方法中都会用到的操作生成 kernel，这个操作叫做 QR decomposition。它是一种线性代数运算，用于对矩阵进行分解。我们针对这个问题运行了一些 auto research 循环，得到的 kernel 比 Nvidia 基线快了好几倍。我们非常高兴。是啊，auto research 奏效了。我们确实写出了一个出色的 kernel，比 Nvidia 的还要好。
我认为 Nvidia 并未全力以赴优化这个 kernel，毕竟它只用在模型的前向传播中，但我们对此仍然感到非常高兴。后来我们决定也举办一场比赛，看看大家能做出什么。有趣的是，现在没人再自己手写 kernel 了，人人都用模型。我们想邀请比赛的获胜者来办公室做分享，讲讲他是怎么写出这个 kernel 的，结果他的回答是：“我甚至没看题目，也没看代码。” 但有趣的是，就比赛结果而言，最好的 kernel 比 Nvidia 的 kernel 快了 60 多倍，也比我们 auto research 循环产出的结果快得多。
这告诉我们几件事。其一，auto research 的质量很重要，有做得好与不好的区别。其二，我认为我们仍然处在一个人类与模型混合协作远比纯模型自身更强大的时代。有些人只是给模型提供了非常宏观的指导，其中很关键的一点在于深入理解硬件的内存层级结构，以及如何利用它。有些解决方案确实非常精妙，但这并不是说这些人没有贡献——仅仅运行 auto research 并不能让你得到世界上最好的 kernel。
这个故事的另一部分是，我们在内部训练框架中测试了所有这些 kernel，因为我们在训练模型时会用到 QR kernel。结果是大部分 kernel 都无法运行，大多数在数值上不稳定，直接失败了。但有趣的是，排名第二的提交实际上是可行的：它比 Nvidia 基线快了 60 倍，数值稳定，而且确实能用来训练模型。所以，你可以得到一个非常好的 kernel，但在今天的世界里，你仍然需要清楚自己在做什么。
不过，auto research 存在一种众所周知的失效模式：如果某个维度你没有去测量，但它仍然在你的目标函数之内，那么你很可能会去钻空子，而且很可能会走到利用问题某些弱点的地步。你必须非常小心地对待评估，小心地衡量自己是否在做正确的事。我们学到了很多。我们正在举办越来越多的 kernel 比赛，如果任何人想参加，而且我们昨天刚刚发布了一场优化器比赛，如果有人想参加，那会非常有趣。这属于深度学习研究的方向之一。
但还有一种思路是直接针对 auto research 本身：把训练模型的任务、把 loss 当作目标函数，然后你可以不断运行它，这几乎是一个永无止境的改进过程。但每个运行过这个流程的人都见过几乎相同的曲线。这可能是世界上很多人都见过的曲线：你启动 outer research 循环，早期会看到大量改进，你做得很好，非常开心；然后随着时间推移，你看到的改进越来越少，幅度也越来越小。某种程度上，存在某种天花板。如果今天我们只要按个按钮就能得到 AGI，那当然好，但不幸的是，模型能够探索的空间是有限的。总有一些东西刚好超出模型的能力边界、视野范围或执行技能之外，而我们就是得不到。
某种程度上，今天的 outer research 是一种搜索方法，用来在你所追求的优化目标下探索解空间的某个邻域，但它并不是问题的解决方案。它能帮你走到某个地方，但不能帮你走完全程。就像刚才 outer research 写 kernel 的例子一样，outer research 做模型研究也是如此。
但这到底意味着什么呢？有一种非常错误的先入之见，认为在机器学习领域，你要么做算法，要么做 scale。人们说：“哦，scaling 很蠢，谁都能做。你只要造一台大计算机，在上面跑东西就行了。” 但实际的论点是，在 scaling 的世界里，算法的重要性绝不是可有可无。如果你决定在一轮训练上花费 1 亿美元或 10 亿美元，你最好有非常好的算法来支撑。而且如果你对算力的杠杆很大——说到 outer research，这里指的是推理算力——但这些也都是真金白银。
如果你想运行一次 auto research，愿意投入 100 万美元、1000 万美元甚至 1 亿美元，为什么不呢？这肯定会在某个时刻发生。如果还没发生，那你最好有非常好的算法来花这些钱。因为如果你只在一个 auto research 问题上花几千美元，那大概不是很多人会关注的事，你确实也能得到一些提升。但如果你想在一个 auto research 问题上花 1000 万美元，那你就想确保自己以最佳方式使用它。
而且在大规模下，糟糕算法和优秀算法之间的性能差距，要比在小规模下大得多。
所以我们必须思考：每当我们做 scaling、每当我们做 auto research 时，最好的 auto research 算法是什么？如何以最佳方式利用 auto research 的计算资源？如何让它更高效？有一篇非常有趣的论文——目前讨论 auto research 算法的论文还不多。Alpha Evolve 是一篇特别好的论文，因为它公开讨论了很多设计要素，以及构成优质 auto research 的诸多组成部分。
其中很多内容是关于构建某种记忆数据库。如何评估？理想情况下，如何在多方面防止钻空子？它谈到了使用多个模型，因为不同模型可以有不同的想法，以及如何以多种方式向模型注入多样性。我建议那些思考 auto research 的人尝试去分析它。那篇论文中已经包含了很多非常有趣的研究，而且我们仍然可以思考如何让 auto research 循环并行化。这在很多方面都关乎将人类的见解和方向注入 auto research 的循环中，因为正如 kernel 的例子所示，即使是很小量的人类指导，也能对 auto research 的进展和它能达成什么产生巨大的影响。
这也恰恰说明了我们仍然被需要，人类仍然有事可做。所以，这大概就是我们为什么还在这里，为什么我们还在谈论这些。
Jared那么，关于我刚才提到的 auto research 未来真正重要的方向。大概每个大规模做过 auto research 的人都知道，当今的头号问题是探索的多样性，以及我们到底在尝试哪些想法。Auto research 循环受限于模型提出的想法，这就是关键所在。这与那种由我们提出想法、模型只负责执行的研究循环非常不同。但 auto research 需要模型自己想出我们可以改进什么，而在大多数情况下，模型并不擅长这一点。
这绝对是瓶颈，而改进这一点是提升 auto research 循环的最重要途径。同样，每个人都知道，每次新模型问世，如果模型在研究方面更强，auto research 的效果就会更好。随着下一次模型发布，一切都会改善，就像圣诞节一样。这就是更好模型的杠杆效应，特别是更擅长研究的模型。如何优化模型以进行研究，这是一个有趣的问题，这完全是另一个话题，也值得单独讲一次。在很多方面，我个人相信并正在我的新公司尝试做的，就是探索如何注入越来越多的 test time training。
技术上讲，auto research 循环默认建立在静态模型之上，你只对这些模型运行推理。但在我们开始研究、探索和构建的过程中，有很多东西可以学习，也许还有很多我们事先不知道的东西。我们该如何把这些反馈回模型？如果我们愿意在那项搜索上投入大量算力，我们如何确保通过 auto research 的过程获得更好模型的收益？我认为这是一个非常有趣的领域，随着时间的推移肯定会带来一些收益。那么，我慢慢结束这次关于 auto research 结构的发言。
Auto research 是一种方法，让我们可以花费更多 inference、全程运行更多实验、收集更多数据，并利用这些数据进一步改进。Auto research 是扩展推理以在问题上获得越来越好的性能的绝佳方式。最后还有一个想法想分享，引用我自己的一条推文：我认为今天构建 auto research 任务的任何人，我想建议的是少做实验，多思考。扩展推理计算有很多方法，但我认为很多人只在一味追求如何获得尽可能多的迭代，如何在这个 auto research 循环中运行尽可能多的轮次。
从某种程度上说，这是数据生成过程，但其中很多都很浅层，而且你也把自己极度局限在一组验证既便宜又容易的循环里。并非所有问题都如此，很多问题确实可以用某种方式验证，但通常验证成本更高。我认为，努力思考我们要运行什么实验，并在这方面多扩展一点推理，比单纯纠结收集多少数据点有着好得多的 scaling slope。我相信这会给每个人带来很好的回报。谢谢，这就是我今天的全部内容。
Host谢谢 Jared，谢谢 Jared。非常精彩，令人鼓舞。好的，接下来我想介绍 Jessica，她是 AG House 的研究员。她将主持与来自 Google DeepMind 的 Pushmeet Kohden 的对话。那么，现在好像该进行问答了。
在此之前，我们想知道 Jared 是否参加问答。好了，首先，给 David 鼓掌。
你逗得大家大笑。
Jared是的，非常感谢。好问题。那么，
David：我一直在研究我的 test time 理论。我们知道需要什么吗？我们需要什么才能真正做到？我们可以简化，比如把你的问题理清楚，像是三位研究员的情况，以及如何获取数据？这三个领域，我会结合其他研究来探讨。这种针对不同事物的具体思考方式。所以，在我结束之前，我很好奇，对于如此复杂的问题，我们目前有哪些解决方案或方法还没有……我做过其中几个。对，就是这样。
test time training 的好处在于，至少你不会有数据问题，因为数据会自然流向你。test time training 就是如此，你在训练时用的是你正在处理的问题，是有人反馈给你的问题。所以这不是问题。但问题在于算法。事实是，目前根本没有好的 test time training 算法。这正是深度学习研究人员可以介入并开始提出算法的地方。研究 test time training 本质上就是研究深度学习算法：如何用一个已经拥有先前所有信息的模型，从呈现给我们的狭窄数据集或我们正在探索的轨迹中学习。这正是需要完成的研究。它有些 open-ended，这很有趣，但困难且开放的问题最终会创造价值。
Host好的。那么下一个问题。你提到将人类专业知识注入训练？能否多讲讲，举些例子？我的意思是，有些例子很明显，比如我不认为 Midjourney 能做到这些。很明显。然后你很多年前在 RLHF 方面的工作也很明显。这也让人反思，在研究过程中，你到底去哪儿找聪明人告诉你哪个 kernel 更好，只是他们在日常工作中不会这么做？
Jared是的，是的，没错。你知道，这有点像学习工作流，但人们写 kernel 已经很多年了，很多人在这个过程中对硬件有了很深的理解。现在他们不再亲自实现代码了，至少没那么多了，但他们可以非常轻松地指导模型，告诉你：“嘿，想想这个。如果我要开始解决这个问题，这三件事是我必须考虑的，我要确保它们没问题。”突然之间，这几行洞察就能极大地改变模型的性能。因为模型可以快速工作，可以不知疲倦地工作，可以检查很多东西，但不幸的是，它没有人们头脑中关于如何写好 kernel 的那些洞察。
Attendee：酷。你好，我有个问题。你给我们展示过，随着计算机速度变快，线性部分最终会在某处趋于平缓。为了不让它平缓下来，你必须展示如何让循环……
但归根结底，这两个循环需要的是一种兼具热情与品味的态度，才能设计出我所构建的评估体系。就拿 GPU kernel 的例子来说，品味从何而来，这是每个人都会问的常见问题。正如 Ravi 所说，“我们可能需要从根本上更好地进行预训练。”Mesa 似乎在品味方面更胜一筹，我认为主要是通过大规模的预训练。你认为还有别的途径可以注入更多品味，从而避免你的 test-time compute 因此变得迟缓吗？
是的，是的。品味肯定需要有来源。还有一个关于 test-time training 的思路是，无论我们从预训练中获得什么，它在某种程度上都来自海量数据，而且这个过程的数据效率并不高，但我们可以把这些洞察蒸馏提炼成对模型真正非常有用的东西，而模型还能利用许多其他资源。我们如何在 test time 获得类似的东西？我们能否有意义地提升模型的品味？这又是一个有趣的算法问题：我们该如何做到这一点？因为在某种程度上，test-time training 旨在提升和改进那些我们以前只能通过预训练获得的能力，而且是针对我们真正关心的领域和问题。
但你要知道，在很多方面，目前主要的技术仍然是 pre-training，我认为这可能也意味着一些品味数据必须存在于其中。这些品味数据究竟是什么，这是一个非常好的问题，但有很多人一直在撰写大量文本，而越来越好的预训练模型能够以越来越高的保真度对这些数据表面进行建模。但我在问自己一个很好的问题：我们该如何取其中的一个子空间？我们如何只关注互联网全部数据里一个非常狭窄的角落，并试图把它建模得非常好，同时又不破坏其他任何东西。
好的。最后一个问题。关于 training 与 compute scaling，我们是否有大致的概念，需要多少算力才能达到类似的结果？那么对于 test-time compute，是否也存在类似的情况，需要多少……
是的。这能做到。我们需要获得更好的结果。
是这样。谢谢。
你可以尝试外推，人们也在这么做，而且取得了一定的成功，但外推非常非常困难。我在 Codex 上做过很多次这样的尝试，比如告诉它，“嘿，我有了这个 kernel，让它以 5 teraflops 运行，或者让它以 10 teraflops 运行。”显然。而为模型设定这个目标本身也是一种技巧。你需要大概了解一个给定的 kernel 能做到什么程度。因为如果你把目标设定得恰当，模型就会朝着这个目标努力，而不会试图去往别处。
有时候，你设定目标的位置也从根本上决定了模型会尝试去往何方。而且从根本上说，存在一些限制。你可以试着告诉模型，“嘿，做一个运行速度超过光速的 kernel。”但无论你投入多少计算量，你都不可能得到它。所以，问题的规格本身存在限制。有时候，当你开始进行研究，做了很多次运行并收集数据点后，你可以尝试画一条线，通常你会看到一些规律，但与此同时，每当环境发生变化，或者事情变得越来越困难时，这些规律总会失效。
所以，你可以尝试，也有一些方法可以让你不至于完全盲目地运行，但这确实取决于你的具体问题和你的模型。而除此之外，就只是前沿领域的未知了。
好的。去赶飞机吧。
好吧，我赶上了。谢谢，Jared。谢谢。
很高兴你能赶上这班飞机。