MBPP基准：Python编程能力的入门级评测

可视化演示

展示MBPP基准的pass@k指标计算过程（k次采样至少一次通过的概率），以及MBPP与HumanEval基准的多维度对比。

基准概览：一张“入门考核试卷”长什么样

餐厅后厨要招人，老板拿出一套统一的“入门考核试卷”——不考满汉全席，而是考西红柿炒蛋、酸辣土豆丝这类家常菜。为什么要统一？因为如果每个厨师做不同的菜，分数就没法比。MBPP 基准就是 AI 界的这套“入门考核试卷”：它给所有大模型出同一批基础 Python 题，让分数变得可比。

MBPP 的全称是 “Mostly Basic Python Problems“，意为”大多是基础 Python 问题“。它由 Google Research 在 2021 年提出，最初出现在 ”Program Synthesis with Large Language Models” 这篇论文中。研究者在探索大模型能否自动写代码时，意识到需要一套标准化的入门级考题，于是从网上公开的代码片段和教程中整理出 974 道基础编程题，并请人类专家逐一验证，确保每道题都可解、表述没有歧义。

这 974 道题被划分为训练、验证和测试三个子集。每道题都是一个“函数级小任务”：包含一句自然语言描述、一个函数签名、一个参考答案，以及约 3 个自动生成的测试用例。评测时，模型根据描述和签名写出函数体，评测器把函数体与测试用例拼在一起运行，测试全部通过才算做对。

所以，当你看到某个模型在 MBPP 上拿到分数，其实是在看它“西红柿炒蛋考核”的成绩单。这张成绩单虽然不能说明它会做满汉全席，但至少能告诉你：它有没有基本的厨房基本功。

题目设计：每道菜都写着“新手友好”

翻开这份“家常菜考核菜谱”，你会发现菜色都很基础：煮个蛋、切个丝、抓把盐。MBPP 的题目设计也是这样“新手友好”——它刻意避开了复杂的算法与数据结构，让每一道题都能在几十秒内读懂。

MBPP 的绝大多数题目属于“函数级入门题”：要求模型根据自然语言描述，补全一个函数体。常见考点包括：基本的算术运算、字符串拼接与替换、列表的增删查改、简单的条件判断与循环。这些能力对应程序员日常编码中最频繁的“肌肉记忆”，就像厨师的基本刀工和火候。

以一道典型题目为例：“编写一个函数 add，输入两个整数，返回它们的和。” 模型需要输出的代码是 def add(a, b): return a + b。配套的测试用例会断言 add(1,2)==3、add(0,0)==0、add(-1,1)==0。题目设计的关键是“每个任务都有明确的输入输出、有限的状态空间、可自动验证”——这正是它适合做大模型评测的原因。

正是这样一道道“看一眼就知道怎么做”的题，让 MBPP 成了厨房里的“基本功摸底”：不考花活，只考手上功夫。

HumanEval 对比：家常菜与创意菜的分工

餐厅考核有两种：一种是家常菜考核，看基本功；另一种是创意料理考核，看算法和构思。在 AI 编程评测里，MBPP 是前者，HumanEval 就是后者。

HumanEval 由 OpenAI 在 2021 年提出，包含 164 道手写的编程题。这些题目更偏算法思维：链表反转、二叉树遍历、动态规划、递归都能看到。而 MBPP 的 974 道题则聚焦基础语法和常见标准库。如果把 HumanEval 比作“法餐考核”，MBPP 就是“家常菜考核”——两者难度明显不同。

具体差异体现在三个维度：题量上，974 对 164，MBPP 几乎是 HumanEval 的 6 倍，统计上更稳定；难度上，MBPP 大多是 10 行以内的简单函数，HumanEval 则需要多步推理，模型在 MBPP 上的 pass@1 普遍高出 15~30 个百分点；考核侧重上，MBPP 看重“能否调用正确的 API”，HumanEval 看重“能否构造正确的算法”。因此业界常把它们搭配使用：先用 MBPP 筛基层次，再用 HumanEval 拉开差距。

