windy/my-vault

Fork 0

Files

T

windyboy 99c64fec46 add go-docs-qa practice project: project overview and task-and-rubric

2026-08-24 17:52:43 +08:00

40 KiB

Raw Blame History

type, tags, status, created, updated

type

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 等主题的基础框架。

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)

只有一个正确结果：

但：

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

可能存在很多合格答案。

于是问题从：

输出是否等于 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

这些维度可能互相冲突。

例如：

更积极调用工具
→ 任务成功率可能提高
→ 成本和风险也可能提高

因此一个单一总分经常不足以表达真实产品质量。

成熟做法通常是：

多个独立指标
+
必要的聚合
+
关键风险 Hard Gate

而不是把所有东西压成一个 0–100 分。

2.5 评测结果依赖测试分布和执行环境

一个模型得到：

Benchmark A = 92%

只说明它在：

Benchmark A 的任务分布
+
对应 prompt / harness / grader / environment

下取得了这个结果。

不能自动推出：

“它在所有真实业务上都有 92% 的能力。”

这就是后面 Coverage、Product Eval、Holdout、Production Monitoring 都必须存在的原因。

三、操作化定义：把“好”变成“可测”

3.1 Construct（构念）

Construct 是我们真正想讨论、但不能直接观测的属性。

例如：

有用
可靠
安全
忠实
专业

这些词不能直接作为 grader。

3.2 Operationalization（操作化）

操作化是把抽象构念转换成可观察条件。

例如：

“回答忠实”

改写成：

回答中所有可外部核验的事实性陈述，都必须得到给定证据支持；否则 groundedness = FAIL。

于是：

Construct
    ↓
Operational Definition
    ↓
Observable Criteria

评测设计最核心的工作，往往就在这里。

四、测量学视角：Reliability 与 Validity

4.1 Reliability：测量结果稳定吗？

这里的 Reliability 指的是测量过程的可靠性。

典型问题：

不同标注者依据同一 rubric，会得到相近判断吗？

同一个 Judge 对同一输入重复评分，会稳定吗？

常见证据：

raw agreement；
Cohen's Kappa；
Krippendorff's Alpha；
重复 Judge 运行；
双人独立标注。

需要注意：

IAA 衡量的是评分者间一致性，不是模型本身的生产可靠性。

4.2 Validity：这个测量支持我们想做的解释吗？

Validity 更深一层。

假设产品真正关心：

“退款有没有成功。”

但 grader 只检查最终回答有没有说：

退款成功。

这个 grader 可以做到 100% 稳定，却仍然测错东西。

所以：

Reliability 高
≠
Validity 高

4.3 三个常用的效度视角

下面采用经典测量学中常见的三个学习视角。它们不是唯一分类，但对 LLM Eval 很有帮助。

Content Validity：内容覆盖够吗？

问：

测试内容有没有覆盖目标能力的重要部分？

例如客服 Eval 全部都是正常退款，却完全没有：

越权退款
身份验证失败
恶意用户
边界金额
重复请求

那么即使通过率很高，也可能存在 coverage 缺口。

Construct Validity：真的测到目标构念了吗？

例如声称测：

Groundedness

但 Judge 实际上主要因为：

答案长
语言正式
引用很多

而给高分。

这说明测量可能混入了别的因素。

例如：

Offline Eval Score ↑

是否对应：

真实任务成功率 ↑
用户投诉 ↓
生产故障 ↓

如果完全脱节，就要重新检查 eval 是否代表真实业务。

4.4 一个重要提醒：效度不是“某个 rubric 天生拥有的属性”

更准确地说：

我们为某个测量结果及其用途提供多少有效证据。

同一个 benchmark：

用于比较某类数学题能力，可能合理；
用来证明“通用智能”，就可能过度外推。

因此：

Score
+
Evaluation Context
+
Intended Interpretation

必须一起看。

五、核心对象：Task、Case、Dataset、Suite

不同框架术语并不完全统一。

Anthropic 把：

task ≈ problem ≈ test case

作为近义词。

为了自己的 Obsidian 知识库更清晰，可以采用以下本地约定：

Task

一个抽象测试意图。

例如：

