模型卡没告诉你的是：公开基准测试与实际工作负载之间的生产差距

模型卡显示代码生成准确率为 89%。你的团队在实际代码库上只得到了 28%。模型卡显示有 100K token 的上下文窗口。而在你的文档工作负载下，性能在 32K 时就大幅下降。模型卡通过了红队安全评估。但在上线后的 72 小时内，针对用户的提示词注入攻击就出现了。

这种差距并不罕见。这已成为常态。在 2025 年对 1,200 个生产部署的分析中，42% 的公司在生产集成阶段放弃了他们的 AI 计划 —— 高于前一年的 17%。他们中的大多数都仔细阅读过模型卡。

问题不在于模型卡撒谎。而在于它们衡量的内容与你需要了解的内容不同。准确理解这一差距 —— 并构建内部基准测试套件来弥补它 —— 是交付可靠 AI 的团队与交付懊悔的团队之间的分水岭。

模型卡实际衡量的是什么

模型卡最初被设计为透明度产物：关于模型预期用途、训练数据来源、评估结果和已知局限性的标准化文档。Google 研究人员在 2018 年提出的原始框架旨在为从业者提供足够的信息，以便做出负责任的部署决策。

它们实际包含的内容：在一组为展示能力而精心挑选的基准测试上的表现，使用最高级的工程脚手架（few-shot 示例、思维链提示、自洽性采样）进行评估，数据集经过清洗和平衡以匹配评估设置，在单一时间点，运行在模型提供商控制的硬件上。

你将要部署的内容：zero-shot 或极简提示词的生产流量，处理你杂乱的数据，在你基础设施支持的规模下，在没有任何基准测试环境能模拟的负载模式下，服务于评估数据集可能代表性不足的用户群体。

这些差异中的每一项都会叠加。当差距累积起来时，在合成基准测试中得分 89% 的模型，在真实的类级（class-level）代码任务中仅能生成 28–34% 的正确输出 —— 研究人员通过将相同模型在类生产代码库与合成测试套件上运行，直接测量出了 3 倍的差距。

致命生产部署的四个差距

上下文长度退化

广告中宣称的 100K 或 200K token 上下文窗口报告的是极限，而不是性能平稳期。实际曲线与到达极限前的平直直线完全不同。

在 2024 年研究中测试的 18 个前沿模型中，随着输入长度增加，性能下降了 13.9–85% —— 即使检索是完美的。特定模型显示了有据可查的“断崖”：Llama 3.1 405B 在 32K token 后开始退化，GPT-4-0125-preview 在 64K 后退化。一项基准测试发现，Claude 3 Sonnet 的版权失效（failure）率从 16K token 时的 3.7% 跳升到 32K 时的 21%，再到 64K 时的 49.5% —— 在许多团队认为“属于上下文窗口内”的范围内增加了 13 倍。

其机制是注意力稀释。100K token 的上下文需要模型维持 100 亿个成对的注意力关系。“迷失在中间”（lost in the middle）效应已得到充分证实：模型能可靠地关注上下文开头和结尾的内容，但会忽略中间的内容，对于埋藏在长文档中的材料，准确率下降幅度超过 30%。

生产意义：如果你的应用涉及长文档、多轮对话或可能将上下文推过 32K–64K token 的检索，你需要在决定使用某个模型之前，在实际的 token 分布下衡量性能。标称“128K 上下文”的模型卡无法告诉你模型在 60K 时的表现。

人口统计学和语言子群差距

模型卡报告的是综合准确率。综合准确率隐藏了错误分布的情况。

医疗多模态模型发布了总体准确率得分，但没有报告不同患者群体之间的性能差异。在医疗保健领域部署的视觉语言模型在不同人口群体中显示出相似的基准测试得分，但在生产环境中，对于代表性不足的患者群体，其产出的结果系统性地更差。在综合多语言基准测试中得分很高的语言模型，在 CJK、阿拉伯语和印地语脚本中表现出 3–8 倍的分词成本，且质量明显较低 —— 这些差距在标题指标中并未体现。

问题在于方法论：大多数公共基准测试都是由西方、英语、受过良好教育的来源组建的。在 MMLU 上得分 85% 的模型是针对特定分布进行优化的。如果你的用户不属于该分布，那个数字对你来说就没有意义。

这不是多样性争论 —— 而是校准争论。如果你的用户中有 30% 是非英语母语者，或者你的产品涉及具有自身术语分布的医疗、法律或金融领域，那么模型卡的基准测试得分是从一个与你所服务的群体不同的群体中提取的样本。

拒绝模式的不稳定性

基准测试红队对抗（Benchmark red-teaming）与生产环境中的对抗行为并不是同一个问题。

模型卡片（Model cards）上的安全性评估衡量的是在受控环境下，针对已知对抗性提示词集的拒绝率。生产环境中的对抗行为源于真实用户实时探测真实系统。2024 年 NeurIPS 的一项研究发现，当前大语言模型（LLM）的拒绝行为是由模型激活中的单一方向介导的——而消融（ablating）这一方向会完全禁用拒绝机制——这一点在任何模型卡片上都没有被提及。

实际后果：将指令与合法通信混合的提示词注入攻击、RAG 上下文污染、多步社会工程提示词——这些都利用了基准测试红队对抗无法模拟的生产环境动态。2025 年通过提示词注入实现的 GitHub Copilot 远程代码执行（CVE-2025-53773），尽管在安全基准测试中表现强劲，但依然发生了。将发布的安全性评分作为主要评估依据的团队对此感到意外。

