07. 代码生成评测的 Pass@k 指标是什么？有哪些常见 benchmark？

简单回答

Pass@k 是代码生成评测中最重要的指标，定义是：对同一道题生成 $n$ 个候选解，只要有 $k$ 个或以上通过所有测试用例，就算 pass。实际中最常用的是 Pass@1（生成一次通过率，模拟实际使用场景）。Pass@k 的优势是结果可执行验证，客观可靠，没有 LLM Judge 的主观偏差。主流代码 benchmark 包括 HumanEval（Python 基础）、MBPP（更多样）、SWE-Bench（真实工程任务）、LiveCodeBench（持续更新防污染）等。

详细解答

Pass@k 的精确定义

直观理解 Pass@k 很简单：生成 $n$ 个候选解，其中 $k$ 个通过了测试用例，就算 pass（$k\le n$）。但这个直观定义有统计问题——如果直接计算 pass 的比例，当 $n$ 较小时方差很大。

Chen et al. 2021（HumanEval 论文）提出了一个无偏的估计公式：

$\text{Pass@k}=\underset{\text{Problems}}{\mathbb{E}}\left[1-\frac{\left(\genfrac{}{}{0ex}{}{n-c}{k}\right)}{\left(\genfrac{}{}{0ex}{}{n}{k}\right)}\right]$

其中 $n$ 是每道题生成的总候选数，$c$ 是通过测试的候选数，$k$ 是我们关心的预算（比如 k=1 或 k=10）。

这个公式的直觉是：$\left(\genfrac{}{}{0ex}{}{n-c}{k}\right)/\left(\genfrac{}{}{0ex}{}{n}{k}\right)$ 是从 $n$ 个候选里选 $k$ 个，全部都是失败的概率；用 1 减去这个概率，就是至少一个成功的概率。

当 $k=1$（最常用的场景）时，公式简化为：

$\text{Pass@1}\approx \frac{c}{n}$

也就是通过率的简单平均，但为了得到稳定估计，需要对每道题生成多个候选（通常 $n\ge 20$），然后用上面的无偏公式计算。

Pass@1 vs Pass@10 vs Pass@100 的意义

Pass@1：模拟"用户只让模型生成一次，有没有得到正确答案"。这最接近真实使用场景，是目前报告最多的指标。

Pass@10：模拟"让模型生成多个方案，用户选最好的一个"。这在 AI 辅助编程工具里比较真实——用户可以看到多个建议，选一个用。

Pass@100：主要用于研究目的，衡量"给足够多的机会，模型能不能至少一次做对"，是模型能力的上界估计。

测试用例质量的重要性

Pass@k 的可靠性完全取决于测试用例的质量。如果测试用例不完整（没有覆盖边界情况），一段有 bug 的代码可能通过所有测试，导致 Pass@k 虚高。HumanEval+ 和 MBPP+ 就是专门为 HumanEval 和 MBPP 补充了更严格的测试用例，很多在原版测试集通过的代码在 + 版本里被检测出了问题。

主流代码 benchmark

HumanEval（OpenAI，2021）：164 道 Python 函数级别的编程题，每道题有约 7~8 个测试用例。是代码评测的基础 benchmark，但数量少、难度中等，现在顶尖模型 Pass@1 已经超过 90%，区分度不足。

MBPP（Mostly Basic Python Programming）（Google，2021）：374 道 Python 编程题，覆盖更多类型的任务，和 HumanEval 相比题目更"真实"（来自编程练习网站）。

SWE-Bench（普林斯顿，2023）：从 GitHub 上收集的真实软件 issue 和对应的修复 PR，要求模型生成能通过测试的 patch。这是目前最接近"真实工程"的代码评测——不是写一个独立函数，而是理解大型代码库、定位问题、修复 bug。SWE-Bench Verified 是人工筛选过的高质量子集，目前最强的 AI 系统 Pass@1 约 50%~60%（截至 2025 年初）。

LiveCodeBench（2024）：从 LeetCode、AtCoder、CodeForces 等竞赛平台持续收集新题，每周更新，用"题目发布时间晚于模型训练截止"来规避数据污染。是目前数据污染最少、更新最及时的代码 benchmark。

MultiPL-E：把 HumanEval 的题目翻译成 18 种编程语言，用来评测多语言代码生成能力。

DS-1000：Python 数据科学相关的代码生成，任务来自真实的 Stack Overflow 问题，覆盖 NumPy、Pandas、Matplotlib 等库。

代码评测的边界情况

代码功能正确但效率差：测试用例只验证功能正确性，不验证效率。一个 $O(n^3)$ 的暴力解和一个 $O(n\log n)$ 的最优解都能 pass，但工程质量差很多。需要额外的时间/空间复杂度检测才能区分。

代码通过测试但不安全：测试用例不能发现 SQL 注入、缓冲区溢出等安全问题。代码安全性评测是独立的维度（CyberSecEval 等 benchmark 专门测这个）。

面试时可以这样答

Pass@k 是代码生成最可靠的评测指标，因为结果可以执行验证，没有主观判断的问题。定义是生成 n 个候选，计算"至少 k 个通过"的概率，实际用无偏公式计算，需要每道题生成多个候选再取统计估计。

最常用的是 Pass@1，模拟用户只取一次结果的场景，现在报告新模型代码能力时基本都用这个。Pass@10 适合 AI 辅助工具场景，用户可以看多个建议选一个。

主流 benchmark 的选择取决于需要测什么：HumanEval 是基础但现在区分度不够了，顶尖模型基本满分；SWE-Bench 是真实工程任务的金标准，修复 GitHub issue，可执行验证，最接近实际工程能力；LiveCodeBench 持续更新竞赛新题，防污染做得好，区分度高。

Pass@k 的质量依赖测试用例覆盖率，HumanEval+ 专门补充了更严格的测试，很多原版通过的代码在 + 版本里被检测出 bug，说明原版测试用例有漏洞。

常见追问

1. 为什么直接用通过率计算 Pass@1 会有偏差？无偏公式具体解决了什么问题？
2. SWE-Bench 和 HumanEval 测的能力维度有什么本质区别？
3. 代码生成评测能不能用 LLM-as-Judge 替代执行验证？有什么场景下可以考虑？