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 5c7e737..11d0e11 100644 --- a/01_Projects/Personal-Tech/LLM_Evaluation/00-Foundations/README.md +++ b/01_Projects/Personal-Tech/LLM_Evaluation/00-Foundations/README.md @@ -22,4 +22,6 @@ created: 2026-08-21 - [[02-Why-Guide|从零开始做 LLM 评测：每一步背后的道理]] - [[01-LLM-Evaluation-Roadmap|从软件工程到 LLM 评测工程：实战路线]] +> ⚠️ **读完本层 ≠ 完成理论学习。** 理论阶段的出口是 [[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**。 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 693de06..cd1dca0 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,8 +13,12 @@ created: 2026-08-21 > 这个看板只追踪“是否形成评测闭环”，不追踪看了多少篇文章或装了多少工具。 +> **使用说明：** 勾选时在条目后补日期，例如 `- [x] 我已读完 [[02-Why-Guide]]（2026-08-21）`。学习过程的详细记录（周记、卡点、复盘）见 [[01_Projects/Personal-Tech/LLM_Evaluation/05-Progress/00-当前位置与下一步|05-Progress]]。 + ## Level 1：建立判断能力 +> **本 Level 是理论阶段的出口、实践阶段的入口。** 全部勾选后，就从"读"切换到"写"：填 [[02-First-Week-Worksheet|首周工作表]]，然后复制 `03-Practice/_template/` 建立第一个项目。 + - [ ] 我能用自己的话解释：为什么先定义成功条件，再运行模型。 - [ ] 我已读完 [[02-Why-Guide]]。 - [ ] 我已从公开资料中选定一个范围足够小的任务。 @@ -39,29 +43,17 @@ created: 2026-08-21 ## Level 4：深度参考（资源地图精读） -> 精读顺序见 [[04-Reference/README|04-Reference 资源地图]]。只精读 4 个，其余按需查阅。 +> 精读顺序见 [[01_Projects/Personal-Tech/LLM_Evaluation/04-Reference/README|04-Reference 资源地图]]。只精读 4 个，其余按需查阅。 - [ ] 我已通读资源地图并选定自己的精读顺序。 -- [ ] AWS Workshop：我已拆解至少 1 个模块的 Task / Case / Rubric / Grader / Failure（[[04-Reference/01-Evaluation-Infrastructure\|01-Evaluation-Infrastructure]]）。 -- [ ] lm-evaluation-harness：我能讲清 Task 标准化、Prompt 固定、Metric 配置与去污染（[[04-Reference/02-Benchmark-and-Reproducibility\|02-Benchmark-and-Reproducibility]]）。 -- [ ] Inspect AI + AISI：我能映射 Evaluate / Isolate / Connect / Run / Scale 与 Task / Solver / Scorer / Sandbox / Trace 抽象（[[04-Reference/01-Evaluation-Infrastructure\|01-Evaluation-Infrastructure]]）。 -- [ ] OLMES：我能解释 Evaluation Protocol 冻结为何带来可复现比较（[[04-Reference/02-Benchmark-and-Reproducibility\|02-Benchmark-and-Reproducibility]]）。 -- [ ] 我已用 [[04-Reference/05-Source-Reading-Checklist\|源码阅读检查清单]] 的 8 个问题对照过至少 1 个框架。 +- [ ] AWS Workshop：我已拆解至少 1 个模块的 Task / Case / Rubric / Grader / Failure（[[01_Projects/Personal-Tech/LLM_Evaluation/04-Reference/01-Evaluation-Infrastructure\|01-Evaluation-Infrastructure]]）。 +- [ ] lm-evaluation-harness：我能讲清 Task 标准化、Prompt 固定、Metric 配置与去污染（[[01_Projects/Personal-Tech/LLM_Evaluation/04-Reference/02-Benchmark-and-Reproducibility\|02-Benchmark-and-Reproducibility]]）。 +- [ ] Inspect AI + AISI：我能映射 Evaluate / Isolate / Connect / Run / Scale 与 Task / Solver / Scorer / Sandbox / Trace 抽象（[[01_Projects/Personal-Tech/LLM_Evaluation/04-Reference/01-Evaluation-Infrastructure\|01-Evaluation-Infrastructure]]）。 +- [ ] OLMES：我能解释 Evaluation Protocol 冻结为何带来可复现比较（[[01_Projects/Personal-Tech/LLM_Evaluation/04-Reference/02-Benchmark-and-Reproducibility\|02-Benchmark-and-Reproducibility]]）。 +- [ ] 我已用 [[01_Projects/Personal-Tech/LLM_Evaluation/04-Reference/05-Source-Reading-Checklist\|源码阅读检查清单]] 的 8 个问题对照过至少 1 个框架。 -## 每周复盘（复制到项目周记） +## 每周复盘 -```markdown -## 本周目标 - -## 我新定义了什么成功 / 失败条件？ - -## 我新增或修订了哪些 case？为什么？ - -## 本周主要失败类型是什么？ - -## 我改变了什么？预期是什么？实际发生了什么？ - -## 下周只保留的一个最小动作 -``` +> 每周复盘模板见 [[01_Projects/Personal-Tech/LLM_Evaluation/05-Progress/01-学习周记|学习周记]]（复制模板、改日期后插到文件最顶部）；问题框架与学习看板 Level 1–3 的闭环检查一致。 返回 [[01_Projects/Personal-Tech/LLM_Evaluation/README|学习专区首页]]。 diff --git a/01_Projects/Personal-Tech/LLM_Evaluation/01-Getting-Started/02-Why-Guide.md b/01_Projects/Personal-Tech/LLM_Evaluation/01-Getting-Started/02-Why-Guide.md index c540688..50ca35f 100644 --- a/01_Projects/Personal-Tech/LLM_Evaluation/01-Getting-Started/02-Why-Guide.md +++ b/01_Projects/Personal-Tech/LLM_Evaluation/01-Getting-Started/02-Why-Guide.md @@ -335,7 +335,7 @@ Run 记录：这个版本的系统在某个时间、某个配置下实际输出 | 暂时不做 | 为什么现在不做 | 什么时候再学 | |---|---|---| | 训练 / 微调模型 | 你还没有稳定的质量标准，不知道该用什么数据改进 | 能稳定设计 case、rubric 与回归集之后。 | -| LLM-as-a-Judge | 自动评分会掩盖 rubric 是否清楚 | 手工盲评至少 20—50 条并复盘分歧之后。 | +| LLM-as-a-Judge | 自动评分会掩盖 rubric 是否清楚 | 手工盲评至少 20—50 条并复盘分歧之后（正式校准用 50–100 条代表样本，见路线图第七节）。 | | CI 门禁、平台和仪表盘 | 它们放大已有流程，不会创造流程 | 手工重跑开始重复、容易漏步骤之后。 | | 大规模红队 | 范围广、风险分类复杂 | 有一个具体系统边界，如 RAG 注入或工具越权之后。 | | 1000 条数据 | 数量会掩盖设计问题 | 你能明确说出每个类别为何存在之后。 | 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 new file mode 100644 index 0000000..d28c429 --- /dev/null +++ b/01_Projects/Personal-Tech/LLM_Evaluation/01-Getting-Started/README.md @@ -0,0 +1,22 @@ +--- +type: hub +tags: + - llm-evaluation + - getting-started +status: active +created: 2026-08-21 +--- + +# Getting Started + +这里负责回答"为什么做评测"并跟踪学习进度。 + +推荐顺序： + +1. [[00-Start-Here|开始这里]]（十分钟动作入口） +2. [[02-Why-Guide|从零开始做 LLM 评测：每一步背后的道理]] +3. [[01-Learning-Board|学习看板]]（进度勾选，全程使用） + +> 学习进度（当前位置、周记、季度复盘）统一记在 [[01_Projects/Personal-Tech/LLM_Evaluation/05-Progress/00-当前位置与下一步|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 6af7499..fd5c7bb 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 @@ -13,8 +13,25 @@ created: 2026-08-21 **使用方法：** 不要先研究工具。直接复制本文件，为一个公开文档问答小任务填写空白处。只要完成到“10 个 case + rubric + 一次盲评”，就已经完成了真正的第一步。 +> **填完放哪：** 填写完成的副本**复制进 [[01_Projects/Personal-Tech/LLM_Evaluation/03-Practice/README|03-Practice]] 下你的项目目录**（骨架见 [[01_Projects/Personal-Tech/LLM_Evaluation/03-Practice/_template/00-项目概览|03-Practice/_template/]]），本文件只保留空白模板，供以后复用。 + > **与路线图的关系：** 本工作表是《LLM 评测工程实战路线图》Day 1—3 的填空版，按“首周最低 10 个 case”设计；若时间充裕，可按路线图扩展至 20 个。 +### 填写内容 → 项目文件的对应关系 + +工作表填完后，把内容按下面的对应关系整理进项目目录（骨架见 [[01_Projects/Personal-Tech/LLM_Evaluation/03-Practice/_template/00-项目概览|03-Practice/_template/]]）： + +| 工作表小节 | 对应项目文件 | +|---|---| +| 第 0 节：任务边界 | `00-项目概览.md`（问题/成功条件/风险）+ `01-任务与Rubric.md`（任务边界表） | +| 第 1 节：Rubric v0.1 | `01-任务与Rubric.md` | +| 第 2 节：10 个 case | `02-Case设计.md` | +| 第 3-4 节：候选与盲评 | `03-运行与盲评.md` | +| 第 5 节：失败分类 | `04-失败复盘.md` | +| 第 6 节：修改与回归 | `05-变更与回归.md` | + +> 也就是说：工作表 = 第一次闭环的线性填空；项目目录 = 长期项目的分文件结构。填完工作表后把内容迁移进项目目录，就进入长期迭代（对应学习看板 Level 2 → Level 3）。 + ## 0. 先确定范围：你到底在评什么 > **为什么先填这一页：** 你不是在评价“模型总体能力”，而是在评价一个明确的系统行为。范围越明确，后面的 case 与评分越可信。 diff --git a/01_Projects/Personal-Tech/LLM_Evaluation/02-Practical-Roadmap/README.md b/01_Projects/Personal-Tech/LLM_Evaluation/02-Practical-Roadmap/README.md new file mode 100644 index 0000000..af2cd60 --- /dev/null +++ b/01_Projects/Personal-Tech/LLM_Evaluation/02-Practical-Roadmap/README.md @@ -0,0 +1,21 @@ +--- +type: hub +tags: + - llm-evaluation + - roadmap +status: active +created: 2026-08-21 +--- + +# Practical Roadmap + +这里把原则转成动作：路线、工作表与阶段性任务。 + +推荐顺序： + +1. [[01-LLM-Evaluation-Roadmap|LLM 评测工程实战路线图]]（怎么做：72 小时最小闭环 → 100 个 case → 12 周路线） +2. [[02-First-Week-Worksheet|首周工作表]]（Day 1–3 的填空版，先填它） + +> 工作表填完后，把内容迁移进 [[01_Projects/Personal-Tech/LLM_Evaluation/03-Practice/README|03-Practice]] 下的项目目录（对照表见该页）。 + +原则：这里回答 **How**；原理与为什么见 [[02-Why-Guide]]（`01-Getting-Started`），基础概念见 `00-Foundations`。 diff --git a/01_Projects/Personal-Tech/LLM_Evaluation/03-Practice/README.md b/01_Projects/Personal-Tech/LLM_Evaluation/03-Practice/README.md index 6c058c0..31e532b 100644 --- a/01_Projects/Personal-Tech/LLM_Evaluation/03-Practice/README.md +++ b/01_Projects/Personal-Tech/LLM_Evaluation/03-Practice/README.md @@ -11,6 +11,12 @@ created: 2026-08-21 这里用于放实际 Eval 项目，而不是继续积累理论笔记。学习材料告诉你“为什么”和“怎么做”（[[02-Why-Guide|Why Guide]]、[[01-LLM-Evaluation-Roadmap|实战路线图]]）；项目目录保存你亲自得到的证据。 +## 项目列表 + +| 项目 | 状态 | 代码仓库 | 最近更新 | 一句话 | +|---|---|---|---|---| +| （暂无——从 [[02-First-Week-Worksheet|首周工作表]] 开始，复制 [[01_Projects/Personal-Tech/LLM_Evaluation/03-Practice/_template/00-项目概览|`_template/`]] 建立第一个项目） | | | | | + ## 建议的第一批项目 按以下顺序推进。先完成一个小型、可重跑的闭环，再增加框架和自动化： @@ -19,6 +25,8 @@ created: 2026-08-21 2. `agent-tool-eval/` — 模拟工具调用、权限与状态 3. `code-agent-eval/` — 编译、测试、静态分析与回归 +> 每个项目复制 [[01_Projects/Personal-Tech/LLM_Evaluation/03-Practice/_template/00-项目概览|`_template/` 骨架]]（6 个文件）即可开始；骨架内的引导说明引用了工作表与路线图，不重复内容。 + 每个项目创建独立子目录，例如： ```text @@ -43,6 +51,18 @@ scripts/ reports/ ``` +### Obsidian 模板 ↔ 代码仓库目录 对照 + +同一份项目内容在 Obsidian（判断与决策）与代码仓库（可运行事实）中各存一份，对应关系如下： + +| 工作表 / 模板（Obsidian 项目目录） | 代码仓库目录（路线图 §4 的 `llm-eval-lab/` 结构） | +|---|---| +| `00-项目概览.md` + `01-任务与Rubric.md` | `task.md` + `rubrics/` | +| `02-Case设计.md` | `datasets/`（冻结的 eval 定义，JSONL） | +| `03-运行与盲评.md` | `runs/`（原始输出 + 盲评记录） | +| `04-失败复盘.md` | `reports/`（确认的失败入 `datasets/regression/`） | +| `05-变更与回归.md` | `scripts/`（validate / eval）+ CI 配置 | + ## 为什么笔记和数据要分开 这个 Obsidian 专区保存**思考与决策**；代码仓库保存 JSONL、脚本和原始运行输出。两边互相链接即可： @@ -66,33 +86,7 @@ reports/ ## 项目模板 -可直接复制以下内容到新项目的 `00-项目概览.md`： - -```markdown ---- -type: project -status: active -project_type: rag-eval ---- - -# 项目名称 - -## 问题与范围 - -## 一句话成功条件 - -## 主要风险 - -## 当前版本 - -## 关键链接 -- 工作表： -- 代码仓库： -- 数据集： -- 最近报告： - -## 下一步最小动作 -``` +新项目的 `00-项目概览.md` 直接复制 `_template/00-项目概览.md`（骨架见 [[01_Projects/Personal-Tech/LLM_Evaluation/03-Practice/_template/00-项目概览|`_template/`]]）；本页不再内嵌模板副本，避免与模板文件漂移。 ## 开始前 diff --git a/01_Projects/Personal-Tech/LLM_Evaluation/03-Practice/_template/00-项目概览.md b/01_Projects/Personal-Tech/LLM_Evaluation/03-Practice/_template/00-项目概览.md new file mode 100644 index 0000000..355c41c --- /dev/null +++ b/01_Projects/Personal-Tech/LLM_Evaluation/03-Practice/_template/00-项目概览.md @@ -0,0 +1,58 @@ +--- +type: project +status: active +project_type: rag-eval # 可选：rag-eval / agent-tool-eval / code-agent-eval / text-to-sql +created: 2026-08-21 +--- + +# 项目名称 + +> **模板使用说明：** 复制整个 `_template/` 文件夹为 `03-Practice/2026-项目名/`，逐项填写。各节的权威方法与表格见 [[02-First-Week-Worksheet|首周工作表]] 与 [[01-LLM-Evaluation-Roadmap|实战路线图]]；本模板只做骨架，不重复内容。 + +## 问题与范围 + +- 任务名称： +- 用户输入： +- 系统输出： + +## 一句话成功条件 + +> （示例：关键事实可由文档支持；资料不足时明确说明） + +## 三类失败 + +1. +2. +3. + +## 非目标 + +- （示例：不评价文档外的常识正确性） + +## 数据来源 / 许可 + +- 来源：／ URL：／ 日期： +- 许可：／ PII 政策： + +## 主要风险 + +- （示例：无依据补全、过度拒答、引用错位） + +## 当前版本 + +- dataset_version：v0.1 ／ rubric_version：v0.1 ／ 最近 run： + +## 关键链接 + +- 工作表：[[02-First-Week-Worksheet|首周工作表]] +- 代码仓库：（GitHub URL） +- 数据集：`datasets/eval-v0.1.jsonl` +- 最近报告：`reports/report-v0.1.md` + +## 下一步最小动作 + +- [ ] + +--- + +返回 [[01_Projects/Personal-Tech/LLM_Evaluation/03-Practice/README|项目实践入口]]。 diff --git a/01_Projects/Personal-Tech/LLM_Evaluation/03-Practice/_template/01-任务与Rubric.md b/01_Projects/Personal-Tech/LLM_Evaluation/03-Practice/_template/01-任务与Rubric.md new file mode 100644 index 0000000..a6b4180 --- /dev/null +++ b/01_Projects/Personal-Tech/LLM_Evaluation/03-Practice/_template/01-任务与Rubric.md @@ -0,0 +1,48 @@ +--- +type: project +status: active +--- + +# 01 · 任务与 Rubric + +> 权威版本：rubric 三维度的完整定义见 [[01-LLM-Evaluation-Roadmap]] 第六节；为什么这样设计见 [[02-Why-Guide]] 第 3 步。本文件只记录本项目的填写结果。 + +## 任务边界（对应工作表第 0 节） + +| 项目 | 你的填写 | +|---|---| +| 任务名称 | | +| 用户输入 | | +| 系统输出 | | +| 一句话成功条件 | | +| 三类失败 | | +| 非目标 | | +| 数据来源 / 许可 | | + +## Rubric v0.1（对应工作表第 1 节） + +| 维度 | 通过条件 | 失败条件 | 正例 | 反例 | +|---|---|---|---|---| +| 有据性（pass/fail） | | | | | +| 资料不足处理（pass/fail） | | | | | +| 核心任务完成度（0/1/2） | | | | | + +> 0/1/2 评分定义见 [[01-LLM-Evaluation-Roadmap]] 第六节；第一版不要增加维度。 + +### 一票否决项 + +- （示例：出现任何无证据事实 → 整体 fail，无论其他维度） + +### 无法判断时的升级路径 + +- （示例：两个片段对同一参数描述冲突 → 标记 low confidence，人工仲裁，不自动评分） + +### Rubric 修改记录 + +| 版本 | 日期 | 改了什么 | 为什么改 | 预期影响 | 实际结果 | +|---|---|---|---|---|---| +| v0.1 | | | | | | + +--- + +返回 [[01_Projects/Personal-Tech/LLM_Evaluation/03-Practice/README|项目实践入口]]。 diff --git a/01_Projects/Personal-Tech/LLM_Evaluation/03-Practice/_template/02-Case设计.md b/01_Projects/Personal-Tech/LLM_Evaluation/03-Practice/_template/02-Case设计.md new file mode 100644 index 0000000..e5094a7 --- /dev/null +++ b/01_Projects/Personal-Tech/LLM_Evaluation/03-Practice/_template/02-Case设计.md @@ -0,0 +1,46 @@ +--- +type: project +status: active +--- + +# 02 · Case 设计 + +> 权威分布表：20-case 配比见 [[01-LLM-Evaluation-Roadmap]] Day 1；10-case 结构见 [[02-First-Week-Worksheet]] 第 2 节。第一版 10-20 个即可。 + +## Case 列表（对应工作表第 2 节） + +| 编号 | 类别 | 问题 | 文档能否完整回答 | 预期系统行为 | case 状态 | +|---|---:|---|---|---|---| +| 01 | 正常路径 | | 是 | | candidate | +| 02 | 正常路径 | | 是 | | | +| 03 | 正常路径 | | 是 | | | +| 04 | 资料不足 | | 否 | | | +| 05 | 资料不足 | | 否 | | | +| 06 | 部分支持 | | 部分 | | | +| 07 | 多证据 | | 是 | | | +| 08 | 幻觉诱发 | | 否 / 部分 | | | +| 09 | 格式约束 | | 是 | | | +| 10 | 边界条件 | | 视情况 | | | + +> case 状态流转：candidate → reviewed → accepted → regression → deprecated（定义见 [[01-LLM-Evaluation-Roadmap]] 第五节）。 +> +> 资料不足的写法：不要写完全无关的问题，写"只差一小块信息就能回答"的问题（如文档讲了字段但没有默认值），才能测出模型会不会补全空白。 + +## JSONL 结构（稳定测试定义） + +> 字段与示例见 [[01-LLM-Evaluation-Roadmap]] 第五节。每个 case 至少包含：id / input / expected / metadata（category、difficulty、risk、split、case_status）/ rubric_version / dataset_version。**测试定义与运行记录分开保存**。 + +```json +{ + "id": "rag-0001", + "input": { "question": "", "context": [] }, + "expected": { "behavior": "", "must_include": [], "must_not_include": [] }, + "metadata": { "category": "", "difficulty": "", "risk": "", "split": "dev", "case_status": "candidate" }, + "rubric_version": "0.1", + "dataset_version": "0.1" +} +``` + +--- + +返回 [[01_Projects/Personal-Tech/LLM_Evaluation/03-Practice/README|项目实践入口]]。 diff --git a/01_Projects/Personal-Tech/LLM_Evaluation/03-Practice/_template/03-运行与盲评.md b/01_Projects/Personal-Tech/LLM_Evaluation/03-Practice/_template/03-运行与盲评.md new file mode 100644 index 0000000..9ec019d --- /dev/null +++ b/01_Projects/Personal-Tech/LLM_Evaluation/03-Practice/_template/03-运行与盲评.md @@ -0,0 +1,58 @@ +--- +type: project +status: active +--- + +# 03 · 运行与盲评 + +> 为什么盲评、最小记录格式见 [[02-Why-Guide]] 第 4 步；run 的 JSONL schema 见 [[01-LLM-Evaluation-Roadmap]] 第五节。 + +## 候选生成条件（对应工作表第 3 节） + +| 项目 | A | B | +|---|---|---| +| 模型 / 来源 | | | +| 系统提示词版本 | | | +| 温度 / 生成设置 | | | +| 运行日期 | | | +| dataset_version | | | + +> 重要：先把来源隐藏、随机标 A/B；完成全部判断前不要看真实来源。 + +## 盲评记录（对应工作表第 4 节） + +| 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/_template/04-失败复盘.md b/01_Projects/Personal-Tech/LLM_Evaluation/03-Practice/_template/04-失败复盘.md new file mode 100644 index 0000000..c61ad21 --- /dev/null +++ b/01_Projects/Personal-Tech/LLM_Evaluation/03-Practice/_template/04-失败复盘.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/_template/05-变更与回归.md b/01_Projects/Personal-Tech/LLM_Evaluation/03-Practice/_template/05-变更与回归.md new file mode 100644 index 0000000..81dc12c --- /dev/null +++ b/01_Projects/Personal-Tech/LLM_Evaluation/03-Practice/_template/05-变更与回归.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/04-Reference/01-Evaluation-Infrastructure.md b/01_Projects/Personal-Tech/LLM_Evaluation/04-Reference/01-Evaluation-Infrastructure.md index 961475b..ce2cbc2 100644 --- a/01_Projects/Personal-Tech/LLM_Evaluation/04-Reference/01-Evaluation-Infrastructure.md +++ b/01_Projects/Personal-Tech/LLM_Evaluation/04-Reference/01-Evaluation-Infrastructure.md @@ -34,12 +34,7 @@ created: 2026-08-21 ### 2. AWS Generative AI Evaluations Workshop - 为什么看：目前垂直场景最全、最硬核的可运行实战代码 -- 覆盖场景： - - Multimodal RAG - - Tool Calling（5 种渐进式评测方法） - - Automated Reasoning（利用 SMT 求解器检查合规） - - Multi-Agent Shared Context - - Red Teaming +- 覆盖场景：Multimodal RAG / Tool Calling（5 种渐进式评测方法）/ Automated Reasoning（SMT 求解器）/ Multi-Agent Shared Context / Red Teaming（完整介绍与链接见 [[01_Projects/Personal-Tech/LLM_Evaluation/04-Reference/archive/01-Curated-External-Resources|archive/01]]） - 学习方式（重要）： 不要只照着 Notebook 跑。每个模块都问： - Task 是什么？ @@ -48,10 +43,10 @@ created: 2026-08-21 - Grader 是什么？ - Failure 如何定义？ - 如何做成 Regression？ -- 适合阶段：最适合作为第一个实操资源 +- 适合阶段：完成第一个小项目以后（与本节开头一致）；精读顺序上建议作为四个 S 级资源中第一个上手（见 [[01_Projects/Personal-Tech/LLM_Evaluation/04-Reference/README|04-Reference 资源地图]]） ## 次级参考 -- Hugging Face evaluation-guidebook（已在本目录下：[[04-Reference/evaluation-guidebook/00-Overview|evaluation-guidebook]]） +- Hugging Face evaluation-guidebook（已在本目录下：[[01_Projects/Personal-Tech/LLM_Evaluation/04-Reference/evaluation-guidebook/00-Overview|evaluation-guidebook]]） - DeepEval（应用级单元测试框架，上手快但抽象层较浅） -> 🔗 本页资源的完整链接、来源背景与上手建议见 [[04-Reference/archive/01-Curated-External-Resources|archive/01-Curated-External-Resources]]（"国家级与顶级学术机构"与"云厂商生产环境"两节）。 +> 🔗 本页资源的完整链接、来源背景与上手建议见 [[01_Projects/Personal-Tech/LLM_Evaluation/04-Reference/archive/01-Curated-External-Resources|archive/01-Curated-External-Resources]]（"国家级与顶级学术机构"与"云厂商生产环境"两节）。 diff --git a/01_Projects/Personal-Tech/LLM_Evaluation/04-Reference/02-Benchmark-and-Reproducibility.md b/01_Projects/Personal-Tech/LLM_Evaluation/04-Reference/02-Benchmark-and-Reproducibility.md index 53e6563..fdff579 100644 --- a/01_Projects/Personal-Tech/LLM_Evaluation/04-Reference/02-Benchmark-and-Reproducibility.md +++ b/01_Projects/Personal-Tech/LLM_Evaluation/04-Reference/02-Benchmark-and-Reproducibility.md @@ -46,4 +46,4 @@ created: 2026-08-21 ## 关键认知 Benchmark 工程的本质是把「测试定义」做成可版本化的资产。 -> 🔗 本页资源的完整链接、来源背景与上手建议见 [[04-Reference/archive/01-Curated-External-Resources|archive/01-Curated-External-Resources]]（"国家级与顶级学术机构"一节）。 +> 🔗 本页资源的完整链接、来源背景与上手建议见 [[01_Projects/Personal-Tech/LLM_Evaluation/04-Reference/archive/01-Curated-External-Resources|archive/01-Curated-External-Resources]]（"国家级与顶级学术机构"一节）。 diff --git a/01_Projects/Personal-Tech/LLM_Evaluation/04-Reference/03-Continuous-Evaluation.md b/01_Projects/Personal-Tech/LLM_Evaluation/04-Reference/03-Continuous-Evaluation.md index 1f95e73..38cf96f 100644 --- a/01_Projects/Personal-Tech/LLM_Evaluation/04-Reference/03-Continuous-Evaluation.md +++ b/01_Projects/Personal-Tech/LLM_Evaluation/04-Reference/03-Continuous-Evaluation.md @@ -34,4 +34,4 @@ created: 2026-08-21 说明该学 experiment tracking 了 - 不建议：一开始就为了"专业"搭 W&B -> 🔗 本页资源的完整链接、来源背景与上手建议见 [[04-Reference/archive/01-Curated-External-Resources|archive/01-Curated-External-Resources]]（"云厂商生产环境"与"名校/大牛的工业级课程"两节）。 +> 🔗 本页资源的完整链接、来源背景与上手建议见 [[01_Projects/Personal-Tech/LLM_Evaluation/04-Reference/archive/01-Curated-External-Resources|archive/01-Curated-External-Resources]]（"云厂商生产环境"与"名校/大牛的工业级课程"两节）。 diff --git a/01_Projects/Personal-Tech/LLM_Evaluation/04-Reference/04-Agent-Safety-and-Environments.md b/01_Projects/Personal-Tech/LLM_Evaluation/04-Reference/04-Agent-Safety-and-Environments.md index a378a85..0e9e6f3 100644 --- a/01_Projects/Personal-Tech/LLM_Evaluation/04-Reference/04-Agent-Safety-and-Environments.md +++ b/01_Projects/Personal-Tech/LLM_Evaluation/04-Reference/04-Agent-Safety-and-Environments.md @@ -30,4 +30,4 @@ created: 2026-08-21 - Tool Calling 的 5 种渐进式评测 - Red Teaming 示例 -> 🔗 本页资源的完整链接、来源背景与上手建议见 [[04-Reference/archive/01-Curated-External-Resources|archive/01-Curated-External-Resources]]（"国家级与顶级学术机构"的 AISI 一节与"解决环境即数据的下一代框架"一节）。 +> 🔗 本页资源的完整链接、来源背景与上手建议见 [[01_Projects/Personal-Tech/LLM_Evaluation/04-Reference/archive/01-Curated-External-Resources|archive/01-Curated-External-Resources]]（"国家级与顶级学术机构"的 AISI 一节与"解决环境即数据的下一代框架"一节）。 diff --git a/01_Projects/Personal-Tech/LLM_Evaluation/04-Reference/README.md b/01_Projects/Personal-Tech/LLM_Evaluation/04-Reference/README.md index fd5da35..c0513c0 100644 --- a/01_Projects/Personal-Tech/LLM_Evaluation/04-Reference/README.md +++ b/01_Projects/Personal-Tech/LLM_Evaluation/04-Reference/README.md @@ -13,6 +13,16 @@ created: 2026-08-21 本目录不是"收藏夹"，而是**评测工程能力地图**。 每个资源都对应明确的能力点，并标明「为什么看、什么时候看、重点看什么」。 +## 本目录包含三类内容 + +| 类别 | 位置 | 定位 | 什么时候读 | +|---|---|---|---| +| 能力地图 | `01-`~`05-` 五篇 | 个人评测工程能力地图（Harness / 可复现 / 持续评测 / Agent 安全 / 阅读方法） | 按各自"前置阶段"插入项目推进过程 | +| 外部知识 | `evaluation-guidebook/` | HuggingFace Guidebook 中文提炼（9 篇） | 设计或执行评测时按主题查阅 | +| 归档 | `archive/` | 早期草案与外部资源清单 | 需要背景时查阅，不作为学习主线 | + +> ⚠️ **本目录是分阶段查阅的工具书，不是要读完的教材。** 在完成学习看板 Level 1 与第一个项目之前，不要系统阅读本目录（见 [[01_Projects/Personal-Tech/LLM_Evaluation/README|专区首页]] 的停止线）。 + ## 五层能力框架 ```text @@ -27,6 +37,8 @@ created: 2026-08-21 5. Safety / Sandbox / Environment ``` +> 注：五层能力是**能力分层**，与下方五个文件（01–05）不是一一对应——第 3 层（System / Agent Evaluation）的内容分散在 01 与 04 两篇；`05-Source-Reading-Checklist` 是阅读方法，不属于能力层。"只精读 4 个"指 4 个 S 级资源（AWS / lm-eval / Inspect / OLMES），不是 4 个文件。 + 对应到本仓库： ```text @@ -39,6 +51,8 @@ created: 2026-08-21 ## 推荐学习顺序（只精读 4 个） +> 本清单属于阶段 4（按需回补）的深度精读计划；在完成看板 Level 1 与第一个项目之前，不需要开始（见 [[01_Projects/Personal-Tech/LLM_Evaluation/README|专区首页]] 停止线）。 + 1. **AWS Generative AI Evaluations Workshop** → 先看实际 Eval 长什么样（RAG / Tool Calling / Multi-Agent / Red Teaming） @@ -55,17 +69,17 @@ created: 2026-08-21 - CircleCI + RAGAS → Continuous Evaluation - BenchFlow → Environment-based Agent Evaluation -## 文件索引 +## 文件索引（含前置阶段） -| 文件 | 对应能力 | 核心资源 | -|------|----------|----------| -| [[01-Evaluation-Infrastructure\|01-Evaluation-Infrastructure]] | Harness / Sandbox / Scaling | Inspect AI, AISI Playbook, AWS Workshop | -| [[02-Benchmark-and-Reproducibility\|02-Benchmark-and-Reproducibility]] | 标准化 / 去污染 / 可复现 | lm-evaluation-harness, OLMES | -| [[03-Continuous-Evaluation\|03-Continuous-Evaluation]] | CI Gate / Experiment Tracking | RAGAS + CircleCI, W&B | -| [[04-Agent-Safety-and-Environments\|04-Agent-Safety-and-Environments]] | Tool Use / Sandbox / Trajectory | Inspect Sandbox, BenchFlow | -| [[05-Source-Reading-Checklist\|05-Source-Reading-Checklist]] | 统一阅读方法论 | 固定的 8 个问题 | -| [[04-Reference/evaluation-guidebook/00-Overview\|evaluation-guidebook]] | 方法论补充 | Hugging Face 官方 Guidebook | -| [[04-Reference/archive/00-Material-List\|archive/]] | 早期草案与外部资源归档 | 索引见 00-Material-List | +| 文件 | 对应能力 | 核心资源 | 前置阶段 | +|------|----------|----------|----------| +| [[01-Evaluation-Infrastructure\|01-Evaluation-Infrastructure]] | Harness / Sandbox / Scaling | Inspect AI, AISI Playbook, AWS Workshop | 完成第一个小项目以后 | +| [[02-Benchmark-and-Reproducibility\|02-Benchmark-and-Reproducibility]] | 标准化 / 去污染 / 可复现 | lm-evaluation-harness, OLMES | 完成 Foundations + Why Guide 后 | +| [[03-Continuous-Evaluation\|03-Continuous-Evaluation]] | CI Gate / Experiment Tracking | RAGAS + CircleCI, W&B | 项目已有 regression set 后 | +| [[04-Agent-Safety-and-Environments\|04-Agent-Safety-and-Environments]] | Tool Use / Sandbox / Trajectory | Inspect Sandbox, BenchFlow | 掌握 Task / Trial / Trace / Outcome / Harness 之后（后期） | +| [[05-Source-Reading-Checklist\|05-Source-Reading-Checklist]] | 统一阅读方法论 | 固定的 8 个问题 | 随时（读任何框架前） | +| [[01_Projects/Personal-Tech/LLM_Evaluation/04-Reference/evaluation-guidebook/00-Overview\|evaluation-guidebook]] | 方法论补充 | Hugging Face 官方 Guidebook | 按主题查阅 | +| [[01_Projects/Personal-Tech/LLM_Evaluation/04-Reference/archive/00-Material-List\|archive/]] | 早期草案与外部资源归档 | 索引见 00-Material-List | 需要背景时 | ## 原则 diff --git a/01_Projects/Personal-Tech/LLM_Evaluation/04-Reference/archive/00-Material-List.md b/01_Projects/Personal-Tech/LLM_Evaluation/04-Reference/archive/00-Material-List.md index 2843eda..139a9cd 100644 --- a/01_Projects/Personal-Tech/LLM_Evaluation/04-Reference/archive/00-Material-List.md +++ b/01_Projects/Personal-Tech/LLM_Evaluation/04-Reference/archive/00-Material-List.md @@ -5,7 +5,7 @@ type: reference tags: - llm-evaluation - archive -status: active +status: archive created: 2026-08-21 --- @@ -18,12 +18,12 @@ created: 2026-08-21 | [[02_Areas/Job/llm_data_annotation_programmer_roadmap\|大模型数据标注与程序员入门]]（原文存于 02_Areas/Job，本专区不再复制副本） | 职业全景与程序员能力迁移背景 | 想理解岗位、方向与能力地图时 | 覆盖面广，但不是第一个项目的直接操作材料。 | | [[02-Intro-Cognitive-Framework-Draft]] | Why Guide 的概念设计底稿 | 想研究内容设计或自行扩展课程时 | 已被正式 Why Guide 吸收，不建议日常阅读。 | | [[03-Roadmap-Refactor-Outline-Draft]] | Practical Roadmap 的结构设计底稿 | 想理解路线如何从审阅意见演化时 | 正式路线图已更完整，草案只保留历史价值。 | -| [[evaluation-guidebook/00-Overview\|HuggingFace Evaluation Guidebook 中文提炼（子目录）]] | 外部权威评测知识参考（自动基准 / 人工评测 / LLM-as-judge / 排错等） | 设计或执行评测时按主题查阅 | 是外部资料的提炼笔记，作为查阅型参考而非个人学习主线的必经之路。 | +| [[01_Projects/Personal-Tech/LLM_Evaluation/04-Reference/evaluation-guidebook/00-Overview\|HuggingFace Evaluation Guidebook 中文提炼（子目录）]] | 外部权威评测知识参考（自动基准 / 人工评测 / LLM-as-judge / 排错等） | 设计或执行评测时按主题查阅 | 是外部资料的提炼笔记，作为查阅型参考而非个人学习主线的必经之路。 | | [[01-Curated-External-Resources\|精选外部评测资源]] | 外部精选资源清单（顶级大厂与开源组织的生产级方案、评测基建、硬核课程源码） | 想找生产级方案与源码时按类型查阅 | 是外部链接的筛选清单，作为资源索引而非学习主线的必经之路。 | ## 外部知识参考（evaluation-guidebook 子目录） -对 [HuggingFace Evaluation Guidebook](https://github.com/huggingface/evaluation-guidebook) 的中文提炼笔记，共 9 篇（00-Overview 总览 + 01–07 旧版分篇 + 08 新版提炼）。各篇清单与阅读方式见 [[evaluation-guidebook/00-Overview|总览：这是什么、怎么读]]，此处不重复罗列。 +对 [HuggingFace Evaluation Guidebook](https://github.com/huggingface/evaluation-guidebook) 的中文提炼笔记，共 9 篇（00-Overview 总览 + 01–07 旧版分篇 + 08 新版提炼）。各篇清单与阅读方式见 [[01_Projects/Personal-Tech/LLM_Evaluation/04-Reference/evaluation-guidebook/00-Overview|总览：这是什么、怎么读]]，此处不重复罗列。 ## 正式学习材料不在本目录 diff --git a/01_Projects/Personal-Tech/LLM_Evaluation/04-Reference/archive/01-Curated-External-Resources.md b/01_Projects/Personal-Tech/LLM_Evaluation/04-Reference/archive/01-Curated-External-Resources.md index ab99419..3a5c89c 100644 --- a/01_Projects/Personal-Tech/LLM_Evaluation/04-Reference/archive/01-Curated-External-Resources.md +++ b/01_Projects/Personal-Tech/LLM_Evaluation/04-Reference/archive/01-Curated-External-Resources.md @@ -7,7 +7,7 @@ tags: - llm-evaluation - resources - archive -status: active +status: archive created: 2026-08-21 --- @@ -15,7 +15,7 @@ created: 2026-08-21 > 目的：不是收藏大量 AI 资料，而是锁定顶级大厂、顶尖开源组织在生产环境中沉淀出的核心方案、底层评测基建与硬核课程源码。按需查阅，不按顺序通读。 > -> 能力地图（每个资源对应哪层能力、何时看、重点看什么）见 [[04-Reference/README|04-Reference 资源地图]]；本页只负责完整链接、来源背景与上手建议。 +> 能力地图（每个资源对应哪层能力、何时看、重点看什么）见 [[01_Projects/Personal-Tech/LLM_Evaluation/04-Reference/README|04-Reference 资源地图]]；本页只负责完整链接、来源背景与上手建议。 ## 1. 国家级与顶级学术机构的"硬核基建" @@ -55,7 +55,7 @@ created: 2026-08-21 ### Automated RAG with Ragas & CircleCI - 博客： -- 源码： +- 源码：（博客配套 fork；官方仓库为 ） - 含金量：给出实际配置文件和 Python 脚本，展示如何利用 databricks-dolly-15k 抽样数据集，在代码提交（CI/CD）时自动触发大模型评测，计算 Faithfulness（忠实度）与 Context Recall（上下文召回率），不达标直接拒绝上线。 ## 3. 名校/大牛的工业级可运行课程 Notebook @@ -87,7 +87,7 @@ created: 2026-08-21 ## 与本专区的关系 -- 与 [[evaluation-guidebook/00-Overview|HuggingFace Evaluation Guidebook 中文提炼]] 互补：guidebook 回答"具体怎么做、有哪些坑"（概念与方法），本页回答"去哪找真材实料的生产级方案与源码"（资源与基建）。 +- 与 [[01_Projects/Personal-Tech/LLM_Evaluation/04-Reference/evaluation-guidebook/00-Overview|HuggingFace Evaluation Guidebook 中文提炼]] 互补：guidebook 回答"具体怎么做、有哪些坑"（概念与方法），本页回答"去哪找真材实料的生产级方案与源码"（资源与基建）。 - 按需查阅：设计某个评测类型（如多模态 RAG、工具调用、Agent 安全）时回到对应小节。 返回 [[01_Projects/Personal-Tech/LLM_Evaluation/README|学习专区首页]]。 \ No newline at end of file diff --git a/01_Projects/Personal-Tech/LLM_Evaluation/04-Reference/evaluation-guidebook/00-Overview.md b/01_Projects/Personal-Tech/LLM_Evaluation/04-Reference/evaluation-guidebook/00-Overview.md index c83ac48..9543f23 100644 --- a/01_Projects/Personal-Tech/LLM_Evaluation/04-Reference/evaluation-guidebook/00-Overview.md +++ b/01_Projects/Personal-Tech/LLM_Evaluation/04-Reference/evaluation-guidebook/00-Overview.md @@ -70,6 +70,15 @@ source: https://github.com/huggingface/evaluation-guidebook 文内标记 ⭐ 的链接是作者特别推荐阅读的资源。 +### 2026 起：主入口与旧版独有内容 + +- **主入口是 [[08-2025-Edition]]（新版提炼）**；日常查阅先看它。 +- 旧版 01–07 只在你需要"旧版独有细节"时查阅： + - [[02-Human-Evaluation]]（标注者组织与实操细节）、[[03-LLM-as-a-Judge]]（judge 详述、模板与 FAQ）、[[04-Troubleshooting]]（推理排错 + LaTeX/sympy 解析）、[[07-Resources]]（资源清单）为细节版； + - [[01-Automatic-Benchmarks]] 保留 §4 数据集大表与 §5 实战技巧（§1–§3 已被新版覆盖）；[[05-General-Knowledge]] 保留 tokenization 细节（§1 已被新版覆盖）； + - [[06-Yearly-Dives]] 保留 2023/2024 年度回顾。 +- 与新版重叠的旧版正文已压缩为指针，不再重复维护。 + ## 与本专区的关系 - 本专区（LLM_Evaluation）是**面向个人学习与工程能力养成**的中文路线（概念 → 为什么 → 工作表 → 项目 → 完整路线图）。 diff --git a/01_Projects/Personal-Tech/LLM_Evaluation/04-Reference/evaluation-guidebook/01-Automatic-Benchmarks.md b/01_Projects/Personal-Tech/LLM_Evaluation/04-Reference/evaluation-guidebook/01-Automatic-Benchmarks.md index 5cafe17..37fe62a 100644 --- a/01_Projects/Personal-Tech/LLM_Evaluation/04-Reference/evaluation-guidebook/01-Automatic-Benchmarks.md +++ b/01_Projects/Personal-Tech/LLM_Evaluation/04-Reference/evaluation-guidebook/01-Automatic-Benchmarks.md @@ -18,13 +18,11 @@ source: https://github.com/huggingface/evaluation-guidebook > > **关联笔记**：[[02-Human-Evaluation]]（人工评测）、[[03-LLM-as-a-Judge]]（模型作评委）、[[04-Troubleshooting]]（排错与可复现性）。 > -> ⚠️ **旧版内容**（2024 GitHub 仓库）。设计自动评测的新版对应：[[08-2025-Edition]] §5；「常用评测数据集盘点」在新版中不再渲染正文（仅保留仓库资产），本节 §4 作为旧版独有细节保留。 +> ⚠️ **旧版内容**（2024 GitHub 仓库）。本页 §1–§3（核心概念 / 优缺点 / 设计流程）与新版重叠，已压缩为指针；保留的旧版独有内容为 **§4 常用评测数据集盘点** 与 **§5 实战技巧**（新版 §5 覆盖设计流程，但数据集大表与部分技巧仅旧版有）。 ## 目录 -- [1. 核心概念](#1-核心概念task--capability--dataset--metric--样本--泛化) -- [2. 自动化基准的优缺点](#2-自动化基准的优缺点) -- [3. 如何设计自己的自动评测](#3-如何设计自己的自动评测) +- [1–3. 核心概念 / 优缺点 / 设计流程（已压缩，见新版）](#1-3-核心概念--优缺点--设计流程已压缩见新版) - [4. 常用评测数据集盘点](#4-常用评测数据集盘点) - [5. Tips and Tricks](#5-tips-and-tricks) - [6. 参考资料](#6-参考资料) @@ -33,212 +31,31 @@ source: https://github.com/huggingface/evaluation-guidebook ## 速览（TL;DR） -| 问题 | 一句话答案（详见对应章节） | +> 下列要点在新版 [[08-2025-Edition]] 中都有对应小节，此处仅保留一句话答案。 + +| 问题 | 一句话答案（详见新版对应小节） | |---|---| -| 自动基准评测是什么？ | 用「数据集（输入+gold 参考）+ metric」给模型在 task / capability 上打分；LLM 输出分两类：生成文本（generative）与序列 log-probability（MCQA / perplexity）。（[§1](#1-核心概念task--capability--dataset--metric--样本--泛化)） | -| 为什么要测模型没见过的数据？ | 测的是泛化（generalization）；在训练数据上评测等于给模型不具备的能力打分（overfitting 的学生类比）。（[§1](#1-核心概念task--capability--dataset--metric--样本--泛化)） | -| 自动化基准有什么优势？ | 一致可复现、成本低、指标可理解、可用专家级高质量数据（但 MMLU 也有错 → MMLU-Pro/Redux）。（[§2](#2-自动化基准的优缺点)） | -| 有什么短板？ | 复杂能力难分解成精确任务（转向 generalist 评测、性能当 proxy）；公开数据集必有 contamination。（[§2](#2-自动化基准的优缺点)） | -| 评测结果好坏取决于什么？ | 取决于评测数据集质量——选数据集要看创建者、标注者一致性、指南、随机抽 50 个样本检查；自建可走聚合/人工标注/合成（LLM 或规则）三条路。（[§3.1](#31-选择数据集)） | -| 用 log-prob 还是生成式？ | 多选题/测知识 → log-prob（快、能给置信度，但高估小模型、对选项顺序敏感）；测流利度/推理 → 生成式（更贴近真实关注点，但难打分、更贵）。（[§3.2](#32-选择推理方法inference-method)） | -| prompt 要注意什么？ | 语义等价的微小改动会让结果波动；模型会过拟合 prompt 格式（Llama 3.2 / Qwen 2.5 在 few-shot 里不跟格式）；必要时约束输出。（[§3.3](#33-选择提示词prompt)） | -| 代码评测的聪明做法？ | 功能测试：用单元测试验证生成程序（降低过拟合、测主动能力）；文本版代表是 IFEval。（[§3.5](#35-智能新任务功能测试functional-testing)） | -| 数据污染怎么办？ | 默认「已污染」；用 canary string、加密/门控发布、动态 benchmark、事后检测（无万全之法）。（[§5.1](#51-管理污染managing-contamination)） | -| 评测结果意外差？ | 先看生成结果：解析太严、few-shot 不跟格式、模型太啰嗦，逐一排查。（[§5.3](#53-生成式评测结果异常差时的排查)） | +| 自动基准评测是什么？ | 用「数据集（输入+gold 参考）+ metric」给模型在 task / capability 上打分；LLM 输出分两类：生成文本（generative）与序列 log-probability（MCQA / perplexity）。（[[08-2025-Edition]] §4） | +| 为什么要测模型没见过的数据？ | 测的是泛化（generalization）；在训练数据上评测等于给模型不具备的能力打分（overfitting 的学生类比）。（[[08-2025-Edition]] §4） | +| 自动化基准有什么优势？ | 一致可复现、成本低、指标可理解、可用专家级高质量数据（但 MMLU 也有错 → MMLU-Pro/Redux）。（[[08-2025-Edition]] §5.5） | +| 有什么短板？ | 复杂能力难分解成精确任务（转向 generalist 评测、性能当 proxy）；公开数据集必有 contamination。（[[08-2025-Edition]] §3） | +| 评测结果好坏取决于什么？ | 取决于评测数据集质量——选数据集要看创建者、标注者一致性、指南、随机抽 50 个样本检查；自建可走聚合/人工标注/合成（LLM 或规则）三条路。（[[08-2025-Edition]] §5.1–5.3） | +| 用 log-prob 还是生成式？ | 多选题/测知识 → log-prob（快、能给置信度，但高估小模型、对选项顺序敏感）；测流利度/推理 → 生成式（更贴近真实关注点，但难打分、更贵）。（[[08-2025-Edition]] §5.4） | +| prompt 要注意什么？ | 语义等价的微小改动会让结果波动；模型会过拟合 prompt 格式（Llama 3.2 / Qwen 2.5 在 few-shot 里不跟格式）；必要时约束输出。（[[08-2025-Edition]] §5.4、§5.11） | +| 代码评测的聪明做法？ | 功能测试：用单元测试验证生成程序（降低过拟合、测主动能力）；文本版代表是 IFEval。（[[08-2025-Edition]] §5.8） | +| 数据污染怎么办？ | 默认「已污染」；用 canary string、加密/门控发布、动态 benchmark、事后检测（无万全之法）。（本页 §5.1） | +| 评测结果意外差？ | 先看生成结果：解析太严、few-shot 不跟格式、模型太啰嗦，逐一排查。（本页 §5.3） | --- -## 1. 核心概念：task / capability / dataset / metric / 样本 / 泛化 +## 1–3. 核心概念 / 优缺点 / 设计流程（已压缩，见新版） -自动化基准（automated benchmark）通常这样工作：你希望知道模型在某件事上表现如何。这件事可以是： +旧版 §1（核心概念）、§2（优缺点）、§3（设计自动评测）的正文与新版大幅重叠，已压缩为指针： -- 一个定义清晰的**具体任务（task）**，例如「我的模型能不能区分垃圾邮件与非垃圾邮件（spam / non-spam classification）？」； -- 一个更抽象、更一般的**能力（capability）**，例如「我的模型数学能力如何（How good is my model at math）？」。 - -### 评测的三要素 - -1. **数据集（dataset）**，由**样本（samples）**组成： - - 每个样本包含给模型的**输入（input）**，有时配一个用来比对输出的**参考答案（reference，也称 gold）**； - - 样本通常刻意设计成贴近你要测的东西：例如做邮件分类，就构造一批垃圾/非垃圾邮件数据集，尽量包含一些难的边界案例（edge cases）。 -2. **度量（metric）**：给模型打分的方式。 - - 示例：垃圾邮件分类的准确率（正确分类的样本记 1 分，错误记 0 分）； - - metric 利用模型输出打分。对 LLM 而言，人们主要考虑两类输出： - - 模型根据输入**生成的文本**（*generative evaluation*，生成式评测）； - - 提供给模型的**一个或多个序列的 log-probability**（*multiple-choice evaluations*，简称 MCQA；或 *perplexity evaluations*，困惑度评测）。 - - 更多细节见 [Model inference and evaluation](https://github.com/huggingface/evaluation-guidebook/blob/main/contents/general-knowledge/model-inference-and-evaluation.md) 页面。 - -### 泛化（generalization）与过拟合（overfitting） - -- 评测最好在**模型从未见过的数据**（不在其训练集里的数据）上进行，因为你测的是它能否**泛化（generalize）**——例如：模型只见过「假银行」类垃圾邮件后，能否正确分类「保健品」类垃圾邮件。 -- **overfitting**：模型只能在训练数据上预测得好、没有学到更高级的通用模式，就称其过拟合。这就像学生把考题背下来却没理解知识点——**在训练集中已经出现过的数据上评测 LLM，等于给它不会的能力打分**。 - ---- - -## 2. 自动化基准的优缺点 - -### 优点 - -| 优点 | 说明 | -|---|---| -| **一致性与可复现性（Consistency and reproducibility）** | 同一 benchmark 在同一个模型上跑 10 次结果相同（除硬件差异或模型固有随机性外）。因此可以方便地为给定任务建立公平的模型排名。 | -| **低成本规模化（Scale at limited cost）** | 目前最廉价的评测模型方式之一。 | -| **可理解性（Understandability）** | 大多数自动化指标非常易懂：exact match 告诉你生成文本是否与参考完全一致；accuracy 告诉你选对选项的次数占比。（相比而言 `BLEU`、`ROUGE` 这类指标就没那么直观。） | -| **数据集质量（Dataset quality）** | 不少 benchmark 使用专家生成的数据集或已有的高质量数据（如 MMLU、MATH）。但高质量 ≠ 完美：MMLU 事后被发现样本中有若干错误（从解析问题到实际上无意义的问题），催生了 MMLU-Pro、MMLU-Redux 等后续数据集。 | - -### 局限 - -1. **对复杂任务的使用受限**：自动化基准擅长性能容易定义和评估的任务（如分类）。更复杂的能力很难分解成定义清晰、精确的子任务。 - - 例如「数学好」到底指什么？算术好？逻辑好？能对新数学概念推理？ - - 这催生了更多**通用型（generalist）评测**：不再把能力拆成子任务，而是假设整体表现是所测目标的**良好代理指标（good proxy）**。 -2. **污染（Contamination）**：数据集一旦以纯文本形式公开，就会进到模型训练数据里。因此打分时你无法保证模型没解析过评测数据。 - ---- - -## 3. 如何设计自己的自动评测 - -核心原则：**你的评测结果只会和你的评测数据集一样好（your evaluation result will only be as good as your evaluation dataset）**。 - -#### 设计自动评测的完整流程（对照清单） - -把原文的设计建议串成一条可执行的流程，每个步骤的细节见对应小节： - -1. **明确要测什么**：具体 task（如垃圾邮件分类）还是抽象 capability（如数学能力）？（[§1](#1-核心概念task--capability--dataset--metric--样本--泛化)） -2. **选或建数据集**：优先复用已有高质量数据集；自建可走聚合现有数据 / 人工标注 / 合成数据（LLM 生成或基于规则）。（[§3.1](#31-选择数据集)） -3. **检查样本**：已有数据集看创建者与标注流程（专家 > 付费 ≈ 众包 > MTurk）、标注者一致性、创建指南；随机抽 50 个样本查质量与相关性；样本数 ≥ 100 才统计显著。（[§3.1](#31-选择数据集)） -4. **选推理方法**：MCQA（log-probabilities）还是生成式（generative）？（[§3.2](#32-选择推理方法inference-method)） -5. **设计 prompt**：task prompt / context / question / options / connector words；注意 prompt 敏感性、few-shot、格式过拟合。（[§3.3](#33-选择提示词prompt)） -6. **选 metric**：log-prob 侧用按长度归一化的 accuracy / perplexity / recall / f1；生成侧先决定是否归一化、再决定匹配方式（exact match、ROUGE、BLEU…）；想清楚任务到底关心平均还是最差表现。（[§3.4](#34-选择度量metric)） -7. **跑评测 + 复盘**：检查生成结果（解析、格式遵循、长度），关注 contamination 与 tokenization 坑。（[§5](#5-tips-and-tricks)） - -### 3.1 选择数据集 - -要么选已有数据集（见 [第 4 节](#4-常用评测数据集盘点)），要么自己设计。过程中必须紧盯上面这条原则。 - -#### 选用已有数据集：必须检查的组件 - -**（1）创建过程（Creation process）** - -- **样本是谁创建的？** 作者给出的质量排序（作者观点）： - > 专家创建（expert created）> 付费标注者（paid annotator）≈ 众包（crowdsourced）> MTurk 标注 -- 找数据卡（data card），看**标注者人口学信息（annotator demographics）**——对理解数据集的语言多样性很重要。 -- **样本是否被其他标注者或作者复核过？** 要确认：标注者间一致性分数（inter-annotator score）是否高（标注者是否达成共识）、以及/或作者是否审查过整个数据集。 - - 这对「用低薪标注者（通常不是你目标语言的母语者，如 AWS Mechanical Turk）」的数据集尤其重要，否则你可能发现拼写错误/语法错误/无意义答案。 -- **标注者是否拿到清晰的数据创建指南（data creation guidelines）？** 换句话说：你的数据集一致吗？ - -**（2）样本（Samples）** - -取 50 个随机样本人工检查： - -- *质量（quality）*： - - prompt 是否清晰无歧义？ - - 答案是否正确？（例：TriviaQA 每个问题有多个 gold 答案（aliases 字段），有时互相冲突。） - - 信息是否缺失？（例：MMLU 的不少问题缺少参考示意图（reference schematics）。） -- *与任务的相关性（relevance）*： - - 这些是你想用 LLM 评测的问题类型吗？ - - 这些例子与你的 use case 相关吗？ - -还要知道数据集有多少样本（保证结果统计显著——**自动基准评测通常最少 100 个样本**）。 - -#### 设计自己的数据集：三条路线 - -| 路线 | 要点 | -|---|---| -| **聚合现有数据（Aggregating existing data）** | 从不同来源聚合现有数据，评估与任务相关的能力。很多评测数据集就是这样从人工评测数据集聚合而来的（如 MATH、LSAT 等）。走这条路同样要执行上面「检查样本」的步骤。 | -| **使用人工标注者（Using human annotators）** | 完整章节见 [Using human annotators](https://github.com/huggingface/evaluation-guidebook/blob/main/contents/human-evaluation/using-human-annotators.md)（人工评测章节）。 | -| **使用合成数据（Using synthetic data）** | 分两种： | -| ├ **用 LLM 生成** | ⭐ 参考 [Cosmopedia](https://huggingface.co/blog/cosmopedia) 博客（HF 同事写的，很酷）：主要研究如何造合成*训练*集，但类似技术可用于评测。生成后务必按上面的步骤人工检查/过滤/审查。 | -| └ **基于规则的技巧（rule-based）** | 如果任务允许，这是获得**几乎无限样本且避免污染**的好办法。示例：[NPHardEval](https://arxiv.org/abs/2312.14890)、[DyVal](https://arxiv.org/abs/2309.17167)、[MuSR](https://arxiv.org/abs/2310.16049)、[BabiQA](https://arxiv.org/abs/1502.05698) 等。 | - -### 3.2 选择推理方法（inference method） - -#### 基于 log-probabilities（MCQA 多选题） - -非常适合选择题（通常测模型知识、或消歧能力）。 - -| 优点 | 缺点 | -|---|---| -| 确保所有模型都能「看到」正确答案 | 轻微高估小模型（若放任自由生成，它们本会生成选项范围之外的内容） | -| 提供模型「置信度」（calibration）的代理 | 有些模型会[根据选项的呈现顺序偏好特定选项](https://arxiv.org/abs/2309.03882)，导致评测不具代表性 | -| 评估快——尤其只让模型预测一个 token（A/B/C/D 选项序号，或 Yes/No）时 | | -| 小模型也能获得任务表现信号 | | - -#### 基于生成（generative / QA 问答） - -适合任何要测流利度（fluency）、推理能力、或模型真正回答问题的能力的任务。 - -| 优点 | 缺点 | -|---|---| -| 应该与 LLM 生成流利文本的能力真实相关，多数时候正是人们真正关心的 | 打分更难（见 3.4 metrics 一节） | -| | 通常比 log-likelihood 评测贵一点，尤其包含 sampling 时 | - -### 3.3 选择提示词（prompt） - -prompt 决定：给模型多少任务信息、这些信息如何呈现。 - -一个通用 MCQA / QA prompt 通常由以下部分构成： - -- **task prompt**（可选）：介绍你的任务； -- **context**：为问题提供额外上下文（例：摘要或信息抽取任务可提供内容来源）； -- **question**：prompt 的核心； -- **options**（多选题时）：选项； -- **连接词（connector words）**：如 `Question`、`Context`、`Choice` 等。 - -把这些要素拼成模板（示意，字段顺序与措辞可自行设计）： - -```text -Task: {task prompt} # 可选：介绍任务 -Context: {context} # 可选：为问题提供额外上下文（摘要/信息抽取时可给内容来源） -Question: {question} # 核心 -Choice A: {option_a} # 多选题时提供选项 -Choice B: {option_b} -Choice C: {option_c} -Answer: # 用连接词引导模型输出 -``` - -> 注意：上面只是结构示意，原文没有给出固定模板——不同模型对格式的敏感度不同，实际使用时按 3.3 的提示设计并验证。 - -设计 prompt 时要注意： - -1. **语义等价的微小改动也可能让结果波动很大**（见 [Troubleshooting reproducibility](https://github.com/huggingface/evaluation-guidebook/blob/main/contents/troubleshooting/troubleshooting-reproducibility.md) 的「Different prompt」一节），且 prompt 格式可能利好或利空特定模型。 - - 缓解方法： - - **昂贵方案**：用多种 prompt 变体把评测多跑几遍； - - **省钱方案**：只跑一次，但把一批**难度相当的不同 prompt 格式**分配到不同样本上。 -2. 可以给模型提供**few-shot 示例**帮它遵守期望格式；加连接词也有帮助。 -3. 但**模型如今倾向于过拟合特定 prompt 格式**： - - ⭐ [这篇论文](https://arxiv.org/abs/2407.07890) 讲得很好：有些模型因为过拟合了测试集的**格式（format）**而被高估。 - - 在 Open LLM Leaderboard 2 上，作者观察到 Llama 3.2 和 Qwen 2.5 出于这个原因，在 few-shot 设置下不再遵循给定 prompt 的格式。 -4. 对不少 metric 来说，你需要**高度受约束的生成/输出**（详见 [Model inference and evaluation](https://github.com/huggingface/evaluation-guidebook/blob/main/contents/general-knowledge/model-inference-and-evaluation.md) 的 `Constraining model outputs` 一节）。 - -### 3.4 选择度量（metric） - -**基于 log-probabilities** 时，metric 很简单：看 **accuracy**（最可能的选项是最佳选项的频率）。重要：要**按长度归一化**（按字符 character、token、或 pmi）。也可以看 perplexity、recall、f1。 - -**生成式评测（generative）** 时可选 metric 范围更广，需要两步决策： - -1. **比较生成结果前是否先归一化（normalize）？** - - 归一化设计得不好时[很容易不公平](https://huggingface.co/blog/open-llm-leaderboard-drop)，但总体上在任务层面仍提供信号； - - 对特定任务非常重要，如数学评测：你可能要从格式化输出中抽取结果； - - 如果要叠加 Chain of Thought 等机制测准确率，也要归一化——你需要把推理痕迹（reasoning trace）从实际结果中剥离。 -2. **如何把生成与参考做比较？** - - 从基于匹配的 metric（exact match、prefix match 等）到摘要/翻译类 metric（ROUGE、BLEU、character n-gram 比较）都可以； - - 现有 metric 列表见 ⭐ [lighteval 的 Metric List wiki](https://github.com/huggingface/lighteval/wiki/Metric-List)（作者表示之后会补「何时用哪个 metric」一节）。 - -**更一般的原则**：选 metric 时要想清楚任务真正关心什么。有些领域（如医疗、有公共交互的聊天机器人）不该测平均表现，而要能评估**最差表现（worst performance）**——如医疗输出质量、毒性等。（延伸阅读：⭐ [这个博客](https://ehudreiter.com/2024/07/10/challenges-in-evaluating-llms/)） - -### 3.5 智能新任务：功能测试（functional testing） - -代码领域：不仅要按语义评估生成的程序，还要按**实际功能**评估。好办法是检查「为遵循 prompt 而生成的代码」能否通过**一套为该任务设计的单元测试（unit tests）**。 - -功能化方法极具前景，因为： - -- 更容易生成测试用例（很多情况下可用基于规则的方法生成 test cases）； -- 因此**降低过拟合（overfitting）**； -- 测的是模型的具体**主动能力（active capabilities）**。 - -不过，要把这种方法**迁移到文本任务需要创造力**！ - -- 一个优秀范例是 **IFEval**：测试模型能否遵循指令的评测 benchmark。它创建一批格式化指令（*Add this number of bullet points.*、*Capitalize only one sentence.* 等），严格检查格式是否被遵循。 -- 作者认为：要把这个思路扩展到文本的其他特性，还需要更多工作。 +- **核心概念**（task / capability / dataset / metric / 泛化与过拟合）：见 [[08-2025-Edition]] §4。 +- **自动化基准的优缺点与污染问题**：见 [[08-2025-Edition]] §3（saturation / contamination 定义）与本页 §5。 +- **设计自动评测的完整流程**（选数据集 / 推理方法 / prompt / metric / 功能测试）：见 [[08-2025-Edition]] §5.1–§5.8。 +- 旧版更详细的步骤与示例（含 prompt 结构模板、metric 选择细节）：可回原文 [designing-your-automatic-evaluation.md](https://github.com/huggingface/evaluation-guidebook/blob/main/contents/automated-benchmarks/designing-your-automatic-evaluation.md) 查阅，本页不再重复维护。 --- diff --git a/01_Projects/Personal-Tech/LLM_Evaluation/04-Reference/evaluation-guidebook/03-LLM-as-a-Judge.md b/01_Projects/Personal-Tech/LLM_Evaluation/04-Reference/evaluation-guidebook/03-LLM-as-a-Judge.md index e7d1714..cfdb8e2 100644 --- a/01_Projects/Personal-Tech/LLM_Evaluation/04-Reference/evaluation-guidebook/03-LLM-as-a-Judge.md +++ b/01_Projects/Personal-Tech/LLM_Evaluation/04-Reference/evaluation-guidebook/03-LLM-as-a-Judge.md @@ -202,7 +202,7 @@ Score the fluency from 0 to 5, 0 being completely un-understandable, ... 可以直接借鉴的现成模板： -- [MixEval judge prompts（lighteval 实现）](https://github.com/huggingface/lighteval/blob/main/src/lighteval/tasks/extended/mix_eval/judge_prompts.pyy) +- [MixEval judge prompts（lighteval 实现）](https://github.com/huggingface/lighteval/blob/main/src/lighteval/tasks/extended/mix_eval/judge_prompts.py) - [MTBench judge prompt templates（lighteval 实现）](https://github.com/huggingface/lighteval/blob/main/src/lighteval/tasks/extended/mt_bench/judge_prompt_templates.py) 这四条准则与"一份好 judge prompt 的要素"的对应关系： @@ -668,7 +668,7 @@ LLM 评委的**已知偏见清单**（原文逐条整理，含缓解方法）： ### 工具与教程 - [distilabel](https://distilabel.argilla.io/latest/)（[UltraFeedback tutorial](https://distilabel.argilla.io/latest/sections/pipeline_samples/papers/ultrafeedback/) / [benchmarking with distilabel（Arena Hard）](https://distilabel.argilla.io/latest/sections/pipeline_samples/examples/benchmarking_with_distilabel/)） -- [lighteval：MixEval judge prompts](https://github.com/huggingface/lighteval/blob/main/src/lighteval/tasks/extended/mix_eval/judge_prompts.pyy) / [MTBench judge prompt templates](https://github.com/huggingface/lighteval/blob/main/src/lighteval/tasks/extended/mt_bench/judge_prompt_templates.py) +- [lighteval：MixEval judge prompts](https://github.com/huggingface/lighteval/blob/main/src/lighteval/tasks/extended/mix_eval/judge_prompts.py) / [MTBench judge prompt templates](https://github.com/huggingface/lighteval/blob/main/src/lighteval/tasks/extended/mt_bench/judge_prompt_templates.py) - [ArtificialAnalysis LLM Performance Leaderboard（成本对比）](https://huggingface.co/spaces/ArtificialAnalysis/LLM-Performance-Leaderboard) - [LeonEricsson/llmjudge（扰动敏感度扩展实验）](https://github.com/LeonEricsson/llmjudge/blob/main/README.md) diff --git a/01_Projects/Personal-Tech/LLM_Evaluation/04-Reference/evaluation-guidebook/05-General-Knowledge.md b/01_Projects/Personal-Tech/LLM_Evaluation/04-Reference/evaluation-guidebook/05-General-Knowledge.md index 8c1b2cd..360f57f 100644 --- a/01_Projects/Personal-Tech/LLM_Evaluation/04-Reference/evaluation-guidebook/05-General-Knowledge.md +++ b/01_Projects/Personal-Tech/LLM_Evaluation/04-Reference/evaluation-guidebook/05-General-Knowledge.md @@ -11,143 +11,26 @@ source: https://github.com/huggingface/evaluation-guidebook # LLM 评测指南 · General Knowledge（通用知识）提炼笔记 -> 本页提炼自 [HuggingFace Evaluation Guidebook](https://github.com/huggingface/evaluation-guidebook) 的 **General knowledge** 章节的两页内容：**Model inference and evaluation**（模型推理与评测）与 **Tokenization**（分词）。面向初学者，重点整理与评测直接相关的部分：生成式评测 vs log-probability 评测、log-prob 的计算方式、tokenizer 对评测结果的影响。 +> 本页提炼自 [HuggingFace Evaluation Guidebook](https://github.com/huggingface/evaluation-guidebook) 的 **General knowledge** 章节的两页内容：**Model inference and evaluation**（模型推理与评测）与 **Tokenization**（分词）。⚠️ §1（模型推理与评测）已被新版覆盖并压缩（见 [[08-2025-Edition]] §4）；本页保留 **tokenizer 对评测结果的影响** 的旧版细节。 > > 原文链接： > - [model-inference-and-evaluation.md](https://github.com/huggingface/evaluation-guidebook/blob/main/contents/general-knowledge/model-inference-and-evaluation.md) > - [tokenization.md](https://github.com/huggingface/evaluation-guidebook/blob/main/contents/general-knowledge/tokenization.md) > -> ⚠️ **旧版内容**（2024 GitHub 仓库）。新版对应：[[08-2025-Edition]] §4（三种任务形式 MCF / CF / FG 与 log-likelihood 细节、tokenization 的影响）。 +> ⚠️ **旧版内容**（2024 GitHub 仓库）。新版对应：[[08-2025-Edition]] §4。本页 §1（模型推理与评测）已被新版覆盖并压缩；保留 §2（tokenization 细节）与 §3（tokenization 对评测的影响）。 --- -## 一、模型推理与评测（Model Inference and Evaluation） +## 一、模型推理与评测（已被新版覆盖，已压缩） -### 1.1 什么是推理（inference） +> 📌 **术语衔接（来自指南其他章节，非本页原文）**：指南的 *Automatic benchmarks* 章节把"对给定序列求 log-probability"的评测称为 *multiple-choice evaluations*，有时也叫 **MCQA** 或 *perplexity evaluations*；perplexity（困惑度）指标的具体用法，以及评测框架 **lm-evaluation-harness**（EleutherAI）与 **lighteval**（HuggingFace）的讨论，详见指南对应章节与本目录 [[01-Automatic-Benchmarks]]、[[07-Resources]] 笔记。 -大型语言模型的工作方式很简单：**给定一段文本作为输入，它们学会了预测"合理的后续内容"**。整个过程分两步： +旧版 §1（模型推理与评测：inference 流程、log-likelihood、生成式评测、约束输出）与新版重叠，已压缩为指针： -#### 第一步：Tokenization（分词） - -- 输入文本（推理时称为 *prompt*）先被切分成 **tokens**——小的文本单元（可以是一个或几个字符，最多到词级）。 -- 每个 token 关联一个数字；模型能解析的全部 token 范围称为它的 **vocabulary**（词表）。 -- 细节见本页第二章（原文 Tokenization 页）。 - -#### 第二步：Prediction（预测） - -![LLM 推理流程示意](https://github.com/huggingface/evaluation-guidebook/blob/main/assets/llm_tk_1.png?raw=true) - -- 基于输入文本，LLM 在**整个词表**上生成"最可能的下一个 token"的概率分布。 -- 要得到连续生成：取概率最高的 token（可加入一点随机性以获得更有趣的输出）作为下一个 token，然后**重复该操作**，把新 token 当作 prompt 的结尾继续下去，如此循环（即自回归生成）。 - -### 1.2 你想预测什么？——评测的两大类别 - -LLM 评测主要分为两大类： - -1. **给定一个 prompt 和一个（或多个）答案**：我的模型给出这些答案的概率是多少？ -2. **给定一个 prompt**：我的模型会生成什么文本？ - -| 维度 | Log-likelihood 评测（选择题式） | Generative 评测（生成式） | -|---|---|---| -| 核心问题 | 给定候选答案，答案是"被模型认可"的概率 | 给定 prompt，模型自己生成什么 | -| 模型输出 | 候选序列的 log-probability | 自回归生成的 token 序列 | -| 典型形态 | 多项选择（multiple-choice / MCQA）、单句概率判断、校准研究 | 开放生成、摘要、翻译、代码生成 | -| 打分方式 | 比较各选项 log-prob、与 0.5 阈值比较、看校准 | 与参考文本比对（exact match、BLEU 等）或模型作评委 | -| 优点 | 计算确定、可复现，直接反映模型偏好 | 更接近真实使用场景 | -| 风险 | 可能偏向"自由生成时会输出别的东西"的模型（见 1.3） | 生成结果多样，打分标准更难定 | - -> 📌 **术语衔接（来自指南其他章节，非本页原文）**：指南的 *Automatic benchmarks* 章节把"对给定序列求 log-probability"的评测称为 *multiple-choice evaluations*，有时也叫 **MCQA** 或 *perplexity evaluations*；perplexity（困惑度）指标的具体用法，以及评测框架 **lm-evaluation-harness**（EleutherAI）与 **lighteval**（HuggingFace）的讨论，不在本页范围内，详见指南对应章节与本目录 [[01-Automatic-Benchmarks]]、[[07-Resources]] 笔记。 - -### 1.3 Log-likelihood（log-prob）评测 - -目标是：**给定 prompt，求一个或多个候选答案的条件概率**——即"给定输入，得到某个特定续写的可能性有多大"。 - -计算过程（对应原文插图 `llm_logprob.png`）： - -```text -1. 拼接：把每个选项（choice）与 prompt 拼接，传给 LLM - ↓ -2. 取 logits：LLM 输出每个 token 的 logits（每个 token 取决于它之前的 token） - ↓ -3. 只保留与选项 token 相关的最后几个 logits，施加 log softmax - → 得到 log-probabilities（值域为 [-inf, 0]，而不是 [0, 1]） - ↓ -4. 求和：把所有单个 token 的 log probability 相加 - → 得到整个选项的总 log probability - ↓ -5. 归一化：最后可按选项长度（choice length）做归一化 -``` - -![log-prob 计算示意](https://github.com/huggingface/evaluation-guidebook/blob/main/assets/llm_logprob.png?raw=true) - -基于此可以应用以下指标： - -- **在多个选项中选出模型最偏好的答案**（如上图）。 - - ⚠️ 注意：这可能**有利于**那些"若自由生成会输出别的东西"的模型——例如图中模型"被迫"在选项里选 `Zygote`，但若让它自由生成可能给出别的答案，从而虚高其得分。 -- **测试单个选项的概率是否超过 0.5**。 -- **研究模型校准（calibration）**：一个校准良好的模型，其正确答案应该拥有最高的概率。 - - 了解校准是什么、如何检测、如何训练出校准良好的模型：Anthropic 论文 [Calibration tutorial](https://arxiv.org/abs/2207.05221)。 - - 校准的一些可能局限：[Limits of calibration](https://arxiv.org/abs/2311.14648)。 - -### 1.4 生成式评测（Generative evaluations） - -目标是：**给定 prompt，得到模型生成的文本**。 - -生成过程是自回归的： - -```text -1. 把 prompt 传给模型 - ↓ -2. 看最可能的下一个 token，选中它作为模型的 "choice first token" - ↓ -3. 重复，直到满足生成结束条件： - - 达到最大长度（maximum length） - - 出现特殊终止 token（special token to stop the generation） - - 等 - ↓ -4. 模型生成的所有 token 即它对 prompt 的"回答" -``` - -![生成式评测示意](https://github.com/huggingface/evaluation-guidebook/blob/main/assets/llm_gen.png?raw=true) - -然后**把生成结果与参考答案（references）比较，对两者之间的距离打分**： - -- 简单指标：**exact match**（精确匹配）。 -- 更复杂的指标：**BLEU** 等。 -- 或用**模型作评委**（models as judges，即 LLM-as-a-judge，详见指南 Model-as-a-Judge 章节）。 - -#### Going further（进阶阅读） - -- ⭐ [Blog on several ways to evaluate MMLU](https://huggingface.co/blog/open-llm-leaderboard-mmlu) —— HuggingFace 团队（原作者所在团队）所写，深入讲解"多项选择 log-likelihood 评测"与"生成式评测"的差异，以及它们对分数变化意味着什么。上文插图即来自该博客（由 Thom Wolf 制作）。 -- ⭐ [A beautiful mathematical formalization of the above inference methods](https://arxiv.org/abs/2405.14782v2) —— EleutherAI 对上述推理方法的数学形式化，直接看 Appendix。 - -### 1.5 约束模型输出（Constraining model outputs） - -在很多情况下，我们希望模型输出遵循特定格式（例如为了与参考答案比较）。原文给出了三种方式： - -| 方式 | 做法 | 优点 | 局限 | -|---|---|---|---| -| **使用 prompt** | 在任务 prompt 中加入非常具体的指令（如 `Provide numerical answers in digits.`、`Use no abbreviation.`） | 最简单；对高能力模型通常够用 | 不一定总是有效 | -| **Few-shot / In-context learning** | 在 prompt 中提供示例（few-shot prompting），让模型隐式偏向遵循示例的 prompt 形状 | 2023 年底之前普遍效果很好 | 见下方说明 | -| **结构化文本生成（Structured text generation）** | 用语法（grammar）或正则表达式定义输出路径，约束输出 | 减少评测中的 prompt 方差，结果与排名更稳定 | 可能降低部分任务的性能（见下方说明） | - -#### Few-shot 的说明 - -- 工作原理：通过 in-context learning，prompt 里的示例会让模型隐式地偏向"按照重复出现的 prompt 形状"作答。 -- **时效性**：该方法直到 2023 年底都整体表现良好；但此后 **instruction-tuning** 的广泛采用，以及预训练后期加入指令数据（**continuous pre-training**），似乎让较新的模型偏向特定输出格式——论文称之为 *Training on the test task*（[arxiv 2407.07890](https://arxiv.org/abs/2407.07890)），作者则称之为 *overfitting the prompt format*（对 prompt 格式的过拟合）。 -- **上下文窗口限制**：对上下文窗口较小的旧模型，few-shot 示例可能**放不进 context window**。 - -#### 结构化生成的说明 - -- `outlines` 库用**有限状态机（finite state machines, FSM）**实现，作者认为非常 neat；也存在其他方法，例如用于 JSON 生成的 **interleaved generation**（作者本人更偏爱 FSM）。 -- 收益：结构化生成降低评测中的 prompt 方差，使结果和排名更稳定（见共同撰写的博客 [Evaluation of structured outputs](https://huggingface.co/blog/evaluation-structured-outputs)；也可看 `outlines` 的 [博客](https://blog.dottxt.co/)）。 -- 风险：近期 [研究](https://arxiv.org/abs/2408.02442) 显示，结构化生成可能通过把先验推离期望概率分布太远，从而**降低模型在部分任务（如推理）上的表现**。 - -#### Going further（进阶阅读） - -- ⭐ [Understanding how Finite State Machine works when using structured generation](https://blog.dottxt.co/coalescence.html) —— Outlines 出品，对其方法的清晰讲解。 -- [The outlines method paper](https://arxiv.org/abs/2307.09702) —— 上述方法的学术版解释。 -- [Interleaved generation](https://github.com/guidance-ai/guidance?tab=readme-ov-file#guidance-acceleration) —— 另一种约束特定输出格式生成的方法。 +- **log-likelihood 评测的计算步骤与 MCF / CF / FG 三种任务形式**：见 [[08-2025-Edition]] §4。 +- **生成式评测与打分**（exact match / BLEU / model judges）：见 [[08-2025-Edition]] §4 与 §5.5。 +- **约束模型输出**（prompt / few-shot / 结构化生成）：见 [[08-2025-Edition]] §5.11。 +- 更详细的旧版步骤与插图：可回原文 [model-inference-and-evaluation.md](https://github.com/huggingface/evaluation-guidebook/blob/main/contents/general-knowledge/model-inference-and-evaluation.md) 查阅，本页不再重复维护。 --- diff --git a/01_Projects/Personal-Tech/LLM_Evaluation/04-Reference/evaluation-guidebook/08-2025-Edition.md b/01_Projects/Personal-Tech/LLM_Evaluation/04-Reference/evaluation-guidebook/08-2025-Edition.md index 0582ab9..cd8c5ed 100644 --- a/01_Projects/Personal-Tech/LLM_Evaluation/04-Reference/evaluation-guidebook/08-2025-Edition.md +++ b/01_Projects/Personal-Tech/LLM_Evaluation/04-Reference/evaluation-guidebook/08-2025-Edition.md @@ -275,7 +275,7 @@ article.mdx（组装层，含正文过渡小节、saturation/contamination 定 ## §5 设计自动评测（designing-your-automatic-evaluation + article.mdx） -> 旧版对应：[[01-Automatic-Benchmarks]] §3（设计自动评测）与 §4（常用评测数据集盘点，新版不再渲染正文）。 +> 旧版对应：[[01-Automatic-Benchmarks]] §4（常用评测数据集盘点）与 §5（实战技巧，均旧版独有）；旧版设计流程部分已被本节省去/覆盖。 新版把"设计自动评测"重写为完整方法论。**与旧版不同的章节结构**（原文实际顺序）： @@ -423,7 +423,7 @@ log-probability 打分容易：accuracy 变体（最可能 choice 是否最佳 - 两条路线：**通用高能力模型**（LLM + prompt）或**小型专用模型**（从偏好数据训练判别，如"毒性垃圾邮件过滤器"）。 - **闭源模型（Claude、GPT-o）**：不可复现（API 更新随时变）、黑盒、隐私风险；优点是免本地部署。**开源模型正在追平**（DeepSeek R1、gpt-oss、最新 Qwen 是竞争性替代）。 - **小型专用 judge**（数 B 参数、可本地跑）：Flow-Judge-v0.1（3.8B，Phi-3.5-mini-instruct 微调）、Prometheus（13B，从零训练）、JudgeLM（7–33B）。**自训 judge 除非 niche 领域否则不建议**；偏好数据可来自 [lmsys 竞赛](https://www.kaggle.com/competitions/lmsys-chatbot-arena) 或 Prometheus collections；[从 reward model 起步优于从 instruct model](https://x.com/dk21/status/1826292289930674590)。 -- **judge prompt 设计**：任务描述 → 评估标准（含详细评分系统）→ 推理步骤 → 指定输出格式（如 JSON `{"Score": ..., "Reasoning": ...}`）。参考 [MixEval](https://github.com/huggingface/lighteval/blob/main/src/lighteval/tasks/extended/mix_eval/judge_prompts.pyy)/[MTBench](https://github.com/huggingface/lighteval/blob/main/src/lighteval/tasks/extended/mt_bench/judge_prompt_templates.py) 模板。**Pairwise 比较比打分与人类偏好相关性更好**（[arxiv 2403.16950](https://arxiv.org/abs/2403.16950)）；整数刻度要给每个分数的详细解释或用 additive prompt；**每个能力一个 prompt**；可用 few-shot / reference / CoT（先输出推理再打分）/ 多轮分析 / **jury（多个 judge 聚合，可用多个小模型降本）** 提升准确率。 +- **judge prompt 设计**：任务描述 → 评估标准（含详细评分系统）→ 推理步骤 → 指定输出格式（如 JSON `{"Score": ..., "Reasoning": ...}`）。参考 [MixEval](https://github.com/huggingface/lighteval/blob/main/src/lighteval/tasks/extended/mix_eval/judge_prompts.py)/[MTBench](https://github.com/huggingface/lighteval/blob/main/src/lighteval/tasks/extended/mt_bench/judge_prompt_templates.py) 模板。**Pairwise 比较比打分与人类偏好相关性更好**（[arxiv 2403.16950](https://arxiv.org/abs/2403.16950)）；整数刻度要给每个分数的详细解释或用 additive prompt；**每个能力一个 prompt**；可用 few-shot / reference / CoT（先输出推理再打分）/ 多轮分析 / **jury（多个 judge 聚合，可用多个小模型降本）** 提升准确率。 - **评估你的 evaluator**（上线前必做）：选 baseline（**约 50 个示例即可**，但必须 representative / discriminative / high quality）→ 选 metric（binary/pairwise 的 accuracy/precision/recall 易解释；score 相关性难）→ 评估并定阈值：**pairwise 对比可设 80%–95% accuracy；score 相关性文献常满意于 0.8 Pearson**（也有人宣称 0.3 就算与人类标注相关良好——"ymmv"）。 - **judge 偏差与缓解**：internal consistency（self-consistency prompting 取多数）→；self-preference（用 jury）；input perturbation blindness（**先给 reasoning 再给分**、给连贯评分刻度）；position-bias（随机交换答案位置、用 logprob 归一）；verbosity/length-bias（考虑长度差，[arxiv 2404.04475](https://arxiv.org/abs/2404.04475)）；format bias（遵守模型训练 prompt 格式）。 - **LLM evaluators 的已知弱点**：整体上**不擅长识别幻觉**（尤其 partial hallucinations，[arxiv 2305.11747](https://arxiv.org/abs/2305.11747)、[2303.08896](https://arxiv.org/abs/2303.08896)）；在摘要/忠实性上与人类标注相关性低到中等，跨任务不持续与人类一致（[arxiv 2406.18403](https://arxiv.org/abs/2406.18403)）。 diff --git a/01_Projects/Personal-Tech/LLM_Evaluation/05-Progress/00-当前位置与下一步.md b/01_Projects/Personal-Tech/LLM_Evaluation/05-Progress/00-当前位置与下一步.md new file mode 100644 index 0000000..f9e80d1 --- /dev/null +++ b/01_Projects/Personal-Tech/LLM_Evaluation/05-Progress/00-当前位置与下一步.md @@ -0,0 +1,46 @@ +--- +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-学习周记.md new file mode 100644 index 0000000..163d3d6 --- /dev/null +++ b/01_Projects/Personal-Tech/LLM_Evaluation/05-Progress/01-学习周记.md @@ -0,0 +1,45 @@ +--- +type: log +tags: + - llm-evaluation + - progress + - journal +status: active +created: 2026-08-21 +--- + +# 学习周记 + +> **使用方式：** 每周一次（或每次学习后），复制下方模板，把日期改为当周，插到文件**最顶部**（最新在上）。周记是你"学习过程"的存档处：学习看板只负责勾选，周记负责记录发生了什么。 + +## 模板（复制这一块，改日期后插到最上方） + +```markdown +## YYYY-MM-DD ｜ 第 N 周 + +### 本周目标 + +### 本周理论理解（用自己的话复述，链接回原笔记） + +- 概念：……（我的理解：……） + - 链接：[[01-What-Is-LLM-Evaluation]] / [[03-Core-Concept-Map]] +- 卡住的地方：…… + +### 本周实践 + +- 我新定义了什么成功 / 失败条件？ +- 我新增或修订了哪些 case？为什么？ +- 本周主要失败类型是什么？ + +### 实验与结果 + +- 我改变了什么？预期是什么？实际发生了什么？ + +### 下周只保留的一个最小动作 +``` + +> 复盘问题与学习看板 Level 1–3 的闭环检查项一致（见 [[01-Learning-Board|学习看板]]）。第一个项目尚未建立时，实践小节可以写"填了工作表第几节、写了几个 case"——学习过程不因没有项目而中断。 + +--- + +返回 [[01_Projects/Personal-Tech/LLM_Evaluation/README|学习专区首页]]。 diff --git a/01_Projects/Personal-Tech/LLM_Evaluation/05-Progress/02-方法季度复盘.md b/01_Projects/Personal-Tech/LLM_Evaluation/05-Progress/02-方法季度复盘.md new file mode 100644 index 0000000..7074b4d --- /dev/null +++ b/01_Projects/Personal-Tech/LLM_Evaluation/05-Progress/02-方法季度复盘.md @@ -0,0 +1,45 @@ +--- +type: log +tags: + - llm-evaluation + - progress + - review +status: active +created: 2026-08-21 +--- + +# 方法季度复盘（含作品集清单） + +> **使用方式：** 每季度一次（约第 12 周）。复盘对象是**这套学习方法本身**，不是单个项目（单个项目的复盘在 `03-Practice/项目名/04-失败复盘.md`）。 + +## 方法论自评 + +1. "先建立判断，再追求自动化"是否真的让我少走了弯路？请给一个具体例子。 +2. 我是否在"读完理论"上花了比计划更多的时间？当时应该在哪一步停下？ +3. 手工盲评是否帮我发现了规则问题？哪些坑是读文章学不到的？ +4. 哪个环节最浪费时间？下一个季度砍掉什么？ +5. 我的失败分类是否真的指导了修复，还是只是写了报告？ + +## 作品集检查清单 + +> 来源：[[01-LLM-Evaluation-Roadmap]] 第十二节。做满 3 个月后，把最能证明工程闭环的项目整理成作品集。 + +- [ ] GitHub 仓库 README：问题 / 数据说明 / 评测方法 / 结果，四节 +- [ ] 数据卡：来源、构造、偏差、许可、PII、版本 +- [ ] 评测报告：类别通过率、失败分类、修复前后对比 +- [ ] 3 分钟录屏：改一个 prompt → 跑 runner → 展示回归变化 +- [ ] 一条技术复盘（具体发现，而非"我学了大模型"） + +### 公开前合规检查 + +- [ ] 无真实用户输入 / 无密钥或 token / 无内部路径或私有代码 / 无个人信息 +- [ ] 外部资料有许可与出处；合成数据明确标注为合成 + +## 内容保鲜（可选，每季度） + +- [ ] 检查专区外部链接是否有失效或已关停（如 OpenAI Evals 平台已宣布 2026-11 关停） +- [ ] 更新 [[01_Projects/Personal-Tech/LLM_Evaluation/04-Reference/README|04-Reference 资源地图]] 的前置阶段标注 + +--- + +返回 [[01_Projects/Personal-Tech/LLM_Evaluation/README|学习专区首页]]。 diff --git a/01_Projects/Personal-Tech/LLM_Evaluation/README.md b/01_Projects/Personal-Tech/LLM_Evaluation/README.md index ff4913e..23bec07 100644 --- a/01_Projects/Personal-Tech/LLM_Evaluation/README.md +++ b/01_Projects/Personal-Tech/LLM_Evaluation/README.md @@ -14,27 +14,48 @@ created: 2026-08-21 ## 先怎么使用 -请不要按文件夹顺序随机阅读。第一次学习建议走下面这条主线： +学习过程分四段，**有明确停止线**：理论是有界的，读完必读部分就动手；`04-Reference` 不是现在读的，是按需查阅的工具书。 -```text -建立概念（What） - → 理解为什么（Why） - → 填写一份最小工作表 - → 做完第一个 10-case 小项目 - → 再进入完整工程路线（How） -``` +> **节奏自选（三选一）：** 每天 10 分钟（Start-Here / 工作表的十分钟动作，碎片推进）、首周 6–10 小时（Why Guide 首周计划）、或 72 小时冲刺（路线图第四节）。起点都是同一份工作表，差别只是投入速度。 + +### 阶段 1 · 有界理论（约 3-4 小时，一次性） | 顺序 | 阅读材料 | 解决的问题 | 完成标志 | |---:|---|---|---| | 1 | [[00-Start-Here\|开始这里]] | 我究竟在学什么，如何不被概念和工具淹没？ | 完成十分钟动作，能复述学习主线。 | | 2 | [[01-What-Is-LLM-Evaluation\|什么是 LLM Evaluation]] | 评测的对象、边界与常用术语是什么？ | 能区分模型评测与系统评测、Benchmark 与 Product Eval。 | | 3 | [[02-Why-Guide\|从零开始做 LLM 评测：每一步背后的道理]] | 为什么先做 case、rubric、盲评、run、失败分类与回归？ | 能解释每个动作在防什么问题。 | -| 4 | [[02-First-Week-Worksheet\|首周工作表]] | 今天应该写什么，卡住时怎样缩小范围？ | 完成任务边界、10 个 case 与 rubric v0.1。 | -| 5 | [[01_Projects/Personal-Tech/LLM_Evaluation/03-Practice/README\|项目实践入口]] | 如何把工作表变成自己的项目仓库？ | 开始一个最小项目并保存第一个 run。 | -| 6 | [[01-LLM-Evaluation-Roadmap\|LLM 评测工程实战路线图]] | 怎样逐步走向 Judge、Agent、安全、数据资产与 CI？ | 为自己选择一个 12 周内的下一阶段。 | -| 7 | [[01-Learning-Board\|学习看板]] | 我学到哪了？还差哪个闭环？ | 能勾选当前 Level 的全部条目。 | +| 4 | [[02-Annotation-Human-Data-and-Evaluation\|数据标注、Human Data 与 Evaluation]] | 标注、人类数据与评测的区别是什么？ | 能区分 Annotation / Human Data / Evaluation 三种用途。 | +| 5 | [[03-Core-Concept-Map\|LLM Evaluation 核心概念地图]] | 术语速查地图在哪？ | 阅读与实践时能快速定位术语（速查用，不要求背诵）。 | -> **数量口径：** 首周最低完成 10 个 case；若时间充裕，按路线图 Day 1 扩展至 20 个（结构见《首周工作表》第 2 节）。 +> ⛔ **停止线：理论到此为止。** 不要继续读 `04-Reference`、guidebook 或归档——它们是"按需查阅的工具书"，不是"要读完的教材"。 + +### 阶段 2 · 出口检查（判断"理论够了"，而不是读完多少页） + +| 检查项 | 材料 | +|---|---| +| 学习看板 Level 1 全部勾选（勾选时补日期） | [[01-Learning-Board\|学习看板]] | +| 首周工作表第 0 节填完 | [[02-First-Week-Worksheet\|首周工作表]] | + +### 阶段 3 · 实践（立即开始） + +| 顺序 | 阅读材料 | 解决的问题 | 完成标志 | +|---:|---|---|---| +| 1 | [[02-First-Week-Worksheet\|首周工作表]] | 今天应该写什么，卡住时怎样缩小范围？ | 完成任务边界、10 个 case 与 rubric v0.1。 | +| 2 | [[01_Projects/Personal-Tech/LLM_Evaluation/03-Practice/README\|项目实践入口]] | 如何把工作表变成自己的项目仓库？ | 复制 `03-Practice/_template/` 建立项目并保存第一个 run。 | + +### 阶段 4 · 按需回补（贯穿整个学习期） + +`04-Reference` 的五篇各自标注了"前置阶段"（见 [[01_Projects/Personal-Tech/LLM_Evaluation/04-Reference/README\|04-Reference 资源地图]]），按项目推进需要插入，不一次读完。 + +| 阅读材料 | 解决的问题 | 什么时候读 | +|---|---|---| +| [[01-LLM-Evaluation-Roadmap\|LLM 评测工程实战路线图]] | 怎样逐步走向 Judge、Agent、安全、数据资产与 CI？ | 阶段 3 中随时查阅 | +| [[01-Learning-Board\|学习看板]] | 我学到哪了？还差哪个闭环？ | 全程，勾选时补日期 | + +> **数量口径：** 首周最低完成 10 个 case（结构见《首周工作表》第 2 节）；若时间充裕，按路线图 Day 1 扩展至 20 个（配比见《实战路线图》Day 1 小节）。 + +> **进度记录：** 学习过程（当前位置、周记、季度复盘）统一记在 [[01_Projects/Personal-Tech/LLM_Evaluation/05-Progress/00-当前位置与下一步\|05-Progress]]；学习看板只负责勾选。 ## 目录结构为何这样设计 @@ -43,9 +64,17 @@ created: 2026-08-21 | `00-Foundations` | 基础概念、术语边界与速查地图（What） | 操作手册与个人项目数据 | 先建立共同语言，后续文档不再重复解释术语。 | | `01-Getting-Started` | 学习入口、进度看板与 Why Guide（Why） | 复杂工具的操作手册 | 让你每次打开专区都能立刻知道下一步与为什么。 | | `02-Practical-Roadmap` | 可执行路线、清单、模板、阶段性任务（How） | 一次性运行结果 | 将原则转成动作，且便于反复使用。 | -| `03-Practice` | 每个亲自完成的 Eval 项目、实验记录、复盘 | 通用学习材料 | 学习材料与个人证据分离，项目才不会被笔记淹没。 | -| `04-Reference` | 评测工程能力地图（基建 / 可复现 / 持续评测 / Agent 安全环境）；旧草案归档于 `archive/` | 正在执行的任务 | 保留来路和背景，但不干扰当前学习。 | -| `99-Attachments` | 外部 PDF、截图、数据文件等二进制附件（也可统一放全库 `05_Attachments`） | 主笔记 | 保持 Markdown 笔记可搜索、可链接、可版本控制。 | +| `03-Practice` | 每个亲自完成的 Eval 项目、实验记录、复盘；`_template/` 提供可复制的项目骨架 | 通用学习材料 | 学习材料与个人证据分离，项目才不会被笔记淹没。 | +| `04-Reference` | 评测工程能力地图（基建 / 可复现 / 持续评测 / Agent 安全环境）；guidebook 外部知识与旧草案归档于子目录 | 正在执行的任务 | 保留来路和背景，但不干扰当前学习。 | +| `05-Progress` | 学习进度与自评：当前位置、学习周记、季度复盘、作品集清单 | 项目证据 | 学习过程有存档处，看板 / README 不被个人数据污染。 | +| `99-Attachments` | （已移除）二进制附件统一放全库 `05_Attachments` | — | 避免"本地附件 vs 全库附件"二选一的歧义。 | + +## 命名约定 + +- `README.md` = 目录总览（hub） +- `00-` 前缀 = 入口页或总览页（如 `00-Start-Here`） +- `01+` 前缀 = 按推荐阅读顺序的内容 +- `_` 前缀 = 模板 / 工具，非学习内容（如 `03-Practice/_template/`） ## 三条使用规则 @@ -57,14 +86,13 @@ created: 2026-08-21 ## 你的当前入口 -打开 [[00-Start-Here|开始这里]]，完成其中的十分钟动作；完成后再填写 [[02-First-Week-Worksheet|首周工作表]]。想追踪进度时，对照 [[01-Learning-Board|学习看板]] 勾选闭环条目。 +打开 [[01_Projects/Personal-Tech/LLM_Evaluation/05-Progress/00-当前位置与下一步|当前位置]]，确认自己处在哪个阶段；从 [[00-Start-Here|开始这里]] 完成十分钟动作；完成后填写 [[02-First-Week-Worksheet|首周工作表]]。想追踪进度时，对照 [[01-Learning-Board|学习看板]] 勾选闭环条目（勾选时补日期）。 ## 关联材料 - 职业与岗位背景：[[02_Areas/Job/llm_data_annotation_programmer_roadmap|大模型数据标注与程序员入门]]（原文存于 02_Areas/Job） -- 入门认知草案：[[02-Intro-Cognitive-Framework-Draft|入门认知框架（草案）]] -- 路线图重构草案：[[03-Roadmap-Refactor-Outline-Draft|实战路线图重构大纲（草案）]] -- 评测工程资源地图：[[04-Reference/README|04-Reference 资源地图]]（五层能力框架与推荐精读顺序） -- 外部权威知识参考：[[04-Reference/evaluation-guidebook/00-Overview|HuggingFace Evaluation Guidebook 中文提炼]]（自动基准 / 人工评测 / LLM-as-judge / 排错，按主题查阅） -- 外部精选资源（已归档）：[[04-Reference/archive/01-Curated-External-Resources|精选外部评测资源]]（顶级大厂与开源组织的生产级方案、评测基建与硬核课程源码） -- 归档总索引：[[04-Reference/archive/00-Material-List|材料清单与归档说明]]（早期草案与外部参考的定位总览） +- 评测工程资源地图：[[01_Projects/Personal-Tech/LLM_Evaluation/04-Reference/README|04-Reference 资源地图]]（五层能力框架与推荐精读顺序） +- 外部权威知识参考：[[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]]（当前位置 / 学习周记 / 季度复盘 / 作品集清单）