拒绝模式在模型版本迭代中也会发生偏移，而模型卡片并不总能精准捕捉到这些变化。提升了某项安全性指标的版本更新，可能会改变相邻提示词的拒绝行为，从而影响合法的用户流程。

延迟与吞吐量的波动

模型卡片可能列出了在稳定、理想负载下测得的吞吐量数据。生产环境的负载并不稳定。

实际部署中，请求和响应的大小在数小时内可能会有几个数量级的波动。KV 缓存利用率从 30% 飙升至 70%；队列深度也随之增加。在真实的负载下，同类模型之间的推理延迟差异可达 3.8 倍——也就是 2.7 秒响应与 10 秒响应之间的区别。区域网络布局在模型级延迟之上又叠加了额外的波动。

这一点至关重要，因为延迟的 SLO（服务水平目标）通常是根据基准测试数据而非生产环境分布设定的。真实突发负载下的 P99 延迟才是触发值班报警的关键指标；而基准测试并不会报告这一项。

为什么基准测试饱和让情况变得更糟

随着基准测试趋于饱和，模型卡片的问题正在加剧。在 MMLU、HumanEval 及类似基准测试中得分接近天花板的模型，正日益掩盖那些仅在特定领域或真实生产环境评估中才会显现的有意义的能力差异。

当基准测试饱和时，微小的分差并不对应于对你的产品至关重要的任务行为上的实质性差异。两个在 HumanEval 上都得 92 分的模型，在你实际的代码库上可能会产生巨大的结果差异——因为基准测试衡量的是比真实代码需求更简单、更统一的东西。

幻觉基准测试也面临同样的饱和以及方法论不可比的问题。2025 年的一项幻觉评估工作发现，由于方法论不同，各厂商发布的幻觉率不可比：频繁弃答的模型在某个框架下看起来更好，但在另一个框架下则更差。正如一项基准测试研究指出的，已发布的模型卡片数据中关于“幻觉率并没有单一的真相”。

你真正需要的内部基准测试套件

考虑到这些差距，问题不在于是否相信模型卡片，而在于在它们之外还需要构建什么。目标是建立一套衡量你的工作负载、而非供应商的最佳情况的基准测试套件。

基于生产数据的特定任务评估。 针对你的实际流量采样出一套留出集（holdout set）——真实的输入、真实的文档形态、真实的查询分布，这是生产环境表现最可靠的预测指标。如果你还没有流量，则从你用户所属的领域采样，而不是使用通用的基准测试数据集。使用零样本（zero-shot）提示词进行评估，而不是经过工程化的少样本（few-shot）示例，因为这才是你的应用程序实际会发送的内容。

上下文长度曲线。 针对你评估的每个模型，测量准确率随输入长度（按照你应用程序实际产生的 Token 计数，而非模型的最大值）变化的函数关系。生成一条衰减曲线。如果你处理的是 6 万 Token 的文档，你需要知道在 6 万 Token 时的表现，而不是 1.6 万 Token。

细分组合切片。 定义对你的用户群体至关重要的统计学和语言分类，然后分别进行测量。如果 20% 的用户是非英语使用者，那么该子组就需要自己的准确率和延迟数据，而不能仅仅包含在总分中。

真实负载下的延迟。 在预期的 P50、P95 和 P99 请求量下测试延迟，而不是单次请求的吞吐量。如果你运行的是共享基础设施，请在并发负载下进行测量。真实突发情况下的 P99 延迟才是用户感受到的数字。

针对实际提示词的拒绝行为。 构建一套精心筛选的集合，包含过去曾触发错误拒绝的合法用户提示词，以及针对你特定领域的对抗性提示词。测量真阳性拒绝率（捕捉到实际问题）和假阳性率（拦截了合法用户）。一个整体安全基准表现良好的模型，其假阳性拒绝率仍可能高到让你的用例无法使用。

回归测试集。 在任何模型版本更新之前，运行一套固定的评估集，捕捉产品所依赖的行为。版本更新会以微妙的方式改变拒绝模式、输出格式和事实行为，而综合基准测试无法体现这些。由真实的生产边界案例构建的回归测试集，能在用户发现这些问题之前就将其捕捉。

单次正确输出的成本。 不是每个 Token 的成本，而是每个正确输出的成本。一个在你的任务上准确率为 40% 的便宜模型，其每个有用结果的成本比一个准确率为 80% 的更贵模型还要高。将这个指标纳入你的选择标准。

在提交之前运行评测套件

运行内部基准测试的时机是在你围绕模型构建生产基础设施之前，而不是之后。

实际的操作流程是：从生产数据中抽取具有代表性的样本，为每个评估类别定义验收标准，针对完整的套件运行每个候选模型；在你获得子组切片（subgroup slices）、延迟分布和退化曲线（degradation curve）之前，不要最终确定模型——而不仅仅是参考综合准确率分数。

这比阅读模型卡（model card）花费的时间更长。但与在发布六个月后调试一个影响 30% 用户群的生产故障相比，它所花的时间要少得多。

从褒义的角度来看，模型卡是营销文档：它们以标准化的格式透明地报告了真实能力的真实测量结果。但它们无法告诉你的是，这些能力如何迁移到你的数据、你的用户、你的负载模式以及你的延迟要求。这种传递函数（transfer function）正是你的内部基准测试套件所衡量的。

构建它并不是可选的。对于那些将产品押注在基础模型上的团队来说，正是这种工程纪律让这场押注变得有据可依。