ReviewBench：開源 AI 程式碼審查基準測試

GitHub 發布 ReviewBench 離線基準測試

GitHub 官方部落格近期發布了 ReviewBench，這是一個用來評估 AI 程式碼審查工具的離線基準測試平台。代理式程式碼審查逐漸成為開發流程中的關鍵環節，團隊需要更精確地衡量現有 AI 審查者的品質，判斷它們能不能在程式碼上線前攔截問題，並篩選出值得關注的項目。不同審查系統在捕捉問題數量、雜訊控制以及關鍵缺陷偵測能力上各有差異，因此必須了解各系統的實際表現與取捨。ReviewBench 要填補現有基準測試在標籤品質、覆蓋範圍與真實世界代表性之間的空白，提供一套嚴謹且可重複的評估方法。

數據基礎與真實情境模擬

ReviewBench 的數據基礎，是對 GitHub 平台上 1.039 億個真實拉取請求（Pull Requests）所做的分佈分析。為了讓基準測試反映現實中的程式碼審查負載，該基準測試選取了來自 187 個公開開源授權儲存庫的 219 個拉取請求，涵蓋 19 種程式語言。這些拉取請求在語言與儲存庫規模的分佈上，與 GitHub 整體趨勢高度一致。

值得注意的是，ReviewBench 刻意調整了拉取請求的大小分佈。語言與規模分佈直接對應 GitHub 數據，但拉取請求的大小被加權，偏向可審查的中段與尾部。這樣做是為了減少微小、單一檔案變更的比例，同時保留更多涉及多個檔案、實質內容較多的拉取請求，因為在這些複雜情境中，審查品質更為重要。完整的基準測試數據集已對外公開，供開發者檢視與使用。

多源黃金集與嚴謹驗證機制

為了建立廣泛且可靠的黃金集（Golden Set）作為真實標籤，ReviewBench 採用三階段流程。首先，從多種來源收集候選發現，包括人類審查者的意見、作者後續提交所推斷出的問題、確定性分析工具，以及多個前沿大型語言模型（LLM）。接著進行語義去重，合併指向相同根本問題的發現，避免多個來源達成共識而人為膨脹黃金集，也避免數據依賴單一來源的盲點。

在驗證階段，所有發現都依據公開的評估準則審查，判定標準是該發現是否真實、相關且非微不足道。ReviewBench 使用 Claude Sonnet 5 作為 LLM 評分者，並套用一致的評估準則。為確保透明與可重現，評估準則及所使用的裁判模型均已公開。此外，在發布前，未參與基準測試數據集建構的高階工程師獨立重新標記了每個真實標籤，其判斷與 ReviewBench 的同意率達 96.6%，專家審核結果也已發布，用來驗證基準測試的品質。

六大評估指標與偏好配置

ReviewBench 提供六種評估指標，分為兩類，分別衡量已知問題與新發現的問題。第一類是「Grounded」系列，包含精確率、召回率與 F1 分數，只使用現有的黃金集標籤，用來嚴格比較不同系統。第二類是「Augmented」系列，同樣包含精確率、召回率與 F1 分數，這些指標也會評估未與黃金集匹配的新發現。裁判會獨立判斷這些未匹配的發現是真實還是虛假陽性，讓審查系統能因找出黃金集未涵蓋的有效問題而得到認可。

由於不存在單一通用的最佳審查體驗，ReviewBench 允許按嚴重性與類別切片分析結果。開發者可以依自身需求調整 Fβ 分數中的 β 值，在廣泛覆蓋（高召回率）與低雜訊（高精確率）之間取捨。偏好改變時，排行榜會跟著重新排名，幫助用戶找出最符合其審查優先順序的系統。Grounded 召回率是主要的跨系統比較指標，Augmented 指標則作為每個系統的額外診斷工具。

內部驗證與生產環境預測

ReviewBench 不只用於評估，GitHub 內部也用它評估 Copilot Code Review (CCR) 的迭代進展。團隊在 A/B 測試前先用 ReviewBench 做離線評估，藉此可靠地追蹤改進效果並抓出回歸問題。近期一項輕量級實驗顯示，引入多模型集成審查後，ReviewBench 預測精確率、召回率與評論量都會提高，單次審查成本則會降低。

線上 A/B 測試結果與 ReviewBench 的預測方向一致：解決率（精確率的線上對應指標）上升 8.0%，召回率上升 13.6%，評論量上升 61%，單次審查成本下降 8.0%。此外，ReviewBench 的嚴重性層級評估預測了關鍵評論增加 227%（線上為 262%），也捕捉到評論轉向較 moderate 的層級，以及微小問題減少的趨勢。這表示 ReviewBench 能在生產實驗前提供快速且可重複的信號，增強團隊對變更有效性的信心。

開放參與與提交流程

目前 ReviewBench 的研究預覽版本已透過官方網站開放。開發者可以瀏覽完整的基準測試數據集、比較排行榜上的系統，或匯入自己的代理程式來評估與迭代。提交流程如下：使用 GitHub 帳戶登入並註冊代理程式，提供容器映像、配置與模型金鑰；先在 25 個拉取請求的測試集上運行，取得逐一拉取請求的細節，並在調整配置時重複執行；最後運行全部 219 個拉取請求（共三輪），由相同的裁判評分。只有當提交分數優於該代理目前排行榜上的分數，或是該代理首次上榜時，分數才會發布到排行榜。GitHub 邀請研究人員與實務工作者一起挑戰現有假設，提升 AI 程式碼審查評估的開放性與可靠性。