ReproRepo 用 GitHub issues 做可重現性稽核

ReproRepo 把 GitHub issues 變成可重用監督訊號，用來擴大機器學習論文的可重現性稽核。

• 研究機構：arXiv 摘要未明確標註
• 核心數據：1,149 篇近期機器學習論文
• 突破點：用人類 issues 當監督

可重現性一直是研究圈的老問題，但它最麻煩的地方，不是大家不知道重要，而是很難規模化地測。你要驗證一個 LLM agent 能不能幫忙做 reproducibility audit，總得先有一套夠真實、又夠大規模的測試資料。問題是，這類 benchmark 往往要靠大量人工整理，成本高，也很難一直擴。

這篇論文的 ReproRepo，就是在解這個痛點。它不從零發明一堆人工任務，而是把 GitHub issues 當成自然生成的 supervision，拿來標記真實世界裡到底是什麼阻礙了重現。

它想解什麼問題

作者先指出一個很實際的瓶頸：reproducibility evaluation 很重要，但現有給 LLM agents 用的 benchmark，通常都很吃手工整理與手工評估。這讓它們難以擴到很多論文、很多 repo、很多失敗類型。

換句話說，問題不只在模型，也在測量方法本身。你如果想知道一個 agent 能不能幫忙稽核可重現性，就需要拿它去面對真實的 blocker；但如果每做一個新 benchmark 都要花大量人力，benchmark 反而成了瓶頸。

ReproRepo 的切入點，就是把這個瓶頸往前推。它把論文和對應的開源程式庫配對，再把 repository 裡人類實際提出的 issues 拿來當標籤，讓模型學到的是現實世界的 debug 痛點，而不是人工編出來的測驗題。

這個方向對開發者很有感，因為它比較接近真實工作流。大家在追 code、看 paper、找 bug 的時候，常常不是卡在單一理論點，而是卡在文件沒寫清楚、實作細節不完整、依賴版本對不上，或是 paper 和 repo 的路徑根本沒對齊。

ReproRepo 怎麼運作

方法本身其實很直接：先把論文和它們釋出的程式庫配對，再把 GitHub issues 裡的人類回報拿來當 reproducibility problem 的訊號。這些 issues 就成了監督資料，反映的是實際有人踩過的坑。

這件事的關鍵不在於 issues 本身新不新，而在於它們夠不夠貼近真實失敗模式。GitHub issues 常常會寫出重現時遇到的摩擦點，例如缺少說明、實作細節含糊、相依套件不合，或某段 code path 跟論文描述對不上。摘要沒有列出更細的 issue 分類，所以只能確定它把這些人類回報當成可重現性阻礙的來源，不能再往下硬拆 taxonomy。

作者把這套框架設計成可重用的評估基礎。也就是說，它不只是做一次性的資料集，而是想成為之後評估 LLM agents 在真實 reproducibility auditing 上表現的工具。這種設計的好處是，未來如果有新的模型或新的 agent 架構，理論上可以直接拿來測，不必每次都重做整套人工標註。

論文把 ReproRepo 實作在 1,149 篇近期機器學習論文上，並評估四種 frontier model-agent 組合。摘要沒有把四組配置完整列出，所以外界目前只能看到一個明確提到的結果：Codex with GPT-5.5。

這裡也要注意，這篇摘要沒有公開完整 benchmark 細節。像是資料切分方式、每個 agent 的完整設定、或全部配置的逐一數值比較，都沒有在摘要裡展開。這代表你可以把它視為一個有方向性的研究結果，但還不能直接當成完整的工程選型依據。

它真正證明了什麼

最醒目的結果，是表現最好的 agent：Codex with GPT-5.5，對資料集中大約 90% 的論文，至少能找出一個語意上相關的人類回報 blocker。這個數字很重要，因為它不是單純說模型「看起來有幫助」，而是指出它常常能把問題定位到正確的語意範圍。

