MLNLP社群是國內外知名的機器學習與自然語言處理社群，受眾覆蓋國內外NLP碩博生、高校老師以及企業研究人員。

社群的願景是促進國內外自然語言處理，機器學習學術界、產業界和廣大愛好者之間的交流和進步，特別是初學者同學們的進步。

來源 | 新智元

編輯 | LRST

近年來，大模型層出不窮，令人目不暇接。為更好理解大模型的能力，許多評測集（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、人工智慧測試、形式化驗證等。其餘作者包括香港科技大學博士後王文軒，副教授王帥，教授張成志；香港中文大學本科生陳昱傑，凌子軒，博士生李樹青、王朝正，教授呂榮聰；香港中文大學（深圳）博士生餘博西，助理教授賀品嘉；中山大學副教授劉名威，教授鄭子彬等。

參考資料：

https://arxiv.org/pdf/2501.10711