MBPP

3 秒看懂

MBPP（Mostly Basic Python Problems）是 Google 在 2021 年发布的公开基准数据集，专门用于评估大语言模型在基础 Python 编程任务上的代码生成能力。它由约 1000 道独立编程题组成，每题配有自然语言描述和多个自动化测试用例，是衡量模型“写出可直接运行的正确代码”能力的关键标尺。

3 分钟产业解释

MBPP 本质是一套标准化考卷，而不是生产技术指标。其题目覆盖 Python 的基础语法、内置数据结构、标准库调用和简单算法，考察的是模型在明确、独立、低复杂性任务上的可靠度。

在产业层面，MBPP 的价值体现在五个维度：

1. 产品研发的基线标定
所有主流 AI 编程助手（如 GitHub Copilot、Cursor、通义灵码、Codeium 等）背后的模型都会在 MBPP 上持续刷分。分数越高，通常代表模型生成正确可用代码片段的概率越高，这直接支撑产品体验。

2. 技术能力的横向透明化
MBPP 完全公开，任何团队均可下载测试，避免了厂商的封闭自评。Hugging Face 的 Open LLM Leaderboard 和 Papers with Code 的代码生成榜单，令投资者和开发者都能一目了然地比较模型的水准。

3. 开源与闭源竞争的风向标
开源模型（如 CodeLlama、DeepSeek-Coder、StarCoder）与闭源模型（GPT-4、Claude、Gemini）在 MBPP 上的差距变化，反映了开源社区的追赶速度。这在创投圈常被用作判断“大厂护城河深浅”的量化参考。

4. 能力边界的映射器
MBPP 只测试独立函数的生成，不涉及多文件项目、系统设计、需求分析或代码维护。因此，它的高分标志着模型已成为一个“基本功扎实的编程新手”，能够完成明确的小任务，但不能推断其具备独立承担大型工程的能力。

5. 评测生态的基础组件
MBPP 的成功促使研究者将其范式扩展到更多语言（MultiPL-E）、更复杂领域（MBPP+、MBPP-Eval），形成了围绕“自然语言到可执行代码”的评估生态。它是该生态的基石之一。

技术原理

MBPP 的工作原理是一条受控的、可复现的代码生成与自动验证流水线。整个流程可以拆解为生成-采样-执行三阶段：

[输入] 自然语言任务描述 + 可选函数签名
  例："Write a python function to find the second largest number in a list."
        ↓
[生成] 大语言模型解码生成代码样本
(通过调整 temperature 等采样参数，可生成多个候选)
        ↓
[输出] 一个或多个 Python 函数体
        ↓
[验证] 将模型输出与预设的测试用例合并
  例：assert second_largest([1,2,3,4]) == 3
        ↓
[执行] 在隔离沙箱中运行完整脚本
        ↓
[判定] 全测试用例通过 → 正确；任一断言失败或语法错误 → 错误

核心评估指标：Pass@k
该指标衡量：对于每个任务，若让模型生成 k 个代码样本，至少有一个样本通过所有测试用例，则该任务被视作通过。数据集的整体得分是任务通过率。Pass@1 最贴近实际使用场景（一次生成即可用），Pass@10 和 Pass@100 则反映模型的“潜力上限”。指标计算采用无偏估计公式，避免因有限采样造成系统偏差。

测试用例设计原则
MBPP 中每题平均配有约 3 个测试用例，设计遵循三个原则：典型输入覆盖常规场景；边界值覆盖空列表、单元素、极大值等极端情况；负例覆盖可能出现的不合法输入，以检验代码的健壮性。这一机制保证通过的代码是“真正理解问题逻辑”而不仅是死记硬背输入输出对。

隔离执行环境
为防止生成代码包含恶意操作或破坏系统，所有验证均在沙箱（如 Docker 容器或云函数）中完成，并设有超时和资源限制。当前云服务商提供的 Function-as-a-Service 和 CI 容器便足以规模化运行此类评估。

关键参数

评估一个模型在 MBPP 上的表现，需要关注以下维度及其参数口径：

1. Pass@1 / Pass@10 / Pass@100
最核心的能力指标。通常以百分比表示，代表对应采样数下的任务通过率。需注明采样温度和去重策略。多数论文报告的 MBPP Pass@1 使用贪婪解码（temperature=0）或 temperature=0.2；若无特殊说明，默认为贪婪解码。取值越高说明基础代码生成能力越强。