测试 Agent 是否会拒绝越权删除。

Eval Case

Task 的具体实例。

例如：

task: unauthorized_delete
input:
  user_id: U1
  request: "删除 U2 的文件"
expected_behavior:
  - refuse
  - explain_permission_boundary
metadata:
  risk: high

于是：

Task = 测什么类型的能力
Case = 用什么具体实例来测

这是教学约定，不是行业强制标准。

Dataset / Eval Set

一组 cases。

真正好的 Eval Set 不是“很多问题”，而是一个经过设计的测试分布。

Eval Suite

围绕某个能力或产品目标组织的一组 tasks / cases / datasets。

例如：

Customer Support Suite
├── Refund
├── Cancellation
├── Authentication
├── Escalation
└── Policy Compliance

六、规格侧对象：Rubric、Reference、Oracle、Grader

这是最值得严格区分的一组概念。

Rubric

Rubric = 判定规则。

例如：

Groundedness = FAIL
if at least one externally verifiable factual claim
is unsupported by the supplied evidence.

Rubric 是 specification 的一部分。

Reference Answer / Reference Solution

Reference = 已知合格实例。

它可以用于：

给 human / judge 提供 anchor；
做相似度判断；
验证 task 是否可解；
验证 grader 是否配置正确。

对于 Agent / coding eval，reference solution 还有很重要的 Eval QA 作用：

如果一个已知正确方案都不能通过 grader，那么首先应该修 eval。

Test Oracle

Oracle = 判断正确性的依据。

例如：

expected database state
unit tests
business rules
rubric
expert consensus

Reference 可以是 oracle 的一部分，但二者不等价。

Grader

Grader = 实际执行判断的组件。

可以记成：

Rubric     = 规则
Reference  = 合格实例
Oracle     = 正确性依据
Grader     = 执行判断

类比：

法律条文 → Rubric
判例     → Reference
法律标准 → Oracle
法官     → Grader

这个类比只是帮助记忆，不要把它当严格定义。

七、Grader 的三种基本类型

7.1 Code-based

适用于存在明确、可程序验证条件的任务。

例如：

exact match；
regex；
JSON Schema；
SQL execution；
unit tests；
static analysis；
database state；
file existence；
tool arguments；
latency / token count。

优点：

便宜
快
稳定
易调试

缺点：

可能过度刚性
容易漏掉有效变体
实现错误时会稳定地判错

7.2 Human

适用于：

rubric 开发；
专业领域判断；
主观质量；
高风险仲裁；
Judge 校准；
ambiguous case 分析。

Human grader 最重要的作用不是“大规模生产标签”，而是：

帮助建立可信的 reference standard。

主观任务里应该叫 reference standard，而不是轻易叫 ground truth。

7.3 Model-based / LLM-as-a-Judge

适用于难以硬编码的语义条件：

completeness；
relevance；
style；
groundedness；
instruction following；
policy compliance。

原则：

LLM Judge 是 measurement instrument，不是天然真值。

使用前要验证：

与 human reference 的一致性；
关键失败的 recall；
对 prompt / position / wording 的敏感性；
重复运行稳定性。

7.4 Composite Grading

复杂任务通常需要多个 grader。

例如退款 Agent：

Task Success
├── State Grader
│   └── refund.status == processed
├── Policy Grader
│   └── refund_amount <= allowed_limit
├── Trace Grader
│   └── identity_verified == true
└── Communication Grader
    └── explanation satisfies rubric

注意：

多 grader 不等于一定要平均。

常见组合方式：

binary gate
weighted score
partial credit
hybrid

高风险条件更适合作为：

Hard Gate

八、执行侧对象：Run、Trial、Trace、Outcome、Harness

Trial

同一个 task / case 的一次尝试。

Case A
├── Trial 1
├── Trial 2
└── Trial 3

Run

Run 更常表示一次版本化的评测执行。

它可能包含：

很多 cases
×
每个 case 的一个或多个 trials

建议保存：

system version
model version
prompt version
dataset version
rubric version
grader version
sampling parameters
environment version
timestamp

否则：

Run A = 82%
Run B = 87%

无法判断变化来自哪里。

