Pass@k

3 秒看懂

Pass@k 是衡量程式碼生成模型能力的核心指標。它回答一個樸素但關鍵的問題：如果讓模型為同一道程式設計題生成 k 個候選程式碼片段，其中至少有一個能通過全部單元測試的機率有多大？

該指標直接量化了模型在“嘗試多次、取最優”這一真實使用場景下的可靠性——這恰好是開發者使用 GitHub Copilot、Cursor 等 AI 程式設計工具時的典型行為：瀏覽多個補全建議，或反覆要求模型重新生成。Pass@k 已成為 HumanEval、MBPP、CodeContests 等主流程式碼基準的標配，也是各大型模型釋出技術報告時的首要效能標尺。

3 分鐘產業解釋

為什麼一次通過率不夠？

在 AI 輔助程式設計的早期，業界常用 Pass@1——即模型單次生成就能通過測試的機率——作為核心衡量。但這一指標嚴重低估了使用者實際體驗。研究表明，開發者在 IDE 中平均會瀏覽 2-5 個補全候選項；在複雜任務中，他們往往會讓模型重新生成數次，從中挑選看起來最合理的方案。Pass@k 刻畫的就是這種“多試幾次總有一次成功”的累積機率。

業內如何計算？

直接讓模型生成恰好 k 次並統計“至少一次成功”的頻率，雖然直覺上正確，但估計方差較大。業界普遍採用 Chen et al. (2021) 在 Codex 論文中規範化的無偏估計方法：

設對某道程式設計題，模型生成 n \gg k 個樣本（典型 n = 200），統計其中通過測試的樣本數為 c。則該題目的 Pass@k 估計值為：

text(Pass@k)_&#123;text(est)} = 1 - \frac&#123;binom(n-c){k}}&#123;binom(n){k}}

（當 n-c < k 時，上式直接取 1。）

該公式的核心直覺是：從 n 個總樣本中不放回地抽取 k 個，至少抽到一個“成功”樣本的機率。對所有題目取平均，即得最終 Pass@k 分數。

產業影響

Pass@k 的普及推動了整個程式碼大型模型行業從“追求一次寫對”向“生成 + 驗證”流水線的範式轉變。它直接影響了產品設計——IDE 外掛預設展示幾個候選項、是否提供“重新生成”按鈕——這些決策都參考 Pass@k 曲線。同時，它也催生了以計算資源換取通過率的策略，典型如 DeepMind AlphaCode (2022) 在競賽級程式設計中對每道題生成數萬甚至數十萬個候選，再通過測試用例過濾出正確解。

技術原理

問題形式化

給定一道程式設計題（包含自然語言描述和隱藏的單元測試集），模型從條件分佈 P(text(code) \mid text(prompt, parameters)) 中取樣。每次取樣結果在測試用例下有明確的二元結局：全部測試通過（成功） 或 至少一個測試失敗（失敗）。

設單次取樣通過的機率為 p（未知且因題而異），假設 k 次取樣間統計獨立（實際中，由於使用相同隨機種子或採樣引數設定不當，獨立性可能不成立，詳見“誤讀糾偏”），則 k 次取樣中至少一次成功的機率為：

text(Pass@k)_&#123;text(ideal)} = 1 - (1 - p)^k

然而 p 未知，直接建模困難。實踐中，我們用有限次取樣的通過頻率來估計 p，進而匯出 Pass@k 的無偏估計量。

無偏估計的數學推導

關鍵洞察來自 Kulal et al. (SPoC, NeurIPS 2019) 和 Chen et al. (Codex, arXiv 2021)：不必對 p 做點估計再代入公式，而是直接在“從 n 次取樣中隨機抽取 k 次”這一過程的機率空間中計算條件期望。

設總取樣數 n，成功數 c。從 n 個樣本中不放回隨機抽取 k 個，此過程服從超幾何分佈。事件 A = “k 個樣本中至少包含一個成功樣本”的補集是“k 個樣本全部來自 n-c 個失敗樣本”：

P(A) = 1 - \frac&#123;binom(n-c){k}}&#123;binom(n){k}}

