AutoSOTA 论文解读

发表于 更新于 分类于
这个论文做的是，从一篇有开源代码库的论文开始，复现论文项目，然后再将这个论文的指标优化高。 没开源 AgentResource 因为现在的论文严重依赖于大规模数据集，预先训练的权重和专门的ckpt。 所以这里做了一个外部资源获取模块。 这个模块由两个阶段构成 符号化资源获取 ze...

这个论文做的是，从一篇有开源代码库的论文开始，复现论文项目，然后再将这个论文的指标优化高。

没开源

AgentResource

因为现在的论文严重依赖于大规模数据集，预先训练的权重和专门的ckpt。

所以这里做了一个外部资源获取模块。 这个模块由两个阶段构成

  • 符号化资源获取

    • zero-download constraint 首先是系统仅通过解析仓库的内部结构和评估清单(这里是人工编写的rubric.csv清单。)来提取信息，这部分不下载，节约下载带宽

    • 建立全局资源注册表 这个表对于每一篇论文（通过唯一序列号 seq 标识），系统会记录：

      • 资源来源的 URL。
      • 资源分类（如：是数据集还是模型）。
      • 预估的文件大小。

    • 最后计算总工作量指标\(S_{total} = \text{cal_total_size_bytes}\)

      \(\text{cal_total_size_bytes}\)是一个作为下游调度和计算资源分配的主要启发式的度量

  • 物理获取与编排 这个阶段基于第一阶段生成的“资源清单”，安全、可靠地将虚拟的元数据转化为本地的物理文件。 同时严格基于注册表执行，不重新扫描原始仓库。
    • 门控选择和过滤 只有\(S_{total} \in [S_{min},S_{max}]\)之间的任务才允许进入执行队列。然后具有不确定或者负大小的任务被抢先丢弃。还有个重复任务拦截层防止失败的没有下载，成功的重复下载。
    • 语义储存架构 资源以变成方式了路由到标准化的分层目录下。(还要确保跨平台文件系统兼容从而替换非法字符并截断为最多80字)正常做法，写的很细
    • 多态检索模式 针对不同的资源来源，系统支持多种定制的检索策略：
      • 基于规则的模式： 对于标准分发渠道，采用模式匹配，如，识别到 HuggingFace 仓库时使用优化过的 huggingface-cli 获取
      • LLM 驱动的自主模式： 对于非标准或结构复杂的来源，系统会调用大语言模型（LLM）来生成并执行自定义的 Python 脚本，从而自动应对复杂的下载界面。
    • 并发与容错机制 允许多个任务同时并发下载，提供异步监控服务，实时追踪磁盘 I/O 并动态映射进度 维护一个全局的内存级 URL 映射表，原生支持去重和断点续传，自动从活跃队列中过滤掉已成功下载的 URL。

在下载完成过后，这些论文就转换成了可执行任务单元，提供规范代码，数据集，模型权重。

AgentObjective

  • 任务目标树形递归分解

利用BFS算法，系统扩展属性结构的题目。从表示论文完整复现的根节点开始，动态的将任务分解成多个二进制子任务。

然后这里还有一个权重驱动的终止机制， 根节点为1，然后第一层节点的权重和为1，然后依次向后分解。到阈值或者达到最大逻辑生长，则停止。

  • 分层上下文注入。这个也挺好的。 这里的上下文注入是为了任务目标树作用的。

论文里面的信息 1. 将PDF转成markdown。 2. 将里面的图片进行视觉理解 VLM 3. 官方代码库的工程细节 这里的官方代码库的工程细节的注入需要进一步探索。但是他没有源码 上下文注入式根据BFS任务分解过程的深度来被动态触发的。被分成三个逻辑层 - 浅层策略层: 在树形结构的标题顶点，系统只注入宏观层次的信息，如目录，摘要等，防止过早被技术细节淹没。

  • 中间技术层: 随着任务分解进入算法模块，详细的方法和实验部分与VLM的视觉证据一起引入

  • 深层实现层: 在到达设计原子工程操作的节点，Agent激活存储库级别的上下文。

AgentInit

构建论文的可执行环境

这部分Agent是使用预设的工作流的。包括输入分析，子任务分解，环境构建，依赖性解析、资源获取、存储库检查、命令发现和执行准备。

