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)_{text(est)} = 1 - \frac{binom(n-c){k}}{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)_{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{binom(n-c){k}}{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 = {题目_1, ..., 题目_m}
模型 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 < 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 与真实企业任务成功率的映射函数。
最新事件（截至 2025 年 6 月）
注：以下事件基于公开信息，不构成对未来趋势的预测。
- 2024 年 Q2：LiveCodeBench (v2) 发布更新，纳入 2024 年 1-6 月的新题目 300+ 道。初步报告显示，在 2023 年训练截止日后发布的新题上，多款头部模型的 Pass@1 下降 10-25 个百分点。这引发了社区对数据污染更系统的讨论，以及动态评测集的更高呼声。
- 2024 年 7 月：BigCode 社区发布 StarCoder2-15B 的加强版，在 HumanEval+ 上首次实现开源模型的 Pass@1 > 80%（公开资料查询所得，精确数字请查阅 BigCode 项目博客）。这标志着测试集增强后，“虚高”空间被压缩。
- 2024 年 8 月：OpenAI 发布 GPT-4o 系统卡更新，其中包含代码能力的 HumanEval 组别实验。值得注意的是，该报告特意展示了在 HumanEval 原始版和增强版上的对比，反映业界头部公司也开始正视测试覆盖问题。公开资料未见详细增强版定义。
- 2024 年 10 月：DeepSeek-V2.5 系列发布，在 HumanEval 上报告开源新的高分，同时首次在技术博客中显著篇幅讨论了温度对 Pass@k 曲线的影响，体现了评估透明度的提升趋势。
- 2025 年 1 月：某独立学术团队在 arXiv 发布论文，对 2023-2024 年期间 12 款商用模型 API 进行了统一的 Pass@k 复现（使用相同的 n=200，T=0.8 协议），揭示出公开报告分数与独立复现间的系统性差异（部分模型高出 3-8 个百分点）。论文呼吁建立类似“标准化考试”的第三方动态评测机制。
- 2025 年 4 月：Anthropic 在 Claude 3.5 相关发布中，首次展示了其模型在“多文件代码生成”基准（自建，未公开细节）上的 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 月的公开研究文献与行业报告。凡涉及公司的具体财务数据、市场份额、定价策略等信息，均未在信源中系统出现，故正文中标注“公开资料未见”。本文不构成对任何模型、公司或技术的推荐或贬低，亦不含任何投资建议或未来预测。