run 是框架相关术语，不同平台粒度可能不同；知识库中最好明确自己的约定。

Trace / Transcript / Trajectory

Agent 执行过程的记录，例如：

User
 ↓
Model
 ↓
Tool Call
 ↓
Tool Result
 ↓
Model
 ↓
...
 ↓
Final Response

它回答：

系统是怎么完成任务的？

Outcome

执行结束后环境中的真实结果。

例如：

Output:
"会议已经取消。"

Trace:
calendar.cancel(event_id)

Outcome:
event.status == cancelled

因此：

Output ≠ Trace ≠ Outcome

九、Agent Eval：结果与过程分别什么时候重要

一个实用原则是：

如果任务目标是改变外部世界，优先验证可观察的最终状态；如果路径本身属于安全、合规或资源约束，则同时验证 Trace。

例如删除文件：

最终文件不存在

通常比：

必须调用 rm

更重要。

过度规定工具调用顺序会产生 brittle eval。

但以下过程不能忽略：

authentication；
authorization；
policy checks；
prohibited tools；
secret access；
irreversible actions；
cost budget；
turn limit；
mandatory confirmation。

所以可以记：

Outcome:
事情做成了吗？

Trace:
事情是以允许的方式做成的吗？

十、一个教学用的四层评测视图

下面的四层是本文的教学框架，不是行业统一标准：

Level 1 — Output
Level 2 — Component
Level 3 — Trace
Level 4 — Outcome

Level 1：Output

检查：

文本正确性
格式
风格
回答质量

Level 2：Component

检查：

retrieval
reranking
routing
tool selection
SQL generation

Level 3：Trace

检查：

步骤
工具调用
权限
循环
成本

Level 4：Outcome

检查：

数据库状态
文件
订单
日历
真实执行结果

并不是所有系统都必须“做到 Level 4”。

例如：

纯问答任务的 outcome 可能就是答案本身；
research agent 的主要产物可能就是报告；
只有真正改变外部状态的 Agent，Outcome 才特别关键。

所以不要记成：

“越高层越专业。”

应该记成：

选择最接近产品真实成功条件的观测层。

十一、Agent Harness 与 Eval Harness

Agent Harness / Scaffold

负责让模型能够作为 Agent 行动：

context management
agent loop
tool orchestration
state handling

可以粗略写成：

Model + Agent Harness = Agent System

Eval Harness

负责测试 Agent System：

Load Cases
     ↓
Initialize Environment
     ↓
Run Agent
     ↓
Capture Trace
     ↓
Inspect Outcome
     ↓
Run Graders
     ↓
Aggregate Results

因此：

Agent Harness ≠ Eval Harness

而且：

Agent Eval 测到的通常是 model + prompt + harness + tools + environment 的组合，而不只是模型。

十二、Dataset Design：Coverage 比 case 数量更重要

12.1 Coverage

Eval 不可能覆盖整个输入空间。

所以要问：

测试集覆盖了哪些重要行为区域？

常见维度：

task type
difficulty
risk
user type
language
tool
edge case
failure mode
environment condition

因此：

Eval score 永远是特定测试分布上的表现。

12.2 Positive 与 Negative Case

只测试：

应该搜索

可能把系统优化成：

什么都搜索

所以还要测试：

不应该搜索

同理：

应该拒绝 / 不应该拒绝
应该升级 / 不应该升级
应该调用工具 / 不应该调用工具

这可以防止：

one-sided optimization

12.3 Capability Eval 与 Regression Eval

Capability Eval

问：

目前能力边界在哪里？

通常应该包含不少难题和失败。

它提供：

hill to climb

Regression Eval

问：

以前已经可靠通过的能力有没有退化？

目标通常接近：

100% pass

所以成熟体系会同时有：

Capability Suite
+
Regression Suite

当 capability eval 接近饱和时，其中稳定通过的部分可以逐渐转入 regression suite。

12.4 Eval Saturation

如果：

Pass Rate ≈ 100%

可能意味着：

系统确实很好；
测试已经失去区分能力。

饱和后的 suite 仍可以发现 regression，却很难继续测 capability improvement。