可以證明：對固定的 n 與 k，該統計量是真實 Pass@k（即：先從模型無限次取樣中確定 p，再計算 1-(1-p)^k）的無偏估計，且方差顯著小於“直接生成 k 次、重複實驗取頻率”的方法——因為後者每次只利用 k 個樣本的資訊，而前者利用了全部 n 個樣本。

邊界處理： 當 n - c < k 時，組合數 binom(n-c){k} 按定義為零（無法從不足 k 個失敗樣本中選取 k 個失敗），此時機率直接定義為 1。

計算流程 ASDII 示意

輸入: 測試資料集 D = &#123;題目_1, ..., 題目_m&#125;
      模型 M, 取樣引數 θ (溫度, top_p 等)
      總取樣數 n, 目標 k 值

FOR EACH 題目_i IN D:
  samples ← M.generate(prompt_i, n, θ)
  c_i ← 0
  FOR EACH sample IN samples:
    IF execute_sandbox(sample, test_cases_i) == ALL_PASS:
      c_i += 1

  IF n - c_i &lt; k:
    pass_at_k_i ← 1.0
  ELSE:
    pass_at_k_i ← 1 - C(n-c_i, k) / C(n, k)

Pass@k ← MEAN(pass_at_k_i FOR i=1..m)
RETURN Pass@k

與硬體/架構無關的宣告

Pass@k 是純統計評估指標，不涉及 GPU 型號、視訊記憶體頻寬、晶片製程等硬體規格。評估所需資源取決於模型規模與取樣次數 n，但指標定義本身與硬體解耦。任何聲稱“ Pass@k 依賴某特定晶片架構”的表述均屬誤讀。

關鍵引數

取樣數量 n 的選擇

n 的取值直接影響估計方差。方差與 1/n 大致成正比關係（在大 n 近似下）。業界共識：

n = 100：早期基準常用，但估計波動較大，不同次評估間分數可能相差 2-3 個百分點。
n = 200：OpenAI Codex (2021) 定下的標準，此後被廣泛採納為“行業規範”，在方差與計算成本間取得平衡。
n = 400+：資源充裕時採用（如 AlphaCode 評估中部分實驗），估計更加穩定。
來源：Chen et al. (2021) 附錄 A.2；BigCode Project 評估規範 (2023)。

k 的常用取值

k=1：單次通過率，反映“即時準確度”。
k=10：10 次嘗試成功率，反映中等迭代下的可靠性。
k=100：大規模取樣上限，用於衡量模型在某題目上的“真潛力”。注：部分研究（如 AlphaCode）會擴充套件至 k=1000 甚至更大，但此時計算成本急劇增長，且需大量取樣支撐無偏估計。

溫度引數的敏感度

取樣溫度 T 和 top-p（nucleus sampling）引數對 Pass@k 影響顯著：

低溫度（T < 0.4）：生成結果趨同，多樣性不足。Pass@1 可能最優，但 k 增大時提升有限，曲線早早飽和。
中等溫度（0.6 ≤ T ≤ 0.8）：平衡多樣性與準確性，Pass@k 曲線爬升明顯。
高溫度（T > 1.0）：多樣性最大，k 增大時 Pass@k 持續上升，但 Pass@1 可能顯著下降。各團隊報告 Pass@k 時必須註明取樣引數，否則分數不可比。這是當前學術界的標準要求，但部分早期報告未嚴格遵守。

估算準確性的置信區間

基於 n=200 取樣計算 Pass@k 時，單個題目的估計存在抽樣誤差。當前社群尚缺乏統一的置信區間報告規範，但研究者通常建議報告多個隨機種子下的均值與標準差。公開資料顯示，多數模型的人類評估基準論文（如 HumanEval）未系統報告置信區間，此為方法學不足。

技術路線與對比

主流程式碼生成評估方法量化對照

