入门 11 分钟概念

HumanEval 已终结：理解 LLM 代码基准测试的含义在 2026

您正在比较两个代码 LLM，第一个宣称在 HumanEval 上得分为 92%，第二个为 94%。这个数字几乎无法说明什么：HumanEval 已饱和数月，几乎所有近期模型的 pass@1 都超过了 90%。本指南解释了为什么这一历史基准已无法区分模型表现、已成为新标准的 SWE-bench Verified 和 LiveCodeBench 实际衡量什么，以及如何在安装开放权重模型之前解读其得分。

作者： Mohamed Meguedmi·更新于 2026-08-24·已在 Windows、macOS 和 Linux 上测试

#为什么 HumanEval 已被淘汰

HumanEval 是 LLM 发展史上被引用最多的代码基准测试。它由 OpenAI 于 2021 年发布，曾连续四年作为参考标准。问题在于：到了 2026 年，它已经饱和。表现最好的开放权重代码模型在该测试中的“pass@1”达到 96% 至 98%，也就是说，它们第一次尝试就能解决几乎所有题目。当所有人都拿到 20/20 的满分时，分数就无法再区分高下。

一个饱和的基准测试已无法反映进步：它更多反映的是噪声。两个模型之间96%到98%的差距，可能仅源于一百个练习中的三个，这些练习往往模糊或表述不当。这不是能力差异，而是误差范围。2026年仍仅依据HumanEval分数选择代码语言模型，就如同在十米短跑中比较长跑选手的排名。

i
什么是pass@1？
« pass@1 » 表示：模型对每个问题仅生成一条回答，统计解决问题的百分比。同时也有 pass@10（进行十次尝试，保留最佳结果），更为宽容。实际应用中，始终应对比使用相同 k 值测得的分数：pass@10 永远不能与 pass@1 直接比较。

并不是 HumanEval 变差了，而是模型已经超出了它所能衡量的范围。它仍可用于回归测试——一个得分跌至 70% 的模型确实存在问题——但已无法用来区分顶尖模型。

#HumanEval 实际测量的是什么

本地 AI 套件

只需 1 小时，即可在您的电脑上拥有专属的免费 ChatGPT — LM Studio、Ollama、Open WebUI、您的文档，无需云端。

  • 在线空间，终身可用
  • PDF + 文件
  • 30 天内退款
本地 AI 套件 →或 所有套件终身使用权 — 49 € →

理解为何 HumanEval 会饱和，需查看其实际测试内容。该基准测试包含 164 个小型 Python 编程问题。每个问题提供函数签名和描述预期行为的文档字符串；模型需编写函数体，随后由一组隐藏的单元测试进行验证。

格式
164个独立的Python函数待完成，每个函数均配有文档字符串和单元测试。
任务的性质
基础算法：处理列表、字符串，少量数学运算。每个问题仅需一个函数即可解决，无外部依赖。
测试内容
将简短且无歧义的规格说明转化为正确代码的能力。这是课堂练习，而非实际工作任务。
它不测试哪些能力
在现有仓库中导航，读取多个文件，理解已有的代码，修复真实缺陷，编写测试用例，管理依赖项。换句话说：真正的开发工作。

差距就在这里。根据清晰的需求描述编写一个独立函数，是 2026 年的模型已经掌握的任务。开发者——或连接到您编辑器的本地代码助手——真正要做的工作，是修改一个已有数千行代码的仓库。这正是新一代基准测试试图衡量的能力。

#SWE-bench Verified 解读

SWE-bench 是取代 HumanEval、成为严肃评测参考的基准测试。它的思路截然不同：不再使用玩具式练习题，而是从 Django、scikit-learn、Flask、sympy 等热门开源 Python 项目中提取真实的 GitHub“issue”。模型会收到完整的代码仓库和待修复 bug 的文字描述。它必须生成一个补丁，也就是 diff，真正解决这个问题。

修复结果不由人工或另一个模型评判：补丁会应用到代码仓库，然后运行项目的测试套件。如果原先失败的测试通过了，而原先通过的测试仍然通过，就说明问题已解决。这是一个客观且贴近实际工作的标准。

