大家好，请入座。我是Vam，还有Jung Yao、Droo和Dex。首先，非常感谢Sean以及全球各地的AI工程师邀请我们参加这次聚会。这里汇聚了众多优秀的AI人才，我们非常高兴能来到这里。如果你们还没有完成设置，不用担心，稍后会有充足的时间进行处理。接下来，Jung Yao将简要介绍AutoResearch背后的基本原理。

我们做的是缩小规模，使用小型数据集而非整个网络数据，并训练一个只需几分钟即可完成的评估模型。这样您实际上就能让循环运转起来，亲眼看到几个真实步骤的实时运行。在讲解下一张幻灯片的指令之前，先做一些背景介绍。您将在“迷你参数高尔夫”（Mini Parameter Golf）上亲自运行 AutoResearch 系统。如果您尚未注册，需要加入两个平台：一个是 Weco 的 AutoResearch Agent（负责搜索），另一个是 Modal（用于实验的计算资源，提供训练和评估功能）。感谢 Modal 提供的免费额度。

接下来克隆我们的参数高尔夫仓库，交给您的编码代理，让它启动运行。它会处理设置并开始循环。一旦后台开始运行，我们将大约 15 到 20 分钟后回来深入细节。指令如下：在 dashboard.ai 注册 Weco，在 modal.com/signup 注册 Modal（网址可能有误，应为 modto.com）。有一个代码可以领取 Modal 额度。如果您已有账户，可直接访问 modal.com/credits 输入代码。完成这两步后，克隆此处显示的仓库，告诉代理根据自述文件设置 Mini PG 并启动运行。

如果遇到任何问题或疑问，请扫描二维码进入群组，我们会进行监控；或者举手示意，我们会过来协助。大约 105 分钟后回来查看。谢谢大家。大家好，很抱歉遇到网络问题，我想正在修复中，但在那之前，也许我们可以先梳理一下 AutoResearch 运行的解剖结构。我们将以 Weco 作为自动研究系统，Mini PG 作为任务背景来进行讲解。但这种合作模式相当通用，大多数 AutoResearch 系统都会让您提出非常相似的问题并思考相同的事项。

首先是源文件，这是代理实际需要修改的文件，它定义了搜索空间以及可以做出更改的地方。它可以是一个文件或多个文件。在 Mini PG 的情况下，是名为 solution.py 的单个文件。solution.py 本质上定义了模型配置以及训练过程中发生的动态变化。其次，在我看来这是自动研究系统中最关键的部分：评估。您需要一种非常简单的方法来让 AutoResearch 系统评估它生成的每一个解决方案，并输出单一标量指标。

您希望评估速度快、成本低且噪声低。因为这直接关系到在固定预算或时间限制下执行更多步骤的能力。如果噪声较低，您和代理在进行爬山式优化时都会更有信心。不过要注意一点：代理喜欢“奖励黑客”行为，即寻找评估协议或基准测试中的漏洞。因此，您必须尽可能使您的评估具有鲁棒性。接下来的两个要素是指标和目标。您需要问自己两个问题：我想改进什么？越高越好还是越低越好？

在我们的案例中，对于 Mini PG，目标是验证集损失（BP）最小化。您 essentially 想要找到一个在未见文本上预测能力更强的模型。接下来是实际运行 AutoResearch 系统的步骤数量。这有点棘手，因为很难预先知道应该给系统多少步数。我们在此选择了 20 步，只是为了给予代理足够的时间去探索不同的想法，让您看到代理实际在探索什么、哪些有效、哪些无效。

通常尝试的想法越多，越容易取得突破。这回到了我之前说的：如果您有快速或廉价的评估机制，那么在时间或成本约束下就可以运行更多步骤。因此，评估始终是需要重点考虑的因素。此外，您还需要限制评估运行的时间上限，因为很多事情可能会出错：循环可能停滞、硬件可能故障，有时代理生成的糟糕代码会导致整个系统挂起。因此您需要限制实际的评估运行时间。

在我们的案例中，我们将其设置为 210 秒。原因是：60 秒用于训练模型，60 秒用于在未见文本上测试模型，剩下的 90 秒作为缓冲时间，供 Modal 启动 GPU 进行训练和测试，以及处理其他任何开销。最后一点是您给予代理的初始优化指导。这是您从开始就引导代理的方式。您需要思考：您可能以前运行过实验，积累了大量的领域专业知识和人类经验。您可能对某些有效的方法、有趣的尝试方向或无效的事情有一些想法，这就是提供此类指导的地方。

