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

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

那么，代碼評測集的現(xiàn)狀究竟如何？

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

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

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

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

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

研究過程

圖1 研究過程大綱

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

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

代碼評測集開發(fā)的生命周期

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

圖2 代碼基準開發(fā)的生命周期

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

綜述一覽

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

圖3 代碼評測集時間分布

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

圖5 代碼任務分布圖

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

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

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

評測集「設計」階段現(xiàn)狀——偏科嚴重

針對「設計」階段，研究團隊提出了4條檢查項?！吨改稀分赋觯跇?gòu)建之前，從業(yè)者應先做好調(diào)研，以確保提出新的評測集的必要性和重要性（如，是否已存在大量相似的評測集）；明確定義評測集所評估的模型能力范圍（如，評測的是代碼續(xù)寫能力、理解能力，或是其他）；思考清楚待評估的能力是否符合真實應用場景（如，輸入是否符合實際；輸出形式是否真的為實際應用場景所需）。

綜述發(fā)現(xiàn)，現(xiàn)有的代碼評測集偏科嚴重：

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

圖7 編程語言分布

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

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

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

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

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

評測集「構(gòu)建」階段現(xiàn)狀——數(shù)據(jù)質(zhì)量的重災區(qū)

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

綜述發(fā)現(xiàn)，現(xiàn)有的代碼評測集構(gòu)建過程「質(zhì)量堪憂」：

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

構(gòu)建時的數(shù)據(jù)「質(zhì)量保障」，你會做嗎？

在構(gòu)建評測集時，確保數(shù)據(jù)質(zhì)量至關重要。

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

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

圖9 數(shù)據(jù)質(zhì)量保障方式分布

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

圖10 數(shù)據(jù)重復的例子（id為71的題目和id為141的題目重復）

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

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

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

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

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

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

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

圖13 評估階段評測的大模型數(shù)量分布

評測集「分析」階段現(xiàn)狀——分析維度「格局打開」

研究團隊對代碼評測集「分析」階段提出了10條檢查項?！吨改稀分赋?，分析實驗結(jié)果時應盡可能考慮多角度、多維度。

借鑒經(jīng)典度量學理論中的評估指標，綜合考慮代碼評測集的難度（評測集是否過于簡單以至于模型表現(xiàn)過好，或過于困難以至于所有模型均一籌莫展）、區(qū)分度（評測集應能區(qū)分不同模型的能力）、穩(wěn)定性等。還可以橫向?qū)Ρ韧惔a評測集在其他編程語言、相關任務、上下游任務中的表現(xiàn)，分析其是否具有相關性。

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

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

圖14 實驗結(jié)果圖示中數(shù)字不可分辨的例子

評測集「發(fā)布」階段現(xiàn)狀——「公開透明」仍需努力

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

研究團隊發(fā)現(xiàn)，近20%的代碼評測集沒有設置許可證，這使得代碼數(shù)據(jù)的權(quán)限不清晰；超過半數(shù)的評測集不提供可復現(xiàn)的提示詞，阻礙可復現(xiàn)性。

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

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

「問卷調(diào)查」剖析，發(fā)現(xiàn)問題——對「可復現(xiàn)」不重視

最后，研究團隊進行了問卷調(diào)查，共發(fā)出50份問卷，其中49份有效。

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

圖16 受訪者的地區(qū)分布

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

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

然而，研究團隊也從問卷調(diào)查中，識別到從業(yè)者意識上的不足：

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

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

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

總結(jié)

該研究做出了如下貢獻：

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

作者介紹

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