十三、Dev / Eval / Holdout 与 Contamination

Dev Set

允许开发期频繁查看，用于：

debug
prompt iteration
rubric development

Eval Set

用于正式比较和 release decision。

在一次正式比较窗口中：

dataset version
grader version
rubric version

应该固定。

Holdout

更严格隐藏，用于检查：

是否对已知 eval 过拟合

Evaluation Contamination

当系统开发过程反复针对正式测试样本优化时：

score ↑

可能只是：

overfitting to eval

而不是：

general capability ↑

公开 benchmark 还存在额外问题：

模型预训练过程中可能已经见过题目或高度相似的数据。

因此关键产品决策通常更值得依赖：

private
recent
representative
versioned

的产品 eval。

关于“冻结”的正确说法

不要记成：

Eval Set 永远不能改。

应该记成：

一次比较所使用的版本必须冻结；长期 Eval Suite 则需要持续维护和版本化。

这同时服务于：

reproducibility
+
continued relevance

十四、非确定性指标：pass@1、pass@k、pass^k

假设某任务每次独立尝试成功概率都是 p。

pass@1

就是单次成功概率。

对于：

用户通常只有一次真实交互机会

首先应该关注：

pass@1

pass@k

k 次尝试至少成功一次：

1 - (1-p)^k

适合：

系统允许生成多个候选，只要一个成功即可。

例如某些代码生成、搜索、候选方案场景。

pass^k

k 次尝试全部成功：

p^k

它是一个更严格的连续成功压力指标。

适合回答：

如果重复执行很多次，这个行为能否持续稳定？

重要限制

上面的简式公式假设：

每次 trial 独立
+
成功概率相同

实际 Agent 中可能不成立：

shared cache；
shared environment；
rate limit；
correlated tool failure；
task 难度不同。

所以这些公式主要帮助理解概念。

真实 benchmark 统计时，应区分：

per-task empirical trials

与：

across-task aggregate estimator

不要把一个简单的 p 当成所有 case 的共同成功率。

十五、结果是估计，不是真值

假设：

100 cases
83 pass

我们观察到：

83%

但这不是一个无限精确的“真实能力值”。

可以用一个概念式理解：

Observed Result
=
System Performance
+
Sampling Variation
+
Measurement Error
+
Environment Noise

所以：

A = 83%
B = 84%

并不足以自动证明 B 更好。

还要考虑：

sample size；
paired cases；
confidence interval；
bootstrap；
trial variability；
grader variability。

15.1 为什么 Paired Comparison 很重要

比较两个系统时，最好让：

System A
System B

跑同一批 cases。

这样可以直接观察：

哪些 case 从 fail → pass
哪些 case 从 pass → fail

比比较两个完全不同样本的平均分更容易归因。

15.2 Slice Analysis

总分：

Overall = 90%

可能隐藏：

Normal = 99%
Edge   = 88%
Safety = 45%

所以必须按 metadata 切分：

risk
task
difficulty
language
tool
failure type

15.3 Micro / Macro / Weighted

Micro

所有 case 放在一起计算。

大类别自然占更大权重。

Macro

先按类别算，再对类别平均。

适合：

各类别业务意义接近，但样本数量不平衡。

Weighted

按产品价值人为赋权。

例如：

Task Success × 3
Quality      × 2
Style        × 1

但高风险指标通常不应该只靠加权：

Safety Critical Failure = 0

往往比：

Safety × 5

更符合真实发布决策。

十六、Human Data、Annotation 与 Evaluation

Annotation

人按照规则对数据做结构化判断。

例如：

Answer A vs B → A better
Trace → wrong_tool
Response → pass / fail

Human Data

范围更广，包括：

Demonstration

Instruction
    ↓
Human Ideal Response

常用于 SFT。

Preference

A > B

Critique

指出：

哪里错
为什么错
怎么改

Evaluation Labels

例如：

pass/fail
severity
failure_type
score

Evaluation

Evaluation 使用数据和规则衡量系统表现。

所以：

Annotation ≠ Evaluation

也不能简单说：

Annotation ⊂ Evaluation

因为 annotation 还可以服务于训练、研究和数据治理。

更准确的是：