→
为什么采用“Verified”版本？
原始 SWE-bench 包含无法解决或描述不清的问题：测试过于严格，题目说明不完整。2024 年，OpenAI 发布了 SWE-bench Verified，这是一个由 500 道经人类开发者审阅并验证的问题组成的子集。应关注这一版本：未注明具体版本的“SWE-bench”分数往往来自旧版，不能与此版本直接比较。
SWE-bench Verified
500个经人工验证的问题。当前用于比较模型在真实Bug修复任务上表现的标准。
SWE-bench Lite
300 个更简单、评估成本更低的问题。适用于快速测试，但判别能力较弱。
SWE-bench 全量
超过 2000 个问题，其中部分存在缺陷。评分偏低且噪声较大，不建议用于对比。

这些数量级足以说明难度。在 HumanEval 上，成绩最高达到 98%；而在 SWE-bench Verified 上，最好的智能体模型达到 60% 至 70%，可在本地安装的优秀开放权重模型则更接近 40% 至 55%。终于有了提升空间，也就有了区分模型高下的余地。

!
SWE-bench 得分取决于智能体的工具框架
SWE-bench 并不只是测试原始模型：它测试的是模型在智能体中的表现（智能体的工具让模型能够读取文件、运行命令并反复迭代）。同一个模型的得分可能因使用的智能体不同（Aider、OpenHands、SWE-agent 等），从 35% 变为 50%。比较时务必使用相同的智能体工具框架，否则比较的就是智能体，而不是模型。

#LiveCodeBench 与污染问题

SWE-bench 衡量在真实代码中修复 bug 的能力。LiveCodeBench 针对的是另一个问题：数据污染。其原理就体现在名称中的“live”（实时）一词里。该基准持续收集新的编程竞赛题目（LeetCode、AtCoder、Codeforces），并为它们记录时间戳。这样，就可以只用模型训练日期之后发布的题目来评估模型。

这一点至关重要。如果某个问题在模型训练前就已出现在互联网上，那么模型在训练过程中可能见过其解决方案。此时，模型的得分反映的就不是推理能力，而是记忆。通过按日期筛选，LiveCodeBench确保模型解决的是它此前不可能见过的问题。

性质
带有时间戳、持续更新的竞赛编程题目。
时间切分
选择一个晚于被测模型训练时间的日期范围。这样就不可能发生测试数据泄漏。
它所衡量的指标
针对全新问题的纯算法推理——与 HumanEval 的设计理念相近，但没有饱和与污染问题。
解读时的注意事项
务必检查公布的评测日期范围。如果 LiveCodeBench 的评测日期范围早于模型发布，其得分就没有参考价值。

LiveCodeBench和SWE-bench是互补关系，而非竞争关系。前者评估模型在新问题上的算法推理能力；后者则测试其在真实代码仓库中的操作能力。一个优秀的代码大模型必须在两者上都表现良好——算法能力强但无法在项目中实际操作的模型，无法胜任日常开发助手的角色。

#用通俗的话说明数据污染问题

数据污染正是需要警惕公布分数的关键原因。LLM 的训练数据涵盖海量网络内容，包括 GitHub。如果基准测试的题目和解答出现在网上，它们很可能最终进入训练数据。模型不再是在解题，而是在背诵。

一个值得警惕的信号：某个模型在老旧的静态基准测试中遥遥领先，却在“实时”或刚发布的基准测试中回到普通水平。两者的差距可以很好地衡量分数中有多大一部分来自记忆。这正是 LiveCodeBench 旨在揭示的问题。

i
为什么“私有”基准测试越来越普及
为杜绝污染，越来越多的评测将题目保密（不公开测试集），只公布排行榜。从未见过的内容不会造成污染。代价是：结果无法核验，必须信任维护排行榜的人。没有任何方法是完美的，因此有必要交叉参考多个来源。

#解读本地模型的分数