評估指標	核心思想	計算需求	與真實使用者體驗的相關性	可被“遊戲”程度	代表基準
Pass@1	單次生成通過率	低（n=1）	中：對應“只看第一個建議”場景	低	HumanEval, MBPP
Pass@k（k>1）	k 次取樣至少一次成功	高（需 n≥200）	高：模擬多次嘗試	中：可通過提高溫度、大量取樣堆高	HumanEval, APPS
Strict Match（貪婪解碼）	確定性解碼下的精確文本匹配	極低（單次）	低：不反映隨機取樣場景	極低	舊自然語言生成基準
BLEU / CodeBLEU	文本表面相似度	極低（無需執行）	極低：與功能正確性相關性弱（Kulal et al. 2019 報告相關係數 <0.4）	高：可生成“文本相似但完全錯誤”的程式碼	舊程式碼生成基準
TestAvgPassRatio	平均每條樣本通過的測試數比例	中（需執行）	中：細粒度反映正確性	低-中	CodeContests (AlphaCode)
Pass@t	限制推論時間 t 下的通過率	中-高	高：結合效率考量	低	新興研究方向 (2023-)
LiveBench	定期更新測試集防資料洩漏	依指標而定	高	極低	LiveCodeBench (2024)

說明：此表為基於公開研究文獻的定性比較。各度量在不同基準上的具體得分差異因模型而異，此處略去以免引發對特定模型的片面解讀。

技術路線演進

文本相似度時代（~2019 前）：以 BLEU、ROUGE、Exact Match 為主。核心問題：一段程式碼可能文本相似度為 0.9 卻完全不能執行；也可能文本完全不同但功能完全正確。
功能正確性引入（2019）：SPoC 論文首次系統定義 Pass@k，將“是否通過測試用例”作為硬判決訊號，標誌著指標的轉型。
標準化與工業化（2021-2022）：OpenAI 的 HumanEval + 無偏估計協議成為事實標準。DeepMind AlphaCode 展示 Pass@k 架構在競賽級程式設計中的極值應用（k 達數十萬級別，每道題過濾出少量正確解）。
資料集增強與糾偏（2023-2024）：出現 HumanEval+、MBPP+ 等增強資料集，通過擴充套件測試用例暴露原 Pass@k 高分模型的“脆性通過”。同時，為避免訓練資料汙染，動態更新測試集的評估方法湧現。

上游

測試基準（Test Benchmarks）

Pass@k 的可信度高度依賴上游測試集質量。主流基準如下（含來源與規模）：

HumanEval（OpenAI, 2021）：164 道手寫 Python 程式設計題，每道題配備 ~8 個測試用例。優點：手寫質量高，避免模板化；侷限：規模小，語言單一，存在題目洩漏風險（訓練資料可能包含相似描述）。
HumanEval+（Liu et al., 2023）：為 HumanEval 每道題擴充至 ~80 個測試用例，通過自動化方法（型別感知的輸入變異）增加覆蓋。據原論文，部分在 HumanEval Pass@1=90% 的模型在 HumanEval+ 上降至 ~75%。
MBPP（Google, 2021）：974 道眾包 Python 題，多數為入門級。優點：規模更大；侷限：部分題目描述模糊，測試用例覆蓋參差。
MBPP+（2023）：MBPP 的增強版，與 HumanEval+ 同類思路，擴充測試。
APPS（Hendrycks et al., 2021）：10,000 道競賽與面試題，覆蓋 Python、C++ 等，難度分層。用於 Codex、AlphaCode 評估。來源：公開線上判題平台。
CodeContests（DeepMind, 2022）：競賽級程式設計題，與 AlphaCode 配合釋出。強調高難度、長程式碼、強演算法要求。來源：Codeforces 等平台歷史題目。
LiveCodeBench（2024）：動態收集近期的 LeetCode、Codeforces 等新題，防止訓練汙染。規模和來源隨時間變化。
MultiPL-E（BigCode, 2023）：將 HumanEval 和 MBPP 翻譯至 19 種程式語言，用於跨語言評估。來源：社群協作翻譯與校驗。

取樣策略與引數

