谢赛宁团队新基准让LLM集体自闭,DeepSeek R1、Gemini 2.5 Pro都是零分

标签: 团队 llm 集体 | 发表时间:2025-06-18 18:14 | 作者:机器之心
出处:https://www.jiqizhixin.com/

当前 LLM 与人类大师级水平之间仍存在显著差距。

近年来,LLMs(如 GPT-4、Claude、Gemini 等)在代码生成领域取得了显著进展。它们不仅在经典编程基准(如 HumanEval)中表现出色,甚至在某些测试中超越了人类平均水平。这促使许多研究者开始宣称:LLM 已经胜过人类程序员,尤其是在竞赛编程领域。 

1750213502324.png

更进一步的,在结合了外部工具之后,一些模型(如 o3 和 o4-mini-high)甚至在 Codeforces 平台上获得了超过 2700 的 Elo 评分 —— 这个分数已跻身参赛者前 0.1%。 

然而,这些简单的量化评估,真的能体现模型解决复杂问题的能力吗?我们不妨先问几个问题:LLMs 真的具备与顶级人类选手相当的推理能力吗?模型的高分究竟有多少来自真实的推理能力,又有多少是依赖外部工具的结果?

为了解答上述问题,来自纽约大学、普林斯顿大学等 8 家机构的研究者提出了 LiveCodeBench Pro,这是一个极具挑战性的竞技编程基准测试。

值得一提的是,这项研究有多位参加过国际算法竞赛。例如,作者之一、纽约大学本科生 Zihan Zheng 曾代表学校参加 ICPC 世界总决赛。

LiveCodeBench Pro 收录了 584 道截至 2025 年 4 月 25 日的高质量题目,这些题目均来自 Codeforces 、ICPC 系列赛和 IOI 系列赛等顶级赛事。并且这些问题会不断更新以降低可能的数据污染。

此外,所有题目均由奥赛奖牌选手进行算法类别标注,并对模型生成的失败提交逐行分析。 

image.png

  • 论文标题:LiveCodeBench Pro: How Do Olympiad Medalists Judge LLMs in Competitive Programming? 

  • 论文地址:https://arxiv.org/pdf/2506.11928

  • 项目主页:https://livecodebenchpro.com/

  • GitHub:https://github.com/GavinZhengOI/LiveCodeBench-Pro

本文在 LiveCodeBench Pro 上评估了一系列前沿大模型,包括 Gemini 2.5 Pro、o4-mini-high 和 DeepSeek R1 等。

image.png

基于这套数据和评测框架,本文发现当前前沿模型依然存在显著不足:在没有外部工具支持的情况下,表现最好的模型在中等难度题上的 pass@1 仅为 53%,在高难度题上则完全无法通过(0%),而这些正是人类专家仍能稳定发挥的领域。

image.png

      LiveCodeBench Pro 排行榜

image.png

此外,本文还发现,LLMs 在以实现(implementation-heavy)为主的问题上表现良好,但在处理复杂的算法推理和边界情况分析时表现欠佳,甚至常常生成自信而错误的解释。模型的高分更多是依赖于辅助工具的加持,而非真正的推理能力。

LiveCodeBench Pro 的出现揭示了当前 LLM 与人类大师级水平之间仍存在显著差距。

分析与讨论

在不同算法范式上的表现

发现 1. 大语言模型在知识密集型和逻辑密集型问题上表现更佳,而在观察密集型问题或分类讨论(case work)上表现较差。

image.png

文中展示了 6 个模型在各类编程问题中的表现。研究发现,人类在不同问题标签上的表现更为一致,而模型的评分则因标签不同而显示出更大的差异。主要发现总结如下: 

知识密集型问题是大语言模型的舒适区。 带有如线段树、图论、树和数据结构等标签的问题,在大多数模型上都表现出很高的性能。这些问题通常可以通过拼接众所周知的模板(例如,树状数组、迪杰斯特拉算法、欧拉路径)来解决。这正是大语言模型的优势所在,因为所需的模式会以字面形式出现在其训练数据中,并且生成语法正确的模板对于大语言模型来说比对人类容易得多。 

