Knowledge VaultReading Workbench
Reading Detail

看到挺多人对自动化ai科研感兴趣,我来分享一点自己的经验

LINUX DO - 热门话题 · 2026-04-10
#开发调优
Open Original
inboxunread

Snapshot Reader

Captured

更新:Claude支持Monitor tool了。让我测试一下是否能解决我们这套监控的问题

开场先叠个甲,CS PhD 在读,发过 CVPR、ICCV、ICML、NeurIPS等。Claude官方max订阅。ChatGPT pro订阅,以及Gemini Ultra。
首先,现在 AI 写论文这件事已经非常成熟了。如果你只是写一些不需要任何实验的论文,我觉得它是完全可以胜任的,甚至它会写得比你还好,只不过需要一些 Harness 以及skill来适配你的工作流。

重新编辑把所有内容放到主楼层了。

但是我现在想讨论的是 Deep Learning 方向的科研任务。AI 是否能完整地解决 Deep Learning 的任务,主要分为以下几个过程:

  1. 文献调研
  2. 确定 Baseline
  3. 确定 Idea
  4. 写代码跑实验(实现 Idea)
  5. 分析实验
  6. 写论文

我真正尝试了几次,自己也搭了多套系统,纯skill方式,agent方式,魔改omc/omcodex等,都会发现最起码到目前为止,它还是没有办法完全自由推进。过程中确实会有一些让人 Amazing 的点,但更多的时候,它还是会在一个地方陷进去打转。
先说模型使用的问题,如果你想拥有最好的性能,三家模型肯定都是要用的。因为首先它们擅长的侧重点不同,其次,多元模型交叉可以互相 review。

这种情况下是防止幻觉以及提升能力最好的办法,类似于只要写过代码都知道,ensemble 是无痛提点的最好方式。

其次,关于文献调研。

首先,AI 的文献调研能力一定是比人强的。我发现找调研(survey)这个过程中有很多值得探索的点,比如大模型是怎么读内容的:是让它自己通过 Web Search 读原文,还是你给它下载好 PDF 之后再喂给它读?以及是直接读PDF还是转markdown在读,这里面有很大的探索空间,也就是怎么把这个流程做到最稳定、最可用。

另外我发现,如果让它读一些论文,因为论文动辄三四十页,它其实会“偷懒”,只读前三页。但事实上,也不需要把一篇 PDF 完整地读完,因为里面很多信息是你只在特定时候才需要的。

比如说:

  1. 比对结果的时候,你才需要看实验结果。
  2. 在最开始,你可能只需要看一个摘要和引言(introduction),就可以判断它到底能不能被你用到。

另外发现最核心的问题是,针对一个点不断翻找、搜论文的时候,系统一定能搜到很好的论文并基于此提出 idea。但我当时考虑的流程是:

  1. 首先会提出很多 idea。
  2. 然后交叉 review,看哪个 idea 更好。
  3. 确定这个 idea 后,再出发去看看有没有润色、打磨的点,以及它的 novelty 够不够。

在这个过程中,基于idea搜论文最大的问题是找到的文献太多了。所以按严格标准来算,你的所有 idea 都没有 novelty。但事实上,这些 idea 可能已经比绝大多数 CVPR 的方法更有新意了。

所以这个评判标准很难界定,而且受模型影响很大。

如果让他确定 Idea 以后从零开始写代码的话,效果一定会很差,这个毋庸置疑。我把这个放在最先,希望大家不要在上面浪费时间。如果你看到开源项目连这点都没有考虑的话,可以直接放弃它,它是不可能好用的。或者最起码,它不可能帮你发出一篇实验能复现、没有任何幻觉造假的 Top Conference 论文。

所以我们一定要找到一个 Baseline。当然,最简单的方式是你已经确定了研究方向和 Baseline,然后基于它去修改,这样就可以跳过这一步。

基于 Baseline 的话,就到了我们的复现环节。复现 Baseline 的主要意义在于:既然 AI 跑这些任务很容易,我们可以简单复现一下 Baseline 的结果,方便观察我们的 Idea 是不是真的 Work。

