美团开源OIBench与CoreCodeBench：揭示大模型编程能力的真实水平

当前，大语言模型（LLMs）在编程领域的能力宣称引人瞩目——DeepMind 的 AlphaCode 曾对标人类竞技编程选手，OpenAI 顶尖模型屡被报道通过谷歌面试、挑战 LeetCode 表现不俗。然而，当深入审视这些模型在真实、复杂场景下的表现时，现有评估体系的深层局限性便暴露无遗，形成了显著的“宣传与现实的认知鸿沟”。

一方面，在算法能力评估上，尽管模型在传统基准（如 HumanEval、MBPP）上通过率高达90%，但移植到更高难度的信息学奥赛或 Codeforces Div.2 C 级题目时，顶尖模型的通过率骤降至个位数或不足15%，远逊于人类选手（如ACM校队成员平均70%），动态规划等题型错误率甚至超80%。传统评测集已“饱和”且区分度不足，新引入的高难度题目又面临数据“泄漏”风险和人机对比（Elo）的复现性差、效率指标粗略等问题。

另一方面，转向真实工程能力评估，问题同样严峻。现有工程基准（如 FullStackBench、SWEBench）虽在多样性和语言覆盖上有进展，但其任务类型主要集中于单段落代码生成，难以覆盖真实开发中跨文件协作、代码修复（BugFix）、测试驱动开发、多函数协同等核心环节。数据构建方法也受限于随机挖空（易忽略核心逻辑）或依赖稀缺的 GitHub PR 记录（需大量人工清洗标注），导致评测“偏科”，无法科学、全面地评估模型在复杂工程中的准确性、健壮性和适用性。

为了系统性地解决这两大评估困境——更真实地衡量顶尖模型的算法推理能力与更全面地评估其工程级代码能力——Meituan-M17 团队联合上海交大等机构，分别推出了 OIBench（聚焦高区分度算法题评测）与 CoreCodeBench（聚焦多场景工程级代码基准）两大数据集，并托管于 AGI-Eval 评测社区。下文将详细介绍它们的构建理念、评测方法及对主流大模型能力的深度剖析。

背景：评测集局限性的深层分析

尽管 GPT-4o 模型被冠以 “竞赛级” 头衔，甚至有声音称其算法水平接近 ACM 区域赛金牌选手，但实际在面对未经大量公开数据训练的、更高难度的信息学奥赛级别问题时，其通过率却往往低至个位数，与 985 级别高校 ACM 校队成员的平均通过率存在显著差距。

当部分评测宣称 Claude 3.5 Sonnet 可替代中级开发人员时，它在动态规划等高难度题型中错误率却高达 80% 以上，且无法独立完成需数学建模的复杂竞赛题。

诸如文心一言、通义千问等模型在 MBPP 基础题库中通过率可达 90% 以上，但移植至 Codeforces Div.2 C 级题目时，通过率却不足 15%，远低于人类选手平均 70% 的水平。

这些鲜明的对比，共同指向一个核心问题：当前对 LLM 编程能力的评估，存在明显的 “宣传与现实的认知鸿沟”。这种差异不仅源于模型能力边界的复杂性，也暴露出现有评估体系的诸多局限性。具体表现为：

• 评测集 “饱和” 与区分度不足：传统评测集（如 HumanEval、MBPP）由于模型能力的快速提升，通过率普遍超过 90%，已无法有效区分最先进模型的细微优劣。
• 数据 “泄漏” 风险： 尽管一些新评测集（如 Codeforces、USACO、LeetCode）引入了高难度题目，但由于大模型预训练数据包含大量互联网公开内容，这些题目可能已被模型 “见过”，导致评测结果虚高，无法真实反映其推理能力。
• 人机对比的局限性：现有基于 Elo 评分体系的模型与真人选手对比方法，存在周期长、选手水平波动大、复现性差等问题，难以提供精确且可靠的评估。

效率指标的粗略性： 部分评测虽引入运行时间、内存等效率指标，但通常仅为粗略的平均分，无法细致反映模型在不同类型题目上的性能差异。