逻辑密集型问题也取得了同样好的结果。 大语言模型在逻辑密集型类别中也表现出色,例如组合数学、数学、动态规划和二分搜索。这些类别需要更有模式的思维方式(例如,在组合数学中应用组合恒等式,在动态规划中构建状态空间并推导转移函数),并且可以从记忆化的脚手架代码中受益。 

在观察密集型问题上表现不佳。 对于博弈论、特定问题特定分析(ad-hoc)、贪心算法和构造性问题,大多数模型的评分骤降至 1500 以下,明显低于其在知识密集型和逻辑密集型类别中的表现。解决这些问题通常取决于发现新颖的见解,而这是无法仅靠记忆化的代码片段来获得的。 

大语言模型在分类讨论上遇到困难。 有趣的是,所有模型都在分类讨论上表现不佳。除了 o4-mini-high 之外,每个模型的评分都低于 1500 分,即便是 o4-mini-high,其表现在此类别中也远逊于其他问题类别。人工检查显示,无法识别和处理边界情况是所有模型的一个突出失败模式。 

交互式问题暴露了模型的显著弱点。 在交互式问题上,o4-mini-high 的评分骤降至 1500 左右,其他模型也表现挣扎。论文附录中讨论了这种糟糕表现背后的可能原因,并指出了 o3-mini-high 在解决交互式问题时出现的异常行为。 

失败原因诊断及与人类的比较

发现 2. o3-mini 在算法逻辑错误和错误观察方面比人类多得多,但在实现逻辑错误方面则少得多。

研究人员专门使用可读性最佳的模型 o3-mini 进行标注和深入分析,并在图 3 的树状图中展示了结果。

image.png

概念性错误是模型失败的主要原因。「思路错误」分支内最大的红色区块显示,在 125 个标注问题中,o3-mini 比人类参赛者多犯了 34 个算法逻辑错误。这些是真正的概念性失误,而非表面的程序错误。 

实现是模型的强项。 与底层编码相关的指标通常对 o3-mini 有利。例如,在 125 个标注问题中,o3-mini 比人类少犯了 25 个实现逻辑错误。值得注意的是,所有观察到的初始化错误和输入输出格式错误都出现在人类提交的代码中。评测结果细分也证实了这一点:o3-mini 几乎没有出现「运行时错误」,突显了其在实现层面相对不易出错。 

一个显著的例外 —— 空闲时间超限。「评测结果」下的一个深红色矩形显示「空闲时间超限」的判罚激增。这源于 o3-mini 在交互式问题上的奇特行为,其大多数提交都被判为「空闲时间超限」。

在示例输入上失败。 树状图突出显示,在「示例失败」类别中,o3-mini 的实例数多出了 45 个,这些情况下解决方案能够编译,但在问题的示例输入上就已经失败。与人类不同,o3-mini 无法在提交前在本地编译或运行示例输入。拥有终端和工具调用能力(例如 o3 和 o4-mini-high)的模型,预计会少犯很多这类容易发现的错误。 

总而言之,该分析表明,大语言模型的代码在语法上通常更可靠,但在构建正确算法或从问题中提取正确观察所需的高层次推理方面存在困难。虽然正式标注仅涵盖了 o3-mini 的提交,但初步的人工检查表明,大多数现有的大语言模型都存在相同的错误模式。 

多次尝试(Pass@k)对模型性能的影响

发现 3. 增加尝试次数(pass@k)能显著提升模型性能,但在高难度问题上仍然会失败。

OpenAI 报告称,具备终端访问权限和 pass@k 的 o4-mini 在 Codeforces 上的 Elo 评分为 2719,这与对 o4-mini-high 的评估(无终端访问权限,pass@1)所获得的 2116 分形成对比。这种差异促使研究人员去研究终端访问和工具调用的性能影响,以及允许多次尝试(pass@k)的效果。

image.png

