HumanEval

3 秒看懂

HumanEval 是一個用於衡量程式碼生成模型功能正確性的評估基準，由 OpenAI 在 2021 年隨 Codex 模型提出。它包含百餘個人工精心編寫的 Python 程式設計問題，每個問題附帶函式簽名、文件字串和一組單元測試。模型需根據問題描述生成程式碼，評估時使用 pass@k 指標，估計從 k 個候選生成中至少有一個能通過全部單元測試的機率。該基準已成為大型模型程式碼能力的“標準秤”，被 GPT-4、Gemini、Claude、Llama 等幾乎所有主流程式碼模型引用，但因其規模有限、題目型別偏數理演算法，常需配合其他基準一起使用。

3 分鐘產業解釋

程式碼生成是生成式 AI 商業化最快的賽道之一（GitHub Copilot、Cursor、通義靈碼等），而衡量模型“寫程式碼是否正確”正是 HumanEval 的存在意義。它提供了一套客觀、可復現的測評流程：給定問題描述 → 模型生成程式碼 → 執行單元測試 → 計算 pass@k。相比 BLEU、CodeBLEU 等基於表面文本匹配的指標，HumanEval 直接驗證程式碼是否滿足功能，因此與開發者的真實需求更對齊。

HumanEval 之所以快速成為產業聖經，源於三個特質：

標準統一：所有模型在同一套題和測試下比較，避免了各廠商“自說自話”。
指標直觀：pass@1 反映模型一次生成通過的機率，工程師容易理解。
簡單可控：百餘道純粹 Python 題讓測評成本低，可嵌入快速迭代流程。

但它也一直被詬病：題目集中在演算法、數學和字串處理，缺少依賴、檔案、網路等工程場景；全部為 Python，無法反映多語言能力；題目公開後可能出現“刷題”導致得分虛高。因此，產業界逐漸採用 MBPP、LiveCodeBench、SWE-bench 等補充基準，建置更全面的程式碼能力圖景。

15 分鐘專家深入

HumanEval 在技術生態中處於“程式碼生成評估棧”的基礎層，往上是更難、更復雜的基準（SWE-bench, CodeContests），往下是多語言擴充套件（如 HumanEval‑X 將 HumanEval 翻譯為多種程式語言）。其評估方法論影響了兩代模型研發：

資料構造：每個問題由專家撰寫，遵循“函式簽名 + 自然語言 docstring + 參考實現 + 單元測試”四件套。這一結構後來被 MBPP、APPS 等廣泛模仿。
評估協議：設定生成溫度、取樣次數、上下文長度等超參。為了計算 pass@k 的無偏估計，通常會對同一個問題取樣 n（n ≫ k）個生成，隨機組合子集來估算，避免直接取 top-k 引入的樂觀偏差。
模型演化：從 Codex（12B）首次達 pass@1 約 28%（HumanEval），到 GPT‑4 的 67%（零樣本），再到近期 Claude 3.5 Sonnet 的 92%，曲線的陡峭攀升反映了程式碼大型模型的指數級進步。但需注意，許多現代模型使用了多步推論、工具使用、思考鏈等後處理，使得單次 pass@1 的數字不再完全可比。

專家關注的深層問題包括：

測試廣度 vs. 深度：HumanEval 每個問題平均僅含少數測試用例，可能放過僅匹配特定樣例的“假陽性”程式碼。
評估效率：對於每個問題執行 n·k 次生成和測試，當 n=200、k=100 時，成本急劇上升，催生了基於估計器的大樣本近似策略。
與真實開發的鴻溝：真實場景需要改程式碼庫、讀文件、多檔案編輯、處理異常，遠非單函式補全可比。因此 HumanEval 分數高不等於能勝任實際程式設計工作。

目前，學術界正推動用“可執行的單元測試池”動態生成新題（如 EvalPlus 對 HumanEval 的測試增強），以緩解過擬合併提高區分度。

技術原理

評估流程

使用者問題
  │
  ▼
┌─────────────────┐
│  模型生成 k 個   │
│  候選程式碼片段    │
└────────┬────────┘
         │
         ▼
