williamliu.ai
EN中文
← 返回文章

高分不等于好分：一年 AI 评估带来的反思

有用的 AI 评估需要在一致条件下比较版本，追踪失败模式，并持续提高任务、运行框架和验收标准的要求。

8 分钟读完
  • AI 评估
  • 软件质量

要点速览

  • 🚨 90%+ 的得分往往是警讯：你的评估可能变容易了。

  • 📈 提升 5 个百分点，比孤立的 95% 得分更有意义。

  • 🧪 应在同一运行框架下比较模型版本，而不是对着固定的分数目标评估。

  • 🔍 失败模式比最后那个醒目的总分更重要。

  • ⚙️ 评估是一套质量体系：模型质量与运行框架质量必须共同演进。

  • 🏁 没有哪个模型能赢下所有基准测试。

过去一年，我花了大量时间评估生产环境中的生成式 AI 产品，并把新的前沿模型与现有基线放在一起对比。这些亲身实践改变了我看待基准测试分数的方式。

我仍然认为，提升五个百分点可以很有意义。但意义只存在于具体背景中。在相同任务、相同运行框架和相同评分规则下，模型从 A 版本到 B 版本提升 5 个百分点，可能说明它确实进步了。缺少这些背景，孤立的 93% 或 97% 得分能告诉我的就少得多。

这就是核心观点：

单看绝对分数，没有意义。

重要的是比较，是版本之间的变化，是失败模式的变化。只盯着一个门槛追分，往往会让团队误以为过线就代表质量可靠。

📈 关注相对进步，放下对门槛的崇拜

在不少团队里，评估被简化为一个目标：“超过 X%。”听起来很务实，却往往引出错误的行为。一旦人们围绕一个固定门槛做优化，就会围着测量方法调参，而不是改善系统。

实际比较模型时，我不太在意某个模型的分数够不够“高”，更在意相同条件下，它与上一版本相比究竟变了什么。相同的提示词、相同的工具、相同的重试策略、相同的评判标准。如果新模型在这套条件下有实质改善，那就是有用的证据。如果它只是在另一套假设不同的基准测试上显得不错，就不该有太强的信心。

这与 HELM 提出的更广泛评估建议一致：模型在不同场景下的行为有明显差别，因此应进行多维度报告，而不是简化成一个数字。斯坦福大学（Stanford University）《2026 年 AI 指数报告》的技术表现章节把问题说得更尖锐：“原本预期能保持多年挑战性的评估，几个月内就达到饱和，压缩了基准测试能够有效追踪进展的时间窗口。”

🚨 极高的分数往往是警讯，未必值得庆祝

90%+ 的分数看起来像胜利。

但在实际运行中，它往往提示你该检查评估本身了。🚨

当测试这么容易时，通常有两种情况：模型的能力确实远超这个任务的要求，或者评估已不足以区分你做决策所关心的差异。在生产环境中，第二种情况很常见。数据变旧，标准变松，边界情况消失。指标上升了，现实风险却还在。

MMLU 曾是通用知识基准测试的标准，如今前沿模型在它上面的得分已超过 88%，趋于饱和，无法再清晰区分领先系统。数据污染和基准测试饱和已经成为核心关切。如果基准测试内容或非常相近的变体泄漏到训练数据中，总分就可能虚高，而真正的泛化能力并未变化。《调查现代大语言模型基准测试中的数据污染》（Investigating Data Contamination in Modern Benchmarks for Large Language Models）展示了这一点。

对此，新一代基准测试开始持续更新，并把防范数据污染纳入设计。LiveBench 每月增加新题。LiveCodeBench 从 LeetCode、Codeforces 和 AtCoder 获取新的编程题。LiveCodeBench Pro 则引入奥林匹克竞赛奖牌获得者的判断，把难度进一步提高。

Humanity's Last Exam 原本是为了替代已经饱和的学术基准测试而设计的更高难度评估。然而，即便是 HLE，最高分也从 2025 年 1 月的 8%，升到了 2026 年 4 月的 50% 以上。这提醒我们，今天的高难度基准，明天就可能变成排行榜上的表演。

所以，进步当然值得庆祝。

但当分数接近上限时：少一点庆祝，多一点调查。

🔍 评估最重要的产出是发现失败，而不是报告分数

很多团队把评估当成一条报告流水线：得出数字，做个仪表盘，然后继续往前走。在生产环境中的生成式 AI 系统里，这错过了评估最有价值的产出。

最有价值的产出，是你及时发现、来得及修复的那些失败模式。

真实系统中的问题，很少只是“答案错了”。

更常见的是：

  • 脆弱的工具调用序列

  • 过度自信的误报

  • 部分工具失败后，恢复能力薄弱

  • 提示词稍有扰动，行为就不稳定

  • 看似有益的模型升级之后，悄无声息地出现退化

一个标量分数不会告诉你，这些失败类型藏在哪里。

行为测试方法多年来一直在强调这一点。CheckList 表明，留出集准确率可能掩盖关键的行为缺陷，即使是能力很强的商业系统也不例外。Dynabench 更进一步，让基准测试具有动态性和对抗性，迫使评估随模型进步而演进。

2026 年的编程基准测试格局，让这一点变得具体。在 SWE-bench Verified 上，排名前六的模型只相差 1.3 个百分点。差距如此之小，以至于排名更能反映运行框架调优和提示词工程，而不是模型本身的能力。