對做 coding agent 或研究工具的人來說，這代表一件事：模型不一定要先真的跑 code，才有機會幫忙找出重現障礙。它有時候只靠 paper 和 repo 的關聯，就能先指出「問題大概在哪裡」，例如是哪一段方法、哪一塊程式、或哪個流程最可能出事。

但論文也把界線畫得很清楚。作者說，這些 agents 對於「可見的失敗」和「語意區域定位」表現不錯，可是對精準定位還不夠可靠。也就是說，它可能知道問題在這個模組附近，卻還不能準確指出是哪個檔案、哪一行，或真正的 root cause。

這個差異很關鍵。因為 reproducibility auditing 跟真正修 bug 不一樣。前者比較像是先判斷哪裡有風險、哪裡值得查；後者則是要真的把問題修掉。ReproRepo 證明的是前者有機會被規模化，不是後者已經被解決。

另外，摘要沒有提供傳統 benchmark 常見的完整數字，例如 accuracy、F1、pass rate 等，也沒有說模型是否會執行程式碼來完成重現。唯一明確公開的量化結果，就是上面那個約 90% 的語意相關 blocker 提示率。這也表示目前能下的結論，應該控制在「能幫忙找方向」而不是「能端到端重現結果」。

對開發者有什麼意義

如果你在做 ML tooling、agentic debugging，或研究基礎設施，ReproRepo 提供了一種很實際的評估思路。它不是拿乾淨的合成題來測模型，而是直接用真實 repo 裡的人類 issue 當題目。這種資料更接近工程現場，因為真實世界本來就充滿模糊描述、缺漏文件和版本相依問題。

對三類人特別有用。第一類是做 code agent 的團隊，因為他們需要知道模型能不能先抓到 blocker。第二類是維護研究 repo 的人，因為他們可以把這種框架想成一種可重現性風險的雷達。第三類是想評估研究流程的組織，因為它提供了一種比較能擴充的測量方式。

更廣一點看，這篇也在提醒 benchmark 設計的一個方向：監督訊號不一定都得從頭人工標。只要生態系本來就會產生有用的訊號，例如 GitHub issue、錯誤回報、或實際除錯紀錄，就可能被轉成可重用的評估資料。這對台灣很多做 AI 工具、DevTools、研究平台的人來說，都是值得參考的思路。

限制在哪裡

第一個限制，是 GitHub issues 不是完美的 reproducibility proxy。不是每個 blocker 都會被人提 issue；有些 issue 寫得很模糊；也有些回報的問題，未必剛好對應 benchmark 真正想量的那個重現障礙。換句話說，它很實用，但不是絕對精準。

第二個限制，是精準定位還不夠好。摘要已經直接說了，agents 在 exact localization 上仍然不足。這意味著 ReproRepo 更像是「先幫你縮小範圍」的工具，而不是可以直接幫你 patch repo、一步重現結果的系統。

第三個限制，是評估範圍。這次資料來自近期的機器學習論文，而且是 major conferences 的脈絡，所以不能直接推論到所有研究領域，也不能直接推論到一般軟體專案。不同領域的 repo 結構、issue 習慣、文件品質，都可能差很多。

最後，摘要也沒有把四種 frontier model-agent 組合的完整比較攤開。這讓我們知道有做多組評估，但還看不到完整的相對差異。對想做實作選型的人來說，這是目前資訊不足的地方。

結論

ReproRepo 的重點，不是炫技式自動化，而是把一個本來很難規模化的問題，做成比較可測的形式。它證明 human-raised GitHub issues 可以變成可重用的監督訊號，拿來做 reproducibility audits，而且 frontier agents 已經能在不少案例裡先抓到真實 blocker。

對開發者來說，這篇的訊號很直接：如果你正在做研究除錯、code agent，或任何跟 paper-to-code 有關的工具，下一個有價值的 benchmark，也許不是合成題，而是 issue tracker 裡那些早就存在的真實問題。

但也別把它看成已經解決可重現性。它更像是把「怎麼有效測這件事」往前推了一大步。能先找到問題在哪裡，已經很有價值；只是離完全自動化重現，還有一段路。