6.5 KiB
type, tags, status, created, updated
| type | tags | status | created | updated | ||
|---|---|---|---|---|---|---|
| guide |
|
active | 2026-08-24 | 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 要可靠、合规，而且真的能把事情办成。”
这里的“可靠”“合规”“办成”都不是可以直接观测的数字。评测首先要把这些抽象目标转成可执行条件，再通过测试取得证据。
Product Requirement
↓
Construct（想测的抽象属性）
↓
Operationalization（操作化）
↓
Success Criteria / Rubric
↓
Eval Cases / Dataset
↓
System Execution
↓
Output / Trace / Outcome
↓
Grader / Measurement
↓
Metrics + Uncertainty
↓
Diagnosis
↓
Decision
因此，LLM 评测不是单纯“给模型打分”，而是在做三件事：
- 定义正确：什么行为才算满足需求？
- 测量正确：我们怎样稳定、有效地观察这种行为？
- 使用正确：这个结果足以支持选模型、上线、回滚或修复吗？
可以进一步压缩成六个动词：
Define → Sample → Execute → Measure → Validate → Improve
一、什么是 LLM Evaluation
一个实用定义是：
LLM Evaluation 是针对模型或 AI 系统设计可重复测试，通过明确的成功标准和评分方法取得行为证据，并据此判断系统是否满足目标要求的过程。
最小结构：
Task / Case
↓
System Under Test
↓
Observed Behavior
↓
Grader
↓
Result
如果是 Agent，还要把“Observed Behavior”拆开：
Output 最终输出
Trace 执行过程
Outcome 最终环境状态
用传统软件测试语言类比：
Requirement
→ Test Case
→ System Under Test
→ Actual Behavior
→ Test Oracle / Assertion
→ Test Result
这里有一个特别重要、但经常被 LLM 教程省略的概念：
Test Oracle（测试判据）
Oracle 是“我们凭什么知道结果对不对”的依据。
它可能是：
- 唯一正确答案；
- 数据库最终状态；
- 单元测试；
- 业务规则；
- Rubric；
- 人类专家判断；
- 经过校准的 LLM Judge。
Grader 是执行判断的组件；Oracle 是判断成立所依赖的正确性依据。
因此：
Oracle = 正确性的依据
Grader = 执行判断的机制
这个区分很重要，因为代码 grader 也可能错：代码本身可以完全确定地执行一个错误的 specification。
二、为什么 LLM 评测比普通单元测试困难
2.1 开放任务没有唯一正确答案
例如：
add(1, 2)
只有一个正确结果：
3
但：
“向初学者解释什么是缓存。”
可能存在很多合格答案。
于是问题从：
输出是否等于 reference？
变成：
输出是否属于“可接受行为集合”？
可以把它想成：
所有可能输出
├── 不可接受
└── 可接受集合
├── 合格答案 A
├── 合格答案 B
└── 合格答案 C
因此开放任务中：
- Rubric 更像集合边界；
- Reference Answer 更像集合里的一个实例。
但不能绝对化。
在以下任务中，reference 本身就可能是最好的 oracle：
- 数值答案；
- 分类标签；
- JSON 结构；
- SQL 执行结果；
- 文件状态；
- 单元测试结果。
所以准确的原则是：
开放任务优先定义行为标准；确定性任务优先使用可验证结果。
2.2 系统行为具有随机性
同一个 case 重复执行：
Trial 1 → PASS
Trial 2 → FAIL
Trial 3 → PASS
所以“这个 case 是否通过”有时只是一次采样。
更完整的问题是：
这个系统在这个任务上的成功概率和稳定性如何？
这就是 trial 和重复测量存在的工程原因。
但这里必须区分两个不同概念：
被测系统的行为稳定性
例如 Agent 同一任务十次成功八次。
这是：
system behavior variability
它反映系统本身的随机性和可靠性。
测量工具的稳定性
例如同一份回答：
Judge Run 1 → PASS
Judge Run 2 → FAIL
这是：
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 可能同时要求：
Task Success
Safety
Policy Compliance
Groundedness
Latency
Cost
User Experience
这些维度可能互相冲突。
例如：
更积极调用工具
[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]