为了解决上述这些评估困境、评测出全球顶尖模型真实的编程能力， Meituan-M17 团队推出了更真实、更具区分度的评估基准 OIBench 数据集，并托管于 AGI-Eval 评测社区，并在 Huggingface 和 GitHub 上开源。基于此数据集，我们对全球 18 个主流大模型的算法编程能力进行了系统评测并量化得分，详细评分榜单如下所示，可以看到全球顶尖大模型距离以往所宣称的编程能力还存在很大差距，哪怕是最高分的 o4-mini-high 也仅仅只有 36.35 分，距离人类竞赛选手的水平还相差甚远，甚至很多模型只有个位数的得分。

OIBench 的评测榜单未来将由 AGI-Eval 评测社区长期维护更新，欢迎持续关注。榜单地址如下：

• 网页端地址：https://agi-eval.cn/evaluation/detail?id=60
• 微信公众号文章：AGI-Eval大模型评测
• 论文地址：https://arxiv.org/abs/2506.10481
• Github地址：https://github.com/AGI-Eval-Official/OIBench

本文数据均引用自 OIBench v1.0 论文（arxiv:2506.10481v3），发布日期 2025 年 6 月 13 日。

接下来为大家详细介绍 OIBench 数据集是如何构建以及如何对大模型进行评测的。

1. OIBench 的构建与创新

OIBench 是一个高质量、私有且极具挑战性的信息学奥赛级别算法题库，旨在提供一个更真实、更具区分度的评估基准。该数据集的算法题主要来源于中国 ACM-ICPC 队伍和信息学奥赛的高校教练团队精心编纂，他们拥有丰富的高难度算法题设计经验和独到见解。

为了确保 OIBench 题目的高质量和高挑战性，我们制定了三条严格的准入标准，OIBench 具备以下关键特性：

• 原创性与私有性：OIBench 包含 250 道候选题目，经难度验证后保留 212 道高难度、防泄漏的信息学奥赛题目（IOI Level）。所有题目在发布前都经过严格检索，确保未在任何公开平台出现，最大程度避免数据污染风险。
• 难度分级与把控：每道题目都参照信息学竞赛和 Codeforces 难度评级进行标注。同时，为避免主观偏差，我们引入了自动化验证机制 —— 只有当 GPT-4o、Qwen2.5-Coder-32B、Doubao-32k-pro、Llama3.1-405B 这几个标杆大模型中 “最多只有一个模型能解出” 时，该题才会被收录，从而确保了题目的 “硬核” 难度。
• 高标准测试用例与标准解答：每道题都配备覆盖大数据量、边界情况等多样的测试用例，力求暴露代码在时间和空间上的潜在瓶颈。同时，每道题都必须配备经过所有测试用例严格验证的 C++ 标准解答，以确保题目本身的准确性及评测的公正性。
• 中英文双语支持： 数据集提供中英文双语版本，方便全球大模型从业者使用。

我们还在论文中展示了 OIBench 与其他主流评测集的对比（见下表），可以看到 OIBench 在题目难度和测试用例规模上都相对更高。

OIBench 在题目难度和测试用例规模上显著领先于其他主流评测集。例如，在其他榜单上表现较好的 GPT-4o 模型在 OIBench 上仅能答对 2.6% 的题目，同时 OIBench 的测试用例数量大幅超过了其他算法竞赛基准，对标真实的竞赛环境。

强抗数据污染能力：在评测集设计中，“同源污染” 是一个重要挑战。由于大模型的预训练和微调数据往往会爬取大量互联网内容，容易出现模型在训练阶段就见过类似题目的情况，从而导致评测分数虚高，无法真实反映模型实际能力。虽然 OIBench 在数据构造时极力避免使用互联网可公开检索的题目，但一些相近的题目仍可能在大模型的预训练或微调阶段带来数据污染。为此，我们专门设计了实验来验证 OIBench 的抗污染能力：

• 具体做法：我们从 OIBench 中抽取部分题目，模拟它们在模型训练数据中 “泄漏” 的场景，并与常规训练数据混合，对比模型在 OIBench 上的表现提升。
• 实验证明：即使模拟少量题目 “泄漏” 到模型的训练数据中，OIBench 的得分提升也极为有限，风险分数几乎为零，表明其对数据污染具有很强的鲁棒性。