┌─────────────────┐
│  對每個程式碼片段  │
│  與問題配套的    │
│  單元測試執行    │
└────────┬────────┘
         │
         ▼
┌─────────────────┐
│  統計：c 個通過  │
│  (c ∈ [0,n])    │
└────────┬────────┘
         │
         ▼
┌─────────────────────────────┐
│ pass@k 無偏估計：           │
│ P̂ = 1 - C(n-c, k) / C(n, k) │
│ （當 n-c &lt; k 時視為 1）     │
└─────────────────────────────┘

其中 C(·, ·) 為組合數。該估計器在小樣本下仍能提供良好性質：只要 n≥k，即使沒有一個樣本在全部問題中都通過，仍可對 pass@k 進行合理推斷。典型配置：n=200，k≤100；或快速評估時 n=20，k=1,5,10。

關鍵引數：

溫度 T：影響取樣多樣性。常用 T=0.8 來平衡創造性與確定性。
top‑p：核取樣閾值，常設為 0.95。
max_tokens：生成長度限制，通常設定為函式體所需長度的 2-3 倍，防止截斷。
單元測試執行環境：隔離 sandbox，避免惡意程式碼影響宿主；常用 Python 的 unittest 架構，超時機制防止死迴圈。

評估指標除 pass@k 外，有時補充 average pass ratio（所有生成中通過測試用例的比例）和 syntax error rate，用以分析模型的基本程式碼可靠性。

技術演進史

2021 年 7 月：OpenAI 釋出 Codex 並推出 HumanEval，初始包含 164 道手寫Python題。論文《Evaluating Large Language Models Trained on Code》亮相，pass@k 評估範式確立。
2021–2022：DeepMind 等推出 MBPP（Mostly Basic Programming Problems），補充了近千道入門級Python題。人類基線 pass@1 ≈ 97% 被確立為天花板參考。
2022 年：BigCode 專案開源 HumanEvalPack（多語言擴充套件）。同年 EvalPlus 大幅增加測試用例，揭示早期模型高分可能來自測試覆蓋不全的“虛高”。
2023 年：隨著 GPT‑4 釋出，HumanEval pass@1 飆升至 67%，引發基準是否已“飽和”的討論。多語言基準（HumanEval-X）和更難的 CodeContests 受到更多關注。
2024 年：Anthropic Claude 3.5 Sonnet 和 OpenAI o1 在 HumanEval 上均突破 90%，表明簡單函式生成對頂尖模型已近天花板。評測重心轉向 SWE-bench（真實 GitHub issue 修復）和 LiveCodeBench（定期從競賽抓新題，防止汙染）。

技術路線對比（量化表）

特徵	HumanEval	MBPP	HumanEval+ (Plus)	CodeContests
問題來源	手動撰寫，側重於演算法邏輯	手工篩選，新手導向	HumanEval 加量測試用例	Codeforces 等競賽題目
題目數	百餘（具體數目見原論文）	約 1,000	同 HumanEval	數百至數千，動態更新
語言	僅 Python	僅 Python	僅 Python	多語言（C++, Java, Python等）
測試用例強度	中等，平均每個問題數個	弱，每個問題3個測試	強，平均數十倍於原版	強，涵蓋邊界與效能
典型指標	pass@k	pass@k	pass@k，fail@k	n@k (部分通過)
天花板效應	已接近飽和 (2025)	高（簡單題易飽和）	有一定區分度	遠未飽和
工程真實性	低	極低	低	中（演算法向）

注：數值來源於原論文及社群公開討論，具體數字可能因版本迭代存在細微差異。[原論文][EvalPlus]。

上下游

上游：提供被評估物件——程式碼大型模型（LLM），包括專有模型（GPT‑4、Gemini、Claude）和開源模型（Llama、Qwen、StarCoder、DeepSeek‑Coder 等）。這些模型通常在預訓練中混合了自然語言和程式碼語料，並經過指令微調、偏好對齊及工具使用等後訓練，以提升程式碼生成質量。