溫度（Temperature）、top-p（nucleus sampling）、top-k 共同決定分佈 P(text(code) \mid text(prompt)) 的“平坦度”。不同溫度影響 Pass@k 曲線的形態（詳見“關鍵引數”節）。典型配置示例：

Codex (2021) 報告 Pass@100 時使用 T=0.8，n=200。
StarCoder (2023) 報告時使用 T=0.2 和 T=0.8 兩組對比。
來源：各模型技術報告。

執行沙箱環境

生成程式碼必須在隔離環境中執行以驗證正確性，同時防範惡意程式碼風險。常用方案：

Docker 容器：標準方案，每次執行在獨立容器中，設定 CPU、記憶體和執行時間上限。
E2B Sandbox：雲端端安全沙箱服務，被部分開源評測架構整合。
本地沙箱：HumanEval 官方評測指令碼使用 subprocess + timeout 方式。安全與超時策略直接影響 Pass@k 分數——若沙箱將超時誤判為“失敗”，可能低估模型能力；若過於寬鬆，可能漏掉死迴圈等缺陷。

下游

模型選型與排行榜

Pass@k 是模型釋出時的“首圖”指標。GitHub Copilot 底層模型能力、CodeLlama 系列、DeepSeek-Coder 等釋出時，均將 HumanEval Pass@1 和 Pass@100 列於摘要開頭。開源社群排行榜（如 Hugging Face Open LLM Leaderboard 程式碼板塊）以 Pass@k 為主要排序依據。

產品體驗設計

IDE 程式碼補全產品的設計決策直接回推至 Pass@k 邏輯：

展示幾個候選項？ 若 Pass@1 已極高，1-2 個較好；若 Pass@1 中等但 Pass@10 高，可展示更多建議或提供一鍵“換一個”按鈕。
是否做自動單元測試？ 部分高階外掛（如 Cursor 的“AI Review”）在後臺靜默執行測試用例，自動過濾未通過的補全，此舉等價於在使用者無感下提升有效 k。
延遲與 k 的權衡：使用者容忍延遲有限。一次展示 10 個候選意味著 10 倍的推論開銷。中介軟體最佳化（快取、早期終止推測）成為關鍵。

成本最佳化與推論經濟性

企業部署程式碼大型模型時，Pass@k 直接對應推論成本賬：

若某模型 Pass@1=60%，Pass@10=90%，則意味著要達到 90% 的使用者成功率，每道題平均需支付 10 次推論的 token 費用。
推論服務商按 token 計費（如 OpenAI Codex API 定價，具體費率因時段和合同而異，此處不詳列）。提高 Pass@k 的經濟性——即單位 GPU 時間內達到的等效 Pass@k——成為企業採購評估的隱性標準。

強化學習訓練訊號

部分研究將“測試通過/失敗”作為二元獎勵訊號，用 Pass@k 相關統計量監控訓練進展：

RLHF for Code：以“生成程式碼 + 執行結果”為反饋，Pass@k 曲線整體上移是目標。
STaR / Rejection Sampling：從 n 次生成中選取通過的樣本用於監督微調，此時高 Pass@k 意味著過濾後的訓練資料更多樣。但此類方法目前仍在研究階段，尚未大規模產業落地證據。

受益公司

宣告：以下僅陳述公開資訊可查證的公司在 Pass@k 評估生態中的角色，不構成任何投資建議或價值判斷。