2. OIBench 评测结果与发现

参评模型与评测方式

OIBench 对 18 个主流大模型（包括 14 个指令微调模型和 4 个基础模型）进行了 zero-shot 评测，涵盖 C++、Python、Java、JavaScript 四种语言。

主榜单结果

• 推理模型表现突出：推理类模型（如 o4-mini-high）在 OIBench 上的平均得分高达 21.4%，远高于普通指令微调模型（约 3.6%）。这表明 OIBench 能有效区分模型的推理和链式思考能力，且 o4-mini-high 在所有语言和任务上表现最优。
• 闭源模型优势明显：闭源模型平均得分 14.5%，显著高于开源模型（6.3%），这主要得益于闭源模型在算力和数据质量上的优势。
• 基础模型决定上限：指令微调模型在 OIBench 上的表现高度依赖其基础模型的能力，说明基础模型的预训练质量是决定代码能力的关键。
• DeepSeek-V3-0324 的亮点：作为非推理模型，DeepSeek-V3-0324 表现突出，得益于其采用了 DeepSeek-R1 的链式推理蒸馏方案，推理能力大幅提升。
• 语言偏好与中英文差异： 模型在 JavaScript 和 Python 上的表现平均比 C++ 和 Java 低 10% 以上，可能与训练数据分布有关；中英文题目表现差异极小，甚至中文略优。

伪代码（Pseudocode）提示的积极作用

OIBench 的高难度对普通模型来说挑战巨大。为了更细致地分析模型的能力，我们还引入了 “伪代码提示” 评测：将标准解答转为伪代码并作为提示输入，考查模型理解和复现解题思路的能力。

结果显示，所有模型在有伪代码提示时表现均有明显提升，尤其是强推理模型（如 o3-mini-high 和 o4-mini-high）提升尤为显著。这说明伪代码极大降低了题目的推理难度，更能考查模型的代码理解与生成能力。同时，推理模型在理解解题思路方面依然具备优势。进一步分析发现，指令微调模型的表现与其基础模型高度相关，说明代码生成能力主要取决于预训练水平。

在提供伪代码提示后，所有模型表现均有明显提升，尤其是强推理模型，这说明伪代码能有效降低推理难度，更能考查模型的代码理解与生成能力。

推理效率：随着 “测试时推理” 成为提升大模型能力的重要手段， OpenAI-o1、DeepSeek-R1 等模型在解题时会生成大量推理内容。我们统计了各模型推理时的 Token 消耗与通过率的关系，发现 o4-mini-high 能以更少的 Token 解出更多题目，推理效率最高；DeepSeek-V3-0324 虽然表现不俗，但推理 Token 数量也最多，体现其长链推理的特点。

3. 模型与人类选手的对比

许多技术人员都关心：现在的大语言模型在算法编程题上的表现，和真正的竞赛选手相比到底如何？OpenAI、 DeepSeek 会用线上编程平台 Codeforces 的 Elo 评分体系来做模型与人类的对比，并报告自家模型最新的 Elo 分数，但这种方式存在一些问题：比如数据时间跨度长（一般需要半年以上的参赛记录）、在线选手水平波动大，导致对比结果不够精确，也不容易复现。

OIBench 创新性地采用了更可控的方法：邀请了中国 985 级别高校 ACM 校队选手参与部分题目的作答，并将其成绩与大模型直接对比，提供了更精准、可复现的人机对比数据；我们用小提琴图展示了每个模型在所有人类选手中的排名分布，能直观反映模型与人类在不同题目上的表现差异。

排名规则参考了信息学奥赛（IOI）的标准：先比较通过的测试用例数量，数量相同则按运行时间排序（越快越高）。

提交标准：人类选手的答案以最后一次提交为准。

人类解答开源: 分析中所涉及的人类解答记录也将匿名化并开源，便于后续研究和复现。

