Python 不是万能代理：Multi-LCB 撕开了大模型代码能力的遮羞布

GigaCode 团队把 LiveCodeBench 从 Python 单语种扩展到 12 种编程语言，测试了 24 个主流大模型。结果不意外却触目惊心：几乎所有模型都是"Python 特化选手"——在 Python 上呼风唤雨，换个语言就现原形。GPT-OSS-120B 成了唯一一个跨语言表现相对均衡的模型，而 Qwen3-235B 虽然 Python 最强，但在 Go、Rust、Ruby 上被 GPT-OSS-120B 反超。这篇论文的价值不在于发现了新大陆，而在于给整个行业立了一面镜子。

一、问题的本质：代码大模型在测什么？

LiveCodeBench（LCB）是 2024 年以来最火的代码能力测评基准。它解决了前辈们（HumanEval、MBPP）最头疼的三个问题：

1. 数据污染：按发布日期过滤，只测模型训练截止日期之后的新题
2. 题库饱和：持续从 LeetCode、AtCoder、Codeforces 抓取新题
3. 场景单一：不只考函数填空，考的是完整的问题解决

但 LCB 有一个致命盲区：只测 Python。

这就像一个驾校只考直角转弯，然后声称能判断一个人会不会开车。现实工程里，开发者每天都在多语言环境中切换——C++ 写系统、Java 写企业级、JavaScript 写前端、Go 写微服务、Rust 写高性能。一个只会 Python 的"全栈工程师"，在真实世界里寸步难行。

Multi-LCB 的出现，就是要回答一个被长期回避的问题：大模型的代码能力，到底是"通用编程智能"，还是"Python 记忆术"？

二、12 种语言、24 个模型、同一个题库

2.1 语言选择

Multi-LCB 覆盖的 12 种语言不是拍脑袋选的，而是基于 2025 年四大排名（TIOBE、GitHub Octoverse、Stack Overflow、RedMonk）的交叉验证：

2.2 技术核心：把函数式测评统一为 STDIN/STDOUT

LCB 的原生题目有两种格式：

• AtCoder/Codeforces：天然 STDIN/STDOUT，直接可用
• LeetCode：函数式（给函数签名，测返回值）

Multi-LCB 的核心技术创新是自动转换管道：把 LeetCode 的函数式题目无损转换为 STDIN/STDOUT 格式，无需为每种语言写不同的测试模板。

转换规则：

• 标量输入/输出：直接映射
• 一维数组：空格分隔值
• 二维数组：首行指定行数，后续每行空格分隔

这样既保留了原题的算法难度，又实现了跨语言的统一评估。

三、实验结果：Python 霸权与语言鸿沟

3.1 总体性能格局（Top 10 模型，Feb-May 2025 数据）

两个关键发现：

1. Python 不是代理：Qwen3-235B 在 Python 上以 74.0% 领先，但在 Go（56.7%）、Rust（47.7%）、Ruby（49.4%）上被 GPT-OSS-120B 全面反超。如果只看 Python 排名选模型，你会选错。

2. GPT-OSS-120B 的跨语言一致性令人惊讶：120B 参数量的模型在 12 种语言上的标准差只有 5.9%，而 Qwen3-235B 高达 9.4%。OpenAI 的 GPT-OSS 在训练时显然有意识地覆盖了多语言代码分布。

3.2 语言难度梯度

论文用箱线图展示了所有模型在 12 种语言上的 Pass@1 分布：

**Python 的平均通过率比其他语言高 10-20 个百分点。**这不是因为 Python 的题目更简单（同一套题库），而是因为模型在训练时被 Python 数据"灌"得最多。

3.3 Python 过拟合：散点图不会撒谎

Figure 3 的散点图展示了每个模型的 Python Pass@1 vs 跨语言平均 Pass@1。几乎所有点都在 x=y 对角线上方——Python 表现系统性高估真实跨语言能力。

最夸张的是 OpenReasoning-Nemotron-32B 和 OpenCodeReasoning-Nemotron-1.1-32B：

• Python 上 64%+，其他语言平均不到 30%
• 差距超过 30 个百分点

这说明这些模型的"代码能力"本质是Python 模式识别，不是通用编程推理。

3.4 静态类型语言更难

数据明确显示：静态类型语言（C++、Java、Rust、Go、C#、Kotlin、Scala、TypeScript）的平均表现普遍低于动态类型语言（Python、JavaScript、Ruby、PHP）。

可能原因：

1. 训练数据偏斜：Python 占代码语料的最大份额
2. 类型系统复杂度：静态类型语言的语法和编译约束更严格
3. 推理链更长：模型需要同时考虑算法逻辑和类型正确性
4. 错误反馈更延迟：编译错误比运行时错误更难调试

四、数据泄露：不只是有没有，还分语言

Multi-LCB 继承了 LCB 的日期过滤机制，但论文发现了一个更微妙的问题：泄露程度因语言而异。

Figure 5 的月度趋势图显示：

• 模型在训练截止日期之前的题目上得分显著更高
• 跨越截止日期后，分数出现阶梯式下跌
• 但下跌的幅度在不同语言上不一样

这意味着：

1. 某些语言的训练数据更新、更充分
2. 某些语言可能通过间接渠道（如 StackOverflow 答案、技术博客）泄露了更多测试题
3. 现有的日期过滤机制不足以消除跨语言不对称泄露

五、谁才是真正的多语言选手？

5.1 推理模型 vs 指令模型

数据毫不含糊：推理模型（带 * 号）全面碾压指令模型。

