HumanEval：函数级生成——LLM 的“入行笔试”

可视化演示

动态展示HumanEval函数级代码生成的评测流程、164题手写数据集结构、pass@k采样指标及HumanEval-X五种语言扩展（820题）。

评测基准概述

阿杰走进考场的那一刻，发现门口贴着一张告示：“本次考试共 164 道题，全部为真实工程场景中的函数编写题，请独立完成。”这张告示，就像 HumanEval 数据集的“考场布告栏”。HumanEval 是 OpenAI 在 2021 年发布的代码生成评测基准，包含 164 道由人类专家手写的编程题——每道题都是一个函数签名（函数名、参数列表、返回类型）加上一段描述功能需求的文档字符串，以及若干用于验证正确性的测试断言。

在 LLM 评测体系中，HumanEval 占据着独特的定位。如果说通用对话评测（如 MMLU、GSM8K）是“问答题考试”，那么 HumanEval 就是“上机编程考试”。它不关注模型能否“聊得好”，只关注模型能否“写对”。这正是函数级生成的核心：模型的输出不是一个完整的文件，而是一个单一函数。

评测流程像极了一个标准的自动化判卷系统：系统把函数签名和文档字符串作为 prompt 送给模型，模型生成函数体，然后系统在沙箱环境中运行该函数，调用预先写好的隐藏测试用例，逐条检查输出是否符合预期。所有测试全部通过，这道题得 1 分；任何一条失败，得 0 分——没有“部分分”。

阿杰从考场出来时感慨：“原来我的代码好不好，不是老师说了算，是那些隐藏测试用例说了算。”HumanEval 也一样——模型的“考试成绩”完全由断言决定，任何“我觉得我写得对”都不算数。这种机制的好处是客观、可复现，坏处是它只奖励正确答案，不奖励“接近正确答案”的尝试。

生成原理剖析

阿杰坐在考场的电脑前，屏幕上是这样一道题：

他的任务：在 def 和冒号之后写出函数体。这正是 HumanEval 中每一道题的标准形态。模型接收的输入是“函数签名 + 文档字符串”——相当于考题的题干，输出是函数体内的一段代码——相当于考生的答案。这个流程在学术上叫作“函数级代码补全”。

函数级生成的关键在于“单次采样”。模型不是通过多轮对话逐步完善答案，而是在给定 prompt 后，一次性地从左到右逐 token 生成函数体。这个过程可以理解为阿杰在草稿纸上一次把代码写完，而不是和监考老师来回确认。模型每一步根据已生成的部分，在词表上计算下一个 token 的概率分布，再从分布中采样。

阿杰写完一道题，深呼吸，点了“提交”。他不知道的是，模型在生成代码时并不能“回头检查”——一旦某个 token 选错，后面的生成很可能“将错就错”越走越偏。这就像写作文时不能回删，一句话写歪了，后面整段都会别扭。这也是为什么函数级生成对模型的“一步到位”能力要求极高。

def has_close_elements(numbers: list[float], threshold: float) -> bool:    """检查列表中是否存在两个元素的距离小于给定阈值。"""

pass@k 评分算法

考场上，有一种特殊情况：阿杰对一道题没有把握，于是他写了三个不同的版本提交。监考老师的评分规则是——只要其中任何一个版本通过了所有测试用例，这道题就算他对了。这就是 HumanEval 的 pass@k 评分思想：允许模型对同一道题生成 k 个候选答案，只要其中至少一个能通过所有测试，就视为该题通过。

但这里有个统计学陷阱。一种看似合理的计算方法是“测试时采样”：多次采样直到获得 k 个通过测试的答案，然后计算通过率。但这会高估模型的真实能力。正确的做法是“无偏估计”：预先采样 n 个独立答案（n ≥ k），统计其中通过测试的答案数量 c，再按下式计算：

为什么不能直接用“成功率”代替这个公式？假设一个模型在 n=10 次采样中有 8 次正确，那么它在 pass@1 上的真实表现更接近 0.8 还是某个调整值？答案是：如果直接取“在全部采样中的通过率”作为 pass@1，会因为样本方差而偏乐观。无偏估计公式在数学上消除了这种偏差。这就像用样本均值估计总体均值时需要修正自由度一样——统计的严谨性在此体现。

数据集构造特点

阿杰在考场上发现一个有趣的现象：这些题目的语言风格非常统一，像是出自同一位老师之手。HumanEval 的确如此——它的 164 道题目全部由 OpenAI 团队的研究人员手工编写，而非从 GitHub 等代码仓库中爬取。这个看似“费工夫”的决定，是为了规避一个大问题：数据污染。

如果题目是从公开仓库爬来的，模型的训练数据中很可能已经包含这些代码，那么考试就变成了“开卷抄答案”，分数字没有意义。手工编写意味着这些题在数据集发布之前从未出现在任何公开语料中，确保模型是“真会做”而非“背过答案”。

每一道题的构造也颇有讲究：题目包含函数签名、文档字符串描述、以及平均 7.7 个测试用例。这些测试用例不仅是简单的输入输出对，还覆盖了边界条件和特殊场景。文档字符串的风格模仿了 Python 标准库和各种开源项目的做法——用一句话描述函数功能，必要时补充参数说明和返回值说明。