Annotation 是生产结构化 human judgment 的一种过程；Evaluation 可以使用这些判断。

十七、Training Data 与 Evaluation Data

同一条：

Prompt + Ideal Answer

既可能用于训练，也可能用于评测。

区别首先在用途：

	Training Data	Evaluation Data
目的	改变系统行为	测量系统行为
是否用于学习	是	正式评测原则上避免
版本管理	同样需要版本化	比较窗口必须冻结
泄漏问题	影响训练质量或泛化	直接损害评测解释

所以不要把二者说成：

“训练集可以随便变，评测集必须永远不变。”

它们都需要严谨的数据治理，只是目标不同。

十八、Calibration、Blind Review、IAA、Adjudication

这几个词解决不同问题。

Blind Review

尽量隐藏与任务无关但可能影响评分的信息，例如：

模型品牌
系统名称
实验组身份

它主要用于：

reduce bias

并不等于“自动提高信度”。

Calibration

多个评审者先独立判断同一批样本：

Annotator A
Annotator B
Annotator C

然后分析分歧：

rubric ambiguous?
example missing?
domain knowledge missing?
case genuinely ambiguous?

所以 Calibration 的重要价值是：

发现 specification 和 measurement 的问题。

IAA

Inter-Annotator Agreement 衡量评分者的一致程度。

Raw Agreement

一致样本数 / 总样本数

直观，但不考虑类别分布和随机一致。

Cohen's Kappa

核心思想：

(observed agreement - expected agreement)
/
(1 - expected agreement)

它尝试扣除按边际分布产生的 chance agreement。

但不要记成：

“Kappa 永远比 raw agreement 更诚实。”

Kappa 会受到类别 prevalence 和边际分布影响，并存在著名的 kappa paradox：

raw agreement 很高
但 kappa 可能很低

因此实践中应该同时查看：

raw agreement
class prevalence
confusion pattern
kappa / alpha 等指标

而不是迷信一个数字。

Adjudication

当分歧无法直接通过 rubric 修订解决时：

Reviewer A
   ↘
   Expert
   ↗
Reviewer B

由更高权限或领域专家仲裁。

真正没有明确答案的样本应该允许：

ambiguous

而不是强行创造假“ground truth”。

十九、LLM-as-a-Judge：怎样校准

假设 Human Reference Label：

PASS / FAIL

并把 FAIL 定义成正类：

	Human FAIL	Human PASS
Judge FAIL	TP	FP
Judge PASS	FN	TN

Failure Recall

TP / (TP + FN)

含义：

所有真实 failure 中，有多少被 Judge 检出。

Failure Precision

TP / (TP + FP)

含义：

Judge 判 failure 的样本中，有多少真的 failure。

False Negative Rate

FN / (TP + FN)

所以：

FNR = 1 - Failure Recall

安全场景常常更重视：

high failure recall
low false negative rate

因为真正危险的是：

危险输出
→ Judge PASS

注意正确表述：

Failure Recall 不是“漏放行比例”；漏放行比例是 False Negative Rate。

不要只看 Agreement

如果：

95% PASS
5% FAIL

一个 Judge 永远预测：

PASS

仍然可能得到：

95% raw agreement

但：

failure recall = 0%

所以 Judge 校准至少要看：

confusion matrix
precision / recall
class distribution
agreement

Multi-Judge Consensus 的边界

多个 Judge 可以减少部分单模型随机性，但：

多个相关模型可能共享同样的系统性偏差。

所以：

3 个 Judge 同意

不等于：

Human Validity 已证明

multi-judge 是工具，不是 human calibration 的替代品。

二十、Benchmark、Product Eval、Monitoring

Benchmark

问：

模型在一个标准化任务分布上的表现怎样？

适合：

横向比较；
通用能力研究；
筛选候选模型。

Product Eval

问：

对我的产品和真实成功标准，它是否够好？

例如客服系统真正可能关心：

refund success
unauthorized action rate
false refusal rate
escalation quality
latency
cost

因此：

Benchmark 高
≠
Product Fit 高

Production Monitoring

问：

真实环境现在发生了什么？

例如：

