256 lines
4.6 KiB
Markdown
256 lines
4.6 KiB
Markdown
|
---
|
|||
|
|
type: guide
|
|||
|
|
tags:
|
|||
|
|
- llm-evaluation
|
|||
|
|
- foundations
|
|||
|
|
status: active
|
|||
|
|
created: 2026-08-21
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
# 什么是 LLM Evaluation
|
|||
|
|
|
|||
|
|
## 一句话定义
|
|||
|
|
|
|||
|
|
**LLM Evaluation（大语言模型评测）**，是用一组明确的任务、测试数据和评分逻辑，系统地判断模型或 AI 系统是否满足预期行为。
|
|||
|
|
|
|||
|
|
最小结构可以写成：
|
|||
|
|
|
|||
|
|
```text
|
|||
|
|
Task / Case
|
|||
|
|
↓
|
|||
|
|
System under test
|
|||
|
|
↓
|
|||
|
|
Output / Trace / Outcome
|
|||
|
|
↓
|
|||
|
|
Grader
|
|||
|
|
↓
|
|||
|
|
Result
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
OpenAI 的 eval 工作流以任务、测试数据和 grader 为核心；Anthropic 对 Agent eval 的定义也采用同样思路：给系统一个任务，再用 grading logic 判断成功与否。[1][2]
|
|||
|
|
|
|||
|
|
## 评测的对象不只有“模型”
|
|||
|
|
|
|||
|
|
这是最重要的概念边界之一。
|
|||
|
|
|
|||
|
|
### Model Evaluation
|
|||
|
|
|
|||
|
|
关注模型本身的能力或行为，例如：
|
|||
|
|
|
|||
|
|
- 是否遵从指令
|
|||
|
|
- 是否正确回答事实问题
|
|||
|
|
- 是否生成合法 JSON
|
|||
|
|
- 是否完成代码任务
|
|||
|
|
- 是否拒绝危险请求
|
|||
|
|
|
|||
|
|
典型形式：
|
|||
|
|
|
|||
|
|
```text
|
|||
|
|
Prompt → Model → Response → Grader
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### Application / System Evaluation
|
|||
|
|
|
|||
|
|
真实产品通常不只有模型：
|
|||
|
|
|
|||
|
|
```text
|
|||
|
|
User
|
|||
|
|
↓
|
|||
|
|
Router / Prompt
|
|||
|
|
↓
|
|||
|
|
Retriever / Context
|
|||
|
|
↓
|
|||
|
|
Model
|
|||
|
|
↓
|
|||
|
|
Tool
|
|||
|
|
↓
|
|||
|
|
State Change
|
|||
|
|
↓
|
|||
|
|
Final Response
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
因此系统失败可能来自：
|
|||
|
|
|
|||
|
|
- 检索错误
|
|||
|
|
- Prompt / 路由错误
|
|||
|
|
- 模型推理错误
|
|||
|
|
- 工具选择错误
|
|||
|
|
- 参数错误
|
|||
|
|
- 权限错误
|
|||
|
|
- 工具执行错误
|
|||
|
|
- 后处理错误
|
|||
|
|
- Grader 错误
|
|||
|
|
|
|||
|
|
所以成熟的 Evaluation 关注的是**整个系统是否完成目标**，而不是简单问“模型强不强”。
|
|||
|
|
|
|||
|
|
## RAG Evaluation 是什么
|
|||
|
|
|
|||
|
|
RAG（Retrieval-Augmented Generation）评测通常至少拆成两个层面：
|
|||
|
|
|
|||
|
|
### Retrieval Quality
|
|||
|
|
|
|||
|
|
检索阶段是否拿到正确证据：
|
|||
|
|
|
|||
|
|
- relevant documents 是否被取回
|
|||
|
|
- 无关内容是否过多
|
|||
|
|
- 是否漏掉关键片段
|
|||
|
|
- 文档版本是否正确
|
|||
|
|
|
|||
|
|
### Answer Quality
|
|||
|
|
|
|||
|
|
生成阶段是否正确利用证据：
|
|||
|
|
|
|||
|
|
- 回答是否 grounded
|
|||
|
|
- 是否存在文档外无依据事实
|
|||
|
|
- 引用是否正确
|
|||
|
|
- 信息不足时是否说明不确定
|
|||
|
|
- 是否覆盖关键约束
|
|||
|
|
|
|||
|
|
因此：
|
|||
|
|
|
|||
|
|
```text
|
|||
|
|
RAG failure ≠ 一定是模型 failure
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
如果 gold context 根本没有被取回，首先应该定位 Retrieval。
|
|||
|
|
|
|||
|
|
## Agent Evaluation 是什么
|
|||
|
|
|
|||
|
|
Agent 的评测对象更加复杂，因为它会跨多轮调用工具并改变环境状态。
|
|||
|
|
|
|||
|
|
Anthropic 将 Agent eval 中几个关键对象定义为：
|
|||
|
|
|
|||
|
|
- **Task**：一个测试问题与成功条件
|
|||
|
|
- **Trial**：同一 task 的一次尝试
|
|||
|
|
- **Grader**：评分逻辑
|
|||
|
|
- **Transcript / Trace**：完整执行轨迹
|
|||
|
|
- **Outcome**：执行结束后的真实环境状态
|
|||
|
|
- **Evaluation Harness**：运行、记录、评分和汇总 eval 的基础设施[2]
|
|||
|
|
|
|||
|
|
例如 Agent 最后说：
|
|||
|
|
|
|||
|
|
> “会议已经取消。”
|
|||
|
|
|
|||
|
|
这句话本身不是成功证据。
|
|||
|
|
|
|||
|
|
真正的 Outcome 是：
|
|||
|
|
|
|||
|
|
```text
|
|||
|
|
Calendar 中该 event 是否真的不存在
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
所以 Agent Evaluation 的关键原则是：
|
|||
|
|
|
|||
|
|
> **评价真实结果，不只评价最终文本。**
|
|||
|
|
|
|||
|
|
## Offline Eval 与 Online Evaluation
|
|||
|
|
|
|||
|
|
### Offline Eval
|
|||
|
|
|
|||
|
|
在固定测试集上重复运行：
|
|||
|
|
|
|||
|
|
```text
|
|||
|
|
Frozen Dataset
|
|||
|
|
↓
|
|||
|
|
System Version A / B
|
|||
|
|
↓
|
|||
|
|
Compare
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
主要用于：
|
|||
|
|
|
|||
|
|
- 开发阶段比较方案
|
|||
|
|
- 模型升级验证
|
|||
|
|
- Prompt 修改回归
|
|||
|
|
- Release Gate
|
|||
|
|
|
|||
|
|
### Online Signals
|
|||
|
|
|
|||
|
|
来自真实使用环境：
|
|||
|
|
|
|||
|
|
- 用户反馈
|
|||
|
|
- 失败日志
|
|||
|
|
- 人工升级
|
|||
|
|
- A/B test
|
|||
|
|
- 生产监控
|
|||
|
|
- 用户重新提问或纠正
|
|||
|
|
|
|||
|
|
在线信号的重要作用之一，是不断发现新的 regression case：
|
|||
|
|
|
|||
|
|
```text
|
|||
|
|
Production Failure
|
|||
|
|
↓
|
|||
|
|
Root Cause
|
|||
|
|
↓
|
|||
|
|
New Eval Case
|
|||
|
|
↓
|
|||
|
|
Regression Suite
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
因此 Evaluation 不是一次考试，而是一套持续演化的质量系统。
|
|||
|
|
|
|||
|
|
## Evaluation 与 Benchmark 的区别
|
|||
|
|
|
|||
|
|
二者相关，但目的不同。
|
|||
|
|
|
|||
|
|
### Benchmark
|
|||
|
|
|
|||
|
|
通常强调：
|
|||
|
|
|
|||
|
|
- 对外可比较
|
|||
|
|
- 固定任务集
|
|||
|
|
- 横向比较不同模型
|
|||
|
|
- 通用能力指标
|
|||
|
|
|
|||
|
|
例如数学、代码、知识类 benchmark。
|
|||
|
|
|
|||
|
|
### Product Eval
|
|||
|
|
|
|||
|
|
强调：
|
|||
|
|
|
|||
|
|
- 当前产品的真实成功标准
|
|||
|
|
- 真实用户路径
|
|||
|
|
- 风险和边界案例
|
|||
|
|
- 历史 regression
|
|||
|
|
- 可直接指导产品修改
|
|||
|
|
|
|||
|
|
一个模型在公开 benchmark 上更高，不意味着它一定更适合你的产品。
|
|||
|
|
|
|||
|
|
## 程序员应该如何理解 Evaluation
|
|||
|
|
|
|||
|
|
最实用的映射是：
|
|||
|
|
|
|||
|
|
```text
|
|||
|
|
Requirement
|
|||
|
|
↓
|
|||
|
|
Acceptance Criteria
|
|||
|
|
↓
|
|||
|
|
Eval Case
|
|||
|
|
↓
|
|||
|
|
Assertion / Rubric
|
|||
|
|
↓
|
|||
|
|
Run
|
|||
|
|
↓
|
|||
|
|
Failure
|
|||
|
|
↓
|
|||
|
|
Root Cause
|
|||
|
|
↓
|
|||
|
|
Regression
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
因此 LLM Evaluation 的核心不是“评分技术”，而是：
|
|||
|
|
|
|||
|
|
1. 定义正确；
|
|||
|
|
2. 暴露失败；
|
|||
|
|
3. 区分根因；
|
|||
|
|
4. 验证修改；
|
|||
|
|
5. 防止回归。
|
|||
|
|
|
|||
|
|
## 参考资料
|
|||
|
|
|
|||
|
|
[1] OpenAI, Working with evals
|
|||
|
|
https://developers.openai.com/api/docs/guides/evals
|
|||
|
|
|
|||
|
|
[2] Anthropic, Demystifying evals for AI agents
|
|||
|
|
https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents
|