my-vault/01_Projects/Personal-Tech/LLM_Evaluation/00-Foundations/04-Concepts-and-Theory.md

type, tags, status, created

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

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

定位： 本文是前三篇概念笔记的教学整合——以 01-What-Is-LLM-Evaluation、02-Annotation-Human-Data-and-Evaluation、03-Core-Concept-Map 为骨架，补全背后的理论逻辑，并加入"信度 / 效度"这一贯穿性测量学视角。目标不是记住术语，而是理解每个概念为什么必须存在。

术语速查仍以 03-Core-Concept-Map 为准；本文负责"讲清楚为什么"。

一、评测的定义与最小结构

LLM Evaluation = 用一组明确的任务、测试数据和评分逻辑，系统地判断模型或 AI 系统是否满足预期行为。

最小的不变结构是五段：

Task / Case（测什么）
    ↓
System under test（被测系统：可能是裸模型，也可能是完整产品链路）
    ↓
Output / Trace / Outcome（系统产生的东西）
    ↓
Grader（评分逻辑：代码、人或另一个模型）
    ↓
Result（可比较、可解释的结果）

用测试工程的语言说：这就是"测试用例 → 被测对象 → 实际行为 → 断言 → 测试报告"。OpenAI 与 Anthropic 的官方评测框架都采用这个结构。评测不是一门"给 AI 打分的学问"，而是给 AI 系统建立的测试与测量体系。

二、理论根基：LLM 评测为什么本质上很难

这是理解后面所有概念的钥匙。传统软件测试的三个隐含假设，在 LLM 系统上全部失效。

困难一：没有唯一正确答案

add(1, 2) 必须等于 3，但"解释什么是缓存"有无数个可接受答案。评测的核心问题从"输出是否等于标准答案"变成"输出是否落在可接受集合内"。

由此直接推导出两个结论：

1. Rubric（判定集合成员资格的规则）比 reference answer（集合中的一个样本）更根本；
2. 字符串比较只在确定性任务上有效。

困难二：非确定性

模型带采样温度、Agent 的工具调用路径每次可能不同。"这个 case 通过了吗"这个问题本身不严谨，严格的问法是"这个 case 在 N 次尝试中通过了几次"——这就是 trial 概念的由来。

困难三：评分器本身会出错

代码断言不会撒谎，但 LLM Judge 有偏差（偏好长答案、偏好位置 A），人工标注者会疲劳误判。于是评测有一个递归问题：谁来评判评判者？ 这就是校准（calibration）、一致率（IAA）、混淆矩阵存在的原因。

应对策略：操作化定义

面对这三个困难，整个学科的应对主线只有一条：

操作化定义（Operational Definition）：把模糊的构念（"回答专业""有用"）改写为可被第三方执行和复现的判定条件（"每一条可核验事实均可由给定上下文支持，否则 fail"）。

这个词来自测量理论。一个测量要成立，必须同时满足两件事：

测量学概念	含义	对应的评测实践
信度（Reliability）	不同的人（或同一人不同时间、不同的 Judge）依据同一规则，能否得出相同结论	双人独立标注、盲评、一致率（IAA）、多次 trial
效度（Validity）	你测的是不是你真正想测的东西	rubric 从产品需求推导、Judge 与人工校准、失败归因

记住这对概念，就能给所有零散实践找到理论坐标：盲评和 IAA 提升信度；校准和需求追溯提升效度。 01-LLM-Evaluation-Roadmap 中"标注即规格工程"的说法，规格工程的本质就是操作化定义。

三、核心对象词汇：按"测什么 / 怎么判 / 怎么跑"三组记忆

A 组：测什么（数据侧对象）

概念	含义	关键理解
Task	一个测试问题 + 成功条件	最小测试单元
Eval Case	一条具体测试数据，含 input、expected behavior、metadata（类别/难度/风险/版本）	相当于一条测试用例；metadata 让失败可分组分析
Dataset / Eval Set	一组 case	不是"很多问题"，而是有设计意图的分布：正常、负例、边界、对抗、历史回归
Eval Suite	围绕一个产品目标组织的一组 dataset	如客服套件 = 退款 + 取消 + 升级 + 合规

B 组：怎么判（规格侧对象）

三个概念必须严格区分：

• Rubric：判定规则本身（"Groundedness = fail，如果回答包含至少一个上下文未支持的事实"）。它是规格（specification），不是分数。好的 rubric 的检验标准是：独立评审能得出相近结论。
• Reference Answer：一个可接受答案的示例。它是集合中的一个成员，不是集合的定义。
• Grader：真正执行评分的组件（人或程序或模型）。同一份 rubric 可以被不同 grader 执行。

三者的关系：rubric 是法律条文，reference 是判例，grader 是法官。 混淆它们是新手最常见的概念错误——比如拿 reference 当 rubric 用（只做相似度比较），或以为换一个更强的模型当 Judge 就不需要 rubric。

Grader 分三类，各有适用域：

