大模型评测没有一个能概括全部质量的“总分”。Accuracy 适合答案可唯一判定的题目，Pass@k 衡量多次生成中至少一次成功的概率，竞技场分数反映特定用户偏好，而 TTFT、TPS 描述服务体验。它们回答的是不同问题，不能直接相加，也不能脱离数据集、Prompt 和推理配置比较。
真正可用的评测至少要同时回答四件事：模型能否完成任务、结果是否稳定、用户要等多久、每次成功要花多少钱。参数配置会改变结果，建议同时阅读大模型参数是什么意思；完整实验规则见大模型对比评测规则。
先把指标分成四层
| 层级 | 主要问题 | 常见指标 |
|---|---|---|
| 模型能力 | 答案对不对、任务做没做成 | Accuracy、Exact Match、F1、Pass@k、Resolution Rate |
| 人类偏好 | 两个答案哪个更有用 | Win Rate、Pairwise Preference、Arena Score |
| 系统体验 | 用户多久看到并拿完结果 | TTFT、端到端延迟、TPS、吞吐量 |
| 业务效率 | 达到合格结果需要多少资源 | 单次成本、成功成本、重试率、格式合规率 |
同一个模型可能知识题准确率高，却在结构化输出或代码仓库修复上不合格；也可能生成速度快，但首字等待时间长。因此评测报告应保留分项结果，不能只展示加权总分。
Accuracy：答对的样本占多少
Accuracy（准确率）通常按 答对样本数 / 总样本数 计算，适合选择题、分类和存在明确标准答案的任务。若 100 个样本中 82 个判定正确，Accuracy 为 82%。
但它有三个常见陷阱：类别严重不均衡时，总是猜多数类也可能得高分；宽松的答案抽取规则会把格式错误隐藏掉；不同数据集或不同 shot 数量的结果不能直接比较。Hugging Face Open LLM Leaderboard 对不同任务分别使用 strict accuracy、normalized accuracy、exact match 等口径，正说明“准确率”不是一个统一实现。
Exact Match、Precision、Recall 与 F1
Exact Match 要求预测与标准答案完全匹配，判定明确，但对同义表达很苛刻。使用它时必须公开大小写、空格、标点和答案抽取规则。
当一个样本可能有多个标签或需要抽取实体时，Precision（查准率）关注预测出的项目有多少是真的，Recall（召回率）关注真实项目有多少被找出，F1 是两者的调和平均。安全拦截常重视 Recall，但 Recall 过高也可能导致过度拒答；最终要同时报告误放和误杀。
Pass@1 与 Pass@k：代码评测最容易被误读的指标
Pass@1 关注第一次生成是否通过测试。Pass@k 则关注生成 k 个候选时，至少一个通过的概率。k 越大，结果通常越高，但计算和人工筛选成本也同步增加。
因此，Pass@10 高并不等于用户一次就能获得正确代码。报告必须写明 k、采样次数、temperature、判定测试和是否允许工具。面向交互式产品，Pass@1 往往更贴近体验；面向可自动生成并验证多个候选的流水线，Pass@k 才有实际意义。
Resolution Rate：仓库级问题有没有真的修好
SWE-bench 用代码仓库中的真实 issue 与测试来判断补丁能否解决问题，核心口径是 resolved instances 占评测实例的比例。它比单函数代码题更贴近工程任务，但结果依赖仓库版本、容器环境、工具权限和代理脚手架。
看到 SWE-bench 成绩时，应确认是哪个子集、是否为 Verified、允许多少次交互，以及评测的是基础模型还是完整 Agent 系统。关于各平台口径可继续看大模型评测网站怎么看。
Win Rate 与 Arena Score：偏好不等于事实正确
成对比较会把两个匿名回答交给用户或裁判，统计 A 胜、B 胜和平局。Win Rate 容易理解；Arena Score 或类似 Elo 的分数则通过多轮对战估计相对强弱。
这类指标适合开放式写作、对话帮助度和风格偏好，但会受到用户构成、题目分布、展示顺序和模型版本变化影响。语言更流畅的错误答案也可能赢得偏好票。所以偏好分应与事实核验、安全性和任务成功率一起看，并附榜单快照日期。
TTFT、TPS、延迟与吞吐量分别代表什么
- TTFT（Time to First Token）：请求发出到收到第一个输出 token 的时间，影响“有没有立即响应”的感受。
- TPS（Tokens per Second）：开始输出后的生成速度。需注明按输出 token 还是总 token 计算，并给出统计口径。
- 端到端延迟：从请求开始到完整响应结束，受输入长度、输出长度、排队、网络和工具调用共同影响。
- 吞吐量：单位时间内完成的请求数或 token 数，衡量并发服务能力。
延迟不应只报平均数。线上应至少同时看中位数和 P95/P99；平均值会掩盖少量极慢请求。测试时还需固定地区、连接复用、并发量、输入输出长度与流式传输设置。
成本指标：不要只抄每百万 Token 价格
一次调用成本可按输入、缓存输入和输出 token 分别计算，但业务真正关心的是“获得一次合格结果的成本”：
成功成本 = 全部调用费用（含重试） / 合格结果数
如果便宜模型需要更多重试、人工复核或二次修复，单 token 价格低也未必更省。价格还会变化，所以报告应记录币种、地区、计费来源和日期。
可靠性指标决定能不能上线
业务数据集还应测格式合规率、工具调用成功率、引用可核验率、幻觉率、安全拒绝率和过度拒答率。每项都要给出机器可执行或人工可复核的判定规则。例如 JSON 可解析不代表字段内容正确，二者应分开计数。
本站的AI 总结质量评估与回归测试展示了如何把固定样本、事实证据、结构断言和人工评分组合成发布门禁。
比较模型时必须附带的最小信息
一张可信的结果表至少应写明：模型与版本、数据集与版本、样本数量、Prompt/聊天模板、zero-shot 或 few-shot、temperature/top-p、最大输出长度、工具权限、裁判与评分规则、重复次数、置信区间、服务地区与测试日期。
如果缺少其中关键项，数字只能作为线索，不能作为采购或上线依据。尤其不要把不同平台、不同日期、不同推理预算下的分数横向排列后宣称绝对排名。
FAQ
哪个指标最能代表模型能力？
没有单一指标。封闭题看 Accuracy 或 Exact Match，代码生成看 Pass@1/Pass@k，仓库修复看 Resolution Rate，开放式回答可看成对偏好；上线还必须加入延迟、成本、稳定性和安全指标。
Arena 分数高就一定更适合业务吗？
不一定。它反映特定题目和投票人群下的相对偏好，不能替代你的业务成功标准。应先用真实脱敏样本建立评测集，再把公开榜单作为候选模型筛选信号。
TPS 越高越好吗？
在质量和成本相当时，更高 TPS 通常意味着更快完成输出；但首字体验主要看 TTFT，短回答中 TTFT 可能比 TPS 更重要。还要关注高并发下的尾延迟。
结论
正确读评测的顺序是：先问任务和判定规则，再看数据集与配置，最后解释分数。能力、偏好、系统体验与业务成本必须分层报告。只有同一输入、同一规则、同一预算下的对比，才足以支持模型选择。