具体流程: 1. 目标分析与任务分解 分析论文、代码仓库、资源文件及 rubric 中的目标指标，明确需要复现的实验，并将初始化过程拆分为环境、依赖、数据、模型、命令和配置等子任务。 2. 环境与资源准备 构建并验证 Docker 运行环境，检查 GPU、CUDA、Python 和 PyTorch 兼容性，安装依赖，并获取所需数据集、预训练模型和检查点。 3. 仓库检查与协议保持型修复 检查 README、文件结构和代码入口，修复硬编码路径、缺失的连接逻辑或非核心脚本，同时保持原始评估协议、数据划分和目标实验设置不变。 4. 命令恢复与执行接口生成 确定训练和评估入口，恢复完整执行命令和实验配置，最终输出可运行的仓库状态、已验证的容器环境及后续执行计划。

AgentMonitor

跟踪长期执行并防止死锁

论文中提及，设计这个Agent的原因是： 自动paper环境复现如果单纯使用主执行Agent，会 1. 陷入本地调试循环，反复尝试低价值修复而没有取得真正的进展， 2. 失去对全局目标的认识，并过度关注工程细节。

AgentMonitor这个Agent是跟踪主执行Agent的。本身并不对环境进行任何更改或者操作。

主要有两项核心能力 1. 在线执行轨迹理解 实时分析主执行Agent在干啥 2. 外部状态跟踪 将重要信息保存到模型上下文之外

  • 执行跟踪和死锁干预 在同一个失败依赖项重复安装尝试，或者没有进展的长时间输出等会被识别为死锁。检测到这种状态过后，AgentMonitor会生成高级纠正指导。典型动作如下:
    1. Continue：继续
    2. Resume with guidance：带指导继续,即切换到手动设置，或者咨询专门的skill。
    3. Fallback：切换备用方案
    4. Terminate：终止
    5. Rollback：回退 同时Monitor剩余的全局预算会限制交互轮数。超过超时阈值时会终止执行。
  • 通过外部存储器的持久上下文管理 这一部分主要是管理临界状态信息的。包括 代码库、评估输出、历史修改记录、当前想法库和累积的研究见解。

这玩意直接做了3个md文档 - code_analysis.md
> 这个文件通过对目标存储库的一次性的探索，构建出来的一个代码认知图。 - idea_library.md > 一个动态演化的想法库，记录所有候选想法，尝试修改以及对应的结果。 - research_report.md > 通过专门的研究阶段填充的外部知识库。提供相关文献里面的简洁，技术，经验配置，优化策略等。

在这两个基础上，系统采取两种互补的机制 1. 一次性提取阶段将存储库的全局结构压缩为持久表示。消除了重复的全存储库扫描。 2. Agent通过命令行操作:(符号搜索，模式匹配等)按需检索。这个需要进一步设计允许本地代码库的部分相关代码加载到上下文。

AgentFix

  • 通过先验的高频故障家族使用明确的修复skill对当前故障进行修复。
  • 对于没有匹配到的修复，让Agent自行修复。为了防止AgentFix脱离论文复现条件的约束。(论文中通过一个科学协议来说明。这部分需要查看源码进一步查看)论文中安排了一个AgentSupervisor限制其的工程修复空间。
  • 故障记忆机制。 > 这部分似乎是说通过将重复的成功提炼成一个md文档。但是没有源码我并不是很确定

AgentIdeator

这个Ideator是在论文要求的基础上进行假设的，论文说这里和其他不同，说明或许有其他的论文是将假设生成作为一个天马行空的想法生成器的。

AgentIdeator在下面的限制下 - Metric Alignment 假设必须针对文件中报告的具体目标，而不是通用的绩效指标 - Implementation Alignment 建议必须相对于复制环境和代码库的实际能力保持合理性 - Constraint Alignment 保留了关键的不变量，例如评估逻辑、数据集分割和核心方法的理论边界 - Lever Alignment 高价值的优化“杠杆”被确定为将抽象知识连接到代码中的具体干预点。 这些限制用来保证生成的假设必须在论文实验的边界内

最终的输出按照粒度$(h) PARAM,CODE,ALGO $并分配一个风险级别 \(\rho(h) \in \lbrace LOW,MEDIUM,HIGH \rbrace\) 同时定义一个权限谓词\(Adm(h)\) \[Adm(h) = \begin{cases} 1 & \text{if } h \text{ preserves evaluation integrity} \\ 0 & \text{if } h \text{ invokes prohibited shortcuts} \end{cases}\]