中游：評估架構與平台。如 Hugging Face 的 evaluate 庫、EleutherAI 的 lm-evaluation-harness、BigCode 的 bigcode-evaluation-harness，它們封裝了 HumanEval 的取樣、測試和指標計算，支援大規模並行評估。

下游：面向開發者的 AI 程式設計助手（GitHub Copilot、Cursor、Amazon Q Developer）、IDE 外掛、API 程式碼生成服務，以及企業內部程式碼質量管控、程式設計能力認證等。產品側將 HumanEval 等基準作為選型參考，但最終會依據實際業務程式碼庫的補全接受率、測試通過率等私有指標決策。

關鍵指標

pass@k：生成 k 個樣本，至少一個通過所有測試的機率估計。k 常取 1、10、100。
- 實用公式（無偏估計）：
  - 對每個問題，從 n 個生成中隨機選 k 個，計算無 c 個通過時的 pass@k。
  - 為減少方差，多采用有放回的重取樣估計（bootstrap）。
嚴格匹配率（Strict Match）：要求生成的程式碼與標準答案完全一致，現已極少使用。
執行成功率：程式碼有無語法或執行時錯誤，衡量模型的基礎編碼能力。
測試覆蓋增強後的 pass@k：EvalPlus 等工具通過自動生成更多變異測試，計算更苛刻的 pass@k，從而揭露模型在原有測試套件下“過擬合”的程度。該複合指標正逐漸成為更真實的衡量標準。

供需與市場資料

學術界和產業界對 HumanEval 評估的需求持續增長，幾乎所有新發布的程式碼相關模型都會宣告其 HumanEval 分數。Papers with Code 可檢索到數百條提交記錄。由於基準已趨向飽和，近年更多模型開始突出 HumanEval+ 分數，作為區隔。
從供應側看，OpenAI 最初發布該基準後，Hugging Face 等社群維護了開源評估工具包，大幅降低了使用門檻。EvalPlus 增強了測試用例，讓“舊瓶裝新酒”，延長了基準的生命週期。
具體市場規模資料 [未充分揭露]，但其衍生效應已顯現在 AI 程式設計助手數十億美元級別的市場估值上（GitHub Copilot 訂閱使用者超百萬，年化營收預估過億美元[第三方估算]）。HumanEval 分數常作為模型能力背書，出現在各公司的技術部落格和營銷材料中。

代表公司與資本對映

OpenAI：Codex/GPT 系列首推 HumanEval，持續保持領先。GPT‑4o、o1 等後續模型均報告該分數。
Anthropic：Claude 3.5 Sonnet 在 HumanEval 上達約 92%，並公開強調其在真實軟體開發基準 SWE‑bench 上的突破，暗示 HumanEval 的侷限性。
Google DeepMind：Gemini 系列釋出時同時報告 HumanEval 和自然語言編碼基準（Natural2Code）分數，其多模態版本可解析影像生成程式碼，拓展了評估邊界。
Meta：Llama 系列開源模型在 HumanEval 上分數逐年提升，Llama 3.1 405B 約達 89%，推動開源模型追趕閉源。
中國廠商：阿里雲端通義靈碼、百度 Comate、智譜 CodeGeeX、深度求索 DeepSeek‑Coder 等均以 HumanEval 作為核心宣傳指標。

資本市場對 AI 程式碼方向高度關注，HumanEval 作為關鍵能力“記分牌”，其提升節奏常影響投資者對相關公司技術實力的判斷，進而影響估值。例如，某公司開源模型 HumanEval 得分跳躍式增長，往往伴隨股價正向波動（但相關性不等於因果，需綜合考量）。

投資邏輯

模型能力追蹤訊號：HumanEval pass@1 的階段性躍升（如從 30% 跨越到 60%）常預示程式碼生成產品質量的質變，可觸發對下游工具預期營收的重新評估。
開源 vs. 閉源的分水嶺：當開源模型在 HumanEval 上縮小與閉源模型的差距（如 65% vs. 67%），可能壓低專有模型 API 的溢價空間，重塑產業鏈價值分配。
互補性指標組合：單一 HumanEval 分數不足以支撐投資決策，需結合 MBPP、HumanEval+、SWE‑bench 等多維指標，評估模型的魯棒性與真實場景泛化能力。分數近 100% 的模型若在 SWE‑bench 上顯著落後，則可能存在過擬合，實際應用風險更高。
行業催化：每當 HumanEval 或同類基準出現突破性新模型，往往刺激企業加大 AI 輔助程式設計的採購預算，利好提供 AI DevOps 平台的公司。

