近年來，大模型層出不窮，令人目不暇接。為更好理解大模型的能力，許多評測集（Benchmarks）應運而生。

然而，這些評測集的質量常常受到質疑：標準答案出錯、指令模糊或錯誤、題目重復、數據泄漏等。

那么，代碼評測集的現狀究竟如何？

為了回答這個問題，由香港科技大學牽頭，聯合香港中文大學、中山大學等多所機構，耗費近一年時間，深入調研了過去10年間的274個代碼評測集，推出了一份《代碼評測集發展指南55項》（英文名：How2Bench，下稱《指南》）。

論文鏈接：https://arxiv.org/pdf/2501.10711

該指南涵蓋代碼評測集設計、構建、評測、分析、發布五大階段，共包含55條檢查項。

研究團隊指出，代碼評測集的質量不容樂觀：

• 即使是上千引的代碼評測集，也存在題目重復、測試用例錯誤、標準答案錯誤、未刪除的隱私信息等問題；
• 近70%的代碼評測集沒有采取數據質量保證措施；
• 超90%的以測試用例為通過依據的代碼評測集沒有考慮代碼覆蓋率；
• 超過一半的代碼評測集不提供可復現信息，如實驗參數設置、提示詞等；
• 超過10%的代碼評測集不開源或僅部分開源；
• 超18%的代碼評測集會作為后續評測集的源頭繼續擴大其影響（如圖6），意味著代碼評測集中的漏洞會持續傳遞，影響后續評測集的質量與可靠性。

研究過程

圖1 研究過程大綱

研究團隊將研究過程分為四個步驟：指南構建、文獻綜述、焦點案例分析、問卷調查。

• 指南構建：研究團隊首先起草了初步的指南，之后通過頭腦風暴、查閱文獻和對模型開發人員、模型評測人員的走訪，對初版指南進行增刪修改，最終敲定了這份包含55條檢查項的構建《指南》How2Bench；
• 文獻綜述：為探究代碼評測集的現狀，研究團隊根據發表年份（2014–2024年）、發表刊物（軟件工程頂會、人工智能頂會及前沿arXiv）、任務（代碼相關），進行滾雪球式收集，最終收錄274個代碼相關評測集（包含為深度學習/大模型設計的評測集）；
• 焦點案例分析：針對Top 5的代碼任務，研究團隊選取了前五個最高引的代碼評測集及一個最新的代碼評測集作為焦點案例進行重點剖析，摘錄其中的不足之處，引以為戒；
• 問卷調查：最后，研究團隊探尋從業者意識上的不足，及意識與行為之間的差距，研究哪些不良操作是由「沒有意識到其重要性」而導致，哪些是由于時間、精力、人力成本所限制而導致。

代碼評測集開發的生命周期

研究團隊將代碼評測集的開發過程分為五個階段（如圖2）：設計、構建、測評、分析、發布。

圖2 代碼基準開發的生命周期

• 設計（Design）：在構建評測集之前，要先考慮該評測集所要評測的范圍、所要考察的模型能力、是否彌補了相關評測集的空白、以及評測集所設計的輸入輸出是否符合真實應用場景。嚴謹的評測設計可以避免；
• 構造（Construction）：確定了評測集的動機和設計之后，開始構建評測集。代碼評測集中的數據通常從開源平臺、社區等（例如 GitHub、LeetCode 和 StackOverflow）收集，經過篩選（例如去掉低質量數據）、清洗（例如刪除重復數據、降噪）、整理（例如將測試數據與所測代碼配對）等預處理方法。該階段還伴隨判定方式（oracle）的構建，例如準備測試用例等。
• 評估（Evaluation）：評測集建立好后，在模型評估時也有不少問題：在什么環境下、用什么實驗設置（如溫度、重復次數、采樣次數、上下文設置、提示詞方式）進行評測？在幾個模型上評測？評測結果是否具有偶然性？是否可復現？實驗過程是否完整記錄？諸如此類設置在評估過程中也是不規范的重災之地。
• 分析（Analysis）：評測得到實驗結果后，對實驗結果的分析、啟發與反思也是重要的步驟。此階段涉及比較每個模型的表現，以找出表現異常的模型；使用適當的視覺輔助工具（例如條形圖和表格），以便于更清晰地觀察模型之間、不同設置下、與相關評測集、或上游下游任務表現的相關性。
• 發布（Release）：最后是發布評測集。這一階段需要對評測集所用的材料（如評測數據、評估方式（如測試用例）、運行環境（如docker）、可運行代碼或代碼實例等）進行整理與打包，以提高評測的可復現性；提供許可證（license），以明確使用權限及方式；提供清晰的文檔，以指導用戶有效地利用基準測試；提供實驗日志，以提高評測的可靠性與透明性。

綜述一覽

研究團隊可視化了所深入研究的274個代碼評測集，展示了它們的時間分布（圖3）、引用量分布（圖4）、代碼任務分布（圖5）等。

圖3 代碼評測集時間分布

圖4 代碼評測集引用量分布

圖5 代碼任務分布圖

