HumanEval与MBPP：AI代码生成能力怎么测

可视化演示

展示HumanEval/MBPP基准的评测流程和pass@k指标的计算方式，直观理解代码生成能力评估方法。

两大基准是什么

回到那场“AI 程序员招聘会”。你手里有两套名声在外的笔试题库：一套出自大厂研发团队（OpenAI）之手，叫 HumanEval，收录了 164 道函数补全题；另一套则来自伯克利等高校研究者的整理，叫 MBPP（Mostly Basic Python Programs），收纳了 974 道基础 Python 编程题。业内很多人把它们戏称为“AI 代码圈的南北两大名校”——一个考逻辑推演，一个考基础功，双管齐下，防止偏科。

HumanEval 的题目长这样：模型拿到一个函数签名和一段说明文档，比如“计算列表中所有偶数元素的和”，它得把函数体补全出来。164 道题看起来不多，但每道题都经过了人工审视，基本覆盖了字符串操作、数学计算、数据结构变换等经典算法场景。MBPP 则更“口语化”：直接用自然语言描述需求，比如“写一个函数，输入一串单词，返回首字母大写的拼接结果”，模型要把整段可运行代码从零生成出来。如果说 HumanEval 是“给定骨架填血肉”，那 MBPP 就是“听到需求搭骨架再填血肉”，难度更基础，但更贴近真实开发中“需求 → 代码”的转化过程。

这两套题库的定位，简单说就是给模型分层级体检：HumanEval 检测“程序员的逻辑肌肉”，MBPP 检测“程序员的语言理解底板”。研究界之所以把这两个基准当作标配，是因为它们互补性强——一个偏严谨的算法理解，一个偏开放的自然语言理解。你在任何一份模型技术报告里看到 “HumanEval@1“ 或 ”MBPP@1“ 的分数，就相当于看到了这个 AI 程序员在这两场标志性笔试中的得分，横向对比时”含金量”最容易被行业认可。

题目设计思路

既然是一份合格的笔试试卷，题目本身的设计就是最大的学问。你给 AI 出题，既不能是“一句废话”式的开放式作文，也不能是偏题怪题。HumanEval 的每一题都遵循一个三段式结构：问题描述、函数签名、测试用例。问题描述用自然语言写清楚“要干什么”，函数签名像答题卡上的密封线，规定了函数名、参数类型和返回值类型，测试用例则交给后面说的判卷系统去处理。

这三段结构里有个常被忽略的隐藏考点：领域语言（domain-specific language）。模型得看懂“palindrome“（回文）、”Fibonacci“（斐波那契）、”binary tree traversal“（二叉树遍历）这些专业词汇，才能在脑海中调取对应的算法模板。这就像笔试里的英文阅读理解——不是单纯考语法，而是考”你知不知道这个行业黑话在说什么“。如果一个模型连”回文”是什么都不知道，那它第一步就输了。

题目难度控制也很有讲究。研究者刻意把题目设置在“大多数人类程序员能在几分钟内解决”的程度，排斥了需要大量领域经验或复杂系统设计的题目。为什么这么做？因为评测的初衷是测“代码生成的基础能力”，而不是测“系统架构能力”。如果题目难到人类专家都要想一小时，那模型答不出来，你也分不清它到底是算法能力不行，还是题目本身太偏。这就像是给小学生出奥数题，考了半天，测出来的其实不是“数学基础”，而是“有没有上过奥数班”。

一句话总结：HumanEval 的题目设计原则，是用规范和简洁，把“写代码”这件事拆解成可量化的能力切片——你翻译需求的能力、你读懂签名的能力、你实现经典算法的能力，各占一个评分维度。理解了出题逻辑，你才能读懂分数的含金量：它考的是“给定精确规格的编码能力”，而非“自由发挥的工程创造力”。

pass@k 怎么打分

笔试考完了，100 分的卷子，AI 交上来好几个版本的答案，怎么算分？人类考试只允许交一份答卷，AI 却可以“多交几份”。pass@k 指标的思路是：允许模型对同一个问题生成 $k$ 个候选答案，只要其中至少一个能通过全部测试用例，就算这道题“做对了”。

