厂商基准测试是你的天花板，而非预测

模型发布的公告在周二早上落地。博客文章开头是一张图表：HumanEval 提升了 4 个点，SWE-bench Verified 提升了 6 个点，MATH 提升了 3 个点，而当前流行的 Agent 测试套件提升的数值在一年之前足以写成一篇研究论文。到了周二下午，你公司的 Slack 频道里就会出现该图表的截图，随之而来的还有一个类似决策的问题：“我们要切换过去吗？”这个讨论线程将基准测试的增量视为一种预测 —— 仿佛这些数字描述了新模型在 你的 产品中、使用 你的 提示词、在 你的 工具链下、针对 你的 评估准则所能表现出的效果。事实并非如此。厂商给出的数字是你可能看到的性能上限。你实际获得的提升大约在零到该标题数值的一半之间，如果不运行一次厂商从未运行过的评估，你无法得知确切结果。

这并非在抱怨基准测试的有效性。基准测试是真实的。它们是针对真实的评估套件运行的。厂商没有撒谎。问题在于厂商的评估套件是一个理想化的环境，剥离了生产部署中引入的每一个变量，而在这些条件下生成的数字在结构上无法预测模型在你环境下的行为。将其视为一种预测是一种范畴错误 —— 它会导致采购决策、容量规划承诺以及发布时间表都基于虚构的事实进行校准。

测试套件的不匹配就是问题的全部

当厂商报告基准测试分数时，他们实际测量的是：固定的提示词模板、精选的输入分布、确定性的解码配置、没有工具层、没有检索索引、没有流式传输预算、没有并发流量控制、没有速率限制、由基准测试作者编写的评估准则，以及通常允许一定程度的后验过滤或 N 选 1（Best-of-N）的通过标准 —— 而厂商自己的产品在运行时并不会这样做。图表上的数字是模型在接近实验室的条件下，针对别人挑选的问题，按照别人设定的标准所表现出的性能。

你的技术栈完全不是这样。你的提示词在不同团队之间存在版本漂移。你的输入来自真实用户，带有拼写错误、多语言语码转换、粘贴的截图和未完成的想法。你的解码温度设置在零以上，因为产品需要多样性。你的工具层会触发检索调用、结构化输出验证器以及用户从未听说过的重排序器。你的评估准则是一个由两名工程师维护的 Google 表格，且维护的认真程度参差不齐。你的通过标准则是支持团队不再抱怨。

2026 年的企业基准测试文献现在为这种不匹配给出了具体数值：Agent AI 系统在实验室基准测试分数与现实世界部署性能之间存在约 37% 的差距，且在准确度相近的情况下，成本差异高达 50 倍。这种差距不是一个可以修复的 Bug。它是两种不同实验条件之间的结构性距离，厂商端的任何基准测试改进都无法消除它，因为驱动这种差距的变量存在于你的那一侧。

饱和、污染，以及为什么标题是在“半撒谎”

有两种失效模式已经主导了排行榜的顶端，这两者都使得标题数字作为预测指标的效果比看起来更糟。

第一种是饱和。对于前沿模型来说，MMLU、HumanEval 和 GSM8K 实际上已经是退役的基准测试 —— 每一个可靠的发布版本得分都在 88–90% 以上，顶部的差异在统计学上与噪声无异。在饱和的基准测试上提升 4 个点，并不代表模型在底层能力上有所提高；它只代表模型在这一组测试项中，多解决了几个先前版本失败的边缘案例，而测试集中的其余部分无论如何都能被解决。你的工作负载几乎肯定与 MMLU 的残差边缘案例分布不匹配，因此厂商图表上的 4 点增量与你实际获得的提升仅在偶然情况下相关。

第二种是污染。SWE-bench Verified 是每个编程 Agent 都会重点展示的基准测试，现在显示的污染率在 8–10% 之间。据测量，前沿模型在污染集上的 Bug 定位准确率比在等效的留出集（held-out sets）上高出 3 到 6 倍。SWE-bench Pro 的构建专门为了解决这个问题，它使用了预训练流水线较少可能摄取的 Copyleft 和留出代码库 —— 在 Verified 上得分 80%+ 的模型，在 Pro 上仅得分 46–57%。OpenAI 已停止报告新发布的 SWE-bench Verified 成绩，理由是数据污染。当厂商在公告图表中突出显示 Verified 级别的数字时，你所看到的测量结果对于你关注的模型群体来说，在某种程度上更像是一场记忆测试。你无法分辨提升的部分有多少是“模型编程能力变强了”，有多少是“模型记住了更多的训练代码库”。你的代码库不在 2023 年左右的 GitHub 上，因此被记住的那部分提升对你的技术栈来说是毫无意义的累赘。

每次发布前的影子评估是必须落地的规范

了解候选模型对你产品的实际影响，唯一诚实的方法是在做出任何上线决定之前，将其与现有的基准模型在你产品的评估平面上并排运行。在 2026 年经受住考验的模式是“每次发布前的影子评估”（per-release shadow eval）：一套固定的评估套件，锚定在真实的生产流量和历史回归用例上，在你的提示词、工具层、检索、解码配置和评分标准下，同时在候选模型和基准模型上运行。输出的是两个分布，而不仅仅是两个数字——你需要对比中位数、长尾表现、各细分领域的切片以及失败模式的分解。