所以别用西红柿炒蛋的分数去评判一个厨师会不会做惠灵顿牛排——MBPP 与 HumanEval，一个是基础功底，一个是进阶实力，各有各的考法。

pass@k 指标：给厨师多次出菜的机会

考核时如果只让厨师炒一次蛋，不小心手抖糊了，能说明他不会炒吗？更公平的办法是让他炒 k 次，只要有一次成功就算过关。pass@k 就是这么一回事。

pass@k 是代码生成评测最核心的指标，指“模型生成 k 个候选答案，其中至少一个通过所有测试用例的概率”。常见口径有 pass@1 和 pass@100。k 越大，对模型越宽容，体现的是模型在“多次试错”下的上限；pass@1 则贴近真实使用中“只生成一次”的体验。

直接枚举所有 k 子集在计算上很昂贵，论文给出一个高效的无偏估计器：让模型对每道题生成 n 个候选，假设其中有 c 个通过测试，则 pass@k 的估计公式如下：

所以说，pass@k 是“给你 k 次机会”的宽容考核，而 pass@1 是“只给一次机会”的实战考核。两个人汇报成绩时，最好把两个数字都亮出来，才不会被漂亮的 k 值迷惑。

评测规范：评委的标准化评分表

有了考核试卷，还得有严格的评分流程：评委不能尝一口就拍板，而是对着标准答案逐项打分。MBPP 的评测规范就扮演了这个角色。

MBPP 评测是“全自动”的：模型输出代码后，评测系统把它和题目配套的测试用例放到同一段代码中运行，只有全部断言通过，这道题才算得分。整个过程不依赖人工打分，避免了主观偏差——就像评委不看菜品的摆盘，只按固定标准尝味道。

评测系统有几个硬性要求：第一，运行环境要与外界隔离（沙箱），避免候选代码访问网络或文件系统；第二，每道题有超时限制（通常 3~5 秒），防止死循环拖垮整个评测；第三，要用统一的解释器版本和依赖环境，保证不同模型得分可比；最后，结果按题目汇总，统计通过题数占总题数的比例，得到最终的 pass 率。

有了这套标准化评分表，哪怕是不同团队来评测，只要按规矩走，分数都可复现、可比较——就像所有厨师用同一把尺子量刀工。

数据污染：偷看过菜谱的“作弊厨师”

如果考核前一天，某位厨师偷偷拿到了菜谱和答案，第二天他当然能轻松过关——但这份高分经不起推敲。MBPP 评测中最常见的坑，就是这种“偷看答案”的数据污染。

数据污染指的是：大模型的预训练语料中混入了 MBPP 的测试题目（比如网上公开的 GitHub 仓库、评测集原文），导致模型在训练阶段就“见过”考题。被污染模型的 MBPP 分数会严重虚高，却并不能反映真实的代码生成能力——就像背过答案的学生，换一套新题就露馅。

检测污染有多种手段：最常用的是 n-gram 重叠检测——把 MBPP 的题目与训练语料切分成连续片段，统计有多少题目在训练语料中出现过；还可以用嵌入向量的余弦相似度，找出“语义相似但字面不同”的变体。防护措施包括：定期发布新题目、对测试集做严格去重、监控模型在时间轴上的分数是否异常跳升。

所以，看到一份高得离谱的 MBPP 榜单时，先别急着赞叹，多问一句：“这位厨师是不是提前看过菜谱？”——防污染，才是评测可信的底线。

应用定位：用入门考核做选型地图

考完西红柿炒蛋，老板心里有了底：这道菜都不及格的厨师，肯定不能要；但拿了满分的人，也未必就能掌勺婚宴大席。MBPP 在模型选型中的定位，正是这样一道“过滤菜”。

