HumanEval基准：LLM代码能力评估标准

可视化演示

展示HumanEval基准的pass@k指标评估原理：多模型多k值对比曲线，以及从Prompt到代码通过的完整评测流程。

基准设计理念

要给AI厨师办考级，第一件事不是做满汉全席，而是先把考卷设计清楚。如果你让厨师自由发挥，出来的菜五花八门，评委根本没法横向比较。于是HumanEval选择了“函数级考题”：只考察从输入到输出的单点技能，相当于给你一盘固定食材和一张菜谱，看你能否按标准完成。这样一来，考卷既容易自动批改，又能精准衡量模型的基本功。

在2021年之前，评估代码生成主要靠人读生成结果，慢且主观。OpenAI团队用HumanEval想解决的就是“如何快速、自动、可复现地判断一个函数实现是否正确”。他们选择函数粒度的任务是刻意的——函数是工程中最重要的可复用单元，也最容易用单元测试验证。每个问题像一张“标准化菜卡”：有明确的食材清单（函数签名）、烹饪说明（文档字符串），还附上评委的验收标准（若干测试用例）。

这背后的设计哲学是：与其追求逼真的大型项目，不如先把小而精的题目做到绝对公平。所有题目由人类专家手工编写，刻意避开公开代码库，防止模型在预训练阶段“偷看过答案”。这就像考级委员会亲自研发新菜，而不是从某本畅销菜谱里原封不动抄题。

最终，HumanEval用“功能正确性”这一个维度统领全局：结果对，就通过；结果错，就失败。这份拳拳到肉的简单，正是它在众多复杂评估方案中脱颖而出的原因。

数据集构建

有了理念，下一步是出考卷。HumanEval的考卷一共包含164道手写编程题。164不是玄学，而是一个平衡点：既要覆盖足够多样的编程模式，又要让人工编写和评审的成本可控。每道题都精心设计，从“判断一个数是否为偶数”到“实现一个简单的图遍历算法”，难度大致落在入门到中等区间。

每道题都有统一的格式，像标准化试卷一样分成三部分。首先是函数签名，例如 def solution(nums: List[int]) -> int:，它规定了函数名、参数类型和返回类型；其次是文档字符串，用自然语言描述函数应该做什么；最后是3到8个测试用例，作为自动批改的依据。模型看到的是“前面两页”，批改系统则用“第三页”来打分。

在题目收集过程中，设计者注意控制难度分布，避免过多难题也避免全是简单题。更重要的是，他们坚持不使用任何第三方库的API，让题目只依赖Python标准库。这好比考食材只从基础菜市场采购，不涉及需要特殊进口调料的烹饪。每道题的平均解答长度不到20行，保证“读懂题目”本身不成为障碍。

于是，这164道手写题成了LLM代码能力评估领域流传最广的“考卷”——它不大，但每个字都经过人工推敲，在规模与质量之间找到了很好的平衡。

测试用例构造

考卷有了，还要有评委。在HumanEval里，评委不是人，而是测试用例集合。想象你品尝一道菜，只尝第一口是不够的，还要试试太辣、太甜、分量太小的极端情况。测试用例的设计正是这个道理：除了常规输入，还刻意加入空列表、负数、重复元素、极大数值等边界条件，专门考验函数的鲁棒性。

“全部通过才算合格”是这套考核的铁律。若一个实现只过了部分测试，哪怕只是某一个边界情况出错，评分系统也判它失败。这就像菜品只要有一道验收标准不达标，厨师就不能拿满分。评判过程不需要人读代码，系统直接调用生成函数，把每个测试用例的输入喂进去，再把返回值与期望输出比对。

用数学语言来说，判定方式是：

正因为测试用例是预先设计好的“评委清单”，不同模型在同一道题上的得分才具有可比性。这也解释了为什么HumanEval能实现“全自动流水线评分”：从输入到判定，全链路无需人工介入。

pass@k指标

即使AI厨师水平再高，也难免有一次发挥失常——采样温度一高，输出就可能偏离正确答案。如果只考一次就下定论，对模型并不公平。于是HumanEval引入了一个关键指标：pass@k，意思是“允许厨师尝试k次，只要其中有一次成功，就算过关”。这像极了考试中的重考机会，只是把“重考”内嵌到了评估指标里。

它的计算方式不是简单重复采样取平均值，而是一个严格的无偏估计。对某道题，我们让模型采样生成 n 个候选解，其中 c 个通过了全部测试。那么随机抽取 k 个候选，至少有一个能通过的成功概率是：

在实际使用中，pass@1和pass@100是两个最常被引用的数值：前者衡量模型“一次写对”的能力，贴近IDE实时补全场景；后者衡量模型在“多轮尝试”下的上限，贴近Agent自主编码场景。这也意味着你不能只看一个数字，而要根据业务场景选择合适k。

评测执行环境

有了考卷和评分标准，还要一个公平的考场。HumanEval的评测执行环境好比“透明玻璃厨房”：厨师在完全隔离的空间里做菜，评委隔着玻璃观察，既能看到制作过程，又防止厨师偷偷携带外部调料。在技术上，这意味着把模型生成的代码放进沙箱——通常是子进程或Docker容器——隔离执行。