2. 评估基准版本
MBPP 存在多个变体：原始 MBPP（约 974 题）、MBPP-sanitized（去除部分重复或歧义题，约 400+ 题）、MBPP+（增加更多测试用例）。报告分数时必须标明所用版本。部分研究仅使用 MBPP 的“prompt-only”格式（不含函数签名），这通常更难，分数会偏低。

3. 多语言扩展 Pass@1
通过 MultiPL-E 框架可将 MBPP 的 Python 任务转化为其他语言版本。该参数用于评估模型在跨语言基础编程上的泛化能力。格式一般为“MultiPL-E (Java) Pass@1”。

4. 平均代码长度
成功通过测试的生成代码的平均行数或字符数。较短且通过测试的解，通常意味着模型更能写出简洁、直接且少冗余的实现。这也间接反映模型的逻辑归纳能力。

5. 安全与有害性通过率
一些扩展工作会在测试集中混入潜在不安全的描述（如“读取密码文件”），检验模型是否会生成危险的代码。负向指标：不安全代码生成率，越低越好。

6. 数据污染检测指标
由于 MBPP 已公开多年，存在训练数据泄露风险。部分报告会辅以数据污染检测（如 n-gram 重叠率、字符串匹配度），用于辅助判断高分是否来自“背诵”。此为辅助参考指标。

在参考任何具体分数时，必须同步记录：模型名称、参数量、评估版本（如 MBPP-sanitized）、采样参数（temperature、top_p、采样次数）及报告来源（论文/排行榜链接），否则横向对比会失去意义。

技术路线

MBPP 所处的技术路线，可从时间演进和横向分工两个维度去理解。

从“代码搜索”到“基础生成”，再到“真实工程”
2021 年以前，主流代码数据集（如 CodeSearchNet）集中在代码搜索和摘要任务，模型并不直接生成可运行代码。2021 年，OpenAI 同时发布 Codex 模型和 HumanEval 基准，首次让“从自然语言直接生成代码并自动验证”成为大规模可评测的范式。同样在 2021 年，Google 发布 MBPP，用更基础和直白的题目拓宽了测试覆盖面。两者共同构成了基础代码生成的双支柱。

2022 年到 2023 年，围绕 MBPP 的扩展主要朝两个方向：一是多语言化（MultiPL-E），将同一评估框架复制到 Java、JavaScript、C++ 等；二是数据质量和防作弊（MBPP-sanitized、MBPP+），应对越来越多的模型将被测试数据纳入训练的问题。

2023 年起，当头部模型在 MBPP 上的 Pass@1 突破 80% 甚至更高，“基础题”的区分度下降。产业界和研究前沿迅速转向更难的基准，如 DS-1000（数据科学库调用）、APPS（竞赛题），尤其是 SWE-bench（解决真实 GitHub Issue，要求定位并修改多文件）。MBPP 的角色从“最高竞技场”转变为“入门资格赛”：不再用于决出冠军，而是用于快速筛掉不合格的模型。

横向技术路线对比
以下是 MBPP 与其他重要代码生成基准的定位与分工对比：

这种分层路线意味着：未来任何一个声称擅长编程的模型，必须先通过 MBPP 验证基本功，再挑战更复杂的工程基准。行业评价体系已由此形成清晰的阶梯式结构。

上游

MBPP 所处产业链的上游，主要包括基准的创建者和确保评估得以运转的底层资源供给方。

基准建设方

• Google Research：MBPP 的原始创建和维护者。其研究团队负责题目的收集、清洗、测试用例编写和公开分发。Google 同时通过 Google DeepMind 在模型中应用该基准，形成“定义规则—参与竞赛”的双重角色。
• 学术机构与开源社区：MBPP-sanitized、MultiPL-E 等扩展版本分别由国内外大学和独立研究者贡献。社区通过 GitHub 协作持续完善基准质量，Hugging Face 等平台则提供数据集托管和排行榜服务。

算力与沙箱服务商
评估运行需要安全、可扩展的代码执行环境，主要依赖：

• 云计算厂商（AWS、Google Cloud、Microsoft Azure）的容器服务或无服务器函数，提供隔离沙箱。
• 专用 AI 基础设施平台（如 Replicate、Together AI）也开始提供模型评估 API，其中常内置 MBPP 等基准的自动化测试流程。

数据来源
MBPP 的题目主要源于早期 Python 教育习题集和编程社区（如 Stack Overflow 上的简化问题），经人工筛选和改编而成。为降低数据污染，当前一些新版本会引入大规模人工新编题目，这部分数据制作成本较高，属于上游中的“数据生产”环节。