复现过程中需要安装环境和下载数据集,这里其实有蛮多坑的:

  1. 网络连接不稳定:尤其是服务器在国内的话,连接各种资源非常不稳定。
  2. 缺乏监控机制:它毕竟是大语言模型驱动的。比如它去下载一个数据集,如果没有监控,可能第一秒就挂掉了,但没有人管它。
  3. 进程阻塞:装环境的时候如果报错就会卡住。

我当时觉得这些任务都应该交给 Sub-agent,或者通过 exec 调用。我不想让它在主线程运行,一方面是在主线程会影响上下文,另一方面是会让我卡在前台等待,而这明明是可以并行处理的。

因此我加了很多监控机制。我考虑过用 Python 写一些 watchdog,或者是加一些心跳轮询之类的机制,但是都不是很 work。

尤其是叠加了 SSH 服务器、给服务器配代理这些操作,以及服务器上可能有数据集不需要下载,但是要验证数据集完整性等问题,导致这件事变得非常 tricky。

因此,我目前也没有想到能完美解决这件事的方式。它可能有能力帮你全做完,但用的不一定是你想要的方式。比如:服务器上其实已有这个数据集,它却给你重新下载一套
但是这个是针对全自动化的。如果你自己已经下好,并且能告诉它路径的话,它其实可以避免这个问题。

Idea 实现以后,深度学习实验最大的问题就是你如何判断这个实验是否值得跑,以及它是否真的在运行。

大模型遇到的最大问题是:代码改好跑起来后,系统就一直在等,以为它已经正常运行了,可能第一秒就挂了。这个倒是有办法解决,但更大的问题在于:

  1. GPU 利用率不高:这需要单独处理。
  2. Loss 直接 NAN:这也得及时处理。

所以这些细节都是一个完善的科研系统必须要考虑的事情。必须让 GPU 得到最大的利用,并且在实验出现明显不行的信号时,第一时间进行处理。
3. 异常信号处理:或者还有一些情况,就是 Loss 可能没有出现 NaN,但是已经有一些明显的信号表明这个实验继续下去没有意义。由于 GPU 资源是一件很昂贵的事情,所以我们当然希望这种情况也能得到处理。

另外还有一个比较重要的,是多种模型之间如何交互的问题:到底是用 MCP、Exec 还是别的方式?

目前我自己的感受如下:

  1. MCP 是一定不能考虑的方式,最垃圾的方式。
  2. 最好区分是一次执行的任务还是多轮执行的任务
    (a) 需要上下文的,可以通过 T-Max 开 Panel,让他们可以实时交互
    (b) 一次执行Exec即可。

写到这儿突然发现,忘了说一个很重要的问题:多个模型到底如何交互?
目前看下来,因为前面也提到了一定要运用多个模型的能力,主要的使用方式可能有两种:

  1. EXEC。
  2. 让他们能主动交互的 tmux 开 panel。

第一种方式用来最简单的review,比如同时10个idea,10个并行exec命令review idea。第二种方式可以实现主的调度器给任何的 session 发信息,并且可以追问,保持上下文。

还有就是上下文管理的问题。我花了很多时间来尝试,能不能让我的每一个 session 都有我想要让它有的上下文。

但我发现目前来看,不知道是我还没调教好,还是确实比较困难,效果不是特别好。但我还是会尽量让它干净一点,所以主调度其实不做任何事情。
因此参考 Harness Engineering,我主要做的改进如下:

  1. 优化 Session 交互与状态记录
    不管怎么开启 Session 都方便交互,系统会记录当前的进度、具体做到哪里,以及是否存在活跃的 Task,防止开了新 Session 以后,甚至不知道有 GPU 任务已经在跑。
  2. 规范 Agent 间的交付流程
    不同的 Agent 之间会有明确的输入输出格式,并且通过在磁盘上读文件的方式来完成他们的输入。

因为主要是分享自己用的过程中的一些感受,还没做好写一个教程的准备。毕竟自己也是初步的探索,所以就是基本想到哪儿说到哪儿。

整篇帖子由 Typeless 完成输入。

84 个帖子 - 39 位参与者

阅读完整话题