研究團隊還對代碼評測集的繼承關系進行分析。如圖6所示，HumanEval、MBPP、Spider、CodeSearchNet被下游代碼評測集繼承得較為頻繁。

另外，值得注意的是，18%的代碼評測集（50/274)被后續評測集繼承、擴展。這也意味著上游代碼評測集的質量不僅影響自身的評估可靠性，還將持續影響下游代碼評測集。

圖6 代碼評測集之間的繼承關系

評測集「設計」階段現狀——偏科嚴重

針對「設計」階段，研究團隊提出了4條檢查項。《指南》指出，在構建之前，從業者應先做好調研，以確保提出新的評測集的必要性和重要性（如，是否已存在大量相似的評測集）；明確定義評測集所評估的模型能力范圍（如，評測的是代碼續寫能力、理解能力，或是其他）；思考清楚待評估的能力是否符合真實應用場景（如，輸入是否符合實際；輸出形式是否真的為實際應用場景所需）。

綜述發現，現有的代碼評測集偏科嚴重：

• 編程語言：58%（158/274）的評測集評估了Python，39%（107/274）評估了Java，23%（63/274）評估了C++，其他編程語言則很少被評估。有31種編程語言僅被一個代碼評測集覆蓋。具體分布如圖7所示。

圖7 編程語言分布

• 自然語言：相似的，自然語言也能觀察到相似的偏科現象——英語絕對領先，占據70%（192/274），中文僅有2%（6/274）。
• 函數級的代碼評測集占主導（71.8%），項目級（15.1%）、類級（2.6%）僅占少數。

代碼評測集是否真的在評測所預期的「代碼能力」？

研究團隊指出，在焦點研究的評測集中，10%的評測集沒有寫明所評估的模型能力，或出現預期評估的能力與實際評估的能力不相符的例子。

例如，被廣泛使用的MBPP（Most-basic Python Problems）致力于評估評估模型最基礎的Python 編程能力（measure the ability of these models to synthesize short Python programs from natural language descriptions），然而，其中有一道題是實現一個狗的年齡與人類年齡的對照轉換（如圖8）。

圖8 所評估能力與實際評估能力不符的例子

評測集「構建」階段現狀——數據質量的重災區

研究團隊對代碼評測集「構建」階段提出了19條檢查項。《指南》指出，從數據收集、清洗、降噪、去重，質量審查（如人工篩查、代碼運行）、數據污染緩解，到最后構建完整輸入輸出對、匹配評估方案（oracle）等，都要盡量做到「有跡可循、有記錄可查、有質量保障，構建過程公開、透明、可復現」等規范，保證代碼評測集構建的可靠性。

綜述發現，現有的代碼評測集構建過程「質量堪憂」：

• 62%的代碼評測集沒有去重，或在文中沒有提及；
• 近80%的代碼評測集沒有處理數據泄漏，即模型可能學習過評測用到的代碼數據而導致評估結果被高估；
• 近七成評測集未經任何質量保障手段，如人工檢查、代碼編譯或執行等；
• 在需要用測試用例判斷是否通過的代碼評測集中，僅8.7%評測集考慮了代碼覆蓋率。

構建時的數據「質量保障」，你會做嗎？

在構建評測集時，確保數據質量至關重要。

然而，研究團隊展示的統計數據（如圖9）令人失望：67.9% 的評測集沒有采取任何數據質量保證措施。

在做了質量保障的代碼評測集中，人工檢查占多數（22.6%）；代碼執行僅占2.2%；使用大模型進行驗證占1.5%；其他方法還包括：代碼倉庫下載量、點贊數等。

圖9 數據質量保障方式分布

研究團隊在文中給出了一些反例，例如評測集中存在重復問題（如圖10）、標準答案不正確（如圖11）、測試數據錯誤（如圖12）等。

圖10 數據重復的例子（id為71的題目和id為141的題目重復）

圖11 標準答案不可運行的例子（函數swap 未定義）

圖12 測試用例錯誤的例子（第7、8行預期輸出應為2）

評測集「評估」階段現狀——評估過程不透明，「復現」成困難

研究團隊對代碼評測集「評估」階段提出了12條檢查項。《指南》指出，實驗設計應具有代表性和完整性；實驗過程要記錄，以提高可復現性；評估過程中應考慮偶然因素（如大模型所天然具有的隨機性）對實驗結果帶來的風險，并盡量避免。

研究團隊先將代碼評測集中針對大模型的評測集篩選出來（67%=183/274），對這部分評測集的評估過程進行統計。

經過觀察，研究團隊指出，在代碼評測集的評估階段，主要存在的問題包括：評估過程不透明，評估存在隨機性，且可復現性堪憂：

• 34%的代碼評測集僅在不到三個大模型上進行評估，有21個僅在一個大模型上進行評估，實驗結果的泛化性難以保證；
• 94.9%的評測集僅用零樣本（zero-shot）評測了一次，實驗結果存在偶然性；
• 僅有34.5%的評測集在評估過程中有重復實驗，實驗結果存在隨機性；
• 超過半數的評測集不提供評估所用的提示詞（prompts）、上下文樣本等；僅有3.6%的評測集說明了評測環境（如軟硬件設備），嚴重阻礙可復現性；