然后得到最终的假设集合 \[ H_{adm} = \lbrace h \in H:Adm(h) =1 \rbrace \]

AgentScheduler

负责管理论文复制的整个生命周期，从环境初始化、基线测量到迭代代码修改和评估，最后到状态持久化和结果导出，包括优化策略和资源管理两个关键机制。

  • 优化策略

Scientific Protocol 生成

首先我们通过LLM作为scientific protocol 生成器。这个生成器的 - 对整个代码库的深入理解，包括跨文件的依赖关系，跨算法阶段的数据流和评估协议约束。 - 对最新研究的认识，能够识别结构平静并检索相关改进。

整个优化工作流

  1. 环境优化和基线测量 执行基本的初始化任务。 然后执行完整的evaluate在本地完成指标测量。用本地测量的指标进行比较。

  2. 代码和论文理解 系统性探索代码库结构，检查评估脚本，识别算法分支，给出完整的推理过程，并估计每次评估的时间。 最后输出code_analysis.md 这个阶段还要被constraints限制。constraints限制的不变量会被后面的AgentSupervisor接受并提供指导。

  3. 思想库构建 一个列出候选优化方向的结构化文档。 Idea的结构化表示：[(type(PARAM,CODE,ALGO) ，风险级别，实施假设)] Idea按照三个粒度级别组织:micro(单一参数调整)，meso(函数级别算法改进), macro(流水线阶段重构)

    初始的时候我们的Idea库至少包含10个想法，按可行性和优化潜力进行优先级排序。

    这个阶段结束后对所有Idea进行审核，并将违规的Idea标记为Reject。

  4. 迭代优化循环

    1. 迭代前Reflection
    2. Idea选择
    3. 代码实现
      1. Git Snapshot 保存当前代码状态，同时记录git COMMITID
      2. 代码实现 在这一段里面有一个Normal path和Leap Path的机制。
      • Normal Path是从已有的idea库中选择一个通过审核的想法去执行,
      • Leap Path是一个强制跳出局部搜索的机制。 如：最近三轮都是PARAM-type的调整，那么当前轮必须进入Leap Path。必须提出一个新的，结构性更强的想法。 对于Leap Path提出的新机制，还会提供一个Honeymoon Period。因为提出的机制可能是有用的，但是因为我们调参等各种各样的原因，没有使指标更高。但这并不代表这玩意没用。这个Period设定是用来允许系统继续尝试Leap Path提出的结构的。
    4. 评估
    5. Debugging 如果出现多次崩溃等，会直接回滚。
    6. 结果记录
    7. 创意库更新 循环持续到MAX_ITERATIONS或者指标超过预定义的阈值

  5. 容器恢复到 _best状态，主机生成对应的docker image保证结果可复现。

  • 资源管理 在系统级管理多篇论文和多个GPU的全局资源框架。这里有一个统一的全局任务队列。 感觉比较常规

AgentSupervisor

这个是确保自动化研究系统长期优化过程一致的Agent。

核心机制为红线系统: 一组六个不可协商的约束和一个随论文改变的约束，在优化工作流的多个点强制执行。

  • 评估指标参数不得更改
  • 必须保持评估脚本完整性
  • 算法输出的完整性不得违反
  • 度量维度之间没有不公平的权衡 主要优化目标度量的改进不能以其他报告度量的显著降级为代价。系统需要在每次迭代中报告所有度量，并且明确约束交叉度量权衡。
  • 必须保持数据集完整性
  • 禁止修改数据集
  • 必须明确识别并严格遵循特定于论文的约束：每篇论文的实验设置引入了独特的可比性要求。

然后对于这些约束，不是单点检查的。是面向整个过程的多层监督机制。

第一层： 明确要求工程师确定手头特定论文所有的硬约束，并在code_analysis.md文档中的专用"硬约束/红线"列表中列举这些约束。

第二层: 在初始的idea库生成之后，执行强制性的审核。Agent必须在idea_library.md中构建审核表。并根据所有红线验证生成的想法。

第三层: 当第三阶段的Leap Path被触发过后，对于三个候选创新解决方案的每一个，Agent都需要对其进行检查。（因为Leap Path是动态生成的，没有经过第二层的审查）

第四层: 主提示中全局规则部分-约束作为最高优先级的操作原则强制执行，声明为"绝对禁止，在任何情况下都没有例外" 防止模型为了追求更好的指标而合理化违反约束。