新智元报道
新智元报道
【新智元导读】科研成果「复现」新革命！还在为堆积如山的论文和难以复现的代码发愁吗？Paper2Code能直接「阅读」机器学习论文，自动生成高质量、可运行的代码库。它通过智能规划、分析、生成三步，效率远超人类，有望极大加速科研迭代，告别「重复造轮子」的烦恼！
这几年，AI领域的科研人员遇到一个问题。
那就是机器学习的论文实在是多到看不过来，更别说还要用代码实现论文中逻辑。
HuggingFace上的「每日论文」板块每天都有十几篇新出的研究论文
这导致一个问题，研究者往往「重视结果」而没有精力来用用代码验证，并且复现很多先前的工作有点「重复造轮子」，浪费研究者的精力。
但与此同时，目前的AI——像o3/Gemini 2.5系列等——在理解科学文献和高质量代码上表现非常好，像Andrej Karpathy、吴恩达等顶级研究者和科学家都在推崇使用AI的「编程氛围」。
有没有办法用现在这些「前沿AI」的能力解决这个问题？
韩国科学技术院和DeepAuto.ai针对这个问题推出了名为Paper2Code的多智能体框架（又名PaperCode），可将机器学习论文直接转换为可用的功能代码库。
论文地址：https://arxiv.org/pdf/2504.17192
一般来讲，单独一个智能体或者LLM很难将一篇论文直接转换为可用代码库（下图左）。
PaperCode多智能体框架通过将任务分为三个阶段：规划阶段、分析阶段和生成阶段。
此外，每个阶段都通过一组专门设计的智能体来实例化这个过程。
这个项目已经开源，如果真的可以让AI「看论文」，并且将论文逻辑用代码实现，确实可以为科研工作者省去很多不必要的精力。
项目开源后，网友突然调侃，你能不能用Paper2Code生成Paper2Code的代码呢。
可重复性（Reproducibility）是科学进步的核心。
通过复现其他人所宣称的科研成果，可以使研究人员验证、并基于公布的成果进行构建，最终推动人类整体知识的边界。
然而因为文档不完整、缺少实验细节、无法访问数据或专有工具，特别是在机器学习研究中，缺乏相应的代码：例如，只有 21.23%的论文在 2024 年被顶级机器学习会议接受并提供了其代码实现，如下图所示。
因此，这种复现他人的成果的过程费时费力。
研究人员经常需要投入大量精力从论文中逆向工程方法和实验结果，这一过程减缓了整体科学创新的步伐。
PaperCoder，是一个多智能体的LLM驱动框架，旨在直接从研究论文中自动生成机器学习的可执行代码库，并与研究论文内容相上下文关联。
具体来说，PaperCoder旨在通过将任务分解为三个结构化阶段来模拟人类开发者和研究人员编写仓库级代码的典型生命周期：
1. 首先，在规划阶段，框架构建了一个高层次路线图以确定要实现的核心组件，绘制了类图和序列图来建模模块之间的结构关系，识别了文件依赖关系及其执行顺序以指导正确的构建和执行流程，并生成了配置文件以使人类研究人员能够灵活定制实验工作流。
2. 接下来是分析阶段，对每个文件和函数进行细致的解析，以理解其预期功能，例如所需的输入和输出、与其他模块的交互，以及从源论文中得出的任何算法或架构约束。
3. 最后，在生成阶段，框架根据先前确定的执行顺序以及前几个阶段产生的工件来合成整个代码库。
为了验证PaperCoder的有效性，在2024年顶级会议（包括 NeurIPS、ICML 和 ICLR）上接受的最近机器学习论文的一个子集上进行了广泛的评估——这也被称为Paper2Code基准。
此外，还将最近OpenAI发布的PaperBench基准纳入评估套件中，从而能够对来自 ICML2024的一些论文的代码实现进行细粒度的评估。
论文地址：https://arxiv.org/pdf/2504.01848
基于LLM的代码生成可以大致分为单文件编码和多文件（仓库级）编码。
单文件编码侧重于生成相对较短的代码片段以解决孤立的任务，例如编程竞赛问题或简单的编码查询。
随着LLM在代码理解、长上下文推理和处理复杂工作流程方面的进步，研究越来越多地转向仓库级编码，其中在联合考虑架构和功能需求的同时生成多个文件。
最近很火的Cursor、Windsurf等AI编程IDE也是因为能够生成仓库级的代码从而在程序员中流行起来。
科学进步的过程通常是一个想法生成、假设验证和实验执行的循环。
LLMs已被应用于这个循环的各个阶段，包括研究构思、假设生成和同行评审，从而帮助研究人员克服现有局限并加速科学发现。
在计算机科学和机器学习中，基于代码的实验是基础，LLMs也被用来设计增强现有代码库的实验。
PaperBench引入了一个基准测试，在该测试中AI智能体尝试重现机器学习论文。
通过专注于库级别的重现，PaperCode将LLM驱动的自动化范围扩展到了构思和假设生成之外，为科学研究中一个关键但尚未充分探索的方面做出了贡献。
在机器学习研究中，实验通常使用代码进行。然而，在很多情况下，研究人员并不发布他们的代码，这使得其他人难以重现和验证所提出的方法和实验。
当非作者尝试手动重新实现代码时，这个过程往往是劳动密集型且耗时的。
受到软件开发方法论的启发，PaperCode采用了一种结构化的方法，该方法反映了经过充分验证的软件工程原则。
提供研究论文作为模型的输入并期望它生成一个完整的仓库是非常具有挑战性的。
研究论文主要是为了记录发现和说服读者，而不是作为软件开发的结构化输入。
因此，论文中通常包含补充信息，这些信息虽然对于传达核心概念是必要的，但与实现并不直接相关。
这可能会引入噪音，使仓库生成变得困难且效果较差。
为了解决这一挑战，PaperCode建议将论文分解成一个结构化的多方面计划，而不是仅仅使用论文作为输入。
这种方法将关键的实现相关元素组织成四个不同的组件，确保生成的仓库结构良好，并与论文的方法论一致。
总体计划
规划阶段的第一步，总体计划，涉及从高层次角度总结和组织实施研究库所需的核心要素。
该摘要提供了一个基本的概念框架，明确指导后续步骤。
架构设计
第二阶段涉及根据前一阶段生成的总体计划和研究论文来架构软件。
设计一个结构良好的架构是必不可少的，特别是对于必须无缝交互的多个功能的软件系统。
此阶段的重点是识别必要的组件并定义它们之间的关系，以确保一个组织良好且功能性的仓库。为此，PaperCode要求创建定义软件架构的关键工件。
文件列表是仓库所需文件的结构化集合，概述了软件的模块化结构。
类图提供了系统的数据结构和接口的静态表示。使用统一建模语言（UML）符号，这是一种用于建模软件系统的标准化视觉语言。
PaperCode将类表示为矩形，将属性和方法表示为列表，并用连接线来说明不同组件如何交互。 序列图动态地表示了程序的调用流程和对象交互，使用 UML 符号将参与者表示为对象，消息表示为箭头，生命线表示为虚线，直观地展示了组件如何随时间进行通信。
这种结构化的方法确保了软件架构的清晰和有组织的表示。
通过构建这些工件，PaperCode直观地表示了研究论文中描述的关键组件，使存储库生成更加结构化和系统化。
这一过程有助于更好地分析依赖关系和关联性，确保生成的存储库与论文的核心思想一致。
逻辑设计
在软件开发中，单个文件很少孤立地工作。
相反，它们通常通过导入和模块交互表现出相互依赖性。
例如，如果函数A在utils.py中定义，然后被导入到evaluation.py中，那么为了保持正确的依赖结构，必须先实现 utils.py再实现evaluation.py。
为了处理这些依赖关系，此阶段将研究论文以及前两个阶段生成的工件作为输入。然后分析每个文件及其组件的逻辑，确定必要的依赖关系和最优执行顺序。
作为输出，它生成一个有序的文件列表，详细说明每个文件的角色，考虑依赖关系时应实现哪些文件及其在仓库中的依赖关系。
这种方法确保了仓库生成不仅考虑单个文件结构，还考虑文件间的通信，从而促进了一个组织良好且逻辑连贯的实现。
配置文件生成
最后，配置文件生成步骤综合所有先前确定的输出，生成一个包含模型训练所需超参数和配置的配置文件（config.yaml）。
此过程以前一阶段产生的总体计划、架构设计和有序文件列表作为输入。
在此阶段，用户可以审查和修改config.yaml文件，以识别和纠正任何缺失或错误指定的细节。
例如，用户可能需要指定通往Hugging Face数据集的路径或定义检查点存储目录。
这一步有助于减少生成过程中出现的幻觉，例如模型产生不存在的数据集或引用错误的文件路径。
虽然规划阶段主要关注设计整体仓库结构和概述高层路线图，但分析阶段则深入到每个单独文件的具体实现细节。
在这个阶段，会彻底分析仓库中每个文件的详细目的和必要考虑因素。
此阶段生成的输出明确指定了每个文件应实现的目标，并强调了成功实施所需的关键因素。
具体来说，分析阶段的输入包括原始研究论文和先前生成的工件（总体计划、架构设计、逻辑设计和配置文件）。
该阶段的输出包括文件级别的分析文档，记录了精确的实现细节，这些细节将为后续的代码生成过程提供信息。
最后阶段是编码阶段，该阶段生成构成研究仓库的代码。
每个文件的生成都由前几个阶段的综合输出指导：研究论文本身、总体计划、架构设计、逻辑设计、配置文件、特定文件分析以及先前生成的代码。
由于仓库文件之间经常存在导入依赖关系，PaperCode严格遵循规划阶段建立的有序文件列表，以确保顺序一致性。
最初生成的代码可能需要后续调试或完善以确保正确性和完全功能性。
在这项工作中，全面的调试策略和详细的错误修正工作流程超出了本文的当前范围。
研究人员进行了一系列严格的实验和评估，构建了两个基准测试。
一个是Paper2Code基准测试，选取了2024年ICML、NeurIPS和ICLR会议上的90篇论文。
这些论文都是经过筛选的，不仅有公开的GitHub代码库，且代码库规模适中，便于进行实验验证。
另一个是PaperBench Code-Dev基准测试，包含了20篇来自ICML 2024的论文，以衡量的是复现论文的准确性。
在实验中，PaperCoder和基线模型进行了对比，ChatDev是一个多智能体框架，通过智能体对话来开发软件；MetaGPT则采用基于角色的多智能体范式进行软件开发。
此外，还有一些比较简单的基线模型，比如只给模型论文摘要（Abstract），或者整篇论文（Paper），让模型生成代码库。
论文作者发布的官方代码库（Oracle）代表了最理想的实现。
研究团队采用了多种评估方法，包括基于模型的评估和人工评估。
基于模型的评估分两种情况：一种是有参考的评估。
当有作者发布的官方代码库时，评估模型会将生成的代码库与论文和官方代码库进行对比，从1到5分进行打分，分数越高表示生成的代码库与官方实现越接近，组件覆盖越全面，错误越少。
另一种是无参考的评估，只靠论文来评估生成的代码库。
在没有官方代码库的情况下，仅依靠论文和生成的代码库进行评估，同样让评估模型去推断和评判代码库是否实现了论文中的关键组件，并给出相应的分数。
人工评估则邀请了硕士和博士研究生参与。这些参与者都有丰富的科研经验，至少发表过一篇同行评审论文。
他们会根据论文内容制定关键的实现标准，然后对不同方法生成的代码库进行比较和排名。
在排名过程中，仔细考量代码库的各个方面，如完整性、结构合理性、对论文方法的忠实度等。
经过一系列严格的实验和评估，在所有会议和两种评估模式下，PaperCoder的表现遥遥领先于其他基线模型。
在基于参考的评估中，PaperCoder在ICML、NeurIPS和ICLR论文上的平均正确性得分分别达到了3.72、3.83和3.68；在无参考评估里，得分更是高达4.73、4.77和4.73，直接碾压其他模型。
与ChatDev和MetaGPT等基线模型相比，PaperCoder生成的代码库不仅质量高，而且细节更丰富。
ChatDev生成的文件数量和PaperCoder相近，但是PaperCoder生成的函数数量明显更多，这意味着它生成的代码库功能更完善。MetaGPT 在评估得分和代码数量指标上都明显落后。
那些只使用摘要或者全文的简单基线模型，和PaperCoder相比就更不尽如人意了。这充分证明了PaperCoder多阶段框架的强大优势。
在人工评估中，PaperCoder同样表现出色。在所有评估标准下，PaperCoder都拿到了最高分。
77%的参与者认为PaperCoder生成的代码库最适合复现他们的研究，代码库完整性好、结构清晰，和论文契合。
85%的人认为用PaperCoder生成的代码库复现实验，比自己从头开始写代码容易多了。
从具体的评估指标来看，PaperCoder在完整性、结构清晰性和对论文的忠实度等方面都得到了高度认可。
详细分析生成代码库，发现数据处理、方法和评估这三个主要部分的覆盖率分别达到了48%、85%和70%。
虽然还存在一些改进空间，但这已经足以说明PaperCoder生成的代码库具有很高的实用价值。
研究分析了基于参考和无参考评估之间的相关性，发现这两种评估得分的相关性非常强，皮尔逊相关系数达到了 0.79，p值也很显著。
说明在没有官方代码库作为参考的时候，无参考评估也能很好地衡量代码库的质量，是一种可靠的评估方法。
团队还研究了不同大语言模型对PaperCoder性能的影响。
他们用了4种不同的LLM进行实验，发现o3-mini-high这个模型在所有评估维度上都表现得最好。
此外，研究人员还进行了消融实验，探究PaperCoder各个模块的重要性。
结果表明，随着逐步添加规划、架构设计、核心逻辑、配置文件和分析等模块，模型的性能稳步提升。
虽然添加架构设计模块的时候，性能暂时下降了，但后续加入核心逻辑等组件后，分数又大幅提高了。
最后，研究团队还测试了生成代码的可执行性。
他们手动调试了五个有代表性的论文生成的代码库，发现平均只需要修改0.48%的代码，就能成功运行。
而且这些修改大多是像更新API调用版本、纠正类型转换这样的常规操作。这说明PaperCoder生成的代码不仅结构合理，而且实用性很强。
目前，PaperCoder的应用范围主要集中在机器学习，未来要是能扩展到其他科学领域，那就更厉害了。
（文：新智元）