在代码大模型选型中，MBPP 适合做第一道快速初筛：候选模型众多（Code Llama、StarCoder、DeepSeek-Coder、GPT-4 等），全部用复杂基准评测成本很高，先跑一遍 MBPP，把基础能力不达标的候选直接排除，再用更难基准对通过者做精测。

同时要清醒认识 MBPP 的局限：第一，入门题多，模型分数容易饱和（一流模型的 pass@1 已达 85% 以上），区分度下降；第二，存在数据污染风险；第三，它不测代码安全性、可维护性等生产关切。因此业界通常采用“组合打榜”：MBPP + HumanEval + 更难的专项基准（如 SWE-bench、LiveCodeBench），综合判断模型能力。

MBPP 就像招聘流程里的第一轮笔试：题目不难，但能高效筛出“连基本功都不过关”的简历。过了这一关，后面还有更难的面试轮次等着——这才是它的正确打开方式。

AI 应用场景

Python 演示

# MBPP风格Python函数评测器：运行代码 + 测试用例 + pass@k 估计import randomfrom math import comb # 模拟MBPP的迷你数据集：每道题只有函数签名与若干断言MBPP_LIKE = [    {        "signature": "def add(a, b):",        "tests": ["assert add(1, 2) == 3", "assert add(0, 0) == 0"],    },    {        "signature": "def is_even(n):",        "tests": ["assert is_even(4) == True", "assert is_even(3) == False"],    },    {        "signature": "def max_list(nums):",        "tests": ["assert max_list([1, 5, 3]) == 5", "assert max_list([]) == None"],    },]  def safe_run(code, tests):    """在受限命名空间中执行候选代码与测试，返回是否全部通过"""    namespace = {}    try:        exec(code, namespace)        for test in tests:            exec(test, namespace)        return True    except Exception:        return False  def estimate_pass_at_k(n, c, k):    """pass@k 无偏估计：1 - C(n-c, k) / C(n, k)"""    if n - c < k:        return 1.0    return 1.0 - comb(n - c, k) / comb(n, k)  def dummy_model(signature):    """扮演一个'小模型'：根据函数签名猜实现，偶尔偷懒写错"""    if random.random() < 0.2:        return "def _fake():\n    pass"    if "add" in signature:        return "def add(a, b):\n    return a + b"    if "is_even" in signature:        return "def is_even(n):\n    return n % 2 == 0"    if "max_list" in signature:        return "def max_list(nums):\n    return max(nums) if nums else None"    return "# 无法实现的空代码"  def evaluate(model, dataset, n_samples=8, k=1):    """每道题生成n_samples个候选，返回平均pass@k"""    total_pass = 0.0    for task in dataset:        codes = [model(task["signature"]) for _ in range(n_samples)]        c = sum(1 for code in codes if safe_run(code, task["tests"]))        total_pass += estimate_pass_at_k(n_samples, c, k)    return total_pass / len(dataset)  if __name__ == "__main__":    print("单题示例：生成8个候选，通过5个 => pass@1 =",          round(estimate_pass_at_k(8, 5, 1), 4))    print("模拟MBPP平均 pass@1 =",          round(evaluate(dummy_model, MBPP_LIKE), 3))

1. exec(code, namespace)在一张全新的“白纸”命名空间里执行候选代码，避免污染评测环境
2. for test in tests: exec(test, namespace)逐个追加运行测试断言，任一断言失败都会抛异常
3. if n - c < k: return 1.0失败候选数不足 k 时，抽 k 个必然能抽到通过样本，直接返回 1
4. 1.0 - comb(n - c, k) / comb(n, k)用组合数计算“抽 k 个全失败”的概率，再取补集
5. codes = [model(task["signature"]) for _ in range(n_samples)]让模型对同一道题生成 n 个候选答案
6. c = sum(1 for code in codes if safe_run(code, task["tests"]))统计这些候选中通过测试的个数
7. total_pass += estimate_pass_at_k(n_samples, c, k)把每道题的 pass@k 累加，最后除以题数得平均分

常见误区

面试题