Multi-LCB：把代码能力评测从Python扩展到12种编程语言，大模型的「偏科」问题暴露无遗
TL;DR
Multi-LCB是一个全新的多语言代码生成基准测试，将LiveCodeBench（LCB）从Python扩展到12种编程语言。研究团队评估了24个大语言模型，发现了三个关键现象：Python过拟合（模型在Python上表现远超其他语言）、语言特定的数据污染（某些语言的训练数据包含了测试题目的答案）、以及多语言性能的巨大落差。这个基准测试直接回应了LCB最大的局限性——只测Python——为评估模型真正的跨语言编程能力提供了严谨的工具。该论文被ICLR 2026接收。
论文信息
| 项目 | 内容 |
|---|---|
| 标题 | Multi-LCB: Extending LiveCodeBench to Multiple Programming Languages |
| 作者 | Maria Ivanova, Pavel Zadorozhny, Rodion Levichev, Ivan Petrov, Adamenko Pavel, Ivan Lopatin, Alexey Kutalev, Dmitrii Babaev |
| 发表 | ICLR 2026 |
| arXiv | 2606.20517v1 |
| 领域 | 代码生成、大语言模型评测、多语言编程 |
研究背景与动机
大模型的代码能力评测现状
过去三年，大语言模型（LLM）在代码生成领域的进步堪称飞速。从GitHub Copilot到Claude、GPT-4，再到各种专门的代码模型如DeepSeek-Coder、CodeLlama，这些模型已经深度嵌入了软件工程师的日常工作流程。一个程序员在Cursor里敲下几行注释，模型就能补全出几十行可运行的代码——这种体验正在从「新奇」变成「标配」。
但问题随之而来：我们怎么知道一个模型的代码能力到底有多强？
答案就是基准测试（Benchmark）。就像高考是衡量学生知识水平的标尺，代码基准测试是衡量LLM编程能力的标尺。目前最广泛使用的代码基准包括HumanEval（164道Python题）、MBPP（974道Python入门题）、以及近期备受关注的LiveCodeBench（LCB）。
这些基准测试之所以重要，是因为它们提供了一个可量化、可比较的评估框架。没有基准测试，我们就无法客观地比较不同模型的代码能力，也无法追踪模型在时间维度上的进步。基准测试就像一把尺子——尺子的精度和范围决定了我们能测量什么。
LiveCodeBench为什么重要？
LCB相比前两者有三个核心优势：
- 题目来源真实：它从LeetCode、Codeforces、AtCoder等竞赛平台收集题目，这些是程序员真正面对的算法挑战，而非人为构造的简单函数。这就像考试用的是真实世界的工程问题，而不是教科书上的练习题。
- 持续更新：LCB会不断加入新题目，避免了「静态基准」的通病——随着时间推移，模型的训练数据可能会无意中包含测试题目的答案（这就是所谓的数据污染问题）。可以想象成一个不断有新题目的题库，学生无法通过死记硬背来应对。
- 时间过滤：LCB按发布日期过滤题目，确保评估时使用的题目在模型训练截止日期之后发布，从机制上杜绝数据污染。这就像高考出题组只使用当年新出的题目，不可能提前泄露。
这三个特性使LCB成为当前最可靠的代码能力评测工具之一，被学术界和工业界广泛采用。当一个AI公司在宣传其模型的代码能力时，LCB的通过率往往是最常被引用的指标。
LCB的致命短板：只看Python
然而，LCB有一个无法回避的问题：它只支持Python。
这意味着什么？想象一下，一个高考只有数学科目——你当然可以区分出谁数学好、谁数学差，但你完全无法判断一个学生的语文、英语、物理水平如何。一个数学满分但其他科目零分的学生，和一个各科都85分的学生，在这个「高考」里看起来可能差不多。
现实世界的软件工程远不止Python。一个后端工程师可能需要写Java、Go或Rust；一个数据科学家用Python和SQL；一个系统程序员用C和C++；一个前端工程师用TypeScript和JavaScript。根据Stack Overflow 2025年的开发者调查，Python虽然是最受欢迎的语言之一，但JavaScript、Java、C#、TypeScript、C++、Go等语言的使用率同样很高。如果我们的评测工具只能衡量Python能力，那我们对模型「编程能力」的认知就是片面的。
更重要的是，不同编程语言有截然不同的范式和特性。Python是动态类型的、解释执行的、强调简洁优雅；C++是静态类型的、编译执行的、需要手动管理内存；Haskell是函数式编程语言，思维方式完全不同。一个在Python上表现出色的模型，可能在这些语言上表现平庸甚至糟糕——但我们无从知晓。
这就好比一个只会说英语的翻译官，你不能因为他英语翻译做得好，就假设他的法语、日语、阿拉伯语翻译能力也同样出色。语言之间的差异，和编程语言之间的差异一样，是结构性的，而非表面性的。
为什么之前没人做这件事？
听起来，「把基准测试扩展到多语言」似乎是一个显而易见的方向。但实际操作中有几个巨大的技术挑战：
- 题目翻译的正确性：把一道Python题目转换成C++或Java，不仅要转换代码逻辑，还要处理语言特有的一切——内存管理、类型系统、标准库差异、输入输出格式等。一个微妙的差异就可能导致题目答案不同。比如Python的整数是任意精度的，而C++的
int有32位限制，溢出会导致完全不同的结果。 - 测试用例的适配：不同语言的输入输出方式不同（比如Python用
input()，Java用Scanner），测试用例需要相应调整。 - 评估公平性：不同语言的代码长度、可读性、执行效率差异巨大，如何设计一个公平的评估框架？
- 工程量巨大：12种语言 × 每道题 = 海量的转换工作，需要对每种语言都有深入理解的工程师来完成和验证。
Multi-LCB论文正是直面这些挑战，交出了一份扎实的答卷。
核心发现
Multi-LCB的研究团队评估了24个大语言模型（包括指令模型和推理模型），覆盖了12种编程语言。实验结果揭示了三个令人警醒的发现：
发现一：Python过拟合是普遍现象
绝大多数模型在Python上的通过率（pass rate）显著高于其他语言。这不是因为Python「简单」——在LCB的竞赛题目中，算法复杂度与语言无关。真正的原因是：这些模型的训练数据中，Python代码占据了压倒性的比例。
以一个具体数字来感受这种差距：某些模型在Python上的通过率可以达到60%，但在C++或Java上只有40-45%，在Rust或Haskell上可能跌到20-30%。这不是小的波动，而是系统性的能力差异。差距可以达到30-40个百分点，相当于从「及格」掉到「不及格」。
这个发现的含义深远。当我们在论文或产品宣传中看到「模型在LiveCodeBench上达到了X%的通过率」时，这个数字只代表了Python能力。如果把语言范围扩大，模型的真实编程能力可能远低于我们以为的水平。就好比一个学生告诉你他高考数学150分，但没告诉你他语文只有60分——你对他学业水平的判断会严重偏高。
更值得注意的是，这种Python过拟合并非个别模型的问题，而是普遍现象。这意味着整个行业对代码模型能力的评估可能都存在系统性的高估。当我们说「AI已经能写代码了」，更准确的说法应该是「AI已经能写Python代码了」。
发现二：语言特定的数据污染
数据污染是基准测试领域的「房间里的大象」。所有人都知道它存在，但很难量化和证明。Multi-LCB提供了一个独特的视角来观察这个问题。
研究发现，某些模型在特定语言上的表现异常地好，超出了其在相关语言上的表现趋势。例如，一个模型可能在C++上的表现远好于Java和Python之间的相对差距所能预测的水平。这种「异常值」强烈暗示该模型的训练数据中包含了C++版本的题目答案。
这种语言特定的污染比整体污染更难检测，也更危险。因为如果你只看Python的结果，你根本不会发现模型在C++上「作弊」了。Multi-LCB的多语言评估框架使得这类异常模式浮出水面。
打个比方：如果一个学生在所有科目上都考了90分，你可能会认为他确实优秀。但如果他数学考了90分，物理考了95分，而化学突然考了满分——考虑到数学和物理的强相关性，化学的异常高分就值得怀疑了。Multi-LCB正是通过这种跨语言的「相关性分析」来发现污染的。
发现三：多语言性能落差巨大
24个模型在12种语言上的表现呈现出高度不一致的模式。一些模型在Python和JavaScript上表现不错，但在函数式语言（如Haskell）或系统编程语言（如Rust）上表现急剧下降。另一些模型虽然整体水平一般，但在各语言间的差距更小，展现出更好的「语言均衡性」。
这揭示了一个重要的权衡：我们应该优先追求在某一种语言上的极致表现，还是追求在多种语言上的均衡能力？ 答案取决于应用场景——如果你的模型只用于Python代码补全，前者更好；但如果你要构建一个通用的编程助手，后者更为重要。
这也引出了一个更深层的问题：代码能力到底是一种通用能力，还是由多个独立的语言能力组成的？Multi-LCB的数据暗示，目前的模型更像是后者——它们的语言能力是相对独立的，跨语言迁移的效果有限。
技术方法详解
Multi-LCB的构建过程
Multi-LCB的构建可以用一个比喻来理解：假设你有一本用英文写的数学竞赛题集（原始LCB），现在你要把它翻译成法语、德语、日语、中文等11种语言。但这里的「翻译」不是简单的文字翻译——你需要确保每道题在每种语言中都能正确运行、产生相同的答案。
更准确地说，这不是「翻译」，而是「移植」（Porting）——就像把一个Windows软件移植到Mac和Linux上，不仅要保持功能不变，还要适配每个操作系统的特性和限制。
具体来说，构建过程分为几个步骤：
第一步：题目选取
从原始LCB数据集中选取Python题目。LCB的题目来自LeetCode、Codeforces、AtCoder等竞赛平台，每道题包含题目描述、参考解答、测试用例。选取时需要确保题目适合多语言转换——某些Python特有的题目（比如大量使用列表推导式或内置函数的）可能不适合直接转换。
这一步就像在翻译一本书之前先做内容审查——确认哪些章节适合翻译，哪些章节因为文化差异太大需要特殊处理。
第二步：代码转换
这是最具挑战性的步骤。将Python代码转换成其他11种语言（如C++、Java、JavaScript、Go、Rust、Kotlin、Ruby、Swift、TypeScript、C#、Haskell），需要处理大量语言特异性问题：
- 类型系统：Python是动态类型，不需要声明变量类型；而Java、C#等是静态类型，每个变量都必须声明类型。转换时需要推断变量类型——一个Python变量
x = []，在Java中需要决定是ArrayList<Integer>还是ArrayList<String>，这需要结合上下文来判断。 - 内存管理：Python有自动垃圾回收；C++需要手动管理内存（虽然竞赛题通常不需要）；Rust有所有权系统，每个值都有唯一的所有者，这可能要求完全重构代码结构。
- 标准库差异：Python的
list对应Java的ArrayList、C++的std::vector、Go的[]int等。排序、查找等操作的API各不相同。Python的sorted()在C++中是std::sort()，在Java中是Collections.sort()。 - 输入输出：竞赛题的输入输出格式在不同语言中处理方式不同。Python用
input()和print()，Java用Scanner和System.out.println()，C++用cin和cout。 - 语法差异：Python用缩进表示代码块，C++/Java用花括号，Haskell用缩进但规则不同。Python的列表推导式
[x**2 for x in range(10)]在Java中需要写成一个完整的循环。 - 数值精度：Python的整数是任意精度的，而大多数语言的整数有固定位数（如32位或64位）。涉及大数计算的题目在转换时需要特别小心，可能需要使用BigInteger等大数库。
用一个更形象的比喻：这就像把一篇用白话文写的文章转换成文言文、法语、日语，不仅要保持意思不变，还要符合每种语言的语法规范和表达习惯。任何一个细微的错误——比如整数溢出、字符串编码差异、浮点精度问题——都可能导致答案不正确。
第三步：测试用例适配
每种语言的程序需要使用自己的输入输出机制来读取测试数据。Multi-LCB为每种语言设计了统一的输入输出模板，确保所有语言的程序接收相同的输入、产生可比较的输出。
这一步看似简单，实则有很多细节。比如，Python的print()会在末尾自动加换行符，而某些语言的输出函数不会。如果测试用例对输出格式要求严格（比如要求恰好没有末尾换行），这些细节就可能导致误判。Multi-LCB需要仔细处理这些边界情况。
第四步：正确性验证
每个转换后的程序都必须通过所有测试用例。这一步通过自动化测试完成——运行转换后的代码，比对输出与预期答案。如果任何测试用例失败，就需要人工检查和修正。
这一步是质量保证的关键。论文报告了其转换的通过率和需要人工干预的比例，展示了其方法的可靠性。在大规模转换中，即使很小的错误率也会累积成大量有问题的题目，因此严格的验证流程至关重要。
评估框架设计
Multi-LCB完全兼容原始LCB的评估协议，这意味着：
- 污染控制：继承了LCB的时间过滤机制，确保评估使用的题目在模型训练截止日期之后发布。这是LCB最核心的设计理念，Multi-LCB完整保留了它。
- 自动更新：当LCB加入新题目时，Multi-LCB可以自动扩展到多语言版本，保持基准测试的新鲜度。这个设计非常聪明——它让Multi-LCB成为LCB的「镜像」，而不是一个需要独立维护的项目。
- 统一评分：使用与LCB相同的pass@1指标，确保结果可与LCB的历史数据直接比较。pass@1的意思是：模型生成一次代码，看它是否能通过所有测试用例。
覆盖的编程语言
Multi-LCB选择了12种编程语言，覆盖了不同的编程范式和应用场景：
| 语言 | 类型 | 典型应用 |
|---|---|---|
| Python | 动态、解释型 | 数据科学、脚本、Web后端 |
| C++ | 静态、编译型 | 系统编程、游戏、竞赛 |
| Java | 静态、编译型 | 企业应用、Android |
| JavaScript | 动态、解释型 | Web前端、Node.js后端 |
| TypeScript | 静态、编译到JS | 大型Web应用 |
| Go | 静态、编译型 | 云原生、微服务 |
| Rust | 静态、编译型 | 系统编程、安全关键 |
| C# | 静态、编译型 | 游戏(Unity)、企业应用 |
| Kotlin | 静态、编译型 | Android、后端 |
| Ruby | 动态、解释型 | Web(Rails)、脚本 |
| Swift | 静态、编译型 | iOS/macOS开发 |
| Haskell | 纯函数式 | 学术、金融 |
这种多样化的语言覆盖确保了评测的全面性。从面向对象到函数式，从脚本语言到系统语言，Multi-LCB几乎覆盖了所有主流编程范式。
实验结果分析
实验设置
研究团队评估了24个大语言模型，包括两类：
- 指令模型（Instruction Models）：经过指令微调的通用模型，如GPT-4o、Claude等。这类模型擅长遵循用户指令，在对话场景中表现良好。
- 推理模型（Reasoning Models）：专门优化了推理能力的模型，如o1、DeepSeek-R1等。这类模型通过「思维链」（Chain of Thought）来逐步推理，通常在复杂问题上表现更好。
评估指标使用pass@1，即模型一次生成代码通过所有测试用例的概率。
关键数据模式
Python作为参照基准：几乎所有模型在Python上的表现都是最佳或接近最佳的。这不是因为Python题目更简单——LCB的题目难度与语言无关——而是因为模型对Python的「熟悉度」最高。Python在训练数据中的占比通常是最高的，这直接转化为了更好的表现。
语言间的性能梯度：从Python到其他语言，性能通常呈现阶梯式下降。大致的规律是：Python > JavaScript/TypeScript > Java/C# > C++ > Go > Kotlin/Ruby/Swift > Rust > Haskell。这个梯度与训练数据中各语言代码的比例大致吻合——训练数据中出现越多的语言，模型表现越好。
推理模型的跨语言优势：推理模型（如DeepSeek-R1、o1系列）在多语言评测中展现出比指令模型更强的跨语言泛化能力。这可能是因为推理模型通过「思维链」来解决问题，而不是简单地记忆代码模式。思维链是语言无关的——「这道题需要用动态规划，状态转移方程是...」这种推理过程不依赖于具体的编程语言。因此，推理模型能够将Python上的推理能力迁移到其他语言上，即使它在那些语言上的训练数据较少。
语言特定的异常表现：如前所述，某些模型在特定语言上表现出不自然的「尖峰」。例如，某个模型在Go上的表现突然比在Java上好很多，但其他模型都是Java优于Go。这种异常模式最合理的解释就是训练数据污染。
与现有工作对比
与HumanEval-Multi的对比
HumanEval-Multi是最早尝试多语言代码评测的基准之一，将HumanEval的164道题扩展到多种语言。但HumanEval-Multi有几个明显的不足：
- 题目太简单：HumanEval的题目大多是「写一个函数，输入X，输出Y」这种级别，与真实的软件工程任务差距较大。很多题目甚至不需要任何算法知识，直接实现即可。
- 静态数据集：HumanEval-Multi不更新，随着时间推移，数据污染问题越来越严重。到了2025年，这些题目几乎肯定已经被包含在了主流模型的训练数据中。
- 规模较小：只有164道题，统计显著性有限。164道题的差异可能只是随机波动，而非真实的能力差距。
Multi-LCB在这些方面全面胜出：题目来自竞赛平台（更难、更真实）、持续更新（抗污染）、规模更大。
与MultiPL-H的对比
MultiPL-H是另一个多语言代码基准，使用启发式规则将Python代码转换成其他语言。Multi-LCB的转换过程更加系统化，正确性验证更严格，且直接继承了LCB的污染控制机制。
Multi-LCB的独特优势
Multi-LCB最大的优势在于其与LCB的兼容性。它不是一个独立的基准，而是LCB的扩展。这意味着：
- 所有已有的LCB实验结果都可以直接与Multi-LCB的结果比较
- 未来的LCB更新会自动反映到Multi-LCB中
- 社区已经熟悉的LCB评估工具链可以直接使用
这种设计大大降低了社区采用Multi-LCB的门槛。它不需要人们学习新的工具或流程，只需要在现有的LCB框架上增加一个「多语言」维度。
潜在应用与影响
对模型开发的影响
Multi-LCB为模型开发者提供了一个更全面的「体检报告」。过去，一个模型在LCB上达到60%的通过率可能被宣传为「强大的代码能力」。但Multi-LCB可能会揭示：这个60%几乎全部来自Python，在其他语言上可能只有30%。这会推动开发者更加关注模型的多语言编程能力，而不仅仅是Python性能。
对训练策略的影响
Multi-LCB的发现暗示了当前训练数据的组成问题——Python代码占比过高。这可能推动训练数据集的重新平衡，增加其他编程语言的代码比例。特别是一些重要的系统编程语言（C++、Rust）和企业级语言（Java、C#），在训练数据中的代表性可能不足。
数据集的平衡不仅仅是增加代码数量的问题，还需要确保各语言的代码质量一致。低质量的代码数据可能反而会降低模型在该语言上的表现。
对评测实践的影响
多语言基准测试可能成为代码模型评测的新标准。就像现在的NLP模型评测会覆盖多种语言一样，代码模型评测也应该覆盖多种编程语言。Multi-LCB为这种评测实践提供了可操作的工具。
对学术研究的影响
Multi-LCB揭示的「Python过拟合」现象提出了一个有趣的研究问题：模型能否通过架构创新或训练策略改进来实现更好的跨语言泛化？ 这可能催生一批新的研究工作，探索代码模型的多语言迁移学习、跨语言代码表示等方向。
一个有趣的研究方向是：能否设计一种「语言无关」的代码表示，让模型学会编程的「底层逻辑」，而非特定语言的语法？如果能实现这一点，模型可能只需在一种语言上训练，就能在所有语言上表现良好。
对工业界的影响
对于使用LLM辅助编程的企业来说，Multi-LCB提供了更实用的选型依据。一个需要同时支持Python、Java和Go的企业，不应该只看Python上的评测结果来选择模型。Multi-LCB的多语言评测结果可以帮助企业做出更明智的决策。
局限性与未来方向
当前局限
竞赛题目的代表性：LCB的题目来自编程竞赛，侧重算法和数据结构。但现实世界的软件工程涉及更多方面——代码可读性、架构设计、调试能力、库的使用等。竞赛题表现好不等于实际编程能力强。
转换质量的上限：尽管Multi-LCB的转换过程非常严格，但某些语言特有的特性可能无法完美转换。例如，Python的列表推导式转换成C++时可能需要完全不同的实现方式，这可能引入微妙的行为差异。
评估指标的单一性：pass@1只衡量代码是否通过测试，不考虑代码质量（可读性、效率、风格）。一个生成了难以理解但正确的代码的模型，和一个生成了优雅且正确代码的模型，在pass@1指标下得分相同。
语言覆盖的局限：虽然12种语言已经相当全面，但仍有一些重要的语言未被覆盖，如Scala、Elixir、Julia、R等。特别是R语言在数据科学领域的重要性不亚于Python。
不评估交互式编程能力：现实中的编程往往是一个迭代过程——写代码、运行、调试、修改。Multi-LCB评估的是一次性生成正确代码的能力，这与实际开发场景有差距。
未来方向
更丰富的评估维度：除了正确性，还可以评估代码效率（时间/空间复杂度）、代码风格、安全性等。
真实软件工程任务：将评测扩展到更接近真实开发场景的任务——比如调试现有代码、理解代码库、编写测试用例等。
多语言协同：现实项目通常使用多种语言（前端TypeScript + 后端Python + 数据库SQL）。评测模型在这种多语言协同场景下的表现将更有实际意义。
动态难度调整：根据模型的能力水平动态调整题目难度，避免「天花板效应」（所有模型都轻松通过）和「地板效应」（所有模型都无法通过）。
跨语言迁移学习研究：利用Multi-LCB作为测试平台，研究如何通过训练策略的改进来提升模型的跨语言泛化能力。
总结
Multi-LCB是一项及时且重要的工作。它将LiveCodeBench——当前最受认可的代码生成基准——从Python扩展到12种编程语言，填补了代码模型评测的关键空白。
研究的三大发现——Python过拟合、语言特定污染、多语言性能落差——每一个都具有重要的实践意义。它们共同指向一个结论：当前大语言模型的「代码能力」被高估了，因为我们只看了它们最擅长的Python。
对于模型开发者，Multi-LCB是一个警钟：需要在训练数据和训练策略上更加关注多语言编程能力。对于模型使用者，Multi-LCB是一个更可靠的选型工具：不再被Python上的单一数字所误导。对于研究社区，Multi-LCB打开了一扇新的大门：跨语言代码生成的泛化能力，将成为一个重要的研究方向。
这篇论文被ICLR 2026接收，说明学术界也认同多语言代码评测的重要性。随着Multi-LCB的开源和推广，我们有理由期待代码模型的评测标准会更加全面和公正，推动整个领域向着「真正的通用编程助手」这一目标迈进。
评论