类型	适用	例子
Code-based	确定性条件	JSON Schema 校验、SQL 是否可执行、单元测试是否通过、状态断言
Human	复杂业务判断、rubric 校准、高风险仲裁	盲评、分歧仲裁
Model-based（LLM-as-a-Judge）	难以硬编码的语义判断	相关性、完整性、是否遵从复杂规则——但必须先与人工校准

实践原则是混合使用：能写代码判的绝不麻烦人，必须人判的用来建立基准和校准，模型 Judge 只在校准通过后用于规模化。

C 组：怎么跑（执行侧对象）

• Run：某系统版本在某数据集版本上的一次执行记录。必须保存版本三元组（system/prompt version、dataset version、rubric version）+ 输出 + 时间戳，否则两次 run 的差异无法归因。
• Trial：同一 task 的一次独立尝试（应对非确定性）。
• Trace / Transcript：Agent 的完整执行轨迹（输入 → 推理 → 工具调用 → 工具结果 → …… → 最终回答）。
• Outcome：执行结束后环境的真实最终状态。
• Harness：端到端跑评测的基础设施：装载 case → 调用系统 → 记录 trace → 运行 grader → 汇总报告，即 LLM 版的 test runner。

最重要的理论区分是 Trace ≠ Outcome ≠ 最终文本。Agent 说"会议已取消"只是文本；trace 记录它声称做了什么；outcome 才是日历里那个事件是否真的没了。Agent 评测的第一原则：评价真实结果，不评价最终文本。

四、评测的四个层级：从 Output 到 Outcome

Level 1 — Output     最终文本是否正确
Level 2 — Component  检索/工具/路由等组件是否正确
Level 3 — Trace      执行路径是否合理、安全
Level 4 — Outcome    真实环境最终状态是否满足目标

越简单的系统越可以停在 Level 1（裸模型答 trivia）；越接近 Agent，越必须下沉到 Level 4。因为 Agent 的典型失败模式是"话说得对，事没办成"——只看 Level 1 会完全漏检。

与层级互补的是横向划分——Model Evaluation vs. System Evaluation。前者测 Prompt → Model → Response；后者测完整链路（路由 → 检索 → 模型 → 工具 → 状态变更 → 后处理）。系统评测的铁律：一条失败不能直接归因"模型不行"。RAG 答错可能因为检索根本没取回 gold context——那是检索组件的问题，换再强的模型也没用。

五、三种评测形态：Benchmark、Product Eval、Monitoring

形态	回答的问题	特点
Benchmark	模型一般能力有多强？	固定任务集、对外可比较、通用能力指标（数学/代码/知识）
Product Eval	对我的产品任务，它是否满足要求？	真实成功标准、真实用户路径、风险与边界 case、历史回归
Monitoring	生产环境现在发生了什么？	用户反馈、失败日志、A/B test、用户重新提问/纠正行为

关键理论点：benchmark 分数高 ≠ 适合你的产品。benchmark 测的是通用能力分布，你的产品关心的是特定任务分布上的表现。三者的成熟闭环：

Benchmark 筛选候选模型 → Product Eval 决定是否适用于产品
→ Monitoring 发现真实失败 → 固化为回归 case → 回流 Eval Set

由此引出另一组二分法：Offline Eval vs. Online Eval。Offline 在冻结数据集上重复运行，用于方案比较和发布门禁，优点是可复现、可归因；Online 信号来自真实使用环境，优点是真实、能发现你想不到的失败，缺点是噪声大、不可控。两者不是替代关系——online 的最大价值之一是为 offline 持续供应新 case。

六、人工数据理论：Annotation、Human Data、Evaluation 的关系

三个词经常被当成一回事，实际是包含关系：

• Annotation（标注）：人按给定规则把原始数据转换为带结构化意义的数据。传统 ML 是打标签（cat/dog）；LLM 场景的"标注"经常是执行复杂 rubric 的判断工作——比较两个回答、给 trace 做失败分类、把差答案改写成理想答案。
• Human Data：更大的集合，为训练/对齐/评测/产品改进而产生的一切人类判断与示范数据。四种形态：Demonstration（示范，SFT 用）、Preference（偏好对）、Critique（带理由的批评）、Evaluation Labels（pass/fail、severity、failure type）。
• Evaluation：用数据 + 规则判断系统表现。它使用标注，但不等于标注。

关键理论区分：同样的标注工作，用途决定性质。

	Training Data	Evaluation Data
目的	改变模型行为	测量系统行为
模型可以学它吗	可以，这正是目的	原则上不可以
版本要求	训练集可演化	正式 eval 集需要冻结
泄漏后果	数据质量问题	evaluation contamination——结果彻底失真

Contamination（评测污染）指系统在开发中已经"见过并针对"了正式测试集，测出的分数过度乐观。这和 ML 里 train/test 不分家是同一个错误，对策也一样：dev / eval / holdout 分离，正式比较期间冻结。

本部分最重要的一句话：人工标注不是评测的低级阶段，它承担两个不可跳过的职责——帮助定义"什么叫正确"（rubric 的来源），以及校准自动 grader 是否可信（暂定真值）。评测体系的演化路径是：人工判断 → 发现规则歧义 → 修 rubric → 建立稳定人工基准 → 规则自动化 / LLM Judge。跳过前面直接上 Judge，等于用一把没校准过的尺子量所有东西。