如图 4 所示,随着 k 值的增加,模型的评分显著提高。例如,o4-mini-medium 的评分从 pass@1 时的 1793 分上升,并在 k 增加到 10 时收敛至 2334 分。o4-mini-low 和 o4-mini-high 也观察到类似的上升趋势。虽然多次尝试带来的这些增益是显著的,但收敛后的评分仍然比报告的 2719 分低了大约 400 分。因此,可以推测,剩余的差距主要归因于工具调用和终端访问带来的好处。

image.png

如图 5 所示,可以观察到在改进最大的五个类别中,有三个 —— 博弈论、贪心算法和分类讨论 —— 属于观察密集型问题,通常可以通过假设结论来解决。更高频率地进行有根据的猜测,会大大增加正确解决这些问题的概率。 

推理模型与其非推理对应模型的比较

发现 4: 推理能力在组合数学中带来最大提升,在知识密集型类别中提升较大,而在观察密集型类别中提升相对较小。

研究人员考察了在大语言模型中启用推理能力对每个问题标签的影响。具体来说,他们直接比较推理模型及其非推理对应模型,以便控制模型架构、训练数据和其他外部因素的变化,从而分离出推理的真正效果。

这种分离对于展示额外的思维链或测试时扩展方法对模型在各问题标签上的解决问题能力的真实影响至关重要。研究特别选择比较 DeepSeek V3 与 R1,以及 Claude 3.7 Sonnet 的非思考(Non-thinking)与思考(Thinking)版本,如图 6 所示,这是两款主流前沿模型,均有非推理版本和推理对应版本。

image.png

主要发现总结如下:

在组合数学中提升最大:两个模型都在组合数学中显示出最大提升,其中 DeepSeek-R1 的评分比 V3 高出近 1400 分。

在知识密集型类别中提升较大:对于数据结构和线段树等知识密集型问题,启用推理也带来了较大提升(例如,在 DeepSeek 上,线段树问题的评分提升了约 700 分;在 Claude 上,数据结构问题的评分提升了约 500 分)。这是符合预期的,因为这些类别中的问题通常涉及结构化思维。

在观察密集型类别中提升有限:有趣的是,对于博弈论、贪心算法、特定问题特定分析和构造性问题 —— 这些通常需要大量观察且大语言模型经常遇到困难的领域,即使启用推理也只带来微乎其微的提升(例如,对于 DeepSeek,在博弈论上的提升几乎是最低的;而对于 Claude,则是负提升)。这就提出了一个问题:当前的思维链方法对于这些类型的问题是否存在固有的局限性?或者是否存在一个涌现阈值 —— 即推理能力发展到某个点后,最终可能会在这些领域解锁显著的性能增益。

相关 [团队 llm 集体] 推荐:

谢赛宁团队新基准让LLM集体自闭,DeepSeek R1、Gemini 2.5 Pro都是零分

- - 机器之心
当前 LLM 与人类大师级水平之间仍存在显著差距. 近年来,LLMs(如 GPT-4、Claude、Gemini 等)在代码生成领域取得了显著进展. 它们不仅在经典编程基准(如 HumanEval)中表现出色,甚至在某些测试中超越了人类平均水平. 这促使许多研究者开始宣称:LLM 已经胜过人类程序员,尤其是在竞赛编程领域.

通向AGI之路:大型语言模型(LLM)技术精要 - 知乎

- -
ChatGPT出现后惊喜或惊醒了很多人. 惊喜是因为没想到大型语言模型(LLM,Large Language Model)效果能好成这样;惊醒是顿悟到我们对LLM的认知及发展理念,距离世界最先进的想法,差得有点远. 我属于既惊喜又惊醒的那一批,也是典型的中国人,中国人善于自我反思,于是开始反思,而这篇文章正是反思的结果.

《史蒂夫·乔布斯传》翻译团队集体亮相译言