在小提琴图中，各模型在每道题中的人类排名位置会作为一个数据点，这些数据点形成的概率密度图就是小提琴图中的“琴身”。“琴身”的宽度显示模型排名分布的密度，越宽表示模型在对应的排名区间内出现的频率越高，从而直观地反映出模型排名表现的集中趋势。中央的框线代表排名数据最集中的区域，以o4-mini-high举例，它的排名大致超过了42%的人类选手。

三种类型的模型表现

• 低谷型： 多数题目排名靠后，只能超越不到 20% 的人类选手，多为没有长链推理能力的模型。
• 双峰型： 在部分题目上能超越一半人类选手，但在另一些题目上表现较差，多数支持长链推理的模型属于此类型，显示其在特定题型上的优势和短板。
• 橄榄型： 排名分布更均匀，表现更接近人类整体能力分布，目前只有 o4-mini-high 具备这种全面和稳定的推理特征。

4. OIBench总结与展望

本文深入分析了当前大模型编程能力评估中存在的认知鸿沟，揭示了 “宣传” 与 “现实” 之间的差距。Meituan-M17团队 通过 OIBench 这一高质量、高区分度的私有数据集，清晰揭示了顶级 LLM 在面对复杂算法挑战时，与人类顶尖水平之间的真实差距。不仅为大语言模型的算法推理能力评测树立了一个全新标杆，也为整个行业带来了更多思考。

它让我们看到：即使在模型能力突飞猛进的今天，真正高质量、高难度的算法挑战依然能够 “难倒” 最先进的 AI。尤为重要的是，希望 OIBench 的开源和透明能够为社区协作和持续创新做出一些贡献。我们期待它能成为连接学术、产业和开发者的桥梁，推动大模型在算法智能领域迈向新高度。未来，随着模型能力和评测需求的不断演进，OIBench 也会持续迭代，与大家共同见证 AI 推理的进化之路。

与此同时，我们也观察到，对于大多数人类开发者来说，即使他们接受过专业的算法设计训练，面对高难度算法和复杂系统设计，同样需要工具和智能助手的辅助才能更上一层楼。大模型的强大推理和代码生成能力，正好能为人类开发者提供有力支持，帮助他们提升算法设计和代码实现的效率。OIBench 促使我们深入思考：未来的代码开发，已超越 “人” 或 “模型” 单打独斗的模式，转变为人机协同、优势互补的新范式。

背景：工程级代码评估的挑战

研究发现，现有的代码基准数据集在面对复杂的工程场景时普遍存在缺乏多样性和可控性的双重问题：

• 工程开发环节覆盖有限：尽管现有基准（如 FullStackBench、SWEBench）在领域和语言多样性上取得进展，但其任务类型仍主要集中于单段落代码生成。而真实工程实践通常涉及跨文件、跨模块的协同，以及代码修复、测试驱动开发、多函数协作等复杂任务，这些都应被工程级基准全面覆盖。
• 数据构建方法局限：大多数数据集采用随机挖空或从代码仓库的历史 PR 记录中提取修改点（如 GitHub 的 Pull Request）。前者容易忽略项目的核心逻辑代码段，后者不仅数据量稀少，还需投入大量人工进行数据清洗和标注，难以规模化构建高质量的评测题目。

总之，我们发现现有的代码基准测试大多“偏科”了。它们要么只关注单个函数的补全，忽略了开发者修复 Bug 、根据单元测试反向开发的真实场景；要么采用随机挖空的方式，难以触及代码的核心逻辑。这导致我们无法科学、完整、全面地测评 LLM 在真实工程场景中的代码能力，尤其是在可靠性和适用性方面，我们亟需一个能解决此难题的方案。

为了应对上述挑战， Meituan-M17 团队、上海交大联合发布了一个全新的大模型工程级别代码基准测试 CoreCodeBench 数据集，托管到 AGI-Eval 社区。

• CoreCodeBench榜单地址：https://agi-eval.cn/evaluation/detail?id=64
• 微信公众号文章：AGI-Eval模型评测
• 论文预印版：《CoreCodeBench: A Configurable Multi-Scenario Repository-Level Benchmark》。

• 论文地址：http://arxiv.org/abs/2507.05281

• GitHub地址：https://github.com/AGI-Eval-Official/CoreCodeBench