七、判定方式与测量质量：一致率、校准、仲裁

四种评测形态（按比较方式）

• Pointwise：单独判一个输出 pass/fail。
• Pairwise：比较 A/B，输出 A 更好 / B 更好 / tie。偏好数据和盲评都用它，因为人做相对判断比绝对打分更稳定。
• Absolute Score：给单个输出打分（0/1/2 或 1–5）。只有评分锚点足够清楚时才有意义——这是 01-LLM-Evaluation-Roadmap 坚持第一版用 pass/fail 和 0/1/2、不用 1–5 分的理论依据：人无法稳定区分 3 分和 4 分，这样的量表没有信度。
• 按判定机制分：Deterministic（程序可判：schema、exact match、unit test）vs. Semantic（必须理解语义：完整性、忠实度），后者必然依赖 human 或 model grader。

测量质量的三个概念

1. Calibration（校准）：多个标注者对同一批样本独立判断，再分析分歧。目的不是"凑一致率"，而是通过分歧发现规格的漏洞。
2. Inter-Annotator Agreement（IAA，标注者间一致率）：量化信度的指标。入门用 raw agreement（相同标签数/总数）即可；成熟项目用 Cohen's Kappa、Krippendorff's Alpha——它们会扣除"随机也能一致"的部分。
3. Adjudication（仲裁）：分歧无法通过修规则解决时（真实专业争议），由更高权限或领域专家裁决，并将该类 case 标记为不适合自动评分。

对 LLM-as-a-Judge，校准理论落地为混淆矩阵：以人工盲评为暂定真值，报告 failure precision / failure recall / raw agreement 三个数。安全场景优先看 failure recall（漏放行的比例）而不是 precision，因为 FN（危险输出被 Judge 放行）的代价远高于 FP（好输出被误拦）——这是一个效度问题：测量工具必须对你最在乎的误差方向敏感。

八、失败分析理论：Taxonomy、Severity、Root Cause

测量只完成了一半，评测的产出价值在于失败分析。三个概念构成递进：

1. Failure Taxonomy（失败分类学）：预先定义的失败类型集合。RAG 例：retrieval miss / unsupported claim / wrong citation / over-refusal；Agent 例：wrong tool / wrong arguments / authorization failure / state mismatch。没有分类学，你只有一堆 "fail"，无法统计分布。
2. Severity（严重度）：区分失败的量级。理论依据：格式问题 ≠ 数据误删 ≠ 权限泄漏，平均通过率会把不可接受的失败稀释成可接受的平均数。所以高危失败必须单独门禁，不允许被平均。
3. Root Cause Analysis（根因分析）：把"模型答错了"拆解到具体层——retrieval? prompt? model? tool? permission? post-processing? grader?。不同根因对应完全不同的修复动作和责任方；这是评测从"打分"升级为"工程决策依据"的关键一步。

九、总图：把所有概念串成一条链

03-Core-Concept-Map 第 10 节的主线图，逐环读法：

Product Requirement（产品需求）
        ↓  操作化定义
Rubric（判定规则）
        ↓  实例化
Eval Case → Dataset / Suite（测试数据）
        ↓  执行
Run / Trial → Trace + Outcome（执行记录与真实结果）
        ↓  判定
Grader → Result（评分与结果）
        ↓  分析
Failure Taxonomy → Root Cause（失败分类与根因）
        ↓  改进与防回归
Fix → Regression（修复与永久回归）

上半段是"定义正确"（需求→规则→数据），中段是"测量与暴露失败"（运行→判定），下半段是"区分根因、验证修改、防止回归"。 01-LLM-Evaluation-Roadmap 的 72 小时闭环和 12 周计划，本质就是把这条链的最小版本先跑通，再逐环加固。

十、自测：十个检验理解的问题

读完能不看书回答这些，概念层就过关了：

1. 为什么 rubric 比 reference answer 更根本？各自对应"可接受集合"的什么角色？
2. 信度和效度分别指什么？盲评提升哪个，Judge 校准提升哪个？
3. Task、Trial、Run、Trace、Outcome 五个词分别指什么，两两的区别是什么？
4. 为什么 Agent 评测必须下沉到 Level 4？举一个"文本正确但 outcome 错误"的例子。
5. Benchmark 分数更高的模型为什么可能不适合你的产品？
6. Training data 和 evaluation data 在冻结要求上为何相反？
7. Evaluation contamination 是怎么发生的？dev/eval/holdout 三分如何防它？
8. 什么任务该用 code grader，什么任务必须用 human/model grader？
9. 为什么第一版 rubric 不要用 1–5 分量表？
10. 安全场景下 Judge 校准为什么优先看 failure recall 而不是 precision？

参考资料

• OpenAI, Working with evals
• Anthropic, Demystifying evals for AI agents
• 操作化定义、信度与效度为经典测量学（measurement theory / psychometrics）概念，本文将其与 LLM 评测实践对应。

---

返回 01_Projects/Personal-Tech/LLM_Evaluation/00-Foundations/README。