TL;DR
LiveCodeBench（LCB）是目前最权威的代码生成基准之一，但只测试Python。Multi-LCB将评估范围扩展到12种编程语言，对24个大模型进行系统测试。核心发现：多数模型存在明显的Python过拟合，在C++、Java等语言上的通过率显著下降；不同语言间性能差距巨大，某些语言可能受到数据污染影响。Multi-LCB与原版LCB完全兼容，可持续跟踪未来更新，为多语言代码生成能力评估设立了新标准。
论文信息
- 论文标题：Multi-LCB: Extending LiveCodeBench to Multiple Programming Languages
- 论文编号：2606.20517v1
- 发布时间：2025年6月
- 关键词：代码生成、基准测试、多语言评估、大语言模型、竞赛编程
研究背景与动机
如果你在过去一年里用过大模型写代码，你大概率用的是Python。这并不奇怪——Python语法简洁、社区庞大、教程遍地，几乎所有"用AI写代码"的演示视频里，主角都是Python。但问题是：现实世界的软件工程从来不是Python一家独大的世界。
一个大型后端系统可能同时用到Java、Go和Rust；一个嵌入式项目离不开C和C++；前端工程师每天和JavaScript、TypeScript打交道；数据工程师可能在SQL和Scala之间来回切换。如果我们要评估一个大模型"写代码"的能力，只看Python显然是不够的。
目前最主流的代码生成基准之一是LiveCodeBench（LCB）。LCB的设计确实精巧：它从竞赛编程平台持续收集新题目，按时间线过滤以避免数据污染，提供了对模型编码能力的全面视角。但LCB有一个根本性的限制——它只支持Python。
这个限制带来的问题是双重的。第一，我们不知道模型在其他语言上的表现如何。一个在Python上得分很高的模型，可能在C++上因为内存管理、指针操作等问题表现糟糕，也可能在Haskell上因为函数式编程范式的差异而完全失灵。第二，我们无法排除数据污染的可能性。如果某个模型的训练数据中恰好包含了大量Python竞赛题目的解法，那么它在LCB上的高分可能部分来自"背答案"而非真正的编码能力——但如果同一道题用Rust或Go来表述，这种污染效应可能就会消失或减弱。
Multi-LCB正是为了解决这个问题而诞生的。它的核心思路很直接：把LCB的Python题目等价地转换为其他11种编程语言，保持LCB原有的污染控制机制和评估协议不变。这样一来，我们就能在完全一致的条件下，观察模型在不同语言上的真实表现差异。
选择哪12种语言也是经过仔细考量的。Multi-LCB覆盖了Python、Java、C++、C、JavaScript、TypeScript、Go、Rust、C#、Kotlin、Swift和PHP。这个列表几乎囊括了工业界最常用的编程语言，同时也涵盖了不同的编程范式：面向对象（Java、C#）、系统编程（C、C++、Rust）、函数式倾向（Swift、Kotlin）、脚本语言（Python、JavaScript、PHP）和静态类型语言（TypeScript、Go）。这种多样性确保了评估结果能够真实反映模型在实际工程场景中的适用性。
另一个关键的工程决策是兼容性。Multi-LCB与原版LCB完全兼容，这意味着当LCB更新题库时，Multi-LCB可以自动跟踪更新，无需人工干预。这解决了基准测试"过期"的常见问题——很多基准在发布后不久就因为题目泄露或模型在训练数据中见过原题而失去评估价值，而LCB通过持续更新缓解了这一问题，Multi-LCB继承了这一优势。
核心发现
Multi-LCB对24个大模型进行了全面评估，这些模型涵盖了指令跟随（instruction）和推理（reasoning）两种模式。评估结果揭示了几个值得关注的现象。
发现一：Python过拟合是普遍现象
这是Multi-LCB最重要的发现。绝大多数模型在Python上的通过率明显高于其他语言。这种差距不是一星半点——在某些模型上，Python与排名第二的语言之间可以相差10个百分点以上。
这个现象的含义很明确：当前的代码大模型在训练过程中过度偏向Python数据。这可能有几个原因。首先，Python在互联网上的代码样本数量确实最大，训练数据中Python的占比天然就高。其次，很多代码生成的训练数据集本身就是以Python为主构建的。第三，竞赛编程社区中Python也是最常用的语言之一，而LCB的题目来源正是竞赛编程。
但"Python过拟合"这个结论本身并不能告诉我们是哪个因素起了主导作用。是训练数据的分布偏差，还是模型架构对某些语言特性的天然偏好？这个问题需要进一步的消融实验来回答。
发现二：语言间性能差异巨大
除了Python之外，模型在其他语言上的表现也存在显著差异。一般来说，Java和C++作为竞赛编程中同样常用的语言，表现相对较好；而Go、Rust、Swift等相对较新的语言，模型的表现往往明显下降。
这种差异可能反映了训练数据中不同语言代码样本的分布。但也有可能是因为某些语言的语法和语义更"独特"，模型更难从类似语言的知识中进行迁移。例如，Rust的所有权系统和借用检查器是其他语言中几乎不存在的概念，模型如果只在C/C++和Python上训练过，就很难正确编写Rust代码。
值得注意的是，即使是同一种语言，不同的问题类型也会导致性能差异。涉及特定语言惯用写法（idiom）的题目，模型往往表现更差，因为这些写法在不同语言之间几乎没有可迁移性。
发现三：推理模式并非万能
近年来，"推理"模式（reasoning mode）被认为能显著提升模型的代码生成能力。Multi-LCB的评估证实了这一点——推理模式确实在大多数语言上带来了提升。但这种提升并非均匀的。
在Python上，推理模式的增益往往最大；而在一些不那么常用的语言上，推理模式的提升幅度要小得多。这说明推理能力的提升在很大程度上依赖于模型对语言本身的基础理解——如果模型对某种语言的理解本来就很薄弱，那么即使给它更多"思考时间"，它也很难从错误的推理路径中找到正确答案。
发现四：数据污染的蛛丝马迹
Multi-LCB的一个意外发现是，某些模型在特定语言上的表现与其在其他指标上的能力不一致。例如，一个在Python和Java上表现平平的模型，可能在某种较少使用的语言上突然表现优异。这种异常模式可能是数据污染的信号——模型的训练数据中可能包含了该语言版本的竞赛题目解法。
Multi-LCB的多语言评估框架天然具备检测这种异常的能力。通过比较同一模型在不同语言上的相对表现，研究者可以识别出可能的数据污染案例。这是单一语言基准无法做到的。
发现五：指令跟随与推理的互补关系
在某些语言上，指令跟随模式反而比推理模式表现更好。这通常出现在语法简单但语义微妙的语言上，推理模式的"过度思考"有时会引入不必要的复杂性。这种现象表明，不同类型的模型能力在不同语言场景下的价值是不同的。
技术方法详解
Multi-LCB的技术挑战在于：如何把一道Python竞赛题目"等价地"转换为其他语言的题目？听起来简单，做起来却暗藏玄机。
问题转换的核心难题
用一个类比来说明：假设你有一道用中文出的数学应用题，你需要把它翻译成英文、日文和法文。表面上看，这只是翻译工作。但问题是，这道题可能用到了中文特有的表达方式——比如"鸡兔同笼"这种经典题型，日文和法文的读者可能根本不知道这是什么。你到底是翻译字面意思，还是保留题目的数学本质？
Multi-LCB面临的是同样的问题。Python中的一道竞赛题，可能大量使用了Python特有的语法糖和内置函数。比如 list comprehension、lambda 表达式、enumerate()、zip() 等特性，在C语言中根本没有直接对应物。直接"翻译"会导致C代码变得面目全非，题目难度也会完全不同。
转换策略：保留算法本质，适配语言特性
Multi-LCB采取的策略是保留题目的算法本质，同时适配目标语言的特性。具体来说，转换过程分为几个步骤：
第一步：问题描述的标准化。 题目的文字描述被修改为与语言无关的形式。输入输出格式的描述变得更加通用，避免引用Python特定的数据类型。比如，原来的描述可能说"输入是一个列表"，标准化后变成"输入是一组整数"。
第二步：输入输出格式的适配。 不同语言处理输入输出的方式差异很大。Python可以直接用 input() 读取一行然后 split()；C语言需要 scanf 或手动解析；Java需要 Scanner 或 BufferedReader。Multi-LCB为每种语言定义了标准的输入输出处理模板，模型只需要关注算法逻辑本身。
第三步：数据类型的映射。 Python的 list 在C中变成数组，在Java中变成 ArrayList，在Rust中变成 Vec。Python的 dict 在不同语言中也有不同的对应物。Multi-LCB为每种语言定义了明确的类型映射规则，确保转换后题目使用的数据类型是目标语言中最自然的选择。
第四步：测试用例的验证。 这是最关键的一步。每道转换后的题目都需要确保其测试用例与原始Python题目的测试用例完全等价。也就是说，同一个算法逻辑在不同语言实现下应该产生完全相同的输出。这一步通过自动化测试来保证——研究者用参考解法在所有12种语言上运行相同的测试输入，确认输出一致。
评估协议：保持一致性
Multi-LCB的评估协议与原版LCB完全一致。模型接收题目描述和代码模板，需要生成完整的问题解答代码。生成的代码在所有测试用例上运行，通过率（pass@k）作为评估指标。
这种一致性是Multi-LCB的核心价值所在。它使得我们可以直接比较同一模型在不同语言上的表现，而不用担心评估方法的差异引入了额外的变量。
兼容性设计：自动跟踪更新
Multi-LCB的另一个技术亮点是其兼容性设计。它不是一次性的静态数据集，而是可以随着LCB的更新自动扩展。当LCB添加新的Python题目时，Multi-LCB的转换流程会自动将新题目转化为其他语言版本。
这种设计通过模块化的代码架构实现。转换逻辑、测试验证、题目管理等组件被解耦，每个组件可以独立更新。这使得Multi-LCB能够长期保持时效性，而不会像很多基准测试那样发布后很快就过时。
防污染机制
LCB的一个重要特性是按时间线过滤题目——它只使用在模型训练截止日期之后发布的竞赛题目，从而避免模型在训练时见过这些题目。Multi-LCB继承了这一机制。
由于Multi-LCB的题目是通过转换LCB题目得到的，而非独立收集的，所以它们天然具有与LCB相同的时间戳属性。如果一道Python题目在LCB中因为时间过滤而被排除，那么它在其他语言上的对应版本也会被排除。
但这里有一个微妙的问题：即使原始Python题目没有出现在训练数据中，转换后的其他语言版本是否也没有出现？Multi-LCB的假设是，竞赛编程题目的多语言版本不太可能同时出现在训练数据中，因为大多数在线评测系统只展示一种语言的解法。当然，这个假设并不是绝对的，这也正是研究者在论文中讨论数据污染可能性时提到的一个潜在局限。
实验结果分析
Multi-LCB评估了24个大模型，这些模型来自不同的厂商，规模从小到大，能力从基础到顶尖。评估覆盖了指令跟随和推理两种模式，在12种编程语言上分别测试。
整体性能排名
在所有语言的综合表现上，顶尖模型的排名与它们在Python上的排名基本一致，但存在一些有趣的差异。某些在Python上排名靠后的模型，在其他语言上反而表现突出，这暗示了不同模型在训练数据和方法上的差异化策略。
指令跟随 vs 推理模式
推理模式在大多数语言上都带来了提升，但提升幅度因语言而异。在Python上，推理模式的平均提升约为5-8个百分点；在Java和C++上，提升约为3-6个百分点；而在一些较少使用的语言上，提升可能不到2个百分点。
这说明推理模式的工作机制更依赖于模型对语言的基础知识。推理本质上是一种"搜索"过程——模型尝试不同的解题路径，评估每条路径的可行性，然后选择最优解。但这种搜索的前提是模型能够正确评估每条路径——如果模型对某种语言的语法规则都不确定，那么即使搜索再多路径也找不到正确答案。
模型规模与多语言能力的关系
一个有趣的发现是，模型规模与多语言代码生成能力之间的关系并不像人们预期的那样简单。大模型确实在Python上的表现更好，但这种优势在其他语言上会有所衰减。换句话说，增大模型规模对Python能力的提升大于对其他语言能力的提升。
这进一步支持了"Python过拟合"的假设：如果模型在训练时接触的Python数据远多于其他语言，那么增大模型规模会放大数据分布的偏差，导致Python能力的增长快于其他语言。
不同语言的"难度"
从实验数据来看，12种语言的"难度"大致可以分为几个层次：
- 第一梯队（模型表现最好）：Python、Java、C++。这三种语言在竞赛编程中最常用，训练数据最丰富。
- 第二梯队（表现中等）：C、JavaScript、TypeScript、Go。这些语言虽然不如前三名常用，但语法相对简单或与第一梯队的语言有较多相似性。
- 第三梯队（表现较差）：Rust、Kotlin、Swift、C#。这些语言要么语法独特（Rust），要么在竞赛编程中不常用（Kotlin、Swift、C#），模型的训练数据中相关内容较少。
PHP的表现则比较特殊。虽然PHP在工业界广泛使用，但在竞赛编程中极为罕见，导致模型在PHP上的表现波动较大——某些模型在PHP上表现不错（可能因为训练数据中包含了足够的Web开发代码），而另一些则表现很差。
与现有工作对比
Multi-LCB并不是第一个尝试多语言代码评估的工作，但它与现有工作有几个关键区别。
与HumanEval多语言版本的对比
HumanEval是最经典的代码生成基准之一，也有多语言扩展版本（如HumanEval-X）。但HumanEval的题目难度相对较低，且题目数量有限（约160道），很难区分顶尖模型之间的能力差异。Multi-LCB的题目来自竞赛编程，难度更高，题目数量也更多，能够提供更细致的评估。
此外，HumanEval是静态数据集，不会随时间更新，而Multi-LCB继承了LCB的持续更新机制，能够保持评估的时效性。
与MBPP的对比
MBPP（Mostly Basic Python Problems）同样以Python为主，虽然也有多语言扩展，但题目过于基础，对当前的顶尖模型来说区分度不够。Multi-LCB的竞赛编程题目提供了更大的挑战。
Multi-LCB的独特贡献
Multi-LCB最独特的贡献在于三个层面：
- 兼容性：与LCB完全兼容，自动跟踪更新。
- 污染控制：继承LCB的时间线过滤机制，同时通过多语言视角提供额外的污染检测能力。
- 覆盖广度：12种语言覆盖了工业界最常用的技术栈，评估结果对实际工程场景有更强的参考价值。
潜在应用与影响
对模型开发者的价值
对于训练代码大模型的团队来说，Multi-LCB提供了一个更全面的评估工具。如果一个模型在Multi-LCB上的表现显示严重的Python过拟合，开发者就需要反思训练数据的配比，增加其他语言的代码样本。
Multi-LCB还能帮助开发者识别模型的弱点。如果某个模型在Rust上的表现特别差，但其他语言都还好，那就说明模型对Rust特有的概念（所有权、生命周期等）理解不足，需要针对性地补充训练数据。
对企业用户的价值
对于企业来说，选择代码大模型时需要考虑实际使用场景。如果团队主要用Java和TypeScript，那么一个在Python上排名第一但在其他语言上表现平平的模型，可能并不是最佳选择。Multi-LCB的多语言评估结果可以直接指导这种决策。
对基准测试研究的影响
Multi-LCB的设计思路——将单语言基准扩展为多语言基准——可以被应用到其他代码评估场景。这种思路的核心价值在于：通过控制语言变量，我们可以更准确地评估模型的"编码能力"，而不是"特定语言的编码能力"。
对AI安全的启示
Multi-LCB的数据污染发现对AI安全也有重要启示。如果一个模型在某些不常用的语言上表现异常好，这可能是数据污染的信号。在评估模型真实能力时，我们需要更谨慎地排除这种可能性。Multi-LCB的多语言框架为这种检测提供了天然的工具。
局限性与未来方向
当前局限
Multi-LCB目前主要关注竞赛编程场景。竞赛编程的代码风格和实际工程代码有很大差异——竞赛代码追求简洁和速度，而工程代码需要考虑可维护性、错误处理、性能优化等多个维度。因此，Multi-LCB的评估结果不能直接等同于模型在实际工程中的能力。
此外，Multi-LCB的题目转换过程虽然经过了严格验证，但仍然可能引入微妙的差异。某些题目可能在特定语言上有天然的优势或劣势，这种差异不是因为模型能力不同，而是因为题目本身在不同语言上的"公平性"不同。
另一个局限是评测的计算成本。在12种语言上运行24个模型，计算量是单语言评估的12倍。对于资源有限的研究团队来说，完整的Multi-LCB评估可能成本过高。
未来方向
研究团队计划将Multi-LCB的覆盖范围进一步扩展，纳入更多编程语言，如Scala、Ruby、Lua、Haskell等。这些语言各有独特的编程范式，能提供更多维度的评估信息。
另一个方向是引入更细粒度的评估指标。目前Multi-LCB主要使用通过率（pass@k）作为指标，但未来可以考虑引入代码质量、运行效率、代码风格等更贴近实际需求的评估维度。
此外，研究团队也在探索将Multi-LCB的框架应用到其他类型的代码任务上，如代码调试、代码重构、代码审查等。这些任务同样存在多语言评估的需求，Multi-LCB的方法论可以提供有价值的参考。
总结
Multi-LCB是一项重要的基准测试工作，它将LiveCodeBench从单一的Python评估扩展到了12种编程语言的全面评估。通过对24个大模型的系统测试，Multi-LCB揭示了当前代码大模型的几个关键问题：Python过拟合普遍存在、语言间性能差异巨大、推理模式的提升因语言而异、数据污染的痕迹可以通过多语言对比来发现。
对于模型开发者来说，Multi-LCB指出了训练数据配比的重要性；对于企业用户来说，它提供了更全面的模型选择依据；对于研究社区来说，它展示了多语言评估框架的设计范式。在AI代码生成日益普及的今天，我们需要的不仅是一个"会写Python"的模型，而是一个真正理解编程本质、能在多种语言间灵活切换的通用编码助手。Multi-LCB为衡量这种能力设立了新的标准。
评论