OpenAI：Codex (2021) 論文定義了現代 Pass@k 評估協議，HumanEval 成為行業標準基準。其 API 商業模式（GPT-4、Codex API）直接受益於以 Pass@k 作為能力背書。
Anthropic：Claude 系列模型釋出時公開 HumanEval Pass@k 分數。據其 2024 年 3 月部落格，Claude 3 Opus 在 HumanEval 上 Pass@1 報告為 92.0%（n=1，貪婪解碼語境，此為單次資料點）。其 API 定價中，程式碼生成是企業場景核心。
Meta：CodeLlama 系列 (2023) 開源，社群自行復現其各規模模型在 HumanEval 上的 Pass@k 成績。Meta 致力於開源生態，不直接銷售 API，但該技術路線影響其 AI 戰略生態。
ServiceNow / Hugging Face：共同主導 BigCode Project，釋出 StarCoder 和 StarCoder2 系列。StarCoder2-15B 在 HumanEval Pass@1 上報告約 86%（Python，來源：BigCode 2024 技術報告，n=200，T=0.2）。Hugging Face 託管的開源模型排行榜推動了 Pass@k 作為標準化指標。
DeepSeek（深度求索）：DeepSeek-Coder 系列 (2023-2024) 在 HumanEval 上報告領先的開源 Pass@1 分數（如 DeepSeek-Coder-33B-Instruct 報告 Pass@1=91.2%，來源：官方技術報告，n=1，貪婪解碼）。其開源策略與 API 同時推進。
微軟 / GitHub：Copilot 產品是 Pass@k 產業化的最終載體。其底層模型迭代（從 Codex 遷移至 GPT-4 系列）被動反映在使用者感知的補全成功率上，但微軟極少公開發布具體 Pass@k 內測資料。
基礎設施建設方：雲端廠商（AWS、GCP、Azure）和推論引擎公司（如 Fireworks、Together AI）間接受益，因為 Pass@k 評估與高 k 推論消耗大量 GPU 例項。

注：上述具體 Pass@k 分數的來源口徑、取樣引數各不同，橫向比較需謹慎。未引數字的部分因公司未公開揭露或公開資料未見。

市場規模與供需

資料宣告：程式碼大型模型市場的具體規模數字高度依賴第三方估算且更新迅速。本節給出趨勢性描述，不提供未經交叉驗證的精確金額預測。

需求端趨勢

AI 輔助程式設計工具使用者量：GitHub Copilot 在 2024 年 4 月（公司部落格）公佈超過 1.8 億累計使用者（含免費版試用，口徑：GitHub 官方），付費使用者數未獨立揭露。JetBrains AI Assistant、Cursor、Codeium 等競品均快速獲取使用者。公開資料未見 2024 年全球 AI 程式設計工具的精確付費使用者總數與市場金額。
企業採購評估：據多份行業調查（如 Stack Overflow 2023 開發者調查，n≈90,000 開發者），參與開發者中 55% 表示正在使用或計劃使用 AI 程式設計工具，員工對工具的通過率（使用者感知的 Pass@k 等價概念）是提及率最高的考量因素之一。調查未區分具體指標名稱。
從“能否用”到“高效用”的轉變：初期採購關注“能不能生成程式碼”，當前關注“生成 n 個候選後，篩選成本有多高”。這直接對應 Pass@k 的經濟解釋。

供給端競爭態勢

開源模型 HumanEval 得分持續攀升：2023 年初，開源模型 Pass@1 普遍在 50%-60% 區間；至 2024 年中，多個開源模型在 HumanEval Pass@1 上報告 ≥85%。分數“內捲”顯著，但實際複雜場景（多檔案專案、長上下文、非 Python 語言）與 HumanEval 分數間存在顯著差距（參見“常見誤讀糾偏”第 5 條）。
推論服務成本下降：通過量化（INT4/INT8）、FlashAttention、推測解碼等技術，單次推論成本持續下降。這使“堆 k”策略在經濟上更可行，變相降低高 Pass@k 的獲取門檻。公開資料未見 2024 年標準化的“單次 HumanEval Pass@k 評估 GPU 小時數”行業基準。

計算資源消耗估算

以評估一個 7B 引數模型在 HumanEval（164 題）上的 Pass@100（n=200）為例：需生成 164 × 200 = 32,800 個程式碼樣本。每個樣本平均生成 ~100 token（估計值），總輸出約 3.28M token。在單張 A100 (80GB) 上，推測耗時約數小時（具體因架構、batch size 而異）。對 70B+ 模型，成本線性放大。因此，Pass@k 的完整評測本身即是資源密集型任務，推動雲端端標準化評測服務的需求。

玩家對比（典型評估協議差異）

由於不同模型群組報告 Pass@k 時的取樣引數、評測集版本、n 值、解碼策略不完全一致，橫向對比存在系統性偏差。以下為定性對照，不給出並列數字。