在 Weco 的情况下，您可以简单地指向一个 Markdown 文件，将所有信息和上下文放在其中。代理能够利用这些信息，从而最大程度地提高成功的几率。在 Mini PG 的案例中，这可以是硬性约束或不同的想法，例如专注于压缩、不同的量化方法，甚至是在模型的不同块之间共享权重。由于网络问题，我们仅演示如何开始使用 AutoResearch。在此之前，再多谈谈我们认为使 AutoResearch 达到生产级标准的关键因素：首先是结构性。

我们采用树状搜索，代理会展示它运行的每一次尝试，正如杜夫（Duv）提到的那样，让想法能够相互叠加，而不是从头开始。其次是可观测性：您可以打开任何一次尝试，查看其评分背后的确切代码更改，从而了解代理采取该策略的原因。第三是可操控性：您拥有控制感，可以在循环运行时注入自己的想法和知识，让它尝试新的方向。

如果卡住了，我们再深入谈谈基于树的搜索。我们很快会在 Auto Research 仪表板上演示这一点，但基于树的自动研究本质上将问题视为代码上的结构化优化过程。它从树根开始，正如你所见，初始得分为 0.5，这仅仅是基线程序及其测量得分。此后路径上的每个节点都是针对评估运行并附带分数的代码修改版本。你可以将这颗树视为实验图，搜索建立在有效的方法之上，寻找优秀的候选方案并剪除糟糕的分支。因此，当某个分支提高了分数时，它会基于这些想法继续深入探索，这意味着你可以检查自动研究系统所做的具体更改并在此基础上构建。

接下来我们要讨论的概念是“可观测性”。因为你可以看到基于树的搜索中的每一个节点，所以可以打开其中任何一个查看确切的变化。你能实时观察指标随变化而移动，并将这种运动归因于特定原因。你可以悬停在节点上获取变更摘要，或者打开它阅读精确的差异对比。当指标发生跳跃时，你可以读取导致该变化的具体代码改动。通常这些运行会持续数小时并涉及数百个实验，因此一旦你能看到它在做什么，下一步自然就是能够改变它的行为。这本质上是从旁观者转变为掌控者的时刻。

如果我有想尝试的想法，用自然语言描述它，系统会开启一个新的分支，你可以看到新想法如何被尝试并生成新的节点和曲线。我还能为每个节点设定预算，让计算资源花在我希望的地方。正是这一点使得它在解决实际问题时变得可用，因为你可能拥有代理所不具备的上下文和直觉。至少目前我们认为，在必要时将人类判断融入系统至关重要。我想用现实案例来支撑“可引导性”这一观点，因为在 Parameter Golf 挑战中，可引导性是我们要表现出色的关键部分。

这是来自比赛的一个实际突破。起初是我们的代理（粉色线），从 4 月 15 日到 19 日连续五天尝试新事物，包括新的注意力机制、压缩技术和更丰富的堆栈结构，但分数基本停滞不前。社区中有人发布了一个巧妙的新型分词器（蓝色线）。在该变更出现后的八小时内，我们的系统捕捉到了它，将其与自己已有的工作成果融合，并带来了数周以来最大的分数跃升。在如此困难的场景下运行自动研究并非“设置即忘”，而是一场协作，我们引导代理并从周围人那里汲取想法。可引导性正是使这一循环成为可能的关键，也是真正突破发生的方式。

接下来我将把时间交给 Dex 和 Jungao，让他们详细讲解如何设置 Auto Research。我们将模拟你们在笔记本电脑上尝试的过程。好的，我们要做的是向大家简要介绍其高层理念及实现方式。我们将使用移动热点进行演示，因此会即兴发挥一些内容，希望大家不介意。我们可以顺便展示一下输入给 Claude 的整个文档过程。基本上，你可以进入仓库并给出简单的指令，例如“基于 README 启动自动研究”，如果网络状况良好，它应该会启动默认的 WLE（Web LLM Environment）运行。

我们还可以讲解一下 WLE 命令的工作原理。在这种情况下，你有一个源文件，解决方案基本上就是 Mini PG 的训练脚本。我认为 Z 也提到过，“Eval”命令是额外的指导或提示，它将引导整个搜索过程。指标则是验证集的 BPB（Bits Per Byte）。这是一种保留集的损失，即仅在测试集上计算的损失。目标是使其最小化，其他则是我们刚才提到的配置项。抱歉，“Eval Commander”实际上是你要运行的 Bash 命令，用于执行评估并最终输出一个分数。