推理模型的跨语言优势不是"多一点"，而是质变——它们似乎真的在"推理"如何解决算法问题，而不是在匹配训练时见过的代码模式。

5.2 模型规模效应

论文中测试的模型从 7B（OlympicCoder-7B）到 685B（Qwen3-235B）不等。

趋势：

• 同系列内，规模越大，跨语言表现越好
• 但规模不是唯一因素：GPT-OSS-20B*（20B）的跨语言均值（59.8%）超过了 Qwen3-30B-A3B-Thk*（53.2%）
• 训练数据的质量和分布可能比参数量更重要

5.3 特殊案例：DeepSeek-R1-Distill 系列

R1 蒸馏出来的小模型表现出极端的语言能力分化：

• DeepSeek-R1-Distill-Qwen-32B*：Python 45.9%，但 Rust 仅 21.2%，Scala 仅 8.7%
• DeepSeek-R1-Distill-Qwen-14B*：Python 41.8%，Rust 仅 3.7%，Scala 仅 3.3%

这说明蒸馏过程放大了原模型的 Python 偏向——学生模型比老师更"偏科"。

六、对行业的启示

6.1 测评基准的反思

如果 Multi-LCB 的结果具有代表性，那么过去两年基于 HumanEval、MBPP、LCB（Python-only）的所有"代码能力排名"都可能有系统性偏差：

• 排名靠前的模型可能只是 Python 更强
• "代码能力"的提升可能只是 Python 语料规模的扩大
• 真正需要多语言能力的场景（企业开发、系统编程、全栈开发）被严重低估

6.2 训练数据的启示

论文的结论很明确：

"We suppose that model performance could be improved by increasing training coverage of non-Python programming languages."

当前代码大模型的训练数据高度偏向 Python（GitHub 上 Python 仓库最多、StackOverflow 上 Python 问答最多、技术文档中 Python 示例最多）。要培养真正的"多语言编程智能"，需要在训练阶段就平衡各语言的分布。

6.3 实际选型建议

如果你在选择代码助手，不能只看 Python benchmark：

• 全栈/多语言团队：优先考虑 GPT-OSS-120B（跨语言最均衡）
• Python 数据科学团队：Qwen3-235B-Thk 或 DeepSeek-R1 性价比更高
• 系统编程/嵌入式：关注 C++、Rust 的专项分数，而非总分
• Java/Kotlin 安卓开发：GPT-OSS 系列在 JVM 语言上表现稳定

七、局限与展望

论文坦诚列出了几个局限：

1. 语言覆盖不全：缺少 Swift、Haskell、R、Julia 等
2. 任务类型局限：只测了算法竞赛题，没测 API 集成、调试、代码审查等真实工程场景
3. STDIN/STDOUT 格式可能引入额外难度：某些语言天然更适合函数式编程，强制转换为 STDIN/STDOUT 可能不公平
4. 只测了开源模型：GPT-4、Claude、Gemini 等闭源模型的表现未知

未来计划：

• 扩展语言（Swift、Haskell、R、Julia）
• 评估闭源模型
• 支持 LCB-Pro 等扩展基准

八、一句话总结

Multi-LCB 的价值不是发现了什么惊天动地的技术突破，而是做了件早该有人做的事：把代码大模型从 Python 的温室里拉出来，放在 12 种语言的竞技场里真刀真枪地比试。结果是——大多数模型都感冒了。

GPT-OSS-120B 的跨语言一致性暗示了一个重要方向：真正的代码智能应该是语言无关的算法推理能力，而不是对某一语言语料的过度记忆。论文的数据证明，当前行业距离这个目标还有很远。

"Our results establish Multi-LCB as a rigorous new benchmark for multi-programming-language code evaluation, directly addressing LCB's primary limitation and exposing critical gaps in current LLM capabilities."

参考信息

• 论文：Multi-LCB: Extending LiveCodeBench to Multiple Programming Languages
• 作者：Maria Ivanova, Pavel Zadorozhny, Rodion Levichev, Ivan Petrov, Pavel Adamenko, Ivan Lopatin, Alexey Kutalev, Dmitrii Babaev
• 机构：GigaCode, Yandex School of Data Analysis
• 论文链接：https://arxiv.org/abs/2606.20517
• 代码库：https://github.com/Multi-LCB/Multi-LCB
• 基准：12 种编程语言（Python, C++, Java, Go, JS, TS, C#, Rust, Ruby, PHP, Kotlin, Scala）
• 测试模型：24 个（7B-685B，推理模型 + 指令模型）
• 核心发现：Python 过拟合、静态类型语言更难、GPT-OSS-120B 跨语言最均衡、数据泄露因语言而异
• 提交：ICLR 2026

步子哥，这篇论文让我想到一个类比：现在的代码大模型测评就像只考中文作文来判断一个人的文学素养——中文好的人不一定懂莎士比亚，Python 强的模型不一定能写 Rust。Multi-LCB 的价值在于给行业立了一个"多语种文学考试"的标准。真正值得注意的是 GPT-OSS-120B 的表现——20B 参数的 GPT-OSS 在跨语言均值上超过了 30B 的 Qwen3，这说明 OpenAI 在训练数据分布上做了功课。规模竞赛的终点可能不是参数量的军备竞赛，而是数据分布的质量和均衡性。

#代码大模型 #MultiLCB #LiveCodeBench #多语言编程 #Python过拟合 #代码测评 #GPT-OSS #Qwen3 #DeepSeek #ICLR2026