Evaluation & Benchmarking

LLM Benchmark 可以分为三个层次：

LLM Evaluation
├── Model Capability Benchmark
│   ├── Knowledge / Reasoning
│   ├── Mathematics / Coding
│   ├── Instruction Following
│   └── Long Context / Tool Calling
│
├── Inference Performance Benchmark
│   ├── TTFT / TPOT / ITL
│   ├── Latency / Throughput
│   ├── Concurrency / Goodput
│   └── GPU Memory
│
└── End-to-End Benchmark
    ├── Agent Task Success
    ├── RAG Quality
    ├── Tool Call Accuracy
    └── Latency / Cost / Reliability

1. Model Capability Benchmark

用于衡量模型本身的能力，而不是推理引擎运行速度。

常见评测维度：

• 知识与事实准确性。
• 数学和逻辑推理。
• 代码生成。
• 指令遵循。
• 多语言能力。
• 长上下文理解。
• Tool Calling 和 Agent 能力。

常用指标

Pass@k

例如对于一道代码题：

Generate 5 Solutions

Solution 1 → Fail
Solution 2 → Fail
Solution 3 → Pass
Solution 4 → Fail
Solution 5 → Fail

这次采样的 5 个候选中至少有一个正确，因此对应的 Pass@5 事件为成功。

正式评测中，通常对多道题及多次采样统计 Pass@k；如果使用 n 个候选、其中 c 个通过测试，可以使用标准无偏估计：

$$\operatorname{pass@k}=1-\frac{\binom{n-c}{k}}{\binom{n}{k}}$$

注意：Pass@k 不是把单个答案的 Accuracy 简单乘以 k。

评测常见问题

• Data Contamination：测试题或答案进入训练数据。
• Benchmark Leakage：测试集、答案或评测信息泄漏。
• Prompt Sensitivity：不同 Prompt / Chat Template 影响结果。
• Sampling Differences：Temperature、Top-p、生成次数不同。
• Judge Bias：LLM Judge 的长度偏好、位置偏好或模型偏好。

比较模型时，应尽量统一评测配置，并记录模型版本、Prompt、生成参数和评测程序版本。

2. 常见模型能力 Benchmark

SWE-bench

SWE-bench 让模型或 Agent 处理真实 GitHub Repository 中的软件问题。

GitHub Issue
      ↓
Agent Reads Repository
      ↓
Modify Code
      ↓
Run Tests
      ↓
Resolved / Failed

相比 HumanEval，它更接近真实软件工程。

但这类结果高度依赖 Agent Scaffold、工具权限、测试环境和执行预算，不能完全归因于基础模型。

此外，2026 年 OpenAI 公开指出 SWE-bench Verified 已受到明显数据污染，并建议改用更新、更可靠的评测基准。因此应谨慎使用 Verified 排行榜分数判断前沿编码能力。

3. Inference Performance Benchmark

推理性能 Benchmark 研究同一个模型在不同硬件、推理引擎、量化方案和负载下的运行效率。

核心指标

TTFT 与 TPOT

对于输出 Token 数大于 1 的请求：

$$TPOT=\frac{Latency-TTFT}{OutputTokens-1}$$

ITL 统计相邻输出之间的延迟，而 TPOT 一般是请求级平均值。

在 Streaming 中，两者相关但不完全相同。

不同 Benchmark 工具的测量位置与统计口径可能不同，比较前需要确认公式。

Goodput

Throughput 高不一定代表用户体验好。

假设服务器每秒完成 100 个请求，但是其中许多请求延迟超过要求。

Goodput 只统计满足 Service Level Objective（SLO）的请求。

例如：

SLO:
TTFT < 1 s
TPOT < 50 ms

100 requests/s total

80 requests/s meet SLO
20 requests/s violate SLO

Goodput = 80 requests/s

实际 SLO 阈值应由产品需求决定。

Goodput 对生产 Serving 尤其重要，因为它把系统处理能力与用户体验约束结合起来。

4. 推理性能测试场景

负载模型

两个重要概念：

Closed-loop Benchmark

固定一定数量的并发客户端，一个请求完成后继续发起下一个。

N Concurrent Clients
       ↓
Request → Response → Next Request

Open-loop Benchmark

按照设定的请求到达速率发送请求，不必等待上一请求完成。

5 Requests/s
10 Requests/s
20 Requests/s
...