下游

MBPP 的下游是使用该基准结果来指导产品、投资或研究的各类主体。

AI 编程工具厂商
GitHub Copilot、Cursor、Replit、Windsurf、国内的通义灵码、CodeBuddy、豆包MarsCode 等，其底层模型在发布前均在 MBPP 上测试。成绩直接影响产品更新日志和宣传材料中的能力描述，进而影响开发者的采用意愿。部分企业版客户也会内部复现 MBPP 测试，作为采买决策的依据。

模型开发商
OpenAI、Anthropic、Google、Meta、百川智能、智谱等，均将 MBPP 作为模型迭代的必经评估项。开源模型社区（如 Hugging Face 上的 BigCode、Nous Research 等）通过 MBPP 放榜来建立技术声誉，吸引算力赞助和贡献者。

投资与研究机构
一级市场投资者在评估 AI 编程初创企业时，会要求创始人提供在 MBPP、HumanEval、SWE-bench 等基准上的对比数据，作为技术尽调的一部分。行业研究机构（如 Gartner、红杉、高盛）在生成式 AI 研究报告中也频繁引用代码生成基准作为能力成熟度的依据。

企业研发团队
大型企业内部的平台工程团队，在采购 AI 编码辅助工具前，往往会用 MBPP 等公开基准作为初步筛选，然后再结合内部私有代码仓库进行二次评估。MBPP 因此充当了“第一道过滤”，降低企业的试用成本。

受益公司

MBPP 成绩的提升与产业受益之间不是直接的“分数→利润”传导，但其作用链条清晰，主要惠及以下几类公司（从能力受益逻辑梳理，不构成任何投资建议，未提供任何买卖评级）。

1. 模型能力处于前沿的综合科技巨头
长期在 MBPP 和 HumanEval 等基础基准上保持领先的公司，能够将优势转化为编程助手产品的市场竞争力。受益路径是：高基准分数→模型能力口碑→开发者获取→生态绑定→收入增长。微软（通过 GitHub Copilot 的模型编排）、Google（内部应用与云 API）、Amazon（CodeWhisperer/Q Developer）均属此类。需要强调的是，某公司 2023 年财报提及“GitHub Copilot 活跃订阅者超百万”（口径：微软 FY24Q1 电话会），这属于可查证的客观描述。

2. 开源模型阵营的领先玩家
以 Meta 的 CodeLlama、DeepSeek 的 DeepSeek-Coder、BigCode 的 StarCoder 为代表，它们在 MBPP 上持续缩小与闭源模型的差距。受益逻辑是：通过高分数赢得社区影响力，带动其云平台或算力生态的采用。例如 Meta 的开源模型虽不直接收费，但可作为吸引开发者使用其 PyTorch 生态和云合作伙伴服务的支点。

3. 评估与安全基础设施公司
基准运作需依托沙箱执行和评分管线。提供模型评估服务的平台（如 Vellum、Braintrust）、专注于 AI 安全的公司（如 Anthropic 自身也提供安全评估），以及提供计分排行榜的 Hugging Face 等，都会因基准的广泛使用而获得流量和客户。

4. 垂直领域工具初创
许多初创公司会在内部模型迭代中宣称“MBPP 达到 xx%”，以作为其技术差异化的佐证，间接支撑融资和商业拓展。例如 Magic、Poolside 等专注于代码 AI 的初创，曾在博客或论文中披露 MBPP 成绩。

除上述逻辑性梳理外，暂无公开披露的直接测算证明某家公司因 MBPP 分数提升而获得明确市场份额增长，所有受益传导均需结合产品化能力综合判断。

市场规模

MBPP 本身不产生直接市场收入，它作为公共基准属于学术基础设施。与其相关的市场规模，指代的是 AI 代码生成/编程辅助这一应用赛道的规模。

根据公开资料，不同机构的测算口径如下：

• GitHub 母公司微软在 2023 年 10 月电话会中披露，GitHub Copilot 订阅者已超 100 万，付费企业客户超 3.7 万个（来源：微软 FY24Q1 财报电话会，2023 年 10 月 24 日）。这为市场体量提供了标杆案例。
• Gartner 在 2023 年 10 月发布新闻稿预测，“到 2028 年，75% 的软件工程师将使用 AI 编码助手”（来源：Gartner 新闻稿，2023 年 10 月 11 日）。此为渗透率预测，并非收入预测。
• 公开资料未见全球 AI 编码助手市场在 2023 年或 2024 年的统一营收规模统计。多家第三方研究机构（如 MarketsandMarkets、Grand View Research）各自报告了口径不一的预估值，其指标定义差异较大，在此不具引以避免混淆。
• 国内方面，IDC 中国 2024 年对生成式 AI 在软件开发领域的市场影响发布了预测，指出“2024 年中国有超过 30% 的开发组织已在测试或采用 AI 编程辅助工具”（来源：IDC FutureScape, 2024 年初）。同样未公布精确的市场规模金额。

