---
type: guide
tags:
  - llm-evaluation
  - foundations
status: active
created: 2026-08-24
updated: 2026-08-24
---

# LLM 评测基础概念与理论：系统讲解

**定位：** 本文是 [[01-What-Is-LLM-Evaluation]]、[[02-Annotation-Human-Data-and-Evaluation]]、[[03-Core-Concept-Map]] 的教学整合版。重点不是堆术语，而是建立一套可以继续承载 RAG Eval、Agent Eval、LLM-as-a-Judge、Benchmark Design 等主题的基础框架。

> ⚠️ **阅读定位：** 本文不是 Stage 1 必读项。完成 [[01-What-Is-LLM-Evaluation]] → [[03-Core-Concept-Map]] 与 [[02-Why-Guide]] 后应进入实践；仅在需要理论支撑（信度/效度、pass@k、失败分析等）时按章节查阅。详见 [[01_Projects/Personal-Tech/LLM_Evaluation/README|专区首页]] Stage 1 停止线。

> [[03-Core-Concept-Map]] 负责术语速查；本文负责解释：**为什么要这样测、结果为什么可信、结果又能支持什么结论。**

---

## 0. 先建立总框架：评测是一条“构念 → 测量 → 决策”的链

假设产品需求是：

> “这个客服 Agent 要可靠、合规，而且真的能把事情办成。”

这里的“可靠”“合规”“办成”都不是可以直接观测的数字。评测首先要把这些抽象目标转成可执行条件，再通过测试取得证据。

```text
Product Requirement
        ↓
Construct（想测的抽象属性）
        ↓
Operationalization（操作化）
        ↓
Success Criteria / Rubric
        ↓
Eval Cases / Dataset
        ↓
System Execution
        ↓
Output / Trace / Outcome
        ↓
Grader / Measurement
        ↓
Metrics + Uncertainty
        ↓
Diagnosis
        ↓
Decision
```

因此，LLM 评测不是单纯“给模型打分”，而是在做三件事：

1. **定义正确**：什么行为才算满足需求？
2. **测量正确**：我们怎样稳定、有效地观察这种行为？
3. **使用正确**：这个结果足以支持选模型、上线、回滚或修复吗？

可以进一步压缩成六个动词：

```text
Define → Sample → Execute → Measure → Validate → Improve
```

---

## 一、什么是 LLM Evaluation

一个实用定义是：

> **LLM Evaluation 是针对模型或 AI 系统设计可重复测试，通过明确的成功标准和评分方法取得行为证据，并据此判断系统是否满足目标要求的过程。**

最小结构：

```text
Task / Case
    ↓
System Under Test
    ↓
Observed Behavior
    ↓
Grader
    ↓
Result
```

如果是 Agent，还要把“Observed Behavior”拆开：

```text
Output      最终输出
Trace       执行过程
Outcome     最终环境状态
```

用传统软件测试语言类比：

```text
Requirement
→ Test Case
→ System Under Test
→ Actual Behavior
→ Test Oracle / Assertion
→ Test Result
```

这里有一个特别重要、但经常被 LLM 教程省略的概念：

### Test Oracle（测试判据）

**Oracle 是“我们凭什么知道结果对不对”的依据。**

它可能是：

- 唯一正确答案；
- 数据库最终状态；
- 单元测试；
- 业务规则；
- Rubric；
- 人类专家判断；
- 经过校准的 LLM Judge。

`Grader` 是执行判断的组件；`Oracle` 是判断成立所依赖的正确性依据。

因此：

```text
Oracle = 正确性的依据
Grader = 执行判断的机制
```

这个区分很重要，因为**代码 grader 也可能错**：代码本身可以完全确定地执行一个错误的 specification。

---

## 二、为什么 LLM 评测比普通单元测试困难

### 2.1 开放任务没有唯一正确答案

例如：

```text
add(1, 2)
```

只有一个正确结果：

```text
3
```

但：

> “向初学者解释什么是缓存。”

可能存在很多合格答案。

于是问题从：

> 输出是否等于 reference？

变成：

> 输出是否属于“可接受行为集合”？

可以把它想成：

```text
所有可能输出
├── 不可接受
└── 可接受集合
    ├── 合格答案 A
    ├── 合格答案 B
    └── 合格答案 C
```

因此开放任务中：

- **Rubric** 更像集合边界；
- **Reference Answer** 更像集合里的一个实例。

但不能绝对化。

在以下任务中，reference 本身就可能是最好的 oracle：

- 数值答案；
- 分类标签；
- JSON 结构；
- SQL 执行结果；
- 文件状态；
- 单元测试结果。

所以准确的原则是：

> **开放任务优先定义行为标准；确定性任务优先使用可验证结果。**

---

### 2.2 系统行为具有随机性

同一个 case 重复执行：

```text
Trial 1 → PASS
Trial 2 → FAIL
Trial 3 → PASS
```

所以“这个 case 是否通过”有时只是一次采样。

更完整的问题是：

> **这个系统在这个任务上的成功概率和稳定性如何？**

这就是 `trial` 和重复测量存在的工程原因。

但这里必须区分两个不同概念：

#### 被测系统的行为稳定性

例如 Agent 同一任务十次成功八次。

这是：

```text
system behavior variability
```

它反映系统本身的随机性和可靠性。

#### 测量工具的稳定性

例如同一份回答：

```text
Judge Run 1 → PASS
Judge Run 2 → FAIL
```

这是：

```text
measurement reliability
```

它反映 grader / annotator 是否稳定。

**不要把这两类波动都笼统叫“信度”。**

---

### 2.3 Grader 本身也会错

Human grader 可能：

- 对 rubric 理解不同；
- 疲劳；
- 标准漂移；
- 缺少领域知识。

LLM Judge 可能：

- 受位置影响；
- 偏好某种表达风格；
- 对冗长回答评分偏高；
- 对模糊标准判断不稳定；
- 被待评内容中的指令干扰。

Code grader 也可能：

- assertion 写错；
- 环境假设错误；
- reference solution 错；
- 只验证了一个过窄实现路径。

所以评测存在一个元问题：

> **我们怎样验证测量工具本身？**

这才是 Calibration、IAA、Human Reference Set、Confusion Matrix、Eval QA 存在的原因。

---

### 2.4 产品目标往往是多维的

一个 Agent 可能同时要求：

```text
Task Success
Safety
Policy Compliance
Groundedness
Latency
Cost
User Experience
```

这些维度可能互相冲突。

例如：

```text
更积极调用工具

[You have received this identical output 3 times. Re-reading '/Users/windy/Documents/vault/my-vault/01_Projects/Personal-Tech/LLM_Evaluation/00-Foundations/04-Concepts-and-Theory.md:raw' will not change it — use a narrower selector (path:A-B), or proceed with the edit.]

[Showing lines 1-300 of 2558. Use :301 to continue]