圖13 評估階段評測的大模型數量分布

評測集「分析」階段現狀——分析維度「格局打開」

研究團隊對代碼評測集「分析」階段提出了10條檢查項。《指南》指出，分析實驗結果時應盡可能考慮多角度、多維度。

借鑒經典度量學理論中的評估指標，綜合考慮代碼評測集的難度（評測集是否過于簡單以至于模型表現過好，或過于困難以至于所有模型均一籌莫展）、區分度（評測集應能區分不同模型的能力）、穩定性等。還可以橫向對比同類代碼評測集在其他編程語言、相關任務、上下游任務中的表現，分析其是否具有相關性。

最后，在實驗分析展示階段，圖示盡量恰當（如，用折線圖表示趨勢、柱狀圖表示數值對比、餅狀圖表示比例等），數字盡量清晰。

研究團隊經過對焦點案例的深入分析指出，30%代碼評測集在分析實驗數據時未能對實驗結果進行分析，并提供合理解釋；存在實驗結果圖示中數字不可分辨（如圖14）等情況。

圖14 實驗結果圖示中數字不可分辨的例子

評測集「發布」階段現狀——「公開透明」仍需努力

研究團隊對代碼評測集「發布」階段提出了10條檢查項。《指南》指出，代碼評測集發布時，應設置好許可證（license）以明確使用權限及方式；提供評測所需的完整素材，包括評測數據、評估方式（如測試用例）、運行環境（如docker）、可運行代碼或代碼實例等；準備使用文檔，以提高用戶友好性；提供評測運行時日志，以提高評測的可靠性與透明性，便于其他從業人員使用。

研究團隊發現，近20%的代碼評測集沒有設置許可證，這使得代碼數據的權限不清晰；超過半數的評測集不提供可復現的提示詞，阻礙可復現性。

團隊還指出，在公布的代碼評測集中要注意刪除隱私、敏感信息（如API密鑰、個人郵箱、密碼等），避免隱私泄漏（如圖15）。

圖15 包含隱私信息的例子（包含API key）

「問卷調查」剖析，發現問題——對「可復現」不重視

最后，研究團隊進行了問卷調查，共發出50份問卷，其中49份有效。

團隊要求受訪者：（1）來自于AI或軟件工程（SE）領域，且（2）至少正式發表過一篇論文。其中，有近一半的受訪者曾參與構建過代碼評測集。

圖16 受訪者的地區分布

首先，所有受訪者都同意「一份評測集構建指南對代碼評測集的構建能起到很大幫助」；《指南》中85%（47/55）的檢查項都得到超八成受訪者的認同。

有趣的事，凡是曾經參與過代碼評測集構建的受訪者，對檢查項的認可度都非常高，55條中有53條得到了所有參與過評測集構建的受訪者的認同。

然而，研究團隊也從問卷調查中，識別到從業者意識上的不足：

• 超過15% 的受訪者沒有意識到評測集中的數據應具有代表性；
• 16% 的受訪者沒有意識到數據要降噪或去重；
• 超過4成的受訪者認為記錄實驗環境不重要，如硬件設備、型號，軟件版本，使用的模型框架或庫等。

受訪者意識上的「缺失」正好解釋了研究團隊在綜述中的觀察——數據質量堪憂、可復現性差、公開透明性差。

最后，研究團隊將綜述及指南整理成一份40頁的研究論文，并附上完整的《指南》，希望能喚起大模型從業者對代碼評測集質量的注意，對評測集可靠性、可復現性的重視。

總結

該研究做出了如下貢獻：

• 開創性：推出了首個全面的、可操作的的代碼評測集構建指南，共包含55條檢測項，涵蓋代碼評測集發展的設計、構建、評測、分析、發布等五個階段，為創造一個更可靠、更透明的研究環境邁出第一步；
• 實用性：《指南》可作為從業者在開發代碼相關評測集之前/之間的指南，也可作為評估現有評測集的一份清單。為方便使用，研究團隊在論文的最后四頁提供了《指南》的PDF版本；
• 通用性：《指南》中列出的大多數檢查項都可適應于其他類型的評測集，例如問答、數學、推理和多模態評測集等；
• 影響力：綜述中指出的現狀不容樂觀，引起科研社區、相關從業者對評測集的質量、可靠性、可復現性等問題的重視，指出其嚴重性和普遍性；且由于評測集的繼承關系，《指南》或將為未來評測集的整體質量做出貢獻。

作者介紹

指南的第一作者是香港科技大學的研究助理教授曹嘉倫，主要研究領域包括AI&SE、人工智能測試、形式化驗證等。其余作者包括香港科技大學博士后王文軒，副教授王帥，教授張成志；香港中文大學本科生陳昱杰，凌子軒，博士生李樹青、王朝正，教授呂榮聰；香港中文大學（深圳）博士生余博西，助理教授賀品嘉；中山大學副教授劉名威，教授鄭子彬等。