模型系	典型基準	常用取樣引數	評估規範特點	公開透明度
OpenAI GPT/ChatGPT 系列	HumanEval, MBPP（內部增強版）	貪婪解碼 (Pass@1)；T=0.8, n=200 (Pass@100)	沿用 Chen et al. 2021 協議；部分新代模型不釋出完整 Pass@100 曲線，只公開 Pass@1	中等：核心數字公開，完整評估細節有限
Anthropic Claude 系列	HumanEval（Claude 3 報告）	貪婪解碼 (Pass@1)	側重 Pass@1，較少釋出大 k 曲線	較低：僅公開精選數字
Meta CodeLlama 系列	HumanEval, MBPP, MultiPL-E	T=0.1 和 T=0.8 兩組，n 因版本而異	社群多進行復現，報告中有分組，對多樣性有討論	高：開源，社群復現資料豐富
BigCode StarCoder 系列	HumanEval, MBPP, MultiPL-E	T=0.2（Pass@1 典型），較高 T 用於 Pass@k	評估管道開源，標準化程度高	很高：完整管道、引數、資料均可查
DeepSeek-Coder 系列	HumanEval (Python), MultiPL-E	貪婪解碼（報告 Pass@1）	側重 Pass@1，少報告大規模 k	較高：技術報告詳細，模型開源
Google Gemini 系列	內部基準為主，部分 HumanEval	未系統性公開	通常釋出時引用 HumanEval 但不提供完整無偏估計細節	低：評測細節有限

解讀要點：對比兩個模型的 Pass@k 分數前，必須確認是否在相同條件下——同測試集（尤其是否含增強版測試）、同取樣溫度、同解碼策略、同 n 取值。直接比較不同來源報告的數字可能導致錯誤結論。該領域亟需獨立第三方進行標準化復現評測（如 LMSys Chatbot Arena 向程式碼方向的擴充套件）。

風險

技術風險

1. 基準過擬合與資料汙染 訓練資料中可能包含 HumanEval 或相似題解。若模型“記住”了答案（而非推論），Pass@k 分數將虛高，但面對新題時能力崩塌。LiveCodeBench (2024) 的初步實驗表明，部分在 HumanEval 上分數領先的模型，在時間新於訓練截止日的題目上分數下降幅度高達 20+ 個百分點（來源：LiveCodeBench 技術報告，具體模型名略去以保持中立）。

2. 測試用例覆蓋不足 早期基準（HumanEval 原始版，每題 ~8 測試）將許多“表面正確但有隱藏 Bug”的程式碼誤判為成功。HumanEval+ 論文揭露了這一點：擴充測試到每題 ~80 個後，多個頂級模型的 Pass@1 下降 15-20 個百分點（來源：Liu et al., 2023）。Pass@k 分數高 ≠ 生產環境可用的程式碼質量。

3. 取樣獨立性的前提可能不成立 無偏估計公式假設對同一題目的 n 次取樣可視為從相對穩定分佈中的獨立抽取。然而，當低溫度或使用確定性取樣（如 top_k=1）時，n 次輸出可能嚴重趨同。此時 Pass@k 曲線將被人為壓低（多樣性不足），或依賴幾個極為稀疏的成功樣本使方差劇烈膨脹。這是實踐偏離理論假設的典型案例。

4. 只測“全對”，忽視部分正確 Pass@k 嚴格要求“全部測試通過”，一道題若 9/10 的測試都通過，唯剩一個不通過，記為失敗。這忠實於“程式碼不能有 Bug”的剛性需求，但可能忽略模型的部分進度。TestAvgPassRatio 等粒度更細的指標可補充此盲區，但尚未成為主流。

商業與產業風險

1. “高分低能”的產品化錯覺 廠商報告 Pass@k = 95% 並不意味著企業部署後用戶體驗就是 95% 成功率。原因：(a) 真實企業任務遠複雜於 HumanEval 幾行函式題；(b) 使用者不一定願意等待 k 次生成的延遲；(c) 真實程式碼庫的多檔案依賴和上下文長度是當前基準不具備的。