Open-loop 更适合研究给定请求到达速率下的排队、延迟和系统容量。

测试注意事项

应固定：

• 模型及精度。
• GPU 型号与数量。
• 推理引擎版本。
• 输入 / 输出 Token 长度分布。
• 请求到达速率或并发数。
• Prefix Cache 设置。
• Sampling 参数。

还应考虑预热、测试时长和多次重复测量。

对延迟建议至少报告 P50、P95、P99，而不是只报告平均值。

5. End-to-End Benchmark

端到端评测关心整个应用是否真正完成用户目标。

User Request
      ↓
Application / Agent
      ↓
Retrieval / Tool Calling
      ↓
LLM
      ↓
Final Result
      ↓
Task Evaluation

常见指标：

模型回答得好，不代表整个 Agent 或 RAG 应用一定能正确完成任务。

6. Agent Evaluation

Agent 评测主要关注工具选择、参数、执行路径和最终结果。

User Task
    ↓
Plan / Reason
    ↓
Select Tool
    ↓
Generate Arguments
    ↓
Execute Tool
    ↓
Observe Result
    ↓
Continue / Finish

核心指标

最重要的原则

Task Success Rate 通常比单独的 Tool-call Accuracy 更重要。

例如一个 Agent 工具选择完全正确，但最终没有完成用户任务，仍然应算任务失败。

同时，Steps 越少不代表一定越好；减少步骤不能以降低成功率为代价。

对于 Agent 系统，评测环境还应该尽量可重复，包括工具返回值、外部状态和测试数据。

7. RAG Evaluation

RAG 通常分成 Retrieval 与 Generation 两部分评估。

User Query
     ↓
Retriever
     ↓
Retrieved Documents
     ↓
LLM
     ↓
Generated Answer

Retrieval 指标

Recall@k

例如某个 Query 有 4 篇相关文档。

Top-5 找到其中 3 篇：

[ Recall@5=\frac34=0.75 ]

如果只关心是否至少找到一篇相关文档，可以使用 Hit Rate@k，但它与 Recall@k 不完全相同。

Precision@k

Top-5 中有 3 篇相关：

[ Precision@5=\frac35=0.6 ]

MRR

Mean Reciprocal Rank 关注第一个相关结果的位置。

Rank 1 → 1
Rank 2 → 1/2
Rank 5 → 1/5
No relevant result → 0

对多个 Query 的倒数排名取平均。

NDCG@k

Normalized Discounted Cumulative Gain 同时考虑：

• 文档相关性等级。
• 文档排序位置。

高相关文档排在前面通常得到更高分数。

常见取值范围为 0～1。

Generation 指标

Faithfulness 与 Correctness

这两个概念容易混淆。

Faithfulness 衡量回答是否有检索上下文作为依据。

Correctness 衡量回答是否事实上正确。

例如，检索文档包含错误信息，LLM 忠实地复述：

Faithfulness → 可能很高
Correctness  → 可能很低

因此 RAG 不能只看 Faithfulness，还需要评估检索来源质量和最终答案正确性。

Ragas 将 Faithfulness、Context Precision、Context Recall、Response Relevancy 等作为不同评测指标。

8. 常用评测工具

vLLM Benchmark 示例

vllm bench serve \
  --backend openai-chat \
  --base-url http://localhost:8000 \
  --model your-model-id \
  --dataset-name random \
  --num-prompts 100 \
  --request-rate 5

这个示例使用随机合成请求，适合初步性能测试；运行前需要启动兼容的模型服务，并确保模型名称一致。

实际压测应尽量使用与生产环境相似的 Prompt 长度及请求分布。

9. 评测结果的可靠性

Benchmark 的可信度不仅取决于评测集，还取决于实验设计。

重点检查：

尤其在 Agent/RAG 应用中，应建立与实际业务任务对应的小型内部评测集。

例如 100 条真实业务请求，通常比只依赖某个通用模型排行榜更有决策价值。

总结

最重要的三个原则：

1. 能力、速度和系统成功率需要分别评测，不能只看一个 Benchmark 分数。
2. 公平比较需要固定测试条件，否则结果可能没有可比性。
3. 生产系统应关注质量、延迟、吞吐量和成本的综合表现，而不只是追求最高 Tokens/s。

---

参考文档

• lm-evaluation-harness
• vLLM Benchmarking
• GuideLLM
• Ragas Metrics
• DeepEval
• SWE-bench