形式上，研究者先从模型中采样 $n$ 个样本（$n \geq k$），再从中随机挑选 $k$ 个样本，看这 $k$ 个里有没有正确的。但是直接枚举“从 n 里挑 k 的组合”代价太大，于是就有了下面这个经典的无偏估计公式：

其中 $n$ 是为每道题生成的答案总数，$c$ 是这批答案中通过全部测试用例的正确个数，$\binom{n}{k}$ 表示从 $n$ 个答案里任选 $k$ 个的组合数。这个公式的直觉是：先算“从 n 个答案里挑出的 k 个全都错了”的概率，用 1 减去这个全错概率，就是“至少命中一个对的”的概率。

如果只看 pass@1，就等价于让模型只提交一个答案，答对算对，答错算错。这衡量的是模型直接可用性——就像招聘时看“刚入职就能干活”的比例。而 pass@100 则衡量模型的潜力上限——哪怕它平时写的代码经常有小 bug，但只要 100 次里有一次能写对，就说明它的知识储备里存着正确答案，只是平时不一定能稳定输出。两个数字配合着看，一个看稳定性，一个看上限，好比看程序员“日常发挥”与“巅峰状态”。

测试用例怎么判

卷子交上来了，谁来判分？答案是测试用例。HumanEval 的每道题都附带一组标准的单元测试用例，比如计算偶数和的函数，测试用例会检查 sum_even([1,2,3,4]) == 6 这样的输入输出对。评测系统执行代码，把输入喂进去，把输出跑出来，跟标准答案逐一比对——全部通过，这道题记 1 分；有一个不通过，记 0 分。整个过程全自动，没有任何人工主观因素，保证了“同卷同判”的公平性。

MBPP 的测试用例比 HumanEval 构造得相对简单，通常覆盖 3 个以内的示例输入。这里隐含一个值得注意的事实：HumanEval 每道题平均只有 7.7 个测试用例。这意味着判卷标准其实很“宽松”——只要代码在这七八个点上输出正确，就算会做这题。这就像面试官只抽查了三四个边界条件，没把你的代码翻个底朝天。那么问题来了：AI 有没有可能“刷题”？有。它完全可能记住了这道题的某个变体，或者恰好写出的逻辑能糊弄过这有限几个用例。

所以，高质量的测试用例是评判的核心竞争力。研究者会用更极端的测试来“刁难”模型，比如引入大数据量输入、边界条件、特殊字符、并发场景等。那个著名的 EvalPlus 项目，就是把 HumanEval 原本平均 7.7 个测试用例，扩充到了平均 769 个——相当于把原本只抽查几张卷子的面试官，升级成把每一行代码都翻来覆去审查的监控器。在 EvalPlus 增强版的判卷标准下，靠“背题”蒙混过关的模型，分数会断崖式下跌，这个现象本身就说明了测试用例的重要性。

跑评测的实战流程

现在你手上有了考题和判卷标准，是不是就可以开跑了？且慢，真正的实战评测比想象中更讲究“实验纪律”。第一步是选择温度参数。温度（temperature）控制模型输出的随机性：温度越低，输出越保守，几乎总是选概率最高的那个答案；温度越高，输出越发散，更可能生成各种不同的答案。跑 pass@k 这类需要多样性的指标时，一般会把温度设置为 0.6~0.8 之间的某个值，让模型“认真作答但允许灵光一闪”。如果温度设成 0，生成的 $k$ 个答案几乎是一模一样的，那 pass@k 就退化成 pass@1 了，失去了“多次机会”的意义。

第二步是控制采样数量 $n$。你为每道题生成多少个候选答案，直接影响最终分数的置信度。生成太少，统计波动大；生成太多，算力和时间成本陡增。常见做法是每道题生成 200 个左右候选，从中计算 pass@1、pass@10、pass@100 这几个档位的分数。

第三步是固定随机种子。AI 从随机噪声开始生成内容，如果不固定种子，同一模型跑两次评测，分数可能差出好几个百分点，这就像两次考试题目内容毫无变化，但考生却因状态起伏考出了不同分数。为了保证“可复现”，研究者会固定随机种子，让每次评估生成相同的候选样本序列。

最后一点，公式实现上也藏着坑：那个组合数公式如果直接用浮点运算，当 $n=200$、$c$ 很大时可能溢出。所以标准实现会在计算过程中不停地约分，或者在分子分母上做变换来避免天文数字。比如，直接用 comb(n-c, k) / comb(n, k) 在数值上更稳健。跑评测不是把模型调出来、把代码喂进去、看个输出就完事——它更像一场“双盲实验”，严格控制变量，才能保证对比有意义。