这种构造方式的意义在于“防作弊”和“保公平”。就像高考出题组不会从学生人手一本的练习册里原封不动地选题一样，HumanEval 的出题人刻意避开了公开代码。同时，题目都足够“小而精”——一个函数、一个明确的功能描述、几个边界测试——不会因为题目歧义导致模型“读不懂题意”。

典型性能表现

阿杰考完试，拿到了成绩单。他好奇数据：这份成绩单，正是 HumanEval 上各模型的“考分排名”。OpenAI 的论文《Evaluating Large Language Models Trained on Code》报告了 Codex 在 HumanEval 上的初始表现——pass@1 为 28.8%。这个数字很快成为业内标杆：一个在 54M 个 GitHub 公开仓库上预训练过的代码模型，仅能答对不到三分之一的题目。

这个“28.8%“的意义远不止一个分数。它像一把尺子，让后续所有模型有了明确的”进步刻度“：GPT-3.5 将 pass@1 提升到 48.1%，GPT-4 达到 67%，Claude 3.5 Sonnet 超过 92%。HumanEval 从”几乎不可能完成的任务“变成了”基本达标”的入门门槛。这种演变展示了 LLM 代码能力的快速进化。

另一个显著特征是题目难度分布的不均衡性。HumanEval 的 164 道题中，既有简单到“返回两个数的和”这样的送分题，也有涉及多重嵌套逻辑、动态规划的中高难度题。模型的“答题正确率”会随题目难度的上升而显著下降——这与人类考生的表现高度一致：难点该不会的还是不会。

优化策略实践

阿杰发现同桌小李提交的答案通过率总是比自己高。一问才知道，小李的策略是：每道题不是只交一个答案，而是把几个不同思路的版本都交上去。而在 HumanEval 的世界里，“多写几个版本”正是最直接的涨分策略。

第一个关键参数是温度（temperature）。它控制着模型采样时的随机程度：温度越低，模型越倾向选择概率最高的 token，输出更保守稳定；温度越高，模型越敢于尝试低概率 token，输出更多样但也更容易出错。在 HumanEval 评测中，如果追求 pass@1，通常把温度设低（如 0.2）以获得最确定的输出；如果追求 pass@100，则把温度提高到 0.8，让模型生成更多样化的候选答案。

第二个策略是多次采样 + 投票。让模型对同一道题生成 k 个答案，然后用测试断言筛选出通过数量最多的答案（或随机选一个通过测试的）。这个策略的涨分效果令人惊讶：Codex 的 pass@100 达到了 71.2%，而 pass@1 只有 28.8%。多生成 99 次，正确率翻了一倍以上，因为不同的采样路径会探索到不同的解题思路，只要有一个想对了，就能得分。

第三个更高级的策略是自一致性（self-consistency）。它让模型在“自由发挥”模式下生成多个多样化答案，再通过“答案聚类”找到最一致的解题逻辑。在代码生成中，这意味着对同一道题生成多个候选，然后运行测试或用某种启发式方法找出“最可靠”的那个。这与人类解题时“多验算几遍”的直觉一致——共识往往更可信。

AI 应用场景

Python 演示

import mathimport random  def generate_candidates(model_prompt, n):    """模拟从 LLM 采样 n 个候选函数体 (这里用随机猜测代替真实 LLM)。"""    candidates = []    for _ in range(n):        # 模拟：随机猜测两个数的和是否正确        guess_sum = random.randint(1, 50)        candidates.append({"sum": guess_sum})    return candidates  def run_test(candidate, a, b):    """断言检查：候选函数是否正确实现了两数求和。"""    return candidate["sum"] == a + b  def compute_pass_at_k(n, c, k):    """无偏估计 pass@k: 从 n 个样本中已知 c 个正确, 随机抽 k 个至少含一个正确的概率。"""    if n - c < k:        return 1.0    comb = math.comb    return 1.0 - comb(n - c, k) / comb(n, k)  def main():    # 题面: 实现两数求和函数    a, b = 3, 5    expected = a + b    n = 100          # 模型采样 100 个候选答案    k = 10           # 允许 10 次尝试 (pass@10)    temp = 0.8     # 采样温度     candidates = generate_candidates("def add(a, b): ...", n)     correct_count = 0    correct_indices = []    for i, cand in enumerate(candidates):        if run_test(cand, a, b):            correct_count += 1            correct_indices.append(i)     passk = compute_pass_at_k(n, correct_count, k)    naive = correct_count / n     print(f"题目: 实现 add({a}, {b}) -> {expected}")    print(f"采样候选数: {n} | 温度: {temp}")    print(f"正确的候选数: {correct_count} / {n}")    print(f"朴素通过率: {naive:.4f}")    print(f"无偏估计 pass@{k}: {passk:.4f}")  if __name__ == "__main__":    main()

1. def compute_pass_at_k(n, c, k):这是核心函数，实现了论文中的无偏估计公式，避免了直接用“通过率”代替“通过概率”的统计偏差。
2. comb = math.combPython 内置的组合数计算函数，对应公式中的二项式系数 \(\binom{n}{k}\)。
3. if n - c < k: return 1.0边界情况处理：如果失败样本数小于 k，那么随机抽 k 个必然至少包含一个正确样本，概率为 1。
4. naive = correct_count / n这是朴素的“通过率”计算方法，注意它高估了 pass@k 中 k<n 时的真实通过概率，所以需要无偏估计修正。
5. run_test(cand, a, b)模拟 HumanEval 的断言验证机制：每个候选答案必须通过测试用例才算正确。

常见误区

面试题