Code LLM评测：代码能力基准

可视化演示

展示HumanEval基准模型对比、pass@k采样概率计算过程、以及多语言编程能力横向评测三大评测维度。

1. 评测概述

评委团的第一项工作，是设计一张能让所有 AI 大厨服气的评分表。没有这张表，大厨 A 说“我做的鱼香肉丝好吃”，大厨 B 说“我做的更地道”，谁也无法说服谁。只有把“好吃”拆解成固定的菜品、固定的调料用量、固定的试吃标准，比赛才能开始。

把场景搬到 AI 领域，Code LLM 评测做的就是这件事：用一套可复现的基准，把“模型会不会写代码”这个模糊问题，变成一串可比较的数字。一套评测基准包含三个要素：题目集（编程任务）、判分方式（通常是单元测试断言）、评分函数（如何汇总成指标）。流程像一个闭环：给模型出题 → 模型生成代码 → 在隔离环境中执行 → 用断言验证输出 → 汇总分数。

这个闭环中最直观的分数，就是“通过率”。

有了这张评分表，评委团才能从“我觉得他会做菜”走向“数据显示他能做 80% 的菜”。这就是评测之于 Code LLM 的意义：它把主观印象变成工程决策的依据。

2. 类人评测集（HumanEval）

评委团的第一份考卷，是一套“固定菜谱”。每道菜的名头、食材、火候要求都写得清清楚楚，大厨只需要把最后的成品端上来。这份考卷就是 HumanEval——OpenAI 在 2021 年发布的人工手写 Python 题目集，一共 164 道函数级编程题。

为什么强调“人工手写”？因为如果题目直接从 GitHub 上抄，AI 大厨可能早就在训练时“背过菜谱”，考试就失去了意义。HumanEval 的每一道题都包含：函数签名、文档注释（docstring）、若干条测试断言。例如题目给出 def add(a, b): """返回两数之和"""，模型需要补全函数体，而评委用 assert add(2, 3) == 5 这类断言来验证对错。

HumanEval 的单次通过率计算非常简单直接。

固定菜谱的价值在于“剥掉创意，只比基本功”。HumanEval 不考读长文档、不考多文件协作，只考一个函数能不能被正确写出来——这让不同模型的编程肌肉记忆可以直接对比。

3. 通过率指标（pass@k）

评委团很快发现一个麻烦：AI 大厨偶尔会手抖。同一道菜，状态好时色香味俱全，状态差时直接糊锅。只给一次机会（pass@1），运气成分太大。于是新规则诞生：每位大厨最多试做 k 次，只要有一次端出合格菜品，这道菜就算过关。这就是 pass@k 的核心直觉——用多次机会对抗随机抖动。

在具体评测中，模型对每个题目采样 n 个结果（通常 n = 200），其中 c 个通过测试。评委会随机从中抽取 k 个，计算“至少有一个通过”的概率。这里不能简单套用 $1-(1-\frac{c}{n})^k$，因为样本之间不独立且存在重复，直接套用会产生偏差。学术界采用如下无偏估计：

试做次数越多，运气成分越被冲淡，真实水平越浮出水面。但同时要注意：采样温度（temperature）调得越高，样本越多样，pass@k 往往越高，而 pass@1 可能反而下降——这正是评测中需要特别小心的“超参陷阱”。

4. 基础编程基准（MBPP）

固定菜谱考的是“照方抓药”，评委团还想看看大厨会不会“即兴发挥”。于是第二场考试改成了家常菜考核：不给出函数签名，只说“我想吃番茄炒蛋，用三个鸡蛋两个番茄”，让大厨自己写出完整做法。这就是 MBPP（Mostly Basic Python Problems）——Google 发布的入门级 Python 编程题集，包含 974 道题目。

MBPP 的题目形式是“自然语言需求描述 + 3 条测试断言”。比如描述“写一个函数，接收列表并返回其元素之和”，模型要生成完整程序，然后由三条断言自动验证。评测时通常采用 few-shot（少样本）设置：先给模型几个“需求→正确代码”的示例，再让它解决新题目。它与 HumanEval 的定位差异明显：HumanEval 偏函数级算法技巧，MBPP 偏自然语言到完整程序的基础能力。

MBPP 的通过率可以用一个带指示函数的均值公式表示：

家常菜最能暴露基本功的短板。那些背熟了固定菜谱的大厨，遇到“只说需求、不给签名”的题目就抓瞎——这正是 MBPP 存在的意义：考的不是套路，而是把自然语言翻译成代码的通用能力。

5. 多语言迁移（MultiPL-E）

大赛进行到一半，评委团提出了灵魂拷问：一个只会做中餐的大厨，能叫“国际名厨”吗？同理，一个只会在 Python 上得分很高的 Code LLM，是真的会编程，还是只背熟了 Python 语法？为了检验这一点，MultiPL-E 上线了——它像一个自动翻译菜谱的机器，把 HumanEval 和 MBPP 的题目翻译成 C++、Java、JavaScript、Go 等 18 种以上的语言。

MultiPL-E 的工作方式分两步：先把 Python 题目转换成一种中间表示，再用每种目标语言的模板渲染成对应语言的题目。同时，翻译后的题目也要配上等价的测试用例，确保“换了语言，考点不变”。这个过程看似简单，实则有陷阱：不同语言的表达力和标准库命名差异，可能让同一道题在 Python 里是送分题、在 C++ 里却变成地狱难度。因此评测时通常逐语言报告 pass@k，再汇总成一个跨语言平均分：