局限与改进方向

任何一套好用的技术，都有它的天花板。HumanEval 和 MBPP 最大的阴影，是数据污染。所谓数据污染，就是指这些静态的题目在互联网上泄露了。模型在预训练阶段可能已经把题目和标准答案一起“背”了下来——它根本不需要会写代码，只要背熟“答案库”，就能在考试中拿到高分。这就好比考题已经在小圈子论坛上传疯了，你再考，考出来的就是“记忆力”，不是“编程能力”。

第二个痛点是测试用例的覆盖不足。前面提到 HumanEval 平均仅 7.7 个测试用例，漏掉大量边界条件。一个模型可能用完全错误的逻辑误打误撞通过了个位数用例，拿个满分。针对这点，EvalPlus 应运而生：它用自动化变体扩展出大量额外测试用例，把“背题党”的分数打回原形。甚至，在 EvalPlus 的增强版测试下，某些模型在原始 HumanEval 的高分神话会瞬间破功，下降 20 个点以上。

第三个方向是动态更新基准。既然静态题库会被污染，那就让考题“活”起来。LiveCodeBench 定期从竞赛网站或代码仓库抓取新题，每隔一段时间就换一批卷子。AI 程序员面对的永远是不曾见过的“新题型”，无从背起。另外，多语言扩展也在弥补 HumanEval 只考 Python 的单一性——MBXP、MultiPL-E 等基准把同一批题翻译成 Java、C++、Go、Rust 等十几种语言，考察模型跨语言迁移的通用代码能力。

AI 应用场景

Python 演示

# -*- coding: utf-8 -*-"""Unbiased pass@k estimation for HumanEval/MBPP evaluation."""import mathimport random  def estimate_pass_at_k(num_samples: int, num_correct: int, k: int) -> float:    """Estimate pass@k of one problem.     Args:        num_samples: total number of generated samples (n)        num_correct: number of samples that passed all tests (c)        k: the k in pass@k     Returns:        Estimated probability that at least one of k samples is correct.    """    if num_correct == 0:        return 0.0    if num_correct == num_samples:        return 1.0    # Use combinatorial identity to avoid division overflow    comb_n_k = math.comb(num_samples, k)    comb_nc_k = math.comb(num_samples - num_correct, k)    return 1.0 - comb_nc_k / comb_n_k  def simulate_pass_at_k(eval_results: list, k: int, seed: int = 42) -> float:    """Simulate pass@k from a list of (n, c) pairs, averaged over problems."""    rng = random.Random(seed)    per_problem = []    for num_samples, num_correct in eval_results:        rng.seed(seed)        p = estimate_pass_at_k(num_samples, num_correct, k)        per_problem.append(p)    total = sum(per_problem)    return total / len(per_problem) if len(per_problem) > 0 else 0.0  if __name__ == "__main__":    # Example: 2 problems, each generated 200 samples,    # with 136 and 158 correct respectively.    results = [(200, 136), (200, 158)]    for k_value in (1, 10, 100):        score = simulate_pass_at_k(results, k=k_value)        print(f"pass@{k_value} = {score:.4f}")    # Direct check for numerical sanity    p1 = estimate_pass_at_k(200, 136, 1)    p10 = estimate_pass_at_k(200, 136, 10)    assert 0.0 <= p1 <= 1.0    assert p10 >= p1    print("sanity check passed")

1. math.comb(num_samples, k)计算组合数 $\binom{n}{k}$，用 Python 标准库实现，避免自写阶乘溢出。
2. comb_nc_k = math.comb(num_samples - num_correct, k)计算从错误样本中抽 $k$ 个的组合数，这是“全错概率”的分子。
3. return 1.0 - comb_nc_k / comb_n_k用 1 减去全错概率，得到“至少对一个”的无偏估计，即 pass@k。
4. for k_value in (1, 10, 100)同一批评测结果分别算 pass@1、pass@10、pass@100，展示不同 k 值的分数差异。
5. assert p10 >= p1验证“k 越大，通过率越高”的单调性直觉，确保公式没有用反。

常见误区

面试题