HumanEval：函数级代码生成

可视化演示

三步展示函数级代码生成：docstring/签名/补全三类输入形式、自回归逐token生成函数体、以及pass@k无偏估计与EvalPlus增强测试用例评测。

评估粒度：一道菜的考试

如果想让一个 AI 厨师做菜，最简单的考法是什么？不是让它开餐厅，而是让它炒一盘宫保鸡丁：考官递上菜名、主料辅料清单、口味要求，它把成品端上来。这就是函数级代码生成——把“做菜”的最小完整单元拎出来单独考。HumanEval 对模型做的事，就是递上这张“单菜考卷”，让模型展示最核心的厨艺基本功。

有人可能会问：为什么不直接考完整项目？答案藏在“评估粒度”四个字里。代码生成可以分成三个层级：函数级只生成一个函数体，像“考一道菜”；文件级要求补全整个文件，像“配一桌宴席”；项目级要跨文件组织模块、管理依赖，像“经营一家餐厅”。函数级聚焦在算法实现与 API 调用能力上，把环境变量、文件 IO、外部依赖全部剥掉，只留纯粹的逻辑。

HumanEval 的函数级任务采用一问一答的结构。问题 = 函数签名 + docstring，签名像菜名和食材清单，docstring 是烹饪说明；答案 = 函数体。评估时，系统把测试用例像评委夹菜一样塞进函数去执行，全部用例通过才算过关。这种格式非常干净：不依赖任何外部文件，因此可以完全自动化地批量判分。

单菜考核的好处，就像考厨师只考一道麻婆豆腐：成本低、标准统一、人人都能上手。它牺牲了对复杂工程能力的考察，却换来了公平、可复现、可大规模执行的评估体验——这正是函数级评估成为业界基准起点的根本原因。

基准构造：164 道手写考题

出考卷是有讲究的。只考一道菜，厨师背熟菜谱就能蒙混过关；考一百多道菜，才能摸出真实水平。HumanEval 的考卷由 OpenAI 团队从零开始手写，一共 164 道 Python 题，每一道都像一个标准化的“单菜考题”，题目之间互不重复，且刻意覆盖不同知识点，防止“押题”。

与题目绑定的，是“可判分”的设计。每道题不仅给出函数签名和 docstring，还配了一批手写单元测试用例，平均每道约 7.7 个。这些用例就是评委的“味觉标准”：输入什么参数、应该输出什么结果，全部写死。没有这些用例，机器的“尝菜”就无从谈起。

从内容上看，这 164 道题覆盖了多个“菜系”：字符串处理、数学运算、链表操作、逻辑推理等。难度定位在中等偏易的编程面试题，既不刁钻也不送分，让大多数模型都能拿到一些分数，从而形成梯度，方便区分能力高低。题目多改编自常见算法书和面试题，但经过了重新表述，尽量与当时的公开训练数据错开，降低模型“背答案”的风险。

这份考卷刻意排除了所有“超纲材料”——没有外部库，没有文件读写，唯一允许的操作都在函数内部完成。正是这种干净利落的“厨房设置”，让 164 道菜之间的难度可比、不同模型的分数可比。题目是手写的，用例是手写的，整个数据集只有 164 条，却撑起了一个行业的标尺。

评估方式：评委实际尝菜

在 HumanEval 出现之前，评估代码生成常用 BLEU、编辑距离这类指标。它们本质上是“看照片评分”：把模型生成的代码和参考答案放一起，比一比字符重叠度。长得像就加分。但长得像不代表好吃——就像一碗麻婆豆腐摆盘再还原，味道不对照样不能过关。HumanEval 换了一个思路：不看了，直接端起来尝。

所谓“尝”，就是把生成的函数放进 Python 解释器执行，用单元测试的断言去比对实际输出。整个过程不需要人工介入，也不需要模型自圆其说。程序跑一遍，对就是对，错就是错，这是“功能正确性”与“文本相似度”最本质的区别。评判逻辑可以写成一句话：

这道公式的意思是：评委不是看“你像不像做了麻婆豆腐”，而是真的夹一筷子（喂入输入），尝一下咸淡（比对输出），评分表上每一项都打钩，才盖下“合格”的章。因此，即使模型写出了一堆风格怪异、和参考答案完全不像的代码，只要执行结果正确，HumanEval 依然给满分——这是它和传统文本指标最大的分水岭。

指标解析：pass@k 过关概率

厨师考试难免紧张，一次发挥失常不代表不会做菜。于是考官改了规则：给你 k 次机会，每次重做一版，只要任意一次过关，就认定你具备这道菜的能力。这就是 pass@k 指标的核心思想。在真实评测中，模型对同一道题会采样 n 个候选答案，其中一部分能通过全部测试，一部分不能，然后我们再模拟“随机抽 k 次，至少抽中一次正确答案”的概率。

为什么不能简单地把正确率当成 pass@k？因为 n 个候选里可能有很多正确解，而我们要评估的是“在有限次尝试内抓住机会”的能力。假设模型采样了 n 个候选，其中 c 个是功能正确的，那么从 n 个里任取 k 个，一次都没抽中正确的组合数，就是从剩下 n-c 个错误候选里取 k 个的组合数。于是：

如果 k=1，公式退化为 pass@1 = c/n，也就是“一次性出手就成功”的概率，这是最严格也最常见的报告指标。如果 k 不断放大，相当于允许厨师反复试错补考，成功率自然节节攀升。所以看模型排行榜时，务必先确认报道的是 pass@1 还是 pass@100——别被“放水规则”骗了。

意义地位：行业标尺