这并不罕见。这正是影子测试（shadow-testing）基础设施在过去 15 年里一直为排序模型所做的，现在被移植到了 LLM 上。将实时流量镜像给候选模型，记录响应但不直接提供服务，使用与基准模型相同的标准进行评分，并根据差值（delta）来决定是否上线。经历过多次模型迭代的团队报告了两个一致的发现：生产环境评分标准下的实际提升几乎总是低于厂商宣传的标题数值，而且同一公司内部不同产品层面的差异非常大，以至于总体的聚合数字本身具有误导性。一个能让你的摘要功能提升 12 个点的模型，在提取功能上可能毫无进展，而在路由功能上甚至是负优化。聚合数据掩盖了这三种情况。

增量归因：是模型变强了，还是你的提示词走运了？

当影子评估确实显示出提升时，团队往往会将其归因于“新模型更强大”。但有一半的情况是，新模型与基准模型具有不同的提示词敏感度特征，而你现有的提示词——针对基准模型编写和调优的——恰好与新模型的偏好或多或少地契合。团队学到的教训（“我们应该升级”）往往是错误的；正确的教训应该是“这个提示词过度拟合了前一个模型的怪癖，而我们在下一个模型上碰巧走运了”。如果没有增量归因（delta attribution），团队在下次发布时会重复这种偶然的调优，而一个周期后，同样的提示词可能会因为运气用尽而表现出退化。

捕捉这一问题的规范是：同时在现有提示词和重新调优的提示词下评估候选模型，并对基准模型也进行同样的双重评估。这种 2x2 的矩阵可以将“模型本身带来的提升”与“提示词契合带来的提升”清晰地分开，从而根据模型组件做出采购决策，并将提示词工程的投入进行分级处理。如果没有这个 2x2 矩阵，团队就会将两个不同的信号混淆为一个数字，并一再基于这种混淆的指标做出自以为是的决策。

建立校准表，不再被“惊喜”所困扰

单次模型发布无法为你提供校准参考，多次发布才能。运行影子评估一两年的团队最终会维护一个内部的小工具，它比任何厂商的基准测试都更有决策价值：一张校准表。每一行代表一次发布，包含四个列：厂商宣传的提升、你在聚合标准下的影子评估提升、你在最差细分领域的影子评估提升，以及宣传值与实际值的比例。在记录四五次之后，这个比例会稳定在一个区间内。对于某个团队，它可能是“厂商宣传平均夸大了 2.3 倍，且最差细分领域的提升通常为零或负数”。对于另一个团队，则可能是“厂商宣传低估了我们 30% 的实际提升，因为我们的检索层放大了模型的收益”。

无论哪种区间都极具价值。它能让你在阅读最新公告时，计算出上线后可能产生的实际提升上限，并让财务合作伙伴不再对“每个有效输出的成本曲线未按公告预期下降”感到惊讶。同样的校准规范也适用于成本维度。厂商在他们的推理测试环境下给出每秒 token 数（TPS）；而你实现的吞吐量取决于你的提示词长度分布、并发负载、重试策略、结构化输出验证器的拒绝率以及工具调用的多样性。厂商标称吞吐量与你观测到的吞吐量的比例，同样是一个在几次发布后趋于稳定的区间——而这才是驱动容量规划的唯一数字。

采购与 FinOps：拒绝将宣传标题作为预算输入

这一切背后的架构认知是：厂商的基准测试是在厂商的测试环境下衡量模型，而不是你的环境；将这些测试视为预测结果的团队，实际上是在让厂商的营销部门来做他们的容量规划。纠正措施是程序性的，而非技术性的。养成一个 FinOps 习惯：任何预算承诺、合同等级升级或 SLA 溢价的签署，都不能仅凭厂商的基准测试。签署的依据应该是你的影子评估结果，它锚定在你的校准表上，并以你实际付费的单位来表达——即每个被接受的输出的有效成本，或你的产品用来定义“好”的任何标准。

这并非对厂商的偏执。而是意识到厂商图表中优化的单位与你损益表（P&L）中优化的单位不同，而两者之间的转换系数只有你才能测量。厂商无法运行你的评估。他们没有你的提示词、工具层、流量或评分标准。基准测试数字是他们在所见范围内能提供的最好信号——而这个信号从本质上讲，是你所能实现的上限，而不是对未来的预测。

预测结果就在你的评估套件中

下一个模型即将发布，图表看起来会非常亮眼，Slack 频道里也都在询问你是否应该切换。正确答案永远不会出现在发布公告里。它存在于将候选模型在影子评估中与现有模型进行对比的结果里：按你的产品维度进行切片，清晰地归因于模型能力的提升或提示词适配的提升，并与你的校准带进行比对。如果你没有评估套件、校准表或影子评估流水线，那么你拥有的不是预测——你拥有的只是一份公告。根据公告进行交付的团队，在每一次发布中都会被那 37% 的差距打个措手不及，周而复始，因为这种差距在供应商那边并不会缩小，也从来没有缩小的可能。差距只会在你这一端缩小，只要你认定：标题上的数字只是关于供应商测试套件的信息，而不是关于你产品的信息。