常見誤讀糾偏

誤讀 1：“HumanEval 得分 90% 的模型，寫程式碼能力已接近人類專業程式設計師。” 糾正：HumanEval 僅測試簡短、自包含的 Python 演算法函式，沒有涉及程式碼庫理解、需求澄清、複雜業務邏輯實現等人類程式設計師日常工作的大部分內容。得分高只能證明模型在類似競賽題的設定下表現優異，不等於能替代真人開發者。

誤讀 2：“只要取樣足夠多，pass@k 一定能接近 100%，所以這個指標沒有意義。” 糾正：pass@k 隨 k 增大而上升是數學必然，但它反映的是模型在多次嘗試中至少找到一次正確解的能力。在實際程式設計輔助中，k 通常很小（使用者不會看 100 個候選），因此 pass@1 或 pass@5 才是貼近產品體驗的指標。如果只有 pass@100 高而 pass@1 低，說明模型“命中率”不佳，對即時互動價值有限。此外，計算資源約束和延遲要求也使得一味增大 k 不可行。

學習路徑

入門：閱讀《Evaluating Large Language Models Trained on Code》(Chen et al., 2021) 全文，理解 pass@k 的定義和無偏估計原理。
實踐：使用 Hugging Face 的 bigcode-evaluation-harness 在本地評估一個小型開源模型（如 StarCoder2-3B），體驗取樣溫度、top-p 對 pass@k 的影響。
深入：研讀 EvalPlus 論文，復現其對 HumanEval 的測試增強，分析原版測試漏檢的模型錯誤型別。
擴充套件：在 HumanEval-X 多語言版本上評估模型，比較不同程式語言間的能力遷移。
前沿：追蹤 LiveCodeBench、SWE‑bench 等新基準的建置思路，思考如何設計“無法被刷題汙染”的動態評估體系。

一句話總結

HumanEval 是衡量大型模型函式級程式碼生成能力的元老級基準，其簡潔的 pass@k 指標已成為行業通用語言，但面對日益逼近的天花板和真實工程場景的鴻溝，仍需結合新一代評測工具才能全面刻畫 AI“程式設計師”的真實水準。

延伸閱讀與來源

Chen, M., et al. “Evaluating Large Language Models Trained on Code.” arXiv:2107.03374 (2021). —— HumanEval 原論文。
Liu, J., et al. “Is Your Code Generated by ChatGPT Really Correct? Rigorous Evaluation of Large Language Models for Code Generation.” (EvalPlus), NeurIPS 2023. —— 測試用例增強工作。
Li, Y., et al. “StarCoder: May the Source Be with You!” arXiv:2305.06161 (2023). —— 開原始碼模型的評估實踐。
Papers with Code 上 HumanEval 排行榜：https://paperswithcode.com/sota/code-generation-on-humaneval
BigCode 專案開源評估工具：https://github.com/bigcode-project/bigcode-evaluation-harness

三步設好你的觀察臺

選 1-3 個想觀察的人或賽道

看一份樣張

設定一次異動告警

HumanEval

HumanEval

3 秒看懂

3 分鐘產業解釋

15 分鐘專家深入

技術原理

評估流程

技術演進史

技術路線對比（量化表）

上下游

關鍵指標

供需與市場資料

代表公司與資本對映

投資邏輯

常見誤讀糾偏

學習路徑

一句話總結

延伸閱讀與來源

HumanEval

3 秒看懂

3 分鐘產業解釋

15 分鐘專家深入

技術原理

評估流程

技術演進史

技術路線對比（量化表）

上下游

關鍵指標

供需與市場資料

代表公司與資本對映

投資邏輯

常見誤讀糾偏

學習路徑

一句話總結

延伸閱讀與來源

相關推薦

同產業鏈 · 相關公司

相關概念