然而，在更新的基准测试上，同一批模型呈现出截然不同的能力分布。一份 2026 年 3 月的对比报告称，Claude Opus 4.6 在 SWE-bench Verified 上接近榜首，但在衡量命令行智能体表现的 Terminal-Bench 上，落后 GPT-5.3 Codex 12 个百分点。没有哪个模型能赢下所有评估。如果只根据一个排行榜选模型，你优化的可能是基准测试的偏好，而不是自己的使用场景。

这与我的经历完全吻合：评估过程有价值，是因为它揭示下一步该改进什么，而不是因为它打印出一个更大的数字。

⚙️ 评估要负责系统质量，不能只测模型

在采用智能体的生成式 AI 产品中，运行框架往往和模型一样重要。

我说的运行框架，是指整个执行层：

  • 提示词策略

  • 工具路由

  • 兜底策略

  • 重试逻辑

  • 记忆处理

  • 输出约束

  • 评判与评分设计

两个团队运行同一个基础模型，可能得到截然不同的质量，因为它们的运行框架不同。

因此，“哪个模型赢了？”往往不是首先该问的问题。更好的问题是：“对我们的真实任务，哪种模型与运行框架的组合，能交出最好的整体质量表现？”

编程评估中也能看到这种关系。SWE-bench Verified 通过人工验证测试实例、提高任务质量来增强可靠性。OpenAI 的《SWE-bench Verified 介绍》（Introducing SWE-bench Verified）进一步解释了这一做法。

难度更高的 SWE-bench Pro，把运行框架与模型的关系展示得更明显。在 SEAL 标准化运行框架下，Claude Opus 4.5 的得分是 45.9%。同一个模型放到 Claude Code 定制的智能体框架中，得分跃升至 55.4%。

也就是说，仅运行框架就带来了 ~10 个百分点的变化。

这个经验可以推广：测量设计的选择，对结果的影响可能不亚于更换模型。

从治理角度看，这与 NIST AI RMF 的思路一致：测量只是一个更大闭环中的职能；这个闭环还包括梳理背景、治理风险和管理持续变化。它不是给模型打一次分的仪式。NIST AI RMF 实践手册（NIST AI RMF Playbook）从更具体的操作层面表达了同样的观点。

🧗 持续提高评估难度

如果系统在进步，评估就应该有意识地变难。

这意味着：

  • 增加更多对抗性测试子集

  • 更新任务集

  • 增加模糊性

  • 收紧验收标准

  • 根据近期事故引入新的失败陷阱

否则，就会出现最糟糕的模式：分数上升，反映的却是对基准测试越来越熟悉，而不是产品越来越稳健。

SWE-bench 的演变是最清楚的例子。最初的 2023 年基准测试，考察模型能否解决真实的 GitHub 问题。随后，SWE-bench Lite 支持更快的迭代，SWE-bench Verified 提供经过人工验证、更干净的任务，现在的 SWE-bench Pro 则面向更难、多语言、也更能抵御数据污染的软件工程工作。SWE-bench Live 沿着同一思路继续推进，从近期 GitHub 活动中加入新任务。

这个演进很重要，因为每个新版本都是为了在旧版本变得更容易、更熟悉或污染更严重时，重新提供有效信号。Verified 曾是黄金标准；如今前沿模型聚集在高分区，下一个有用的问题已经转向更难的变体，以及更干净的运行框架对比。

行业更广泛地转向持续更新、重视数据污染的基准测试，也说明了同一个问题。LiveBench、LiveCodeBench 和 SWE-bench Live 都是例子。LiveBench 仍在积极维护，2026 年 4 月还有新的模型更新，这正是一个持续演进的基准测试应有的样子。但内部评估也需要同样的纪律。团队应当把评估集难度当成需要主动管理的变量，而不是固定不变的产物。

做不到这一点，我们就会无意中奖励停滞。做好了，指标或许更难提高，但每一点进步都会可信得多。

🛠️ 我现在采用的一套实际做法

面向生产决策，我现在采用五个方面的评估原则：

  • 📊 比较进步幅度，别只看榜单名次。 在相同的运行框架和规则下，把候选模型与当前基线对比。

  • 🚨 盯住上限。 任务一旦饱和，立即更新或提高难度。

  • 🔍 追踪失败的变化。 报告分数的同时报告失败类型，并把失败情况的变化列为顶层 KPI。

  • ⚙️ 评估运行框架。 测试工具可靠性、重试策略、评判的稳健性和编排，而不只是模型输出的文本。

  • 🧗 持续加强测试。 持续提高评估要求，让评估难度跟上系统能力。

这种做法比发几张排行榜截图慢，但它能支撑经得起追问的决策。

🧭 最后的看法

我仍然支持用分数衡量。

我反对的只是脱离背景的分数。

提升五个百分点可以很有意义。极高的分数也可能是一种警讯。评估真正的价值，是它建立的质量改进闭环：发现失败，修复系统行为，在更难的条件下重新测试，然后反复迭代。

在 2026 年，强大的生成式 AI 团队不会靠追逐孤立的门槛取胜。它们会把评估当成一套跨模型、运行框架、数据与标准、持续演进的质量体系，从而赢得竞争。

这就是纸面上好看，与真正交付可靠产品之间的区别。