它专注于评估大语言模型在真实工程项目中的综合代码能力，覆盖了从代码开发到代码修正的多个核心阶段。

通过在 CoreCodeBench 上对当前主流大语言模型的全面评测，我们得出了以下关键结论：

• 大模型编程能力迭代进步显著，但发展不均衡：较新的模型 {如 Claude 3.7 、o4 mini（high）} 相较于前代产品表现出明显进步。然而，受测模型在代码修正（BugFix）任务上表现欠佳，尤其是单函数任务场景下，修正任务的成功率全部低于开发任务，这揭示了当前 LLM 在理解和修复深层逻辑错误方面存在的普遍短板。
• 多函数协作是当前大模型编程场景的主要瓶颈：几乎所有模型在处理多函数任务时的表现都显著劣于单函数任务。这表明，当需要同时处理多个函数间的依赖关系、调用逻辑和协同实现时，当前大模型的跨函数推理和规划能力尚显不足。
• 大模型编程场景普遍缺乏灵活的规划与分层推理能力：在多函数代码生成任务中，我们观察到大多数模型严格遵循输入提示中的函数顺序生成代码，而非像人类工程师那样，基于功能依赖（如先实现被调用的工具函数）进行优化。这一现象反映了当前模型在面对复杂任务时，倾向于采用默认的顺序策略，缺乏主动规划的意识。

1. 基准构建方法与实验分析

数据集构建方法：CorePipe 流程

为了构建一个既关注多样化工程问题，又聚焦于核心代码的基准，CoreCodeBench 中设计了从工程代码仓库到多种函数题型的全自动化构建流程CorePipe。

如上图所示，CorePipe 基于函数调用树，系统化地生成覆盖三大核心场景的单函数与多函数题目，确保每一道题目都直击“要害”：

精选真实项目：我们从 PyPI 对应的 GitHub 仓库中筛选出高活跃度、高测试覆盖率和高技术复杂度的顶级开源项目。

定位核心代码：通过动态和静态追踪代码的执行，我们首先构建函数调用图，再利用抽象语法树（AST）抽取出关键函数中的核心代码，精准定位项目中那些“牵一发而动全身”的核心代码块。我们能精准定位项目中那些“牵一发而动全身”的核心函数。

模拟三大真实场景：

• 直接开发（Development）： 不仅仅是填空，我们利用 GPT-4o 生成高质量的函数功能描述，并由 Claude 3.5 Sonnet 进行“挑刺”和审核，确保模型是在理解真正需求的前提下进行开发。
• 代码修正（BugFix）：告别简单的语法错误，转而使用 LLM 生成更隐蔽、更复杂的逻辑错误，真实模拟了开发中那些令人头疼的 Bug 。
• 测试驱动开发（TDD）：提供完整的单元测试，要求模型根据测试用例反向开发功能代码，考察其遵循现代开发范式的能力。

引入多函数难题

我们将上述单函数问题按照真实的函数调用关系组合起来，创造出更复杂的多函数题目，全面考验模型在宏观层面的代码组织和规划能力。

2. 实验结果与深度分析

为确保评测的科学性，我们采用了信息增益分数（IG Score）作为核心指标，并通过 IG Filter（信息增益过滤）和专业工程师人工审核（最终合格率78.55%） 对题目质量进行充分的监测，兼具可读性、准确性和完整性。

2.1 单函数与多函数任务分析

如上图可以看出，实验结果有力地支持了我们的核心结论， Claude 3.7 在所有任务中表现突出。

但所有模型在多函数任务上的普遍表现下滑差于单模型任务，这可能是因为多函数任务需同时处理多个函数间的依赖关系、调用逻辑和协同实现，对大语言模型的跨函数推理和规划能力要求更高，以及在 BugFix 任务上的集体短板，清晰地勾勒出当前技术的能力边界。

2.2 模型规划能力洞察

多函数任务的实验分析揭示，模型缺乏对实现顺序的规划能力。

大多数模型严格遵循输入提示中的函数顺序生成代码。当前模型在多函数代码生成时缺乏灵活规划能力与分层推理能力，往往采用默认的顺序输出策略，而非基于逻辑或功能依赖进行优化。