当您查看开放权重模型的模型卡（在 Hugging Face 上或厂商的公告中）时，代码评测得分几乎总会被突出展示。以下是解读这些信息的判断框架，帮助您避免被误导。

  1. 01
    确认基准测试的精确版本
    「SWE-bench」单独来看毫无意义。请查找「Verified」。对于 LiveCodeBench，需同时查找版本（v5、v6 等）和时间窗口。缺少这些细节，该数值无法与其他数据进行比较。
  2. 02
    检查pass@k
    pass@1 和 pass@10 绝不能拿来比较。厂商有时会展示两者中更好看的那个指标。如果没有明确说明，应按最坏的情况估计实际使用效果：日常使用中，重要的是第一次回答。
  3. 03
    确认 SWE-bench 所用的智能体框架
    SWE-bench 得分与取得该得分的智能体密不可分。“使用 OpenHands 达到 52%”并不等同于“使用 Aider 达到 52%”。如果发布方没有说明所用的智能体，这个数字就很难用于判断。
  4. 04
    警惕自行发布的评分
    模型卡上的数据来自厂商，厂商希望其表现良好。请寻找独立验证（公开排名、第三方文章）。从未被复现的分数仍属于商业宣传。
  5. 05
    至少对比两个基准测试
    模型在各项测试中都表现出色，是一个好迹象；如果某个模型只在一项基准测试中表现突出，在其他测试中却表现不佳，就可能意味着它针对特定测试做了专门优化，或存在数据污染。
→
唯一真正重要的基准测试
任何排名都无法替代在您自己的代码上进行的测试。将模型安装到本地，给它三四项能代表您实际工作的任务——修复您仓库中的一个 bug、按您的风格编写一个函数、审查一次 diff——再根据实际结果作出判断。三十分钟的测试胜过一张评分表。

#选择编程 LLM 时应关注哪些基准测试

根据您对本地助手的期望，相关基准测试会有所不同。以下是按使用场景进行优先级排序的方式。

智能体助手（Aider、Cline、Continue）
优先看 SWE-bench Verified。这是最接近“独立修改我的代码仓库”的基准测试。智能体的实际价值正是体现在这里。
自动补全与小型函数
使用 LiveCodeBench，并辅以 HumanEval 作为把关手段。对于边输入边补全代码的任务，算法推理比项目导航更重要。
从零开始生成代码
LiveCodeBench（针对新问题的推理）；如果您不只用 Python 编程，还应结合多编程语言基准测试进行评估——HumanEval 和 SWE-bench 都非常侧重 Python。
代码审查与错误检测
公开基准测试对这方面的覆盖较少。SWE-bench 仍是最好的间接评估依据，但在这里，必须针对您自己的代码改动进行自建测试。
!
偏向 Python 的评测偏差
HumanEval、SWE-bench以及LiveCodeBench中的很大一部分测试主要针对Python。如果您使用Rust、Go、TypeScript或C++编程，在这些基准测试中取得优异成绩，也不能保证模型在您所用语言上的表现。请寻找多语言版本（MultiPL-E、HumanEval-X），或直接在您的技术栈中测试。

#需避免的常见误区

比较不同的 k 值
pass@1 与 pass@10：这是最常见的比较错误。后者会因 k 更大而使分数偏高。得出结论前，务必统一 k 值。
忽略量化
公布的分数是在全精度（BF16/FP16）下测得的。本地运行时，您会使用 Q4_K_M 或 Q5_K_M 量化版本，质量会略有损失。在 FP16 下 SWE-bench 得分为 50% 的模型，量化后表现会稍逊一筹。
把基准测试当作最终目标
专门为通过基准测试而优化的模型（“基准测试刷分”）在实际代码任务中可能表现不佳。分数只是参考，并非保证。
忽略基准测试日期
如果 LiveCodeBench 得分所用的评测时间窗口早于模型训练时间，该得分很可能受到数据污染。务必检查时间窗口是否晚于模型训练时间。
混淆模型与智能体
“这个模型在 SWE-bench 上取得 55% 的成绩”，往往隐含着“这个模型在这个特定智能体中运行”的前提。换一个智能体，分数就会变化。

#深入了解

掌握基准测试的评估框架后，下一步是选择并安装一个模型，然后在您自己的代码上进行测试：

2026 年最适合编程的本地 LLM
我们对可自主部署的代码模型（Devstral、Qwen3-Coder 及其替代方案）的对比评测，包含评分、所需VRAM以及根据您的GPU选择推荐方案。
选择量化方案（Q4、Q5、Q8、FP16）
了解模型转为 Q4_K_M 后会损失多少质量——也就是公布的得分与您实际运行的模型表现之间的差距。
安装 Ollama（Windows、macOS、Linux）
这是在本地通过 11434 端口测试代码模型，并在几分钟内将其接入编辑器的前提。
这份指南对您有帮助吗？

有反馈、发现了错误，或想补充说明？请告诉我们，让这份指南对每个人都更有帮助。