多语言考试让“伪全能”无处遁形。一个只在 Python 上刷高分的模型，一旦被翻译成静态类型语言就会暴露短板——这提醒我们：编程能力评测不能只看单一语言，跨语言对齐才是检验通用性的试金石。

6. 补全与生成

比赛规则进一步细化，把题目分成两类：一类是“续写对联”，大厨站在半成品菜前，只完成最后一步勾芡收汁；另一类是“命题作文”，从一句“来一桌年夜饭”开始，做出一整桌菜。前者对应代码补全，后者对应代码生成。

代码补全的任务设定是：给定文件上下文和光标位置，预测后续 token。它最常见的落地场景是 IDE 里的自动补全插件。评测补全时，除了测试通过率，还常用精确匹配率（EM）——生成的代码与参考代码逐字符一致才得分；或者用编辑距离衡量“有多接近”。代码生成则是给定自然语言指令（如 docstring 或 issue 描述），生成完整函数或程序，其评测以 pass@k 为主。

精确匹配率公式如下：

补全与生成看似同源，实则能力要求不同：补全考验“上下文理解”，生成考验“需求到实现的跳跃”。评委团若用同一把尺子量两种能力，就会像逼着做满汉全席的大厨去参加一分钟拼盘比赛一样，结论必然失真。

7. 评测实践

规则定得再好，也要保证所有大厨用同一口锅、同一把火。Code LLM 评测的实践环节，就是赛场公平的保障：统一环境、统一超参、统一采样方案。否则一次评测跑出来 0.62，下次跑出来 0.55，你分不清是模型退步了还是比赛流程飘了。

评测实践中的三个关键词是：工具链、防泄漏、可复现性。工具链方面，社区常用 bigcode-evaluation-harness、EvalPlus 等框架；EvalPlus 会为 HumanEval 每道题额外补充大量测试断言，防止模型“生成代码看着对但经不起推敲”。防泄漏方面，要尽可能使用人工手写题或动态新题，并过滤训练语料中的相似代码。可复现性方面，必须固定 temperature、采样数量 n、随机种子以及模型版本。

为了衡量多次评测的稳定性，分析师通常对同一配置运行 m 次并取均值：

没有统一赛规的冠军毫无意义。一次可信的 Code LLM 评测，必须像正规体育赛事一样写清楚“比赛用球、风速、计时规则”——任何超参的含糊，都可能让分数变成一场不可复现的幻觉。

8. 评测趋势

评委团逐渐意识到，固定考卷考久了，大厨们会开始“押题”。一个把 164 道菜练得滚瓜烂熟的 AI，遇到真实厨房里的新菜依然可能手忙脚乱。于是评测制度迎来了新趋势：离开固定题库，走向真实世界的厨房。

前沿方向主要有三条：一是动态题库，如 LiveCodeBench 持续从最新代码资源中抽取新题，让模型无法靠记忆得分；二是仓库级任务，不再只考单个函数，而是让模型理解整个项目结构、跨文件修改代码；三是真实缺陷修复，如 SWE-bench 直接使用 GitHub 上真实 issue 和代码仓库，让模型修复真实 bug。这些任务更接近程序员的实际工作场景。

衡量一次模型迭代是否有进步，最简单也是每个评测工程师都会写的公式是能力差：

考卷压中再多，也不如真材实料。Code LLM 评测正在从“背菜谱”进化到“进真厨房”，只有那些在动态题库、仓库级任务和真实缺陷修复中都能稳定发挥的模型，才能真正赢得评委团（和用户）的信任。

AI 应用场景

Python 演示

import randomfrom math import comb  def generate_samples(model_fn, problem, n, temperature):    """Sample n candidate solutions from the model."""    samples = []    for _ in range(n):        samples.append(model_fn(problem, temperature))    return samples  def is_correct(sample, test_cases):    """A sample is correct only if it passes all test cases."""    return all(t(sample) for t in test_cases)  def estimate_pass_at_k(n, c, k):    """Unbiased pass@k estimator from Chen et al."""    if n - c < k:        return 1.0    return 1.0 - comb(n - c, k) / comb(n, k)  def dummy_model(problem, temperature):    """A dummy model that returns the correct answer with 70% prob."""    return "correct" if random.random() < 0.7 else "wrong"  def main():    random.seed(42)    problems = [        {"tests": [lambda x: x == "correct"]}        for _ in range(100)    ]    total_p1 = 0.0    total_p10 = 0.0    for p in problems:        samples = generate_samples(dummy_model, p, 200, 0.8)        c = sum(1 for s in samples if is_correct(s, p["tests"]))        total_p1 += estimate_pass_at_k(200, c, 1)        total_p10 += estimate_pass_at_k(200, c, 10)    n = len(problems)    print(f"pass@1  = {total_p1 / n:.3f}")    print(f"pass@10 = {total_p10 / n:.3f}")  if __name__ == "__main__":    main()

1. def estimate_pass_at_k(n, c, k):定义无偏估计器，对应正文中 pass@k 的组合数公式。
2. if n - c < k:失败样本数不足 k 个时，随机抽出的 k 个必然至少有一个成功，直接返回 1.0。
3. return 1.0 - comb(n - c, k) / comb(n, k)核心公式：从 n 个样本随机抽 k 个，至少一个成功的概率。
4. samples = generate_samples(dummy_model, p, 200, 0.8)每个题目采样 200 个候选解，模拟模型多次试做过程。
5. c = sum(1 for s in samples if is_correct(s, p["tests"]))统计 200 个样本中通过全部测试的样本数。
6. print(f"pass@1 = {total_p1 / n:.3f}")输出最终的单次通过率，便于对比不同 k 值下的能力变化。

常见误区

面试题