這幾年，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也是因為能夠生成倉庫級的代碼從而在程序員中流行起來。

LLM驅動的科學研究

科學進步的過程通常是一個想法生成、假設驗證和實驗執行的循環。

LLMs已被應用于這個循環的各個階段，包括研究構思、假設生成和同行評審，從而幫助研究人員克服現有局限并加速科學發現。

在計算機科學和機器學習中，基于代碼的實驗是基礎，LLMs也被用來設計增強現有代碼庫的實驗。

PaperBench引入了一個基準測試，在該測試中AI智能體嘗試重現機器學習論文。

通過專注于庫級別的重現，PaperCode將LLM驅動的自動化范圍擴展到了構思和假設生成之外，為科學研究中一個關鍵但尚未充分探索的方面做出了貢獻。

PaperCode的三步走

在機器學習研究中，實驗通常使用代碼進行。然而，在很多情況下，研究人員并不發布他們的代碼，這使得其他人難以重現和驗證所提出的方法和實驗。

當非作者嘗試手動重新實現代碼時，這個過程往往是勞動密集型且耗時的。

受到軟件開發方法論的啟發，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的應用范圍主要集中在機器學習，未來要是能擴展到其他科學領域，那就更厲害了。