- 万俟尘 - 译言-每日精品译文推荐
2011年7月,东西网和译言网刚刚合并,初具全球最大的中文译者社区的规模. 中信出版社找到我们,希望以“众包”模式翻译《史蒂夫·乔布斯传》并在全球范围内招募译者. 招募页面上线仅一周,报名人数即达到400余人. 考虑这本书的独特性,要求译者的综合素质而不仅是英文水平. 这本书内容时间跨度大,涉及历史、人文、社会、信息技术和苹果产品等多方面的信息和知识点,加之广大读者对此书有着很高的期待,所以让尽可能多的优秀译者参与进来,再从中选择最合适的人选.

GPT-4被曝重大缺陷,35年前預言成真!所有LLM正確率都約等於0

- - Futubull - Headlines
最近,一项研究发现,大模型身上存在一种「逆转诅咒」,即使学会「A是B」,它们也无法推理出「B是A」. 大语言模型,竟然存在一种「逆转诅咒」. 所谓逆转,也就是说,一个训练于「A是B」的语言模型能否推广到「B是A」呢. 例如,当我们教会一个模型「乔治·华盛顿是美国第一任总统」后,它能否自动回答「谁是美国第一任总统.

团队

- Lorna - 坏脾气的小肥
我最近心情起落比较大,如果把时间线再拉长一点,则是去年多自负,今年多自责. 冷静下来的时候也会想,我能不能做得更好. 每一个团队都有它的长处,有它的短处,对于团队的缺陷首先要问自己几个问题:. 1、有没有激励大家全心全意地认同和投入这个项目. 2、有没有分工合理,使每个人认同和投入自己的任务. 3、他的缺陷是否可以通过工作指导、严格督促,在半年或一年时间里自我完善.

团队管理101招

- 狂之想 - C++博客-牵着老婆满街逛
转载自:http://www.iteer.net/modules/doc/article.php?storyid=1402. 无论你是新手还是资深管理人,对你而言,管理好团队都是重要且具激励性的挑战. 切记:每位成员都能为团队作出一些贡献. 谨慎地设定团队目标,且认真严肃地对待它们. 尽早决定何种形态的团队适合你的目标.

DBA团队的使命

- 2sin18 - Alibaba DBA Team
DBA团队的使命:提供高可用、高性能、可扩展的数据存储服务. 高可用:可用性是运维的根本,我们不管做什么事情,都要把可用性放在第一位. 高性能:对性能的关注是我们一直坚持、做的最好的一面,仍需要继续做到极致. 可扩展:也就是最适合的,易部署,可线形透明伸缩. 数据存储:不只是关注某个数据库本身,是基于对各种最先进的数据存储技术的精深理解,提供最专业的服务.

谈团队知识管理

- - 人月神话的BLOG
如果要谈学习型团队,那么团队知识管理就相当重要,团队知识管理介于企业知识管理和个人知识管理之间,核心是知识能够成为整个团队的资产,并为团队创造价值. 今年在团队知识管理上,重点就是按照cmmi的一些思路,形成指导书,规范流程,工具模板,培训教材,检查单的完整知识库积累. 明确各个岗位职责和分工边界,能够按着规范流程做事情,大量前期积累的知识库又能够帮助团队成员快速的学习和解决问题.

谈技术团队目标

- - Tim[后端技术]
技术主管新年想得最多的一件事必定是如何比上一年做得更好. 宏大的目标设定每个团队都会做,谈几个不引人注意的小问题. 见过一些技术团队将计划定义为“按时完成需求”,需求驱动并没有什么不对,但是研发工作仅考虑被动需求的话是很难做好. 之前完成的许多需求有什么共性. 经常出问题/bug/故障的项目/功能/模块是哪些.

团队沟通杂感

- - 人月神话的BLOG
随时随地的短时间的,快速迭代的培训和教练作用远远大于正规的系统培训. 系统性培训一个是针对性往往弱,另外一个就是对团队成员有较高的要求,即自我强烈的系统性学习欲望. 走动时管理目的是及时的发现各种问题和团队技能之欠缺点,有针对性的进行沟通和经验传递,这需要团队管理者有敏锐的洞察力,不能脱离到团队工作事务之外.