2. 評估軍備競賽與成本膨脹 為追求 Pass@k 數字上的領先，部分團隊可能傾向於使用極高 n、極高 k、極高溫度的極限配置，這對實際產品沒有指導意義，卻大量消耗公共研究資源。社群尚未就“有意義的 k 上限”達成共識。

3. 對多元語言與生態的覆蓋不足 HumanEval+ 目前仍以 Python 為主。MultiPL-E 雖有翻譯版，但測試用例質量在不同語言間存在差異。JavaScript、TypeScript、Rust、Java 等企業主流語種的 Pass@k 評估生態不夠成熟。企業在非 Python 場景下難以獲得同等可靠的資料。

常見誤讀糾偏

誤讀 1：“Pass@k 是人類挑選最佳答案後的準確率。” 糾正：Pass@k 完全由自動測試用例判定“至少一個全過”，不涉及任何人工挑選。人工挑選引入的主觀偏差（如：看起來最“像對”的程式碼實則不通）反而可能低於自動化篩選的成功率。兩者概念截然不同。
誤讀 2：“Pass@10 = 90% 說明模型一次生成就有 90% 正確率。” 糾正：Pass@k 是累積機率，不是單次機率。一個模型可能 Pass@1 只有 50%，靠 10 次獨立取樣才達到 90% 的至少一次成功率。如果使用者只看到第一個建議（Pass@1 體驗），成功率仍是 50%，而非 90%。據此誤判產品體驗，可能導致使用者失望。
誤讀 3：“計算 Pass@k 只要生成 k 個樣本，統計其中有幾次‘至少一次成功’就行。” 糾正：這個直接方法雖然是無偏的（期望等於真實 Pass@k），但方差較大。從 n=200 中取樣並利用超幾何公式估計，可以在不改變期望的同時顯著降低方差（等價於“使用了更多資訊”）。前者相當於只用 k 個樣本的稀有事件頻率，極其不穩定；後者用了全部 n 個樣本的資訊。兩者並非“有偏 vs 無偏”，而是“高方差無偏 vs 低方差無偏”。
誤讀 4：“Pass@k 只與模型能力有關，測試用例不重要。” 糾正：測試用例質量直接決定 Pass@k 是否可信。HumanEval+ 的實驗證明：同樣的模型，在原始 HumanEval 上 Pass@1=90%，在增強測試集上可能降至 75%。因此，引用 Pass@k 分數時，必須明確基於哪個測試集（原始版還是增強版）以及測試用例數量。
誤讀 5：“HumanEval 高分就意味著模型在企業專案中可用。” 糾正：HumanEval 是手寫、短函式、自包含的 Python 題目，且大多獨立於外部庫。真實企業程式碼涉及：多檔案依賴、私有的內部 API、長上下文理解、遵循程式碼庫現有風格、處理模糊需求等。這些維度 HumanEval 分數完全不觸及。目前尚無公開研究能定量建立 HumanEval Pass@k 與真實企業任務成功率的對映函式。

追蹤指標

如何持續評估 Pass@k 生態的變化與信度：

定量指標

各模型在 HumanEval / HumanEval+ / MBPP+ 上的 Pass@1 與 Pass@100：可查閱各模型技術報告、Open LLM Leaderboard（Hugging Face）及獨立復現論文。留意數值變化趨勢及新模型釋出的頻率。
Pass@1 與 Pass@100 的比率：該比值反映通過取樣增益的幅度。若比值接近 1，說明模型確定性已強；若比值顯著小於 0.5，說明高 k 是當前發揮性能的必需品。該指標指導產品端的取樣策略。
LiveCodeBench 等動態基準上的分數 vs. 靜態基準上的分數：該差值可視為“資料汙染溢價”的近似代理。差值越大的模型，越可能依賴訓練記憶而非泛化推論。
不同溫度下的 Pass@k 曲線族：同模型在 T=0.2, 0.4, 0.6, 0.8 下的 Pass@1 至 Pass@100 曲線，是評估取樣魯棒性的關鍵。社群壓力正促使更多模型釋出此類完整曲線族（但目前仍非標配）。