这种“顺序执行”而非“逻辑执行”的策略，是其与人类工程师在解决复杂问题思路上的一大差异。

2.3 极限挑战

我们通过放宽多函数问题的复杂度限制，构建了 CoreCodeBench-Difficult 数据集。

在该测试中，所有模型的通过率均低于30%，这不仅印证了该基准在揭示模型局限性方面的有效性，也为未来技术的突破提供了严苛的测试平台。

2.4 LLM 代码能力全景雷达图

我们将模型的六个核心场景表现绘制成雷达图，可以直观地看到：

• 没有一个模型能在所有场景中独占鳌头，证明了 CoreCodeBench 评估维度的全面性。
• 开发（Development）和测试驱动开发（TDD）任务中，单/多函数表现并不完全相关，说明开发多关联函数需要额外的规划能力。
• 代码修正（BugFix）任务中，单/多函数表现高度相关，这说明调试更依赖于一种通用的、局部的错误修正技能。

为进一步分析各评测维度之间的关系，我们计算了所有模型在六个维度上的皮尔逊相关系数并绘制热力图。

如上图所示可以观察得到，相关系数的测算结果表明，CoreCodeBench 的六个核心场景之间既存在一定的相关性，也体现出各自的差异性：

• Single-function 任务之间相关性较高，表现出单函数任务在基础编程、理解和实现能力上的共性。
• Multi-TDD 和 Multi-Development 存在一定的相关性，这是因为 Multi-function 任务通常考察模型在更复杂场景下的综合能力，包括多步推理、实现规划等，与单函数任务所需的基础能力存在明显区别。
• Multi-BugFix 虽然属于多函数任务，但它和单函数任务相关性高，反而和 Multi-TDD、Multi-Development 相关性低。这是因为 Multi-BugFix 任务的本质更接近于“单点排查”，它更侧重于具体细节或某一局部的能力考察，而与需要全局综合能力的多函数任务存在差异。

3. CoreCodeBench总结与展望

CoreCodeBench 的构建与应用，旨在为大语言模型的代码能力评估提供一把更科学、更全面、更贴近真实的“工程标尺”。回顾我们的研究，我们系统性地揭示了当前顶尖 LLM 在真实工程场景中的核心短板：无论是多么先进的模型，都在逻辑错误修复方面步履维艰；在面对多函数协同任务时，其跨函数推理与规划能力都显得捉襟见肘；并且，它们普遍缺乏人类工程师所具备的灵活规划与分层推理能力。

然而，这些被揭示的局限性并非技术的终点，而是为下一代大语言模型的发展指明了清晰的优化方向。我们相信，通过在 CoreCodeBench 这类更贴近真实工程需求的基准上进行训练和迭代，大语言模型将能更快地从一个“代码片段生成器”，进化成一个真正具备分析、规划和解决复杂工程问题的“虚拟软件工程师”，从而在软件开发领域释放出更深远的变革力量。

总结

通过OIBench和CoreCodeBench两大基准的构建和评测，Meituan-M17团队系统性地揭示了当前大语言模型在编程领域的真实能力边界。这两个数据集不仅填补了现有评估体系的空白，更重要的是为整个行业提供了一面”照妖镜”，让我们能够更清晰地看到顶尖AI模型与人类专业水平之间的真实差距。

核心发现包括：

• 即使是最强的推理模型，在复杂算法挑战面前仍显不足，距离真正的竞赛选手水平还有很大差距；
• 在工程级代码任务中，模型普遍在代码修复和多函数协作方面存在明显短板；
• 现有模型缺乏人类工程师所具备的灵活规划和分层推理能力。

展望未来

这些发现并非技术发展的终点，而是为下一代大语言模型的优化指明了明确方向。我们相信，通过在更贴近真实需求的基准上持续训练和迭代，AI将逐步从”代码生成工具”进化为真正的”智能开发伙伴”，与人类开发者形成优势互补的协作关系。

Meituan-M17团队将持续致力于高质量评估研究，推动大语言模型技术向更广阔的未来发展。