当整个厨师行业都认可“麻婆豆腐单菜证”，餐厅招人、厨师切磋就有了共同语言。HumanEval 在 LLM 世界扮演的正是这把标尺的角色。它定义了一个简单、透明、可复现的“菜品”，让所有 AI 厨师都能在同一张灶台上比试，分数一出来，高低立判。

它让不同实验室的模型能够在同一张考卷上横向对比。OpenAI 的 Codex、Anthropic 的 Claude、Meta 的 Llama，几乎所有主流模型的论文里都会写一句“在 HumanEval 上 pass@1 达到了 xx%”。这就好比运动员参加统一的百米赛跑，虽然训练方法各异，但计时器只有一个，成绩可以直接放进同一个排行榜。

除了对比价值，它的工程意义也很突出。数据集完全开源，复现成本极低；一次评估只需几分钟到几十分钟，非常适合研发迭代；它还被社区移植成多语言版本，衍生出 MBPP、HumanEval+、MultiPL-E 等一系列评测集，形成了一套完整的评测生态。码能力由模糊的“感觉”变成了可量化的分数。

一句话总结：HumanEval 给了每个 AI 厨师一张全国通用的“等级证书”。它只是入门级的考核，但正因为入门，才让所有选手站在同一条起跑线上。没有这把标尺，各家模型“代码能力很强”的说法就只是自说自话。

挑战局限：考试有漏洞

任何考试都有应试技巧，HumanEval 也不例外。第一道裂缝是“题库泄漏”：如果模型在训练阶段已经见过这 164 道原题，考试就变成了“默写”。不少研究已经发现，部分模型在 HumanEval 上的高分包含了对训练数据的记忆成分，导致分数虚高，无法真实反映泛化能力。

第二道裂缝是“难度天花板”。这 164 道题都是家常菜级别，大厨能做，刚学厨的新手也能做，大家分数都接近满分时，就分不出水平高低了。近年来头部模型在 HumanEval 上的 pass@1 已经逼近 90%，甚至更高，区分度明显下降。想进一步拉开差距，需要更难的题库。

第三道裂缝是“只考味道不看摆盘”。HumanEval 不评估代码风格、可读性、运行效率，只要测试通过就给分。于是模型可能产出“能跑但很丑”的代码——变量名混乱、逻辑绕弯、性能糟糕，这些在真实工程中恰恰是致命的。它也不涉及依赖管理、系统设计等大型工程能力，无法反映“经营餐厅”的综合素质。

所以，要把 HumanEval 当成“入门笔试”，而不是“终极裁判”。高分说明基本功扎实，低分说明能力有明显短板，但两个同分的大厨谁更厉害，还得另开一个更硬核的赛场。理解这些漏洞，才能正确解读排行榜上的数字，而不是被一个漂亮的分数冲昏头脑。

AI 应用场景

Python 演示

# -*- coding: utf-8 -*-"""极简 HumanEval 风格函数级评估演示。""" import randomfrom math import comb TASKS = [    {        "name": "add",        "signature": "def add(a, b):",        "doc": "Return the sum of a and b.",        "tests": [(1, 2, 3), (0, 0, 0), (-1, 5, 4)],        "candidates": [            lambda a, b: a + b,        # 正确实现            lambda a, b: a - b,        # 做了减法            lambda a, b: a * b,        # 做了乘法            lambda a, b: abs(a + b),   # 加了绝对值        ],    },    {        "name": "is_even",        "signature": "def is_even(n):",        "doc": "Return True if n is even, else False.",        "tests": [(2, True), (3, False), (0, True)],        "candidates": [            lambda n: n % 2 == 0,            lambda n: n % 2 == 1,            lambda n: n % 2 == 1,            lambda n: n % 2 == 0,        ],    },]  def run_test(func, test):    """执行单个测试：把输入喂给函数，比对期望输出。"""    inputs, expected = test[:-1], test[-1]    return func(*inputs) == expected  def evaluate_one(func, tests):    """评估单个函数：全部测试通过才算过。"""    return all(run_test(func, t) for t in tests)  def sample_candidates(task, n):    """模拟模型从候选池中采样 n 个函数。"""    return [random.choice(task["candidates"]) for _ in range(n)]  def pass_at_1(correct, n):    """pass@1：一次出手就成功的概率。"""    return correct / n if n else 0.0  def pass_at_k(correct, n, k):    """pass@k：k 次机会至少命中一次正确的概率。"""    if correct == 0:        return 0.0    return 1.0 - comb(n - correct, k) / comb(n, k)  def main():    random.seed(42)    n, k = 8, 2    print("=== 极简 HumanEval 函数级评估器 ===")    for task in TASKS:        print("\ntask:", task["name"], task["signature"], "-", task["doc"])        for idx, cand in enumerate(task["candidates"]):            passed = evaluate_one(cand, task["tests"])            print("  cand %d -> %s" % (idx, "PASS" if passed else "FAIL"))        samples = sample_candidates(task, n)        correct = sum(evaluate_one(s, task["tests"]) for s in samples)        print("  sampled=%d correct=%d pass@1=%.2f pass@%d=%.2f"              % (n, correct, pass_at_1(correct, n), k, pass_at_k(correct, n, k)))    print("\n=== 评估完成 ===")  if __name__ == "__main__":    main()

1. def evaluate_one(func, tests):定义“单菜考核”入口，一个函数配一批测试。
2. return all(run_test(func, t) for t in tests)关键判分逻辑：测试全部通过才返回 True，等价于正文中的全称量词公式。
3. samples = sample_candidates(task, n)模拟模型对同一道题采样 n 个候选答案。
4. correct = sum(evaluate_one(s, task["tests"]) for s in samples)统计 n 个候选中功能正确的数量 c。
5. return 1.0 - comb(n - correct, k) / comb(n, k)直接实现 pass@k 组合公式。

常见误区

面试题