沙箱的作用有三层。第一层是安全隔离：模型生成的代码不可信，可能包含恶意系统调用或死循环，必须限制文件读写、网络访问等操作。第二层是资源限制：每道题分配固定的超时时间和内存上限，超时即判失败，防止某个坏实现拖垮整个评估系统。第三层是标准判定：程序退出时只检查函数返回值是否匹配期望输出，不依赖标准输出文本，避免“打印结果碰巧正确”这种取巧情况。

在HumanEval最初的实现中，评测服务会为每个候选解启动一个独立进程，在干净的Python环境里执行导入和函数调用。任何运行时异常、超时或返回值不匹配，都会被记为失败。这种“考场上只看结果”的做法，最大程度保证了不同模型之间的公平性。玻璃厨房虽然隔离，但阳光透明——每一位裁判看到的都是同一套规则。

现存局限

再经典的考卷也有过时的一天，HumanEval同样不例外。第一个局限是规模偏小：只有164道题，覆盖的编程模式终究有限。好比一份只含十几道菜的菜单，很难测试出厨师的全部手艺。第二个局限是代码规模有限：题目平均解答不到20行，根本触及不到真实工程中的模块设计、异常处理、性能优化等复杂问题。

更令人担忧的是数据污染风险。HumanEval发布于2021年，此后大量模型的训练语料可能已经包含了这些题目和解答。就像一个考生偷偷拿到了考卷答案，再考一次超高分也就不能说明真实实力了。此外，随着模型能力快速提升，HumanEval的难度天花板逐渐触顶：新一代模型在pass@1上普遍能拿到80%~90%以上的分数，区分度明显下降。

这好比当初精心设计的入门级厨师考卷，如今被各路大厨轻松拿满分，作为晋升考核已经不够用了。HumanEval本身没有变，变的是AI厨师的整体水平。它依然有参考价值，但不再能单独作为衡量代码能力的标尺。

改进扩展方向

既然Old考卷不够用，业界自然开始了“升级考卷”的探索。一个方向是给原题加难度：EvalPlus在HumanEval原有测试用例基础上，通过自动生成和变异测试补充了大量新用例，把每道题的平均用例数从不到10个扩充到数百个。相当于原来的评委只尝一口，现在要闭着眼睛盲试几十种极端口味，让“碰巧通过”的模型原形毕露。

另一个方向是扩充题量。MBPP（Mostly Basic Python Problems）收集了约1000道更基础但也更多样的Python编程题，作为HumanEval的补充，尤其适合考察模型在简单任务上的稳定性。还有研究团队把HumanEval翻译成C++、Java、JavaScript等多语言版本，相当于用同一套菜谱考不同菜系的厨师，检验模型跨语言迁移能力。

最值得一提的是LiveCodeBench：它坚持“滚动更新题库”，定期加入新题，从而对抗数据污染。就像考级委员会每季度更换一批秘制新菜，彻底杜绝背答案的可能，让分数始终反映真实能力。这些改进方向共同指向一个目标——让LLM代码评估从“静态考卷”走向“动态、全面、抗污染”的新时代。

AI 应用场景

Python 演示

"""一个小型的 HumanEval 风格评估演示"""from math import comb  def estimate_pass_at_k(num_samples, num_correct, k):    """用无偏估计公式计算 pass@k。"""    if k <= 0:        return 0.0    if num_correct >= num_samples:        return 1.0    return 1.0 - comb(num_samples - num_correct, k) / comb(num_samples, k)  def run_unit_tests(source_text, test_cases):    """在受控环境里执行函数源码，全部用例通过才算 True。"""    namespace = {}    try:        exec(source_text, namespace)    except Exception:        return False    func = namespace.get("solution")    if func is None:        return False    for args, expected in test_cases:        try:            if func(*args) != expected:                return False        except Exception:            return False    return True  def main():    docstring = (        "def solution(n: int) -> bool:\n"        '    """返回 n 是否为偶数。"""\n'    )    test_cases = [((2,), True), ((3,), False), ((0,), True), ((-4,), True)]     candidates = []    for i in range(10):        if i < 7:            candidates.append(docstring + "    return n % 2 == 0")        else:            candidates.append(docstring + "    return n % 2 == 1")     results = [run_unit_tests(src, test_cases) for src in candidates]    num_correct = sum(results)    print("候选解数量:", len(candidates), " 通过数量:", num_correct)    for k in (1, 2, 5, 10):        score = estimate_pass_at_k(len(candidates), num_correct, k)        print(f"pass@{k} = {score:.4f}")  if __name__ == "__main__":    main()

1. from math import comb导入组合数函数，为无偏估计公式做准备。
2. exec(source_text, namespace)动态执行模型生成的代码，相当于在评估容器里运行候选解。
3. namespace.get("solution")从执行环境中取出模型定义的函数对象。
4. for args, expected in test_cases:逐个测试用例运行函数并比对输出。
5. comb(num_samples - num_correct, k) / comb(num_samples, k)计算“抽到的全是失败解”的概率。
6. 1.0 - ...用补集算出至少一个通过的概率，即无偏pass@k。

常见误区

面试题