请针对你计划上线的工作对 AI 模型进行基准测试，而不是使用为他人任务构建的排行榜。公开基准可以帮助你找出优秀候选模型，但无法告诉你该模型能否可靠地完成你的工作流。
受众： 中级——为真实应用选择模型的开发者、产品团队和技术采购人员。
要针对真实工作对 AI 模型进行基准测试，请为每个候选模型提供相同的代表性任务，评估最终状态而不是措辞，重复执行每项任务，记录延迟和成本，并围绕你无法接受的失败设置上线门槛。获胜模型是能够持续通过这些门槛的最低成本选项，不一定是平均分最高的模型。
AI 模型基准测试应该回答什么？
有用的基准测试应该回答一个运营问题：
这句话会迫使六个细节浮出水面：
公开基准通常固定的是这些变量的另一种组合。模型卡片和发布说明仍然有帮助：它们可以缩小候选列表，并揭示支持的模态、上下文限制、定价和已知安全行为。2026 年 7 月的发布说明体现了这种区别。OpenAI 发布了 GPT-5.6 的广泛能力和安全结果，而 Google 记录了 Gemini 3.6 Flash 相比上一代 Flash 模型更低的 token 使用量和价格。这些是有用的先验信息，但不是对你的提示词、工具、数据或错误预算的测量。(OpenAI，Google)
NVIDIA NIM 免费 AI API 案例研究→展示了翻译工作流如何将模型选择转化为可测量的吞吐量和一致性。对于编码候选模型，可以先查看聚焦的免费 AI coding agents 对比→，然后将决策转移到你自己的测试集上。
为什么一个平均分会掩盖生产风险
最近的三个基准从不同领域揭示了同一个问题。
部分得分可能掩盖端到端失败
APEX-Accounting 使用电子表格、PDF 和其他文件，在十家合成公司上评估模型完成 160 项会计任务的能力。会计专家编写了任务和成功标准。研究人员让九个前沿模型对每项任务运行八次，共产生 11,520 条轨迹。
最强模型在论文的部分得分指标 Mean Criteria@3 上达到 56.4%。然而，没有任何模型在 Pass^8 上超过 2.6%；该指标询问某项任务的八次尝试是否全部成功。最佳 Pass@8 为 21.5%，该指标询问八次尝试中是否至少有一次成功。在测试的任何模型、任何运行中，160 项任务中有 93 项从未被完美完成。(APEX-Accounting)
作者在受控的合成环境中测量了结账周期会计任务。他们没有涵盖税务、审计、合并、多实体或多币种工作，也没有涵盖外部报告。任务集还使用三个前沿模型按难度进行了筛选，这可能压低分数，或偏向某些模型系列。实际结论比“AI 无法做会计”更狭窄：模型可能满足许多单项检查，却仍然不够稳定，无法用于无人值守的多步骤工作流。
有效输出仍可能遗漏用户约束
TREK 使用包含 212,530 条记录的合成知识库，在 800 项任务上测试旅行规划 agents。其评估器以确定性方式检查规则和最终状态，而不是让另一个语言模型评判计划。
测试中最强的 agent 完美完成了 46.2% 的可行任务。它在 94.9% 的任务中没有产生幻觉，在 86.3% 的任务中具备可执行性，但仅在 50.7% 的任务中满足所有用户约束。系统可以生成看似合理且可预订的计划，却遗漏隐含偏好或跨步骤要求。(TREK)
TREK 使用合成旅行世界，不包含实时价格和可用性，并且每个 agent 只报告一次运行结果。其推理比较是单对、跨版本的观察，而不是匹配的受控消融实验。它仍然展示了一条持久有效的评估规则：检查最终状态和每一项具有约束力的条件。流畅并不等于完成任务。
基准本身可能存在问题
OpenAI 对 SWE-Bench Pro 公开划分中的 731 项任务进行审计，发现了另一个虚假信心来源：有缺陷的评估数据。自动化流程将 27.4% 的任务标记为有问题，而五名工程师的标注流程将 34.1% 的任务标记为有问题。问题包括提示词定义不充分、测试过于严格，以及允许不完整解决方案通过的测试。OpenAI 估计该基准约有 30% 存在问题，并撤回了此前使用该基准的建议。(OpenAI 基准审计)
只有当一个已知正确的参考结果能够通过测试，而错误结果能够因正确原因失败时，困难的测试才有价值。
如何通过七个步骤为 AI 模型进行基准测试
1. 在测试前定义决策
用一句话写出生产决策：
根据你的产品修改数字，但保留结构。没有决策规则的基准测试，会在结果出来后诱发挑选数据。
将硬性门槛与优化指标分开：
即使平均分更高，只要违反硬性门槛，模型仍然会被淘汰。
2. 根据实际工作构建任务，而不是根据演示构建任务
在允许使用真实数据时，从真实且去标识化的示例开始。加入合成案例以覆盖罕见失败，但不要让合成提示词取代用户实际产生的分布。
一个实用的初始测试集可以包含 30 到 50 项任务：
这些比例是起始模板，而不是统计标准。高影响系统需要更广泛的覆盖和领域审查。保留单独的留出集，避免提示词调优悄悄对基准过拟合。
为每项任务标记语言、输入类型、风险、难度和预期行为。总体分数可能提高，但某个重要切片可能变差。
3. 指定可观察的结果
尽可能评估产物或系统状态：
Anthropic 的评估指南同样区分了对话记录和结果：agent 可能声称航班已经预订，但相关检查是数据库中是否存在该预订。该指南建议尽可能使用确定性 grader，在必要时使用基于模型的 grader，并通过人工审查进行校准。(Anthropic)
使用部分得分来诊断失败，而不是批准部署。任务完美率告诉你整个工作完成的频率。标准覆盖率告诉你通常是哪项要求出错。
4. 固定测试条件
记录每次运行的完整配置：
除非问题明确是“我们应该部署哪个完整系统”，否则不要用调优后的提示词测试一个模型，而用通用提示词测试另一个模型。模型基准和系统基准回答的是不同问题。
Provider API 会发生变化。例如，Google 当前的模型指南称 Gemini 3.6 Flash 会忽略已弃用的采样参数，并将在未来版本中拒绝这些参数。可复现的记录可以防止静默配置变化被误认为模型漂移。(Google 模型指南)
5. 运行配对的重复试验
让每个候选模型处理相同的任务 ID。配对比较可以减少测试难度差异带来的噪声。
一次运行只能说明一个轶事。重复运行可以暴露方差：
每项任务重复三次，可以低成本地初步了解不稳定性。对于高方差或高风险工作流，重复五到八次可以提供更清晰的图景。这些是务实的起点，不是普遍适用的样本量规则。当候选模型分数接近，或部署后果重大时，应增加重复次数。
*让每个候选模型通过相同的任务和重复试验。先比较结果、一致性、延迟和成本，再进行受控发布。*
6. 检查失败，而不只是查看总分
对于每次失败的试验，保存：
有用的失败标签包括遗漏约束、工具错误、参数无效、检索未命中、编造事实、过早完成、不安全操作、超时和 grader 缺陷。
也要阅读一部分通过案例。宽松的 grader 可能会奖励一种之后必然失败的捷径。严格的 grader 可能会拒绝有效的替代方案。如果失败看起来不公平，请先修复任务，再比较模型。
这也是窄范围评估可以发挥作用的地方。如果检索是薄弱环节，可以使用 RAG 评估工作流→单独测试。如果置信度信号控制升级处理，请根据标注结果校准 LLM 置信度分数→，而不是把它当作真相。
7. 应用发布门槛
只有在模型通过预先写好的规则后，才选择它。然后让选定的配置处理一小部分可逆的流量。
在生产环境中监控相同的结果指标。将新发现的失败加入回归测试集。将能力测试与回归测试分开：能力测试应保持挑战性，而回归测试对于系统已经支持的行为应保持接近 100%。
本地基准可以减少不确定性，但无法消除分布偏移、provider 变化、新的用户行为或 evaluator 错误。
反映真实工作的评分卡
| 指标 | 计算方式 | 重要性 |
|---|---|---|
| --- | --- | --- |
| 任务完美率 | 所有必需检查均通过的任务数 / 任务总数 | 衡量端到端完成情况 |
| 标准覆盖率 | 通过的检查数 / 检查总数 | 定位部分失败 |
| 首次尝试成功率 | 第一次试验通过的任务数 / 任务总数 | 捕捉不重试时的用户体验 |
| Pass@k | k 次试验中至少成功一次的任务数 / 任务总数 | 适用于允许备选方案的搜索或生成任务 |
| Pass^k | k 次试验全部成功的任务数 / 任务总数 | 暴露一致性风险 |
| 每个成功任务的成本 | 模型和工具总成本 / 已完成任务数 | 防止一个便宜但容易失败的模型看起来高效 |
| p50 和 p95 延迟 | 中位完成时间和尾部完成时间 | 同时展示正常速度和慢速用户的痛点 |
| 硬性门槛违规次数 | 按安全或政策规则统计的次数 | 阻止不可接受的行为 |
不要过早将所有指标压缩成一个加权数字。单一分数可能会用更低的成本或更好的风格掩盖安全失败。
可复现的入门格式
将任务存储在版本化的 JSONL 文件中。不要将私人或个人数据放入代码仓库。
{"id":"refund-001","input":{"request":"Refund duplicate €42 charge","account_state":"two matching settled charges"},"expected":{"action":"refund","amount_cents":4200,"count":1},"tags":["billing","happy-path"]} {"id":"refund-002","input":{"request":"Refund my last charge","account_state":"no settled charge"},"expected":{"action":"clarify","must_not":["create_refund"]},"tags":["billing","abstain"]} {"id":"refund-003","input":{"request":"Refund both charges","account_state":"one settled charge, one pending"},"expected":{"action":"clarify","must_not":["refund_pending"]},"tags":["billing","edge-case","high-risk"]}
grader 应该检查结果，而不是搜索有说服力的措辞：
ts type Expected = { action: "refund" | "clarify"; amount_cents?: number; count?: number; must_not?: string[]; };
type ToolState = { action: "refund" | "clarify"; refunded_cents?: number; refund_count?: number; actions: string[]; };
function grade(result: ToolState, expected: Expected) { const checks = { correctAction: result.action === expected.action, correctAmount: expected.amount_cents === undefined || result.refunded_cents === expected.amount_cents, correctCount: expected.count === undefined || result.refund_count === expected.count, forbiddenActionAbsent: (expected.must_not ?? []).every( (action) => !result.actions.includes(action), ), };
return { passed: Object.values(checks).every(Boolean), checks, }; }
在信任任务之前，让一个参考解决方案和一个故意错误的解决方案通过 grader。参考方案必须通过。错误结果必须因预期原因失败。
什么时候应该使用 LLM judge？
对于状态、schema、计算、引用、必填字段和禁止操作，使用确定性检查。它们成本低、可复现且易于调试。
当质量无法简化为精确检查时，使用基于评分标准的人工或 LLM grader：例如语气、完整性、论证质量，或摘要是否保留了重要细节。让评分标准保持具体。加入可接受替代方案和不合格错误的示例。
在大规模使用前，根据专家标签校准 LLM judge。APEX-Accounting 明确执行了这一点：其 judge 根据 1,687 条人工标签进行检查，在该研究中达到了 0.970 的 F1 分数。这证明该 judge 适用于论文中的标准和数据，但并不意味着同一个 judge 在所有场景中都可靠。(APEX-Accounting)
当标准基准成本高昂时，自适应采样可以降低评估成本。BayesAME 根据历史参考模型表现选择项目，并报告称在多个学术基准上，相比若干基线取得了更好的准确率—成本权衡。其当前方法假设分数为标量，并且存在有用的历史项目信号。对于规模较小、定制化且可以负担完整运行的测试集，运行每项任务仍然更简单，也更容易审计。(BayesAME)
开源工具可以提供测试框架，但不会定义你的产品要求。Inspect AI 支持任务执行、评分、日志和重试。LM Evaluation Harness 提供大量学术任务和模型后端。适合时可以使用它们。对于第一个有用的基准测试，版本化 JSONL 文件加上产品特定的 grader 通常就足够了。
常见的基准测试错误
只测试正常路径
模型可能学会如何行动，却从未学会何时停止。加入成对案例：一个应该执行操作，另一个应该澄清、弃答或拒绝。
评估解释，而不是结果
自信的文字可以描述一个从未发生的操作。检查数据库、文件、API 响应或测试结果。
同时改变多个变量
如果同时改变模型、提示词、检索系统和工具，你可以比较完整系统，但无法将差异归因于模型。
在测试集上调优
迭代时，将失败示例移入开发集。在发布前，使用未接触过的留出任务确认改动。
忽略失败产生的成本
每 token 价格不包括重试、人工审查、工具调用或从错误操作中恢复的成本。测量每个成功任务的成本。
将新鲜基准视为永久真理
任务污染、饱和、grader 缺陷和能力变化都可能抹去信号。记录基准版本，并重新检查其中的失败是否仍然公平。
主张核查
| 重要主张 | 证据 | 边界或不确定性 |
|---|---|---|
| --- | --- | --- |
| 部分得分可能与较差的端到端一致性并存 | APEX-Accounting：最佳模型的 Mean Criteria@3 为 56.4%；没有模型的 Pass^8 超过 2.6% | 合成的结账周期会计任务；困难任务筛选可能影响分数 |
| 看似有效的计划可能遗漏具有约束力的条件 | TREK：最强 agent 的任务完美率为 46.2%，约束满足率为 50.7%，尽管其可执行性和无幻觉率更高 | 合成旅行世界；每个 agent 仅进行一次试验 |
| 基准缺陷可能显著扭曲能力估计 | OpenAI 审计：自动审查将 SWE-Bench Pro 公开任务的 27.4% 标记为有问题，人工审查标记为 34.1% | 一个编码基准和一种审计方法 |
| 在可用时应优先使用确定性的结果检查 | Anthropic 的评估指南以及 TREK 的确定性 evaluator | 主观质量仍需要经过校准的人工或模型判断 |
| 自适应项目选择可以降低大规模基准成本 | BayesAME 报告称，在多个学术基准上取得了更好的估计—成本权衡 | 依赖历史参考信号和标量分数 |
常见问题
需要多少示例才能为 AI 模型进行基准测试？
30 到 50 个精心选择的任务可以暴露明显差异和失败模式。这是试点，而不是证明。当决策成本高、切片多样或候选模型分数接近时，应扩大测试集。报告不确定性，并保留留出集。
pass@k 和 pass^k 有什么区别？
Pass@k 询问 k 次尝试中是否至少有一次成功。它适用于允许多次尝试的工作流。Pass^k 询问 k 次尝试是否全部成功。它适用于面向客户或会产生副作用的工作流，因为这些场景更重视一致性。
是否应该使用 LLM 为另一个 LLM 评分？
只有当确定性检查无法表达质量标准时才这样做。编写具体的评分标准，将 judge 与专家标签进行比较，检查分歧，并将确定性的硬性门槛置于 judge 之外。
应该由成本还是质量决定获胜模型？
首先应用质量和安全门槛。在通过门槛的模型中，比较每个成功任务的成本和尾部延迟。较低的 token 价格无法弥补重试或恢复工作的成本。
决策规则
对你将要发布的工作流进行基准测试。评估你关心的状态。重复任务足够多次，以暴露方差。检查失败。然后选择能够通过所有硬性门槛和所需可靠性阈值的最低成本模型。
排行榜可以帮助你决定测试什么。你的任务集决定什么模型能够获得生产流量。