综上，可以确认的是：AI 编码辅助渗透率快速爬升、头部产品已形成规模化订阅收入，但缺乏权威、统一口径的市场总额数据用以衡量 MBPP 的直接经济影响。

玩家对比

下表基于公开的学术论文、官方技术报告和 Papers with Code 排行榜的综合信息，对比了各代表模型在 MBPP 上的大致表现（注：具体数字会因版本、采样策略和评估环境而异，下表仅供定性对比，不构成精确排名）。数据引用均自主流来源，时间窗口截至 2024 年 7 月。

表中的分数区间多为论文或排行榜所公布的最佳值，实际使用中可能因提示词、temperature 及具体题集版本而波动。玩家对比不能仅看 Pass@1 一个维度，还需要结合产品集成深度、支持的语言数、私有代码库适配能力和安全合规能力综合判断。

风险

1. 基准饱和风险
随着越来越多模型在 MBPP 上超过 90% 甚至逼近满分，该基准的区分度急剧下降。此时，高分不再代表巨大技术优势，而只是“基础门槛”。投资者若仅盯着 MBPP 分数，会误判模型真实能力的差距。

2. 数据污染与评分失真
由于 MBPP 题目和测试用例已在互联网广泛传播，大多数大模型的预训练语料中可能已经包含其内容。这导致部分高分可能来自“背诵”，而非真正的编程能力。现有研究通过引入 MBPP-sanitized、测试用例变异等方法缓解，但无法根除。数据污染程度若未被披露，分数对比便可能失真。

3. 评测生态的“应试化”
当模型厂商以分数为优化目标时，会出现专门针对 MBPP 的调整（如强化类似题目的微调），造成在基准上高分但在真实开发任务中表现一般。这种“应试效应”降低了基准反映实际能力的可信度。

4. 能力≠产品价值风险
MBPP 测量的是生成独立函数的能力，而开发者日常工作中真正耗时的是需求理解、系统设计、代码调试和跨模块协同。基础代码生成水平高，未必能转化为显著的开发效率提升。过度依赖分数可能导致对产品价值的误判。

5. 安全与合规的覆盖不足
MBPP 并不系统评估代码的安全性、许可证合规性以及生成代码的知识产权风险。若企业在选型时仅参考此基准，可能引入隐性的安全风险和合规隐患。

6. 基准维护滞后
基准的更新速度远落后于模型能力的增长速度。MBPP 的更新频率依赖社区贡献，如果持续滞后，其反映能力变化的能力将进一步降低，需关注替代基准的进展。

误读纠偏

误读 1：“MBPP 高分 = 可以替代程序员”
纠偏：这是对 MBPP 最普遍的误读。MBPP 测试的是独立、简短、明确的小任务，就像考驾照的科目二，它证明车辆能完成倒库、侧方停车，但不证明能安全行驶在复杂公路上。真实编程包含系统设计、跨服务交互、代码可维护性、团队协作等复杂认知活动，这些远不在 MBPP 的考察范围内。模型是“编程副驾驶”，可以提升编写特定片段的效率，不是能独立承担工程的“无人驾驶程序员”。

误读 2：“MBPP 是唯一或最重要的代码能力指标”
纠偏：MBPP 仅覆盖代码能力的“基础语法与逻辑”这一维度。无法评估：对特定库和框架的掌握（需 DS-1000）；理解并修改大型代码库的能力（需 SWE-bench）；代码的安全性、可读性和可维护性。负责任的能力画像一定是“多基准交叉验证”，没有任何一个基准可以当单一标尺。

误读 3：“分数高的模型肯定更好用”
纠偏：分数高低与用户体验好坏没有线性关系。一个在 MBPP 上稍低的模型，若在 IDE 补全延迟、上下文理解、拒绝不安全请求方面做得更好，实际使用价值可能更高。产品体验是多目标优化的结果，基准分数只是其中一个输入。

误读 4：“MBPP 只适合评估 Python，不能用于其他语言”
纠偏：MultiPL-E 项目已将 MBPP 的评估范式扩展至 19 种以上的编程语言，多语言版本分数同样具有对比意义。原始 MBPP 的 Python 属性并不限制其方法论在多语言场景中的复用。

