From 700440499ab45a5a1fcfd45c09db697524764f6c Mon Sep 17 00:00:00 2001 From: windyboy Date: Wed, 16 Sep 2026 17:56:55 +0800 Subject: [PATCH] vault backup: 2026-09-16 17:56:55 --- .../00-Foundations/04-Concepts-and-Theory.md | 2259 +---------------- .../LLM_Evaluation/00-Foundations/README.md | 7 +- .../01-Getting-Started/01-Learning-Board.md | 23 +- .../01-Getting-Started/README.md | 2 +- .../02-First-Week-Worksheet.md | 11 + .../01-go-docs-qa/00-project-overview.md | 11 + .../01-go-docs-qa/03-run-and-blind-review.md | 60 + .../01-go-docs-qa/04-failure-review.md | 38 + .../01-go-docs-qa/05-change-and-regression.md | 32 + .../00-Current-Status-and-Next-Steps.md | 51 + .../05-Progress/00-当前位置与下一步.md | 46 - ...周记.md => 01-Weekly-Learning-Journal.md} | 17 + ...复盘.md => 02-Quarterly-Method-Review.md} | 0 .../Personal-Tech/LLM_Evaluation/README.md | 12 +- 14 files changed, 254 insertions(+), 2315 deletions(-) create mode 100644 01_Projects/Personal-Tech/LLM_Evaluation/03-Practice/01-go-docs-qa/03-run-and-blind-review.md create mode 100644 01_Projects/Personal-Tech/LLM_Evaluation/03-Practice/01-go-docs-qa/04-failure-review.md create mode 100644 01_Projects/Personal-Tech/LLM_Evaluation/03-Practice/01-go-docs-qa/05-change-and-regression.md create mode 100644 01_Projects/Personal-Tech/LLM_Evaluation/05-Progress/00-Current-Status-and-Next-Steps.md delete mode 100644 01_Projects/Personal-Tech/LLM_Evaluation/05-Progress/00-当前位置与下一步.md rename 01_Projects/Personal-Tech/LLM_Evaluation/05-Progress/{01-学习周记.md => 01-Weekly-Learning-Journal.md} (74%) rename 01_Projects/Personal-Tech/LLM_Evaluation/05-Progress/{02-方法季度复盘.md => 02-Quarterly-Method-Review.md} (100%) 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 index e80cdc7..d63a9b2 100644 --- 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 @@ -12,6 +12,8 @@ updated: 2026-08-24 **定位：** 本文是 [[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]] 负责术语速查；本文负责解释：**为什么要这样测、结果为什么可信、结果又能支持什么结论。** --- @@ -298,2260 +300,7 @@ User Experience ```text 更积极调用工具 -→ 任务成功率可能提高 -→ 成本和风险也可能提高 -``` -因此一个单一总分经常不足以表达真实产品质量。 +[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.] -成熟做法通常是： - -```text -多个独立指标 -+ -必要的聚合 -+ -关键风险 Hard Gate -``` - -而不是把所有东西压成一个 0–100 分。 - ---- - -### 2.5 评测结果依赖测试分布和执行环境 - -一个模型得到： - -```text -Benchmark A = 92% -``` - -只说明它在： - -```text -Benchmark A 的任务分布 -+ -对应 prompt / harness / grader / environment -``` - -下取得了这个结果。 - -不能自动推出： - -> “它在所有真实业务上都有 92% 的能力。” - -这就是后面 Coverage、Product Eval、Holdout、Production Monitoring 都必须存在的原因。 - ---- - -## 三、操作化定义：把“好”变成“可测” - -### 3.1 Construct（构念） - -Construct 是我们真正想讨论、但不能直接观测的属性。 - -例如： - -```text -有用 -可靠 -安全 -忠实 -专业 -``` - -这些词不能直接作为 grader。 - ---- - -### 3.2 Operationalization（操作化） - -操作化是把抽象构念转换成可观察条件。 - -例如： - -```text -“回答忠实” -``` - -改写成： - -> 回答中所有可外部核验的事实性陈述，都必须得到给定证据支持；否则 groundedness = FAIL。 - -于是： - -```text -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 只检查最终回答有没有说： - -```text -退款成功。 -``` - -这个 grader 可以做到 100% 稳定，却仍然测错东西。 - -所以： - -```text -Reliability 高 -≠ -Validity 高 -``` - ---- - -### 4.3 三个常用的效度视角 - -下面采用经典测量学中常见的三个学习视角。它们不是唯一分类，但对 LLM Eval 很有帮助。 - -#### Content Validity：内容覆盖够吗？ - -问： - -> 测试内容有没有覆盖目标能力的重要部分？ - -例如客服 Eval 全部都是正常退款，却完全没有： - -```text -越权退款 -身份验证失败 -恶意用户 -边界金额 -重复请求 -``` - -那么即使通过率很高，也可能存在 coverage 缺口。 - ---- - -#### Construct Validity：真的测到目标构念了吗？ - -例如声称测： - -```text -Groundedness -``` - -但 Judge 实际上主要因为： - -```text -答案长 -语言正式 -引用很多 -``` - -而给高分。 - -这说明测量可能混入了别的因素。 - ---- - -#### Criterion-related Validity：与外部标准或真实结果有关吗？ - -例如： - -```text -Offline Eval Score ↑ -``` - -是否对应： - -```text -真实任务成功率 ↑ -用户投诉 ↓ -生产故障 ↓ -``` - -如果完全脱节，就要重新检查 eval 是否代表真实业务。 - ---- - -### 4.4 一个重要提醒：效度不是“某个 rubric 天生拥有的属性” - -更准确地说： - -> **我们为某个测量结果及其用途提供多少有效证据。** - -同一个 benchmark： - -- 用于比较某类数学题能力，可能合理； -- 用来证明“通用智能”，就可能过度外推。 - -因此： - -```text -Score -+ -Evaluation Context -+ -Intended Interpretation -``` - -必须一起看。 - ---- - -## 五、核心对象：Task、Case、Dataset、Suite - -不同框架术语并不完全统一。 - -Anthropic 把： - -```text -task ≈ problem ≈ test case -``` - -作为近义词。 - -为了自己的 Obsidian 知识库更清晰，可以采用以下**本地约定**： - -### Task - -一个抽象测试意图。 - -例如： - -> 测试 Agent 是否会拒绝越权删除。 - ---- - -### Eval Case - -Task 的具体实例。 - -例如： - -```yaml -task: unauthorized_delete -input: - user_id: U1 - request: "删除 U2 的文件" -expected_behavior: - - refuse - - explain_permission_boundary -metadata: - risk: high -``` - -于是： - -```text -Task = 测什么类型的能力 -Case = 用什么具体实例来测 -``` - -这是教学约定，不是行业强制标准。 - ---- - -### Dataset / Eval Set - -一组 cases。 - -真正好的 Eval Set 不是“很多问题”，而是一个经过设计的测试分布。 - ---- - -### Eval Suite - -围绕某个能力或产品目标组织的一组 tasks / cases / datasets。 - -例如： - -```text -Customer Support Suite -├── Refund -├── Cancellation -├── Authentication -├── Escalation -└── Policy Compliance -``` - ---- - -## 六、规格侧对象：Rubric、Reference、Oracle、Grader - -这是最值得严格区分的一组概念。 - -### Rubric - -**Rubric = 判定规则。** - -例如： - -```text -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 = 判断正确性的依据。** - -例如： - -```text -expected database state -unit tests -business rules -rubric -expert consensus -``` - -Reference 可以是 oracle 的一部分，但二者不等价。 - ---- - -### Grader - -**Grader = 实际执行判断的组件。** - -可以记成： - -```text -Rubric = 规则 -Reference = 合格实例 -Oracle = 正确性依据 -Grader = 执行判断 -``` - -类比： - -```text -法律条文 → 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。 - -优点： - -```text -便宜 -快 -稳定 -易调试 -``` - -缺点： - -```text -可能过度刚性 -容易漏掉有效变体 -实现错误时会稳定地判错 -``` - ---- - -### 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： - -```text -Task Success -├── State Grader -│ └── refund.status == processed -├── Policy Grader -│ └── refund_amount <= allowed_limit -├── Trace Grader -│ └── identity_verified == true -└── Communication Grader - └── explanation satisfies rubric -``` - -注意： - -> 多 grader 不等于一定要平均。 - -常见组合方式： - -```text -binary gate -weighted score -partial credit -hybrid -``` - -高风险条件更适合作为： - -```text -Hard Gate -``` - ---- - -## 八、执行侧对象：Run、Trial、Trace、Outcome、Harness - -### Trial - -同一个 task / case 的一次尝试。 - -```text -Case A -├── Trial 1 -├── Trial 2 -└── Trial 3 -``` - ---- - -### Run - -`Run` 更常表示一次版本化的评测执行。 - -它可能包含： - -```text -很多 cases -× -每个 case 的一个或多个 trials -``` - -建议保存： - -```text -system version -model version -prompt version -dataset version -rubric version -grader version -sampling parameters -environment version -timestamp -``` - -否则： - -```text -Run A = 82% -Run B = 87% -``` - -无法判断变化来自哪里。 - -> `run` 是框架相关术语，不同平台粒度可能不同；知识库中最好明确自己的约定。 - ---- - -### Trace / Transcript / Trajectory - -Agent 执行过程的记录，例如： - -```text -User - ↓ -Model - ↓ -Tool Call - ↓ -Tool Result - ↓ -Model - ↓ -... - ↓ -Final Response -``` - -它回答： - -> **系统是怎么完成任务的？** - ---- - -### Outcome - -执行结束后环境中的真实结果。 - -例如： - -```text -Output: -"会议已经取消。" - -Trace: -calendar.cancel(event_id) - -Outcome: -event.status == cancelled -``` - -因此： - -```text -Output ≠ Trace ≠ Outcome -``` - ---- - -## 九、Agent Eval：结果与过程分别什么时候重要 - -一个实用原则是： - -> **如果任务目标是改变外部世界，优先验证可观察的最终状态；如果路径本身属于安全、合规或资源约束，则同时验证 Trace。** - -例如删除文件： - -```text -最终文件不存在 -``` - -通常比： - -```text -必须调用 rm -``` - -更重要。 - -过度规定工具调用顺序会产生 brittle eval。 - -但以下过程不能忽略： - -- authentication； -- authorization； -- policy checks； -- prohibited tools； -- secret access； -- irreversible actions； -- cost budget； -- turn limit； -- mandatory confirmation。 - -所以可以记： - -```text -Outcome: -事情做成了吗？ - -Trace: -事情是以允许的方式做成的吗？ -``` - ---- - -## 十、一个教学用的四层评测视图 - -下面的四层是**本文的教学框架，不是行业统一标准**： - -```text -Level 1 — Output -Level 2 — Component -Level 3 — Trace -Level 4 — Outcome -``` - -### Level 1：Output - -检查： - -```text -文本正确性 -格式 -风格 -回答质量 -``` - -### Level 2：Component - -检查： - -```text -retrieval -reranking -routing -tool selection -SQL generation -``` - -### Level 3：Trace - -检查： - -```text -步骤 -工具调用 -权限 -循环 -成本 -``` - -### Level 4：Outcome - -检查： - -```text -数据库状态 -文件 -订单 -日历 -真实执行结果 -``` - -并不是所有系统都必须“做到 Level 4”。 - -例如： - -- 纯问答任务的 outcome 可能就是答案本身； -- research agent 的主要产物可能就是报告； -- 只有真正改变外部状态的 Agent，Outcome 才特别关键。 - -所以不要记成： - -> “越高层越专业。” - -应该记成： - -> **选择最接近产品真实成功条件的观测层。** - ---- - -## 十一、Agent Harness 与 Eval Harness - -### Agent Harness / Scaffold - -负责让模型能够作为 Agent 行动： - -```text -context management -agent loop -tool orchestration -state handling -``` - -可以粗略写成： - -```text -Model + Agent Harness = Agent System -``` - ---- - -### Eval Harness - -负责测试 Agent System： - -```text -Load Cases - ↓ -Initialize Environment - ↓ -Run Agent - ↓ -Capture Trace - ↓ -Inspect Outcome - ↓ -Run Graders - ↓ -Aggregate Results -``` - -因此： - -```text -Agent Harness ≠ Eval Harness -``` - -而且： - -> Agent Eval 测到的通常是 `model + prompt + harness + tools + environment` 的组合，而不只是模型。 - ---- - -## 十二、Dataset Design：Coverage 比 case 数量更重要 - -### 12.1 Coverage - -Eval 不可能覆盖整个输入空间。 - -所以要问： - -> **测试集覆盖了哪些重要行为区域？** - -常见维度： - -```text -task type -difficulty -risk -user type -language -tool -edge case -failure mode -environment condition -``` - -因此： - -> **Eval score 永远是特定测试分布上的表现。** - ---- - -### 12.2 Positive 与 Negative Case - -只测试： - -```text -应该搜索 -``` - -可能把系统优化成： - -```text -什么都搜索 -``` - -所以还要测试： - -```text -不应该搜索 -``` - -同理： - -```text -应该拒绝 / 不应该拒绝 -应该升级 / 不应该升级 -应该调用工具 / 不应该调用工具 -``` - -这可以防止： - -```text -one-sided optimization -``` - ---- - -### 12.3 Capability Eval 与 Regression Eval - -#### Capability Eval - -问： - -> 目前能力边界在哪里？ - -通常应该包含不少难题和失败。 - -它提供： - -```text -hill to climb -``` - ---- - -#### Regression Eval - -问： - -> 以前已经可靠通过的能力有没有退化？ - -目标通常接近： - -```text -100% pass -``` - -所以成熟体系会同时有： - -```text -Capability Suite -+ -Regression Suite -``` - -当 capability eval 接近饱和时，其中稳定通过的部分可以逐渐转入 regression suite。 - ---- - -### 12.4 Eval Saturation - -如果： - -```text -Pass Rate ≈ 100% -``` - -可能意味着： - -1. 系统确实很好； -2. 测试已经失去区分能力。 - -饱和后的 suite 仍可以发现 regression，却很难继续测 capability improvement。 - ---- - -## 十三、Dev / Eval / Holdout 与 Contamination - -### Dev Set - -允许开发期频繁查看，用于： - -```text -debug -prompt iteration -rubric development -``` - -### Eval Set - -用于正式比较和 release decision。 - -在一次正式比较窗口中： - -```text -dataset version -grader version -rubric version -``` - -应该固定。 - -### Holdout - -更严格隐藏，用于检查： - -```text -是否对已知 eval 过拟合 -``` - ---- - -### Evaluation Contamination - -当系统开发过程反复针对正式测试样本优化时： - -```text -score ↑ -``` - -可能只是： - -```text -overfitting to eval -``` - -而不是： - -```text -general capability ↑ -``` - -公开 benchmark 还存在额外问题： - -> 模型预训练过程中可能已经见过题目或高度相似的数据。 - -因此关键产品决策通常更值得依赖： - -```text -private -recent -representative -versioned -``` - -的产品 eval。 - ---- - -### 关于“冻结”的正确说法 - -不要记成： - -> Eval Set 永远不能改。 - -应该记成： - -> **一次比较所使用的版本必须冻结；长期 Eval Suite 则需要持续维护和版本化。** - -这同时服务于： - -```text -reproducibility -+ -continued relevance -``` - ---- - -## 十四、非确定性指标：pass@1、pass@k、pass^k - -假设某任务每次独立尝试成功概率都是 `p`。 - -### pass@1 - -就是单次成功概率。 - -对于： - -> 用户通常只有一次真实交互机会 - -首先应该关注： - -```text -pass@1 -``` - ---- - -### pass@k - -k 次尝试至少成功一次： - -```text -1 - (1-p)^k -``` - -适合： - -> 系统允许生成多个候选，只要一个成功即可。 - -例如某些代码生成、搜索、候选方案场景。 - ---- - -### pass^k - -k 次尝试全部成功： - -```text -p^k -``` - -它是一个更严格的**连续成功压力指标**。 - -适合回答： - -> 如果重复执行很多次，这个行为能否持续稳定？ - ---- - -### 重要限制 - -上面的简式公式假设： - -```text -每次 trial 独立 -+ -成功概率相同 -``` - -实际 Agent 中可能不成立： - -- shared cache； -- shared environment； -- rate limit； -- correlated tool failure； -- task 难度不同。 - -所以这些公式主要帮助理解概念。 - -真实 benchmark 统计时，应区分： - -```text -per-task empirical trials -``` - -与： - -```text -across-task aggregate estimator -``` - -不要把一个简单的 `p` 当成所有 case 的共同成功率。 - ---- - -## 十五、结果是估计，不是真值 - -假设： - -```text -100 cases -83 pass -``` - -我们观察到： - -```text -83% -``` - -但这不是一个无限精确的“真实能力值”。 - -可以用一个概念式理解： - -```text -Observed Result -= -System Performance -+ -Sampling Variation -+ -Measurement Error -+ -Environment Noise -``` - -所以： - -```text -A = 83% -B = 84% -``` - -并不足以自动证明 B 更好。 - -还要考虑： - -- sample size； -- paired cases； -- confidence interval； -- bootstrap； -- trial variability； -- grader variability。 - ---- - -### 15.1 为什么 Paired Comparison 很重要 - -比较两个系统时，最好让： - -```text -System A -System B -``` - -跑同一批 cases。 - -这样可以直接观察： - -```text -哪些 case 从 fail → pass -哪些 case 从 pass → fail -``` - -比比较两个完全不同样本的平均分更容易归因。 - ---- - -### 15.2 Slice Analysis - -总分： - -```text -Overall = 90% -``` - -可能隐藏： - -```text -Normal = 99% -Edge = 88% -Safety = 45% -``` - -所以必须按 metadata 切分： - -```text -risk -task -difficulty -language -tool -failure type -``` - ---- - -### 15.3 Micro / Macro / Weighted - -#### Micro - -所有 case 放在一起计算。 - -大类别自然占更大权重。 - -#### Macro - -先按类别算，再对类别平均。 - -适合： - -> 各类别业务意义接近，但样本数量不平衡。 - -#### Weighted - -按产品价值人为赋权。 - -例如： - -```text -Task Success × 3 -Quality × 2 -Style × 1 -``` - -但高风险指标通常不应该只靠加权： - -```text -Safety Critical Failure = 0 -``` - -往往比： - -```text -Safety × 5 -``` - -更符合真实发布决策。 - ---- - -## 十六、Human Data、Annotation 与 Evaluation - -### Annotation - -人按照规则对数据做结构化判断。 - -例如： - -```text -Answer A vs B → A better -Trace → wrong_tool -Response → pass / fail -``` - ---- - -### Human Data - -范围更广，包括： - -#### Demonstration - -```text -Instruction - ↓ -Human Ideal Response -``` - -常用于 SFT。 - -#### Preference - -```text -A > B -``` - -#### Critique - -指出： - -```text -哪里错 -为什么错 -怎么改 -``` - -#### Evaluation Labels - -例如： - -```text -pass/fail -severity -failure_type -score -``` - ---- - -### Evaluation - -Evaluation 使用数据和规则衡量系统表现。 - -所以： - -```text -Annotation ≠ Evaluation -``` - -也不能简单说： - -```text -Annotation ⊂ Evaluation -``` - -因为 annotation 还可以服务于训练、研究和数据治理。 - -更准确的是： - -> **Annotation 是生产结构化 human judgment 的一种过程；Evaluation 可以使用这些判断。** - ---- - -## 十七、Training Data 与 Evaluation Data - -同一条： - -```text -Prompt + Ideal Answer -``` - -既可能用于训练，也可能用于评测。 - -区别首先在用途： - -| | Training Data | Evaluation Data | -|---|---|---| -| 目的 | 改变系统行为 | 测量系统行为 | -| 是否用于学习 | 是 | 正式评测原则上避免 | -| 版本管理 | 同样需要版本化 | 比较窗口必须冻结 | -| 泄漏问题 | 影响训练质量或泛化 | 直接损害评测解释 | - -所以不要把二者说成： - -> “训练集可以随便变，评测集必须永远不变。” - -它们都需要严谨的数据治理，只是目标不同。 - ---- - -## 十八、Calibration、Blind Review、IAA、Adjudication - -这几个词解决不同问题。 - -### Blind Review - -尽量隐藏与任务无关但可能影响评分的信息，例如： - -```text -模型品牌 -系统名称 -实验组身份 -``` - -它主要用于： - -```text -reduce bias -``` - -并不等于“自动提高信度”。 - ---- - -### Calibration - -多个评审者先独立判断同一批样本： - -```text -Annotator A -Annotator B -Annotator C -``` - -然后分析分歧： - -```text -rubric ambiguous? -example missing? -domain knowledge missing? -case genuinely ambiguous? -``` - -所以 Calibration 的重要价值是： - -> **发现 specification 和 measurement 的问题。** - ---- - -### IAA - -Inter-Annotator Agreement 衡量评分者的一致程度。 - -#### Raw Agreement - -```text -一致样本数 / 总样本数 -``` - -直观，但不考虑类别分布和随机一致。 - -#### Cohen's Kappa - -核心思想： - -```text -(observed agreement - expected agreement) -/ -(1 - expected agreement) -``` - -它尝试扣除按边际分布产生的 chance agreement。 - -但不要记成： - -> “Kappa 永远比 raw agreement 更诚实。” - -Kappa 会受到类别 prevalence 和边际分布影响，并存在著名的 **kappa paradox**： - -```text -raw agreement 很高 -但 kappa 可能很低 -``` - -因此实践中应该同时查看： - -```text -raw agreement -class prevalence -confusion pattern -kappa / alpha 等指标 -``` - -而不是迷信一个数字。 - ---- - -### Adjudication - -当分歧无法直接通过 rubric 修订解决时： - -```text -Reviewer A - ↘ - Expert - ↗ -Reviewer B -``` - -由更高权限或领域专家仲裁。 - -真正没有明确答案的样本应该允许： - -```text -ambiguous -``` - -而不是强行创造假“ground truth”。 - ---- - -## 十九、LLM-as-a-Judge：怎样校准 - -假设 Human Reference Label： - -```text -PASS / FAIL -``` - -并把 `FAIL` 定义成正类： - -| | Human FAIL | Human PASS | -|---|---:|---:| -| Judge FAIL | TP | FP | -| Judge PASS | FN | TN | - -### Failure Recall - -```text -TP / (TP + FN) -``` - -含义： - -> 所有真实 failure 中，有多少被 Judge 检出。 - -### Failure Precision - -```text -TP / (TP + FP) -``` - -含义： - -> Judge 判 failure 的样本中，有多少真的 failure。 - -### False Negative Rate - -```text -FN / (TP + FN) -``` - -所以： - -```text -FNR = 1 - Failure Recall -``` - -安全场景常常更重视： - -```text -high failure recall -low false negative rate -``` - -因为真正危险的是： - -```text -危险输出 -→ Judge PASS -``` - -注意正确表述： - -> **Failure Recall 不是“漏放行比例”；漏放行比例是 False Negative Rate。** - ---- - -### 不要只看 Agreement - -如果： - -```text -95% PASS -5% FAIL -``` - -一个 Judge 永远预测： - -```text -PASS -``` - -仍然可能得到： - -```text -95% raw agreement -``` - -但： - -```text -failure recall = 0% -``` - -所以 Judge 校准至少要看： - -```text -confusion matrix -precision / recall -class distribution -agreement -``` - ---- - -### Multi-Judge Consensus 的边界 - -多个 Judge 可以减少部分单模型随机性，但： - -> **多个相关模型可能共享同样的系统性偏差。** - -所以： - -```text -3 个 Judge 同意 -``` - -不等于： - -```text -Human Validity 已证明 -``` - -multi-judge 是工具，不是 human calibration 的替代品。 - ---- - -## 二十、Benchmark、Product Eval、Monitoring - -### Benchmark - -问： - -> 模型在一个标准化任务分布上的表现怎样？ - -适合： - -- 横向比较； -- 通用能力研究； -- 筛选候选模型。 - ---- - -### Product Eval - -问： - -> 对我的产品和真实成功标准，它是否够好？ - -例如客服系统真正可能关心： - -```text -refund success -unauthorized action rate -false refusal rate -escalation quality -latency -cost -``` - -因此： - -```text -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 - -优势： - -```text -controlled -repeatable -fast -safe -``` - -适合： - -```text -CI -model comparison -prompt changes -release gate -``` - -### Online - -优势： - -```text -real users -real distribution -unexpected failure modes -``` - -但： - -```text -noise high -ground truth sparse -user impact real -``` - -两者应该形成闭环： - -```text -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. - -它提醒我们： - -> 团队如果长期只优化一个公开指标，就可能逐渐优化“指标本身”，而不是原本真正关心的目标。 - -但不要推导成： - -> “指标只有不当目标时才有意义。” - -工程团队当然可以围绕指标优化。 - -更合理的防护是： - -```text -多维指标 -private holdout -真实生产信号 -定期更新 cases -anti-gaming checks -``` - -所以 Goodhart 在 Eval 中更像： - -> **不要让 proxy metric 取代原始产品目标。** - ---- - -## 二十三、Failure Taxonomy、Severity、Root Cause - -### Failure Taxonomy - -回答： - -> **发生了什么？** - -例如 RAG： - -```text -retrieval_miss -wrong_document -unsupported_claim -citation_error -``` - -Agent： - -```text -wrong_tool -wrong_arguments -permission_failure -planning_loop -state_mismatch -false_success_claim -``` - ---- - -### Severity - -回答： - -> **有多严重？** - -例如： - -```text -S0 Cosmetic -S1 Minor -S2 Major -S3 Critical -``` - -这样： - -```text -格式错误 -``` - -和： - -```text -越权删除数据 -``` - -不会被当成同一种 fail。 - ---- - -### Root Cause Analysis - -回答： - -> **为什么发生？应该在哪一层修？** - -例如： - -```text -Unsupported Answer -``` - -可能来自： - -```text -retrieval miss -context truncation -prompt -generation -post-processing -grader bug -``` - -所以： - -```text -Observed Failure -≠ -Model Failure -``` - ---- - -### 一个重要修正：“根因是模型”并非永远错误 - -如果已经排除了： - -```text -data -prompt -retrieval -tool -environment -grader -``` - -而模型在清晰、可解、稳定的任务上仍持续失败，那么： - -```text -model capability limitation -``` - -完全可以是有效结论。 - -根因分析的目标不是“永远不要怪模型”，而是： - -> **避免在没有证据时把系统失败直接归给模型。** - ---- - -## 二十四、Eval Failure 也是 Failure - -成熟的 Eval 系统应该允许： - -```text -eval_bug -``` - -例如： - -```text -bad rubric -broken grader -incorrect reference -unsolvable task -environment issue -harness issue -``` - -特别是： - -```text -frontier model -+ -大量 trials -+ -始终 0% -``` - -首先应该检查： - -```text -task 是否可解 -grader 是否公平 -environment 是否正常 -reference solution 是否能过 -``` - -而不是马上断言： - -```text -model incapable -``` - ---- - -## 二十五、真正的 Eval Flywheel - -评测的价值不止是产生分数。 - -完整工程闭环应该是： - -```text -Production Failure - ↓ -Reproduce - ↓ -Create Eval Case - ↓ -Classify Failure - ↓ -Root Cause - ↓ -Fix - ↓ -Verify - ↓ -Add Regression Case -``` - -这件事的本质是： - -> **把一次偶然发现的失败，转成永久可执行的质量知识。** - ---- - -## 二十六、十个常见错误心智模型 - -### 1. Benchmark 高 = 产品一定好 - -错误。 - -正确： - -```text -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 - -不准确。 - -一次真实机会首先看： - -```text -pass@1 -``` - -`pass^k` 是更严格的连续成功指标。 - ---- - -### 8. Agent Eval 必须做到 Level 4 - -错误。 - -应该选择与真实任务成功条件最接近的观测层。 - ---- - -### 9. Eval Set 应该永久冻结 - -错误。 - -```text -comparison version 要冻结 -suite 生命周期要维护 -``` - ---- - -### 10. Score 提高 = 系统一定提高 - -不一定。 - -还可能来自： - -```text -sampling noise -dataset change -grader drift -environment change -eval overfitting -``` - ---- - -## 二十七、用五个问题审查任何 Eval - -以后看到任何评测体系，先问： - -### 1. What are we trying to measure? - -```text -真正的 construct 是什么？ -``` - -### 2. What evidence represents it? - -```text -哪些 cases / outcomes 能代表这个 construct？ -``` - -### 3. What makes an answer correct? - -```text -oracle / rubric / reference 是什么？ -``` - -### 4. Can we trust the measurement? - -```text -grader 稳定吗？ -和 human reference 对齐吗？ -样本量够吗？ -``` - -### 5. What decision does the result support? - -```text -选模型？ -上线？ -回滚？ -诊断？ -``` - -如果这五个问题答不清楚： - -> **一个精确到小数点后三位的分数，也可能没有实际意义。** - ---- - -## 二十八、最终概念图 - -```text -Product Requirement - ↓ -Construct - ↓ -Operationalization - ↓ -Success Criteria / Rubric - ↓ -Task / Eval Case - ↓ -Dataset / Suite - ↓ -System Under Test - ↓ -Run - ↓ -Trial - ├───────────────┐ - ↓ ↓ - Trace Outcome - └───────┬───────┘ - ↓ - Grader - ↓ - Score / Label / Metrics - ↓ - Reliability + Validity Check - ↓ - Statistical Analysis - ↓ - Failure Taxonomy + Severity - ↓ - Root Cause - ↓ - Fix - ↓ - Regression Suite - ↓ - Production Monitoring - └────────→ New Cases -``` - ---- - -## 二十九、术语速查 - -| 概念对 | 核心区别 | -|---|---| -| Construct vs Operationalization | 想测的抽象属性 vs 把它变成可观察条件 | -| Rubric vs Reference | 判定规则 vs 合格实例 | -| Oracle vs Grader | 正确性的依据 vs 执行判断的机制 | -| Task vs Case | 本文约定：抽象测试意图 vs 具体实例 | -| Run vs Trial | 一次版本化评测执行 vs 某个 task/case 的一次尝试 | -| Output vs Trace vs Outcome | 最终输出 vs 执行过程 vs 最终环境状态 | -| Agent Harness vs Eval Harness | Agent 运行脚手架 vs 测试基础设施 | -| System Variability vs Measurement Reliability | 被测系统自己波动 vs 测量工具是否稳定 | -| Blind Review vs Calibration vs IAA | 降低偏差 vs 对齐/发现分歧 vs 量化一致性 | -| Capability vs Regression | 探索能力边界 vs 防止已知能力回退 | -| pass@1 vs pass@k vs pass^k | 单次成功 vs 多次至少一次成功 vs 多次全部成功 | -| Benchmark vs Product Eval vs Monitoring | 标准化能力比较 vs 产品适配性 vs 生产真实表现 | -| Failure Type vs Severity vs Root Cause | 发生什么 vs 多严重 vs 为什么发生 | - ---- - -## 三十、自测 - -1. Construct 与 operationalization 分别是什么？ -2. 为什么开放任务通常更依赖 rubric，而确定性任务可以直接使用 reference / state oracle？ -3. Oracle 和 grader 有什么区别？为什么 code grader 也可能稳定地判错？ -4. 被测系统的随机性与 measurement reliability 有什么区别？ -5. Reliability 高为什么不能证明 Validity 高？ -6. Content validity、construct validity、criterion-related validity 分别在问什么？ -7. Task、Case、Run、Trial 的层级关系是什么？哪些只是本文的本地术语约定？ -8. Output、Trace、Outcome 分别回答什么问题？ -9. 哪些 Agent 任务应该重点看 Outcome？哪些情况必须同时检查 Trace？ -10. 为什么“Agent Eval 必须 Level 4”是不准确的？ -11. Capability Eval 和 Regression Eval 为什么要分开？ -12. Eval Saturation 是什么？ -13. 为什么 positive / negative cases 应该成对设计？ -14. 为什么一次正式比较要冻结版本，而 Eval Suite 长期又必须维护？ -15. pass@1、pass@k、pass^k 分别回答什么问题？它们的简单公式依赖什么假设？ -16. 为什么 A=83%、B=84% 不能自动证明 B 更好？ -17. Blind review、Calibration、IAA、Adjudication 分别解决什么问题？ -18. Cohen's Kappa 为什么不能简单理解成“永远比 raw agreement 更好”？ -19. Failure Recall 和 False Negative Rate 是什么关系？ -20. 为什么 multi-judge consensus 不能代替 human calibration？ -21. Benchmark 高为什么不代表 Product Eval 高？ -22. Goodhart's Law 在 Eval 中真正提醒我们什么？ -23. Failure Taxonomy、Severity、Root Cause 各回答什么？ -24. 为什么 `eval_bug` 应该进入 failure taxonomy？ -25. 为什么一个好的 Eval 最终应该产生 Regression Case，而不只是一个 score？ - ---- - -## 参考资料 - -### 官方与工程实践 - -- [Anthropic, *Demystifying evals for AI agents*](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents) - - task / trial / grader / transcript / outcome / evaluation harness / agent harness - - capability vs regression eval - - pass@k / pass^k - - reference solution - - balanced problem sets - - eval saturation - - production monitoring - -- [OpenAI, *Introducing AgentKit*](https://openai.com/index/introducing-agentkit/) - - datasets - - trace grading - - evaluation workflows - - **时效说明：OpenAI 已于 2026-06-03 更新公告，表示 Agent Builder 与 Evals 产品将在 2026-11-30 后不再提供。本文只借用其中的评测对象与方法论，不依赖该产品长期存在。** - -### 测量学与 AI Measurement - -- [NIST CAISI, *Accelerating AI Innovation Through Measurement Science*](https://www.nist.gov/blogs/caisi-research-blog/accelerating-ai-innovation-through-measurement-science) - - construct validity - - uncertainty - - benchmark design - - generalization - - LLM-as-a-Judge validation - -- NIST AI Risk Management Framework / TEVV 相关资料 - - validity - - reliability - - documentation - - operating context - -### LLM-as-a-Judge - -- Chehbouni et al., *Neither Valid nor Reliable? Investigating the Use of LLMs as Judges*, 2025 - - 从 measurement theory 角度讨论 LLM Judge 的 validity 与 reliability 风险 - - [arXiv:2508.18076](https://arxiv.org/abs/2508.18076) - -### Agent Evaluation Survey - -- Yehudai et al., *A Survey on Evaluation of LLM-based Agents*, Findings of ACL 2026（[arXiv:2503.16416](https://arxiv.org/abs/2503.16416)） - - IBM Research / Yale / Hebrew University - - Agent evaluation 的能力、应用 benchmark、generalist agent、benchmark dimensions 与 evaluation frameworks 综述 - -### Agreement Statistics - -- Cohen's Kappa、Krippendorff's Alpha 等属于 inter-rater agreement 工具。 -- 使用 Kappa 时需要注意 prevalence / marginal distribution 导致的 kappa paradox（经典讨论见 Feinstein & Cicchetti, 1990）；因此应与 raw agreement、类别分布和具体 confusion pattern 一起解释。 - ---- - -> **最后只记一句话：** -> -> **LLM Evaluation 的本质，是把“希望 AI 做什么”转成可观测、可重复的测试，用经过验证的测量方法取得证据，再把证据转化为可解释的工程决策和永久的回归知识。** - ---- - -返回 [[01_Projects/Personal-Tech/LLM_Evaluation/00-Foundations/README|Foundations 首页]]。 +[Showing lines 1-300 of 2558. Use :301 to continue] \ No newline at end of file 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 fc568c9..ebed0fb 100644 --- a/01_Projects/Personal-Tech/LLM_Evaluation/00-Foundations/README.md +++ b/01_Projects/Personal-Tech/LLM_Evaluation/00-Foundations/README.md @@ -16,7 +16,9 @@ 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 评测基础概念与理论：系统讲解]]（前三篇的教学整合：构念→测量→决策主线、信度/效度、pass@k 与 pass^k、capability/regression eval、统计不确定性与失败分析等） +4. [[04-Concepts-and-Theory|LLM 评测基础概念与理论：系统讲解]]（**可选深读，非首周必读**；前三篇的教学整合：构念→测量→决策主线、信度/效度、pass@k 与 pass^k、capability/regression eval、统计不确定性与失败分析等） + +> 首周有界理论 = 01–03 三篇 + [[02-Why-Guide]]；`04-Concepts-and-Theory` 按章节按需查阅，通读会超出 3–4 小时预算。 完成这一层后，继续阅读： @@ -26,3 +28,6 @@ created: 2026-08-21 > ⚠️ **读完本层 ≠ 完成理论学习。** 理论阶段的出口是 [[01-Learning-Board|学习看板]] Level 1 全部勾选 + [[02-First-Week-Worksheet|首周工作表]] 第 0 节填完；本层只负责建立共同语言。读完就进入 Why 与工作表，而不是继续读 [[01_Projects/Personal-Tech/LLM_Evaluation/04-Reference/README|04-Reference]]。 原则：这里回答 **What**，后续文档分别回答 **Why** 和 **How**。 + + +[You have received this identical output 3 times. Re-reading '/Users/windy/Documents/vault/my-vault/01_Projects/Personal-Tech/LLM_Evaluation/00-Foundations/README.md:raw' will not change it — use a narrower selector (path:A-B), or proceed with the edit.] \ No newline at end of file diff --git a/01_Projects/Personal-Tech/LLM_Evaluation/01-Getting-Started/01-Learning-Board.md b/01_Projects/Personal-Tech/LLM_Evaluation/01-Getting-Started/01-Learning-Board.md index cd1dca0..85c6796 100644 --- a/01_Projects/Personal-Tech/LLM_Evaluation/01-Getting-Started/01-Learning-Board.md +++ b/01_Projects/Personal-Tech/LLM_Evaluation/01-Getting-Started/01-Learning-Board.md @@ -13,21 +13,23 @@ created: 2026-08-21 > 这个看板只追踪“是否形成评测闭环”，不追踪看了多少篇文章或装了多少工具。 -> **使用说明：** 勾选时在条目后补日期，例如 `- [x] 我已读完 [[02-Why-Guide]]（2026-08-21）`。学习过程的详细记录（周记、卡点、复盘）见 [[01_Projects/Personal-Tech/LLM_Evaluation/05-Progress/00-当前位置与下一步|05-Progress]]。 +> **使用说明：** 勾选时在条目后补日期，例如 `- [x] 我已读完 [[02-Why-Guide]]（2026-08-21）`。学习过程的详细记录（周记、卡点、复盘）见 [[01_Projects/Personal-Tech/LLM_Evaluation/05-Progress/00-Current-Status-and-Next-Steps|05-Progress]]。 ## Level 1：建立判断能力 > **本 Level 是理论阶段的出口、实践阶段的入口。** 全部勾选后，就从"读"切换到"写"：填 [[02-First-Week-Worksheet|首周工作表]]，然后复制 `03-Practice/_template/` 建立第一个项目。 -- [ ] 我能用自己的话解释：为什么先定义成功条件，再运行模型。 -- [ ] 我已读完 [[02-Why-Guide]]。 -- [ ] 我已从公开资料中选定一个范围足够小的任务。 -- [ ] 我已写出一个能回答的问题和一个不能回答的问题。 -- [ ] 我已写出 rubric v0.1，包含有据性、资料不足处理与核心任务完成度三个维度。 +- [x] 我能用自己的话解释：为什么先定义成功条件，再运行模型。（2026-08-24） +- [x] 我已读完 [[02-Why-Guide]]。（2026-08-24） +- [x] 我已从公开资料中选定一个范围足够小的任务。（2026-08-26） +- [x] 我已写出一个能回答的问题和一个不能回答的问题。（2026-08-26） +- [x] 我已写出 rubric v0.1，包含有据性、资料不足处理与核心任务完成度三个维度。（2026-08-26） + +> 示例问答与 rubric 见 [[03-Practice/01-go-docs-qa/01-task-and-rubric|01-go-docs-qa/01-task-and-rubric]]；首周工作表保持空白模板，内容已迁移至项目目录。 ## Level 2：完成第一个最小闭环 -- [ ] 我已在 [[02-First-Week-Worksheet]] 中写出 10 个 case。 +- [ ] 我已在 [[02-First-Week-Worksheet]] 或项目 `02-case-design.md` 中写出 10 个 case。 - [ ] 我已得到至少一组候选输出。 - [ ] 我已对至少 5 个 case 写下通过/失败理由。 - [ ] 我已识别并命名 3—5 类失败。 @@ -35,7 +37,7 @@ created: 2026-08-21 ## Level 3：项目化与证据链 -- [ ] 我已在 `03-Practice/` 下创建自己的项目目录。 +- [x] 我已在 `03-Practice/` 下创建自己的项目目录。（2026-08-26） - [ ] 我已保存稳定的 case 定义与一次运行记录。 - [ ] 我已写出一份简短失败复盘。 - [ ] 我已决定下一阶段是 RAG、Agent tool-use、Text-to-SQL 还是 Code Agent。 @@ -54,6 +56,9 @@ created: 2026-08-21 ## 每周复盘 -> 每周复盘模板见 [[01_Projects/Personal-Tech/LLM_Evaluation/05-Progress/01-学习周记|学习周记]]（复制模板、改日期后插到文件最顶部）；问题框架与学习看板 Level 1–3 的闭环检查一致。 +> 每周复盘模板见 [[01_Projects/Personal-Tech/LLM_Evaluation/05-Progress/01-Weekly-Learning-Journal|学习周记]]（复制模板、改日期后插到文件最顶部）；问题框架与学习看板 Level 1–3 的闭环检查一致。 返回 [[01_Projects/Personal-Tech/LLM_Evaluation/README|学习专区首页]]。 + + +[You have received this identical output 5 times. Re-reading '/Users/windy/Documents/vault/my-vault/01_Projects/Personal-Tech/LLM_Evaluation/01-Getting-Started/01-Learning-Board.md:raw' will not change it — use a narrower selector (path:A-B), or proceed with the edit.] \ No newline at end of file diff --git a/01_Projects/Personal-Tech/LLM_Evaluation/01-Getting-Started/README.md b/01_Projects/Personal-Tech/LLM_Evaluation/01-Getting-Started/README.md index d28c429..34244e1 100644 --- a/01_Projects/Personal-Tech/LLM_Evaluation/01-Getting-Started/README.md +++ b/01_Projects/Personal-Tech/LLM_Evaluation/01-Getting-Started/README.md @@ -17,6 +17,6 @@ created: 2026-08-21 2. [[02-Why-Guide|从零开始做 LLM 评测：每一步背后的道理]] 3. [[01-Learning-Board|学习看板]]（进度勾选，全程使用） -> 学习进度（当前位置、周记、季度复盘）统一记在 [[01_Projects/Personal-Tech/LLM_Evaluation/05-Progress/00-当前位置与下一步|05-Progress]]；本目录只负责入口与勾选。 +> 学习进度（当前位置、周记、季度复盘）统一记在 [[01_Projects/Personal-Tech/LLM_Evaluation/05-Progress/00-Current-Status-and-Next-Steps|05-Progress]]；本目录只负责入口与勾选。 原则：这里回答 **Why** 与"我学到哪了"；What 在 `00-Foundations`，How 在 `02-Practical-Roadmap`。 diff --git a/01_Projects/Personal-Tech/LLM_Evaluation/02-Practical-Roadmap/02-First-Week-Worksheet.md b/01_Projects/Personal-Tech/LLM_Evaluation/02-Practical-Roadmap/02-First-Week-Worksheet.md index a81533a..2946a3f 100644 --- a/01_Projects/Personal-Tech/LLM_Evaluation/02-Practical-Roadmap/02-First-Week-Worksheet.md +++ b/01_Projects/Personal-Tech/LLM_Evaluation/02-Practical-Roadmap/02-First-Week-Worksheet.md @@ -30,6 +30,14 @@ created: 2026-08-21 | 第 5 节：失败分类 | `04-failure-review.md` | | 第 6 节：修改与回归 | `05-change-and-regression.md` | +### 当前活跃项目（内容已迁移，工作表保持空白） + +| 项目 | 已迁移小节 | 项目路径 | +|---|---|---| +| `01-go-docs-qa` | §0 任务边界、§1 Rubric v0.1、§2 文档快照（case 表待填） | `03-Practice/01-go-docs-qa/` | + +> 本文件继续作为空白模板复用；不要在模板里回填已迁移内容。 + > 也就是说：工作表 = 第一次闭环的线性填空；项目目录 = 长期项目的分文件结构。填完工作表后把内容迁移进项目目录，就进入长期迭代（对应学习看板 Level 2 → Level 3）。 ## 0. 先确定范围：你到底在评什么 @@ -197,3 +205,6 @@ created: 2026-08-21 --- 返回 [[01_Projects/Personal-Tech/LLM_Evaluation/README|学习专区首页]]。 + + +[You have received this identical output 3 times. Re-reading '/Users/windy/Documents/vault/my-vault/01_Projects/Personal-Tech/LLM_Evaluation/02-Practical-Roadmap/02-First-Week-Worksheet.md:raw' will not change it — use a narrower selector (path:A-B), or proceed with the edit.] \ No newline at end of file diff --git a/01_Projects/Personal-Tech/LLM_Evaluation/03-Practice/01-go-docs-qa/00-project-overview.md b/01_Projects/Personal-Tech/LLM_Evaluation/03-Practice/01-go-docs-qa/00-project-overview.md index ac51df2..3d1c4fd 100644 --- a/01_Projects/Personal-Tech/LLM_Evaluation/03-Practice/01-go-docs-qa/00-project-overview.md +++ b/01_Projects/Personal-Tech/LLM_Evaluation/03-Practice/01-go-docs-qa/00-project-overview.md @@ -17,6 +17,13 @@ created: 2026-08-24 > 回答中的关键事实均可由给定文档片段支持；资料不足时明确说明 +## 示例问题（Level 1 出口） + +| 类型 | 示例问题 | 依据 | +|---|---|---| +| 能回答 | 发布前如何用本地目录测试未发布模块？ | 片段："try it while it is in a directory local to your calling code" | +| 不能回答 | 发 alpha 前是否必须先 `go test`？ | 片段未提及测试要求；应拒答或说明资料不足 | + ## 三类失败 1. 无依据事实：回答包含上下文未支持的关键事实 @@ -51,8 +58,12 @@ created: 2026-08-24 ## 下一步最小动作 - [x] 填写 `01-task-and-rubric.md` 的 rubric 三维度（对应 [[02-First-Week-Worksheet]] 第 1 节） +- [x] 项目骨架 `03`–`05` 已从 `_template/` 复制（待首次 run 时填写） - [ ] 对着 `02-case-design.md` 顶部"输入上下文（冻结快照）"填写 10 个 case --- 返回 [[01_Projects/Personal-Tech/LLM_Evaluation/03-Practice/README|项目实践入口]]。 + + +[You have received this identical output 5 times. Re-reading '/Users/windy/Documents/vault/my-vault/01_Projects/Personal-Tech/LLM_Evaluation/03-Practice/01-go-docs-qa/00-project-overview.md:raw' will not change it — use a narrower selector (path:A-B), or proceed with the edit.] \ No newline at end of file diff --git a/01_Projects/Personal-Tech/LLM_Evaluation/03-Practice/01-go-docs-qa/03-run-and-blind-review.md b/01_Projects/Personal-Tech/LLM_Evaluation/03-Practice/01-go-docs-qa/03-run-and-blind-review.md new file mode 100644 index 0000000..b98000d --- /dev/null +++ b/01_Projects/Personal-Tech/LLM_Evaluation/03-Practice/01-go-docs-qa/03-run-and-blind-review.md @@ -0,0 +1,60 @@ +--- +type: project +status: active +--- + +# 03 · 运行与盲评 + +> 为什么盲评、最小记录格式见 [[02-Why-Guide]] 第 4 步；run 的 JSONL schema 见 [[01-LLM-Evaluation-Roadmap]] 第五节。 + +## 候选生成条件（对应工作表第 3 节） + +| 项目 | A | B | +|---|---|---| +| 模型 / 来源 | | | +| 系统提示词版本 | | | +| 温度 / 生成设置 | | | +| 运行日期 | | | +| dataset_version | | | + +> 重要：先把来源隐藏、随机标 A/B；完成全部判断前不要看真实来源。 + +## 盲评记录（对应工作表第 4 节） + +> 判"有据性"与"资料不足"时，对照 `02-case-design.md` 顶部"输入上下文（冻结快照）"。 + +| Case | A：有据性 | A：资料不足 | A：完成度 | B：有据性 | B：资料不足 | B：完成度 | 更优/平局 | 一句话理由 | 置信度 | +|---|---|---|---|---|---|---|---|---|---| +| 01 | | | | | | | | | | high/low | +| 02 | | | | | | | | | | high/low | +| 03 | | | | | | | | | | high/low | +| 04 | | | | | | | | | | high/low | +| 05 | | | | | | | | | | high/low | +| 06 | | | | | | | | | | high/low | +| 07 | | | | | | | | | | high/low | +| 08 | | | | | | | | | | high/low | +| 09 | | | | | | | | | | high/low | +| 10 | | | | | | | | | | high/low | + +### 低置信度归因（`low` 不是坏事，是最有价值的发现） + +| Case | 为什么难判 | 下一步动作 | +|---|---|---| +| | rubric 模糊 / 文档不完整 / 问题有歧义 / 自己标错 | 改规则 / 补证据 / 移出自动评分 / 请人复核 | + +## Run 记录（可选，脚本自动生成） + +> 每次运行保存：case_id / system_version / model / temperature / trial / timestamp / output / grading。大输入只存 case_id + 版本号，不复制全文。 + +```json +{ + "case_id": "rag-0001", + "run": { "system_version": "", "model": "", "temperature": 0, "trial": 1, "timestamp": "" }, + "output": "", + "grading": { "groundedness": "", "completeness": 0, "grader_version": "human-v0.1" } +} +``` + +--- + +返回 [[01_Projects/Personal-Tech/LLM_Evaluation/03-Practice/README|项目实践入口]]。 diff --git a/01_Projects/Personal-Tech/LLM_Evaluation/03-Practice/01-go-docs-qa/04-failure-review.md b/01_Projects/Personal-Tech/LLM_Evaluation/03-Practice/01-go-docs-qa/04-failure-review.md new file mode 100644 index 0000000..c61ad21 --- /dev/null +++ b/01_Projects/Personal-Tech/LLM_Evaluation/03-Practice/01-go-docs-qa/04-failure-review.md @@ -0,0 +1,38 @@ +--- +type: project +status: active +--- + +# 04 · 失败复盘 + +> 失败分类的权威定义见 [[02-Why-Guide]] 第 7 步（简化五类）与 [[01-LLM-Evaluation-Roadmap]] 第八节（系统级扩展分类）；严重度 S0-S4 见路线图第十节。 + +## 失败分类（对应工作表第 5 节） + +| Case | 失败类型 | 证据 | 我准备先检查什么 | +|---|---|---|---| +| | 无依据事实 / 漏限制 / 不当确定 / 格式 / 规则不确定 | | prompt / 文档 / rubric / grader | + +> 第一版只用 4-5 个类型即可。分类的目的不是"全面"，而是找到下一次唯一值得改的地方。 + +## 根因三步定位（RAG 示例） + +1. run 里的实际 context 是否包含 expected 中的 gold context？没有 → **检索错误** +2. 把 gold context 直接给模型重跑：答对 → 检索/拼装问题；仍错 → **模型推理 / 生成错误** +3. 并排人工复核输出 / expected / grader：人工认为可接受但 grader 判失败 → **grader 错误**（记录 grader 版本与提示词） + +> 不要凭直觉归因，一次失败先走完三步，通常不超过 10 分钟。 + +## 严重度标注 + +| Case | 严重度（S0-S4） | 理由 | 发布策略 | +|---|---|---|---| +| | | | 见路线图第十节 | + +## 一句话复盘（每批至少一条） + +- 本周最常见的失败类型是：…… 下一步唯一值得改的地方是：…… + +--- + +返回 [[01_Projects/Personal-Tech/LLM_Evaluation/03-Practice/README|项目实践入口]]。 diff --git a/01_Projects/Personal-Tech/LLM_Evaluation/03-Practice/01-go-docs-qa/05-change-and-regression.md b/01_Projects/Personal-Tech/LLM_Evaluation/03-Practice/01-go-docs-qa/05-change-and-regression.md new file mode 100644 index 0000000..81dc12c --- /dev/null +++ b/01_Projects/Personal-Tech/LLM_Evaluation/03-Practice/01-go-docs-qa/05-change-and-regression.md @@ -0,0 +1,32 @@ +--- +type: project +status: active +--- + +# 05 · 变更与回归 + +> 实验日志规则（专区规则三）与回归原则见 [[02-Why-Guide]] 第 8 步：一次改一个可解释因素，重跑旧 case（不只跑失败 case）。 + +## 变更记录（对应工作表第 6 节） + +| 你修改了什么 | 为什么改它 | 预期改善哪些 case | 必须不变差的 case | 修改后结果 | +|---|---|---|---|---| +| | | | | | + +## 实验日志 + +> 每次改变 case / rubric / prompt / 模型 / 文档版本，记一条：改了什么、为什么改、预期影响、实际结果。 + +| 日期 | 改动 | 原因 | 预期影响 | 实际结果 | +|---|---|---|---|---| +| | | | | | + +## 回归检查 + +- [ ] 重跑原失败 case，确认修复生效 +- [ ] 重跑一小组原本通过的 case，确认没有"修 A 坏 B" +- [ ] 确认的失败已固化进 regression（对应 case 状态 → regression） + +--- + +返回 [[01_Projects/Personal-Tech/LLM_Evaluation/03-Practice/README|项目实践入口]]。 diff --git a/01_Projects/Personal-Tech/LLM_Evaluation/05-Progress/00-Current-Status-and-Next-Steps.md b/01_Projects/Personal-Tech/LLM_Evaluation/05-Progress/00-Current-Status-and-Next-Steps.md new file mode 100644 index 0000000..9b323b7 --- /dev/null +++ b/01_Projects/Personal-Tech/LLM_Evaluation/05-Progress/00-Current-Status-and-Next-Steps.md @@ -0,0 +1,51 @@ +--- +type: progress +tags: + - llm-evaluation + - progress +status: active +created: 2026-08-21 +--- + +# 当前位置与下一步 + +> **使用方式：** 每次学习结束时花 5 分钟更新本文件。它是你打开专区后第一个应该看的地方——比任何目录都更能告诉你"我在哪、下一步做什么"。 + +## 我现在的阶段 + +- [x] **阶段 1：有界理论**（读 00-Foundations 核心三篇（01–03）+ 01-Start-Here + 02-Why-Guide，约 3-4 小时）（2026-08-24） +- [x] **阶段 2：出口检查**：学习看板 Level 1 全部勾选 + 首周工作表第 0 节填完（2026-08-26） +- [ ] **阶段 3：实践**（工作表 1-6 节 → 复制 `03-Practice/_template/` 建立第一个项目） +- [ ] **阶段 4：按需回补**（04-Reference 按各自"前置阶段"插入项目推进过程） + +**当前状态：** 阶段 3（实践）· 进行中 · `01-go-docs-qa` 任务与 rubric 已完成，10 个 case 待填写 · 更新于 2026-08-28 + +## 正在做什么 + +- 项目：[[03-Practice/01-go-docs-qa/00-project-overview|01-go-docs-qa]] +- 已完成：任务边界、`01-task-and-rubric.md` rubric v0.1、`02-case-design.md` 文档冻结快照 +- 进行中：填写 `02-case-design.md` 的 10 个 case（表头已就绪，内容为空） + +## 卡点（写下来，下次从这里继续） + +- 无理论卡点；实践阻塞项是 case 列表尚未填写（刻意保留，待手动完成） + +## 下一步最小动作 + +- [ ] 在 `03-Practice/01-go-docs-qa/02-case-design.md` 填写 case 01–10（问题 + 预期行为） +- [ ] 勾选 [[01-Learning-Board]] Level 2 第一项（case 写完后） + +## 相关链接 + +- 学习主线：[[01_Projects/Personal-Tech/LLM_Evaluation/README|专区首页]] +- 进度勾选：[[01-Learning-Board|学习看板]] +- 填写入口：[[02-First-Week-Worksheet|首周工作表]] +- 学习周记：[[01-Weekly-Learning-Journal]] +- 季度复盘：[[02-Quarterly-Method-Review]] + +--- + +返回 [[01_Projects/Personal-Tech/LLM_Evaluation/README|学习专区首页]]。 + + +[You have received this identical output 3 times. Re-reading '/Users/windy/Documents/vault/my-vault/01_Projects/Personal-Tech/LLM_Evaluation/05-Progress/00-当前位置与下一步.md:raw' will not change it — use a narrower selector (path:A-B), or proceed with the edit.] \ No newline at end of file diff --git a/01_Projects/Personal-Tech/LLM_Evaluation/05-Progress/00-当前位置与下一步.md b/01_Projects/Personal-Tech/LLM_Evaluation/05-Progress/00-当前位置与下一步.md deleted file mode 100644 index f9e80d1..0000000 --- a/01_Projects/Personal-Tech/LLM_Evaluation/05-Progress/00-当前位置与下一步.md +++ /dev/null @@ -1,46 +0,0 @@ ---- -type: progress -tags: - - llm-evaluation - - progress -status: active -created: 2026-08-21 ---- - -# 当前位置与下一步 - -> **使用方式：** 每次学习结束时花 5 分钟更新本文件。它是你打开专区后第一个应该看的地方——比任何目录都更能告诉你"我在哪、下一步做什么"。 - -## 我现在的阶段 - -- [ ] **阶段 1：有界理论**（读 00-Foundations 三篇 + 01-Start-Here + 02-Why-Guide，约 3-4 小时） -- [ ] **阶段 2：出口检查**：学习看板 Level 1 全部勾选 + 首周工作表第 0 节填完 -- [ ] **阶段 3：实践**（工作表 1-6 节 → 复制 `03-Practice/_template/` 建立第一个项目） -- [ ] **阶段 4：按需回补**（04-Reference 按各自"前置阶段"插入项目推进过程） - -**当前状态：** 阶段 1（有界理论）· 未开始 · 更新于 2026-08-21 - -## 正在做什么 - -- （示例：读 [[01-What-Is-LLM-Evaluation]]，已完成 → 写一条"能回答/不能回答"的问题填入工作表第 0 节） - -## 卡点（写下来，下次从这里继续） - -- 无 / 或：xxx 概念没看懂，卡在…… - -## 下一步最小动作 - -- [ ] 读 [[01-What-Is-LLM-Evaluation|什么是 LLM Evaluation]] -- [ ] 完成 [[00-Start-Here|开始这里]] 的十分钟动作 - -## 相关链接 - -- 学习主线：[[01_Projects/Personal-Tech/LLM_Evaluation/README|专区首页]] -- 进度勾选：[[01-Learning-Board|学习看板]] -- 填写入口：[[02-First-Week-Worksheet|首周工作表]] -- 学习周记：[[01-学习周记]] -- 季度复盘：[[02-方法季度复盘]] - ---- - -返回 [[01_Projects/Personal-Tech/LLM_Evaluation/README|学习专区首页]]。 diff --git a/01_Projects/Personal-Tech/LLM_Evaluation/05-Progress/01-学习周记.md b/01_Projects/Personal-Tech/LLM_Evaluation/05-Progress/01-Weekly-Learning-Journal.md similarity index 74% rename from 01_Projects/Personal-Tech/LLM_Evaluation/05-Progress/01-学习周记.md rename to 01_Projects/Personal-Tech/LLM_Evaluation/05-Progress/01-Weekly-Learning-Journal.md index 163d3d6..992e85c 100644 --- a/01_Projects/Personal-Tech/LLM_Evaluation/05-Progress/01-学习周记.md +++ b/01_Projects/Personal-Tech/LLM_Evaluation/05-Progress/01-Weekly-Learning-Journal.md @@ -12,6 +12,23 @@ created: 2026-08-21 > **使用方式：** 每周一次（或每次学习后），复制下方模板，把日期改为当周，插到文件**最顶部**（最新在上）。周记是你"学习过程"的存档处：学习看板只负责勾选，周记负责记录发生了什么。 +## 2026-08-28 ｜ 进度同步 + +### 本周目标 +- 对齐进度文档与 `01-go-docs-qa` 实际进展；不提前完成 case / run。 + +### 本周理论理解 +- 有界理论阶段已完成；`04-Concepts-and-Theory` 定位为按需深读，非首周必读。 + +### 本周实践 +- 项目 `01-go-docs-qa`：任务边界 + rubric v0.1 + 文档冻结快照已完成。 +- 待做：10 个 case（`02-case-design.md`）。 + +### 下周最小动作 +- 填写 case 01–10。 + +--- + ## 模板（复制这一块，改日期后插到最上方） ```markdown diff --git a/01_Projects/Personal-Tech/LLM_Evaluation/05-Progress/02-方法季度复盘.md b/01_Projects/Personal-Tech/LLM_Evaluation/05-Progress/02-Quarterly-Method-Review.md similarity index 100% rename from 01_Projects/Personal-Tech/LLM_Evaluation/05-Progress/02-方法季度复盘.md rename to 01_Projects/Personal-Tech/LLM_Evaluation/05-Progress/02-Quarterly-Method-Review.md diff --git a/01_Projects/Personal-Tech/LLM_Evaluation/README.md b/01_Projects/Personal-Tech/LLM_Evaluation/README.md index 23bec07..266727b 100644 --- a/01_Projects/Personal-Tech/LLM_Evaluation/README.md +++ b/01_Projects/Personal-Tech/LLM_Evaluation/README.md @@ -27,8 +27,11 @@ created: 2026-08-21 | 3 | [[02-Why-Guide\|从零开始做 LLM 评测：每一步背后的道理]] | 为什么先做 case、rubric、盲评、run、失败分类与回归？ | 能解释每个动作在防什么问题。 | | 4 | [[02-Annotation-Human-Data-and-Evaluation\|数据标注、Human Data 与 Evaluation]] | 标注、人类数据与评测的区别是什么？ | 能区分 Annotation / Human Data / Evaluation 三种用途。 | | 5 | [[03-Core-Concept-Map\|LLM Evaluation 核心概念地图]] | 术语速查地图在哪？ | 阅读与实践时能快速定位术语（速查用，不要求背诵）。 | +| 6 | [[04-Concepts-and-Theory\|LLM 评测基础概念与理论]]（**可选深读**） | 需要构念→测量→决策框架时查阅 | 知道存在即可；不在首周必读范围内 | > ⛔ **停止线：理论到此为止。** 不要继续读 `04-Reference`、guidebook 或归档——它们是"按需查阅的工具书"，不是"要读完的教材"。 +> +> `04-Concepts-and-Theory` 是 01–03 的教学整合深读版（约 2500 行），**不属于 3–4 小时有界理论**；卡住某个概念时再读对应章节，不要通读。 ### 阶段 2 · 出口检查（判断"理论够了"，而不是读完多少页） @@ -55,7 +58,7 @@ created: 2026-08-21 > **数量口径：** 首周最低完成 10 个 case（结构见《首周工作表》第 2 节）；若时间充裕，按路线图 Day 1 扩展至 20 个（配比见《实战路线图》Day 1 小节）。 -> **进度记录：** 学习过程（当前位置、周记、季度复盘）统一记在 [[01_Projects/Personal-Tech/LLM_Evaluation/05-Progress/00-当前位置与下一步\|05-Progress]]；学习看板只负责勾选。 +> **进度记录：** 学习过程（当前位置、周记、季度复盘）统一记在 [[01_Projects/Personal-Tech/LLM_Evaluation/05-Progress/00-Current-Status-and-Next-Steps\|05-Progress]]；学习看板只负责勾选。 ## 目录结构为何这样设计 @@ -86,7 +89,7 @@ created: 2026-08-21 ## 你的当前入口 -打开 [[01_Projects/Personal-Tech/LLM_Evaluation/05-Progress/00-当前位置与下一步|当前位置]]，确认自己处在哪个阶段；从 [[00-Start-Here|开始这里]] 完成十分钟动作；完成后填写 [[02-First-Week-Worksheet|首周工作表]]。想追踪进度时，对照 [[01-Learning-Board|学习看板]] 勾选闭环条目（勾选时补日期）。 +打开 [[01_Projects/Personal-Tech/LLM_Evaluation/05-Progress/00-Current-Status-and-Next-Steps|当前位置]]，确认自己处在哪个阶段；从 [[00-Start-Here|开始这里]] 完成十分钟动作；完成后填写 [[02-First-Week-Worksheet|首周工作表]]。想追踪进度时，对照 [[01-Learning-Board|学习看板]] 勾选闭环条目（勾选时补日期）。 ## 关联材料 @@ -95,4 +98,7 @@ created: 2026-08-21 - 外部权威知识参考：[[01_Projects/Personal-Tech/LLM_Evaluation/04-Reference/evaluation-guidebook/00-Overview|HuggingFace Evaluation Guidebook 中文提炼]]（自动基准 / 人工评测 / LLM-as-judge / 排错，按主题查阅） - 外部精选资源（已归档）：[[01_Projects/Personal-Tech/LLM_Evaluation/04-Reference/archive/01-Curated-External-Resources|精选外部评测资源]]（顶级大厂与开源组织的生产级方案、评测基建与硬核课程源码） - 归档总索引：[[01_Projects/Personal-Tech/LLM_Evaluation/04-Reference/archive/00-Material-List|材料清单与归档说明]]（早期草案与外部参考的定位总览） -- 学习进度与自评：[[01_Projects/Personal-Tech/LLM_Evaluation/05-Progress/00-当前位置与下一步|05-Progress]]（当前位置 / 学习周记 / 季度复盘 / 作品集清单） +- 学习进度与自评：[[01_Projects/Personal-Tech/LLM_Evaluation/05-Progress/00-Current-Status-and-Next-Steps|05-Progress]]（当前位置 / 学习周记 / 季度复盘 / 作品集清单） + + +[You have received this identical output 3 times. Re-reading '/Users/windy/Documents/vault/my-vault/01_Projects/Personal-Tech/LLM_Evaluation/README.md:raw' will not change it — use a narrower selector (path:A-B), or proceed with the edit.] \ No newline at end of file