user feedback；
tool errors；
task completion；
repeated questions；
manual transcript review；
support escalation；
production incidents。

二十一、Offline Eval 与 Online Evidence

Offline

优势：

controlled
repeatable
fast
safe

适合：

CI
model comparison
prompt changes
release gate

Online

优势：

real users
real distribution
unexpected failure modes

但：

noise high
ground truth sparse
user impact real

两者应该形成闭环：

Offline Eval
    ↓
Deploy
    ↓
Monitoring / Feedback
    ↓
New Failure
    ↓
Curated Eval Case
    ↓
Regression Suite

二十二、Goodhart's Law：作为警告，而不是绝对定律

常见表述：

When a measure becomes a target, it ceases to be a good measure.

它提醒我们：

团队如果长期只优化一个公开指标，就可能逐渐优化“指标本身”，而不是原本真正关心的目标。

但不要推导成：

“指标只有不当目标时才有意义。”

工程团队当然可以围绕指标优化。

更合理的防护是：

多维指标
private holdout
真实生产信号
定期更新 cases
anti-gaming checks

所以 Goodhart 在 Eval 中更像：

不要让 proxy metric 取代原始产品目标。

二十三、Failure Taxonomy、Severity、Root Cause

Failure Taxonomy

回答：

发生了什么？

例如 RAG：

retrieval_miss
wrong_document
unsupported_claim
citation_error

Agent：

wrong_tool
wrong_arguments
permission_failure
planning_loop
state_mismatch
false_success_claim

Severity

回答：

有多严重？

例如：

S0 Cosmetic
S1 Minor
S2 Major
S3 Critical

这样：

格式错误

和：

越权删除数据

不会被当成同一种 fail。

Root Cause Analysis

回答：

为什么发生？应该在哪一层修？

例如：

Unsupported Answer

可能来自：

retrieval miss
context truncation
prompt
generation
post-processing
grader bug

所以：

Observed Failure
≠
Model Failure

一个重要修正：“根因是模型”并非永远错误

如果已经排除了：

data
prompt
retrieval
tool
environment
grader

而模型在清晰、可解、稳定的任务上仍持续失败，那么：

model capability limitation

完全可以是有效结论。

根因分析的目标不是“永远不要怪模型”，而是：

避免在没有证据时把系统失败直接归给模型。

二十四、Eval Failure 也是 Failure

成熟的 Eval 系统应该允许：

eval_bug

例如：

bad rubric
broken grader
incorrect reference
unsolvable task
environment issue
harness issue

特别是：

frontier model
+
大量 trials
+
始终 0%

首先应该检查：

task 是否可解
grader 是否公平
environment 是否正常
reference solution 是否能过

而不是马上断言：

model incapable

二十五、真正的 Eval Flywheel

评测的价值不止是产生分数。

完整工程闭环应该是：

Production Failure
       ↓
Reproduce
       ↓
Create Eval Case
       ↓
Classify Failure
       ↓
Root Cause
       ↓
Fix
       ↓
Verify
       ↓
Add Regression Case

这件事的本质是：

把一次偶然发现的失败，转成永久可执行的质量知识。

二十六、十个常见错误心智模型

1. Benchmark 高 = 产品一定好

错误。

正确：

performance is distribution- and setup-dependent

2. Reference Answer = 唯一正确答案

只适用于部分确定性任务。

3. Code Grader = Ground Truth

错误。

代码可以稳定执行一个错误 oracle。

4. Judge 模型越强 = Judge 越可信

错误。

Judge 仍然需要 calibration。

5. IAA 高 = Eval 一定有效

错误。

所有评分者可以非常一致地测错东西。

6. 多次 Trial = 在测 grader 信度

不一定。

Trial 首先用于观察被测系统本身的行为随机性。

7. 用户只有一次机会，所以应该看 pass^k

不准确。

一次真实机会首先看：

pass@1

pass^k 是更严格的连续成功指标。

8. Agent Eval 必须做到 Level 4

错误。

应该选择与真实任务成功条件最接近的观测层。

9. Eval Set 应该永久冻结

错误。

comparison version 要冻结
suite 生命周期要维护

10. Score 提高 = 系统一定提高