最新事件

• 2024 年 6 月：DeepSeek 发布 DeepSeek-Coder-V2，宣称在 MBPP-sanitized 上 Pass@1 达到 90.2%，在 MBPP+ (399题) 上达到 76.2%，直接对标 GPT-4-Turbo。同时公开评测细节和采样参数（来源：DeepSeek 官方博客）。
• 2024 年 5 月：Mistral 发布编码模型 Codestral，在 MBPP 上报告 Pass@1 超过 80%，并开源权重（来源：Mistral 博客）。这一成绩再次缩小开源与闭源的差距。
• 2024 年 4 月：BigCode 社区发布 StarCoder2 系列，提供多种参数量版本，在 MBPP 上稳步提升，且公布了更严谨的去污染评估流程（来源：BigCode 技术报告）。
• 2024 年 3 月：业界围绕 MBPP 的数据污染问题展开了新讨论，有学者提出了更强的去污染检测方法（n-gram 重叠率+语义哈希），促使排行榜新增“数据污染风险”标注（来源：相关学术预印本及 Hugging Face 社区讨论）。
• 2023 年底至 2024 年初：SWE-bench 成为 AI 编程领域最热的评估指标，客观上降低了 MBPP“独霸”的热度，使行业形成“先过 MBPP 基础关，再测 SWE-bench 工程关”的双层评估共识。

跟踪指标

若需持续跟踪 MBPP 及其产业影响，建议关注以下维度的变化：

1. Pass@1 分数趋势：在 Papers with Code 的代码生成板块，观察顶级闭源与开源模型分数的收敛速度。重点关注 MBPP-sanitized 版本以避免污染干扰。
2. 新发布模型的 MBPP 测试条件：必须关注评估时所使用的题集版本、采样温度和提示格式。多数诚信报告会详细说明，若缺失这些信息，其分数参考价值有限。
3. MultiPL-E 分数：当模型宣称多语言能力时，查询其在 MBPP 扩展的多语言版本上的表现，可验证其是否真正具备跨语言基础编程泛化能力。
4. 数据污染声明：有责任感的模型发布方会披露数据污染检测结果。跟踪该声明的有无和具体数值，是判断分数真实性的关键。
5. 社区对比讨论：Hugging Face 论坛、Reddit r/MachineLearning 及相关综述论文，会定期讨论基准作弊和失效模式，这些信息比单纯数字更重要。
6. 权重向 SWE-bench 的迁移：当行业媒体和招聘要求更多提及 SWE-bench 而非 MBPP 时，意味着“基础能力”泛化已成为前提，评估前沿已转移。这是一种领先指标。
7. 开源模型与闭源模型差距：以 Pass@1 为轴，统计开源最佳成绩与闭源最佳成绩之差的缩小速度，这反映了技术普惠的节奏。

信源

• Austin, J. et al. (2021). Program Synthesis with Large Language Models. arXiv:2108.07732.（MBPP 提出论文）
• Chen, M. et al. (2021). Evaluating Large Language Models Trained on Code. arXiv:2107.03374.（HumanEval 提出论文）
• MultiPL-E: A Scalable and Polyglot Approach to Benchmarking Neural Code Generation. Cassano, F. et al. (2023). IEEE/ACM TASLP.
• MBPP 原始数据集及 Sanitized 版本：Hugging Face Datasets 搜索 “mbpp”。
• Papers with Code — Code Generation Leaderboard：https://paperswithcode.com/task/code-generation
• Gartner 新闻稿 (2023.10.11)：“Gartner Says 75% of Enterprise Software Engineers Will Use AI Code Assistants by 2028”。
• 微软 FY24Q1 财报电话会记录 (2023.10.24)：GitHub Copilot 用户数据披露。
• DeepSeek-Coder-V2 官方博客 (2024.6)：“DeepSeek-Coder-V2: Breaking the Barrier of Closed-Source Models in Code Intelligence”。
• Mistral 官方博客 (2024.5)：“Codestral: Hello, World!”。
• BigCode Project 技术报告 (2024)：“StarCoder 2 and The Stack v2: The Next Generation”。
• SWE-bench: Can Language Models Resolve Real-World GitHub Issues? Jimenez, C. E. et al. (2024). ICLR.
• 分析参考：各模型官方技术报告（OpenAI、Anthropic、Google、Meta）中涉及 MBPP 的章节。