diff --git a/01_Projects/Personal-Tech/LLM_Evaluation/00-Foundations/04-Concepts-and-Theory.md b/01_Projects/Personal-Tech/LLM_Evaluation/00-Foundations/04-Concepts-and-Theory.md
new file mode 100644
index 0000000..df8b9a1
--- /dev/null
+++ b/01_Projects/Personal-Tech/LLM_Evaluation/00-Foundations/04-Concepts-and-Theory.md
@@ -0,0 +1,234 @@
+---
+type: guide
+tags:
+  - llm-evaluation
+  - foundations
+status: active
+created: 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 系统是否满足预期行为。**
+
+最小的不变结构是五段：
+
+```text
+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
+
+```text
+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 测的是通用能力分布，你的产品关心的是特定任务分布上的表现。三者的成熟闭环：
+
+```text
+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 节的主线图，逐环读法：
+
+```text
+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*](https://developers.openai.com/api/docs/guides/evals)
+- [Anthropic, *Demystifying evals for AI agents*](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents)
+- 操作化定义、信度与效度为经典测量学（measurement theory / psychometrics）概念，本文将其与 LLM 评测实践对应。
+
+---
+
+返回 [[01_Projects/Personal-Tech/LLM_Evaluation/00-Foundations/README|Foundations 首页]]。
diff --git a/01_Projects/Personal-Tech/LLM_Evaluation/00-Foundations/README.md b/01_Projects/Personal-Tech/LLM_Evaluation/00-Foundations/README.md
index 11d0e11..e4c602b 100644
--- a/01_Projects/Personal-Tech/LLM_Evaluation/00-Foundations/README.md
+++ b/01_Projects/Personal-Tech/LLM_Evaluation/00-Foundations/README.md
@@ -16,6 +16,7 @@ created: 2026-08-21
 1. [[01-What-Is-LLM-Evaluation|什么是 LLM Evaluation]]
 2. [[02-Annotation-Human-Data-and-Evaluation|数据标注、Human Data 与 Evaluation]]
 3. [[03-Core-Concept-Map|LLM Evaluation 核心概念地图]]
+4. [[04-Concepts-and-Theory|LLM 评测基础概念与理论：系统讲解]]（前三篇的教学整合，补全"为什么"与信度/效度视角）
 
 完成这一层后，继续阅读：