質性指標

是否公開 n 值和取樣引數：不提供完整引數的報告，其 Pass@k 分數的可信度需打折扣。
是否報告增強測試集（+版本）上的分數：僅報告原始 HumanEval 的分數可能掩蓋對邊緣用例的脆弱性暴露。主動報告 + 版本分數的團隊在評測嚴謹性上領先。
是否出現獨立第三方復現報告：開源模型可由社群自行評測，可信度較高。純 API 模型的復現成本高、黑箱性強，需等待學術界或基準組織的統一復現（如 LMSys 的持續追蹤）。
評估倫理與潛在的題目洩漏宣告：負責任的團隊會宣告其模型訓練資料截止日與基準釋出時間的關係，以及採取了何種去汙措施。缺乏此類宣告的報告應謹慎對待。
真實生產環境使用者留存與主觀評價：單個 IDE 外掛的市場反饋（如 VS Code 商店評分、使用者論壇討論）是補充硬指標的軟訊號。雖然嘈雜，但反映了 Pass@k 數字無法涵蓋的“符合預期程度”。

信源

Chen, M. et al. (2021). “Evaluating Large Language Models Trained on Code.” arXiv:2107.03374. — 現代 Pass@k 評估協議、無偏估計公式、HumanEval 資料集的原始出處。
Kulal, S. et al. (2019). “SPoC: Search-based Pseudocode to Code.” NeurIPS 2019. — 首次提出 Pass@k 概念並使用無偏估計對比搜尋與神經合成方法。
Li, Y. et al. (2022). “Competition-Level Code Generation with AlphaCode.” Science, Vol 378. — 展示大規模取樣 + 過濾範式下 Pass@k 的極值應用，k 達數十萬量級。
Liu, J. et al. (2023). “Is Your Code Generated by ChatGPT Really Correct? A Large-Scale Human Evaluation.” arXiv:2305.01210. — HumanEval+ / MBPP+ 擴充測試集來源，揭露測試覆蓋不足導致的高分膨脹。
BigCode Project (2023-2024). “StarCoder 2 and The Stack v2.” BigCode 專案部落格及技術報告. https://www.bigcode-project.org/ — 開源模型標準化評估、MultiPL-E 多語言翻譯基準的主要推動方。
OpenAI (2021). HumanEval 資料集與評估指令碼. https://github.com/openai/human-eval — 基準資料及官方實現。
Austin, J. et al. (2021). “Program Synthesis with Large Language Models.” arXiv:2108.07732. — MBPP 資料集出處。
Hendrycks, D. et al. (2021). “Measuring Coding Challenge Competence With APPS.” NeurIPS 2021 Datasets Track. — APPS 基準來源。
Jain, N. et al. (2024). “LiveCodeBench: A Dynamic, Contamination-Free Code Generation Benchmark.” arXiv preprint. — 動態評測、反資料汙染的方法與資料。
Meta AI (2023-2024). CodeLlama 及 CodeLlama 2 系列技術報告. — 開原始碼模型代表，評估引數與分數的公開記錄。
DeepSeek AI (2024). DeepSeek-Coder-V2 技術報告. — 行業最新模型之一，含評估細節。
Anthropic (2024). “Claude 3 Model Card.” Anthropic 官網及公開技術文件. — 商用 API 模型程式碼能力報告的參考案例。
Stack Overflow (2023). “Stack Overflow Developer Survey 2023.” https://survey.stackoverflow.co/2023/ — 開發者群體中使用 AI 程式設計工具的滲透率與關注指標調查資料（注：該調查旨在描繪開發者行為，非市場規模的直接測算）。

宣告：本文內容基於截至 2025 年 6 月的公開研究文獻與行業報告。凡涉及公司的具體財務資料、市場份額、定價策略等資訊，均未在信源中系統出現，故正文中標註“公開資料未見”。本文不構成對任何模型、公司或技術的推薦或貶低，亦不含任何投資建議或未來預測。