该分数会被打印到终端并传递给代理，这是驱动整个试错循环的关键信号。与此同时，我还可以展示仪表板界面。如果你进入 W 仪表盘，可能会看到很多内容。在命令由代理自动启动后，你会看到“Ramping”（加速/爬坡）阶段弹出，然后你可以尝试我们提供的功能。我们要不要先启动一个运行来开始演示？是的，我想它刚刚才开始。好的，仍在运行中……看来 Claude 正在工作。

观众提问：在你们演示期间，能否调高仪表板的亮度或切换到浅色模式？有人问：“我在现场，能把仪表盘切换成浅色模式吗？现在有点难看清。”好的，浅色模式。我忘了在哪里设置……第二个问题是：Auto Research 能否应用于强化学习（RL）？当有多个优化目标时，标量指标是什么？是的，它肯定可以应用于 RL 训练脚本。有一个名为 SpeedR Runner 的项目正是这样做的，用于后训练 Aquin 模型以进行游戏。你可以将 Auto Research 应用于 RL 训练脚本中。

关于你提到的多个优化目标，最终的想法是将它们组合成一个单一指标：你可以为不同的指标应用不同权重，或者将某些矩阵视为约束条件并优化其中一个。例如，在进行欺诈检测时，你可能保持准确率不变而尝试优化精确率。而在 Parameter Golf 中，我们正是将模型大小作为约束条件，并优化系统的准确率。是的，我们可以看到代理已经生成了一个节点。“零号”节点基本上是作为基线解决方案的根节点，“3.93”表示附加到该解上的验证 BPB。你可以看到 WOS 自动研究已经在这里生成了一个节点，这里也有它尝试过的想法摘要。看起来已经开始取得改进了。对了，你也可以打开代码查看实际发生了哪些更改。

好的，关于稳定性问题，你可以指示代理去探索量化方法。但这不仅仅是改变模型配置，因为我们的目标不仅是进行超参数调优，还想尝试更激进的方法。

我认为这并不相关，时钟似乎没有遵循指令。我们支持将自定义代码代理带入我们的仪表板，这被称为桥接会话。这样你可以同时查看仪表板的树状结构、指标以及时钟代码，从而引导整个搜索过程的方向。

接下来进入竞赛环节，这部分不需要使用 Modal 支付功能。原本设计为30分钟的限时挑战，但现在允许大家直到今天结束前持续进行。

大家都玩过《Flappy Bird》吧？这次我们要举办的是“Fl扑杯”。核心玩法依然是点击屏幕让小鸟飞行，躲避管道以争取最高分。我们将这个游戏转化为自动研究问题：不再由玩家直接操作，而是有一个名为“should flap”的控制器决定每一帧小鸟是否扇动翅膀。你的任务就是优化这个控制器，目标是让平均得分尽可能高。

为了增加难度，我们在四个不同的世界中运行此挑战：第一是经典模式；第二是管道间隙上下漂移的移动间隙模式；第三是有风将小鸟吹偏的风力模式；第四是混合了所有条件的可变世界。最终得分基于这四个世界的平均分，因此不能只专注于某一种情况。此外，排行榜分数基于你看不见的隐藏验证集计算，以防止过拟合公开游戏数据。

为确保公平且系统稳定，有一些规则：你只能编辑 controller.py 文件中的控制器代码。必须保持 should flap 函数的签名完全不变，不得修改游戏逻辑或评估器。禁止使用外部库导入、文件IO等操作，以保持代码的自包含性。同时，为了公平起见，不允许使用并行计算。所有参赛者默认使用相同的模型 Opus 4.8，确保起跑线一致。请注意，本地测试分数可能与排行榜不符，因为存在隐藏测试集。

建议从基线代码开始改进，而不是重写整个控制器。尝试进行小而专注的编辑，例如调整安全边际、速度阈值或底部缓冲区域，针对不同世界微调行为。也可以尝试今天讨论过的其他功能，比如检查表现良好的节点并在此基础上构建，或者引入外部想法。

本次竞赛的奖品是一台 Nintendo Switch 游戏机。获胜者将由团队名称关联的电子邮件地址确定，今天结束前得分最高的人将获得联系机会。在此期间，欢迎大家通过 Slido 提问或举手示意。

目前看来分数正在陆续提交中。有个名为 Fern Nog 的参赛者有些可疑，因为只有一个节点在运行，我们将检查所有运行情况以确保没有作弊行为。比赛将持续到今晚午夜。我们会通过你提交的电子邮件或运行记录中的信息联系获胜者，你也可以直接在我们的网站上联系我们。请大家继续挑战，感谢大家的参与！