dedupe LLM_Evaluation zone: single-source tables, fix nav orphans, compress guidebook 2025
- Why Guide: remove duplicated 20-case/rubric/test-definition tables, link to authoritative Roadmap/Worksheet instead; 10-min action points to entries - Concept Map / What-Is: cross-link narrative vs quick-reference roles - Worksheet: annotate sections with authoritative sources - 04-Reference 01-04 <-> archive/01: bidirectional resource links - archive/00-Material-List: shrink guidebook listing, now reachable from READMEs - guidebook: compress 06-Yearly-Dives 2025 section (-> 08-2025-Edition §3), add old/new version nav banners to 01-05, reverse links in 08 - README/Start-Here: link Learning Board (was orphaned)
This commit is contained in:
windyboy
@@ -140,21 +140,11 @@ OpenAI 将 eval 描述为对模型输出进行结构化测试，并强调先定
|
||||
|
||||
先写 10—20 个 case，是为了迫使你回答一个更难的问题：用户会以哪些不同方式使用系统？哪些情况最容易诱发错误？你写不出来，恰恰说明你还没有足够理解任务，而不是说明你需要更多数据。
|
||||
|
||||
建议先用如下小分布，而不是随机列 20 个问题：
|
||||
|
||||
| 样本类型 | 初始数量 | 为什么要有 |
|
||||
|---|---:|---|
|
||||
| 文档可完整回答 | 8 | 验证核心功能是否成立。 |
|
||||
| 文档完全没有答案 | 4 | 观察系统是否乱猜。 |
|
||||
| 文档只支持部分答案 | 2 | 观察系统能否承认边界，而非二元化地答或不答。 |
|
||||
| 多片段才能回答 | 2 | 暴露遗漏证据、拼接错误或片面回答。 |
|
||||
| 容易诱发常识补全 | 2 | 检测看似合理但无证据的内容。 |
|
||||
| 格式或引用约束 | 1 | 检查输出结构与引用格式是否被遵守。 |
|
||||
| 边界或对抗输入 | 1 | 检查系统是否错误执行不可信指令。 |
|
||||
建议先用如下小分布，而不是随机列 20 个问题：7 个类别（文档可完整回答、完全没有答案、只支持部分、多片段、容易诱发常识补全、格式/引用约束、边界/对抗输入）按 `8 / 4 / 2 / 2 / 2 / 1 / 1` 配比，每类的意图与权威表格见 [[01-LLM-Evaluation-Roadmap]] 的 Day 1 小节。
|
||||
|
||||
这 20 个 case 不是“训练数据”，而是**你写给系统的 20 个问题**。每个问题都在问：“当我换一种真实但容易出错的条件时，你还能遵守同一个行为标准吗？”
|
||||
|
||||
如果时间只够做 **10 个 case**，不要把所有类别机械地等比例砍半。优先保留：3 个正常路径、2 个资料不足、1 个部分支持、1 个多证据、1 个幻觉诱发、1 个格式约束、1 个边界条件（与《首周工作表》第 2 节的结构一致）。第一版必须先学会测试“能答”与“不能答时不乱猜”这两个核心行为。
|
||||
如果时间只够做 **10 个 case**，不要把所有类别机械地等比例砍半。优先保留：3 个正常路径、2 个资料不足、1 个部分支持、1 个多证据、1 个幻觉诱发、1 个格式约束、1 个边界条件（与 [[02-First-Week-Worksheet]] 第 2 节的结构一致）。第一版必须先学会测试“能答”与“不能答时不乱猜”这两个核心行为。
|
||||
|
||||
### 为什么负例和资料不足特别重要
|
||||
|
||||
@@ -178,13 +168,7 @@ OpenAI 将 eval 描述为对模型输出进行结构化测试，并强调先定
|
||||
|
||||
同一个正确答案可以有不同措辞；同一个看起来像参考答案的输出，也可能漏掉了最关键的安全限制。参考答案只是一个例子，rubric 才是**判定逻辑**。
|
||||
|
||||
以“根据文档回答问题”为例，第一版 rubric 可以只有三项：
|
||||
|
||||
| 维度 | 通过意味着什么 | 失败意味着什么 | 为什么这样设计 |
|
||||
|---|---|---|---|
|
||||
| 有据性 | 每个关键事实能在上下文找到支持 | 出现至少一条无依据事实 | 直接约束幻觉风险。 |
|
||||
| 资料不足处理 | 资料不足时明确说明 | 把未知内容说成确定结论 | 让“拒答”成为正确行为。 |
|
||||
| 核心任务完成度 | 覆盖问题中的必要部分 | 漏掉核心限制或答偏 | 防止系统只写安全套话却不解决问题。 |
|
||||
以“根据文档回答问题”为例，第一版 rubric 只保留三个维度：**有据性**（约束幻觉风险）、**资料不足处理**（让“拒答”成为正确行为）、**核心任务完成度**（防止只写安全套话却不解决问题）。三个维度的通过/失败定义与判定方式以 [[01-LLM-Evaluation-Roadmap]] 第六节为权威版本；可填写的空白模板见 [[02-First-Week-Worksheet]] 第 1 节。
|
||||
|
||||
第一版优先使用 `pass/fail` 或 `0/1/2`，不要上来就给“专业度、清晰度、帮助性”各打 1—5 分。原因不是细粒度评分不好，而是你还没有建立足够的锚点：3 分与 4 分差在哪里？如果人自己答不清，模型评分器更不可能稳定答清。
|
||||
|
||||
@@ -250,13 +234,7 @@ Case 定义：我想测试什么、成功条件是什么。
|
||||
Run 记录：这个版本的系统在某个时间、某个配置下实际输出了什么。
|
||||
```
|
||||
|
||||
这个区分就是 `Test Definition ≠ Test Execution`。它的意义与传统测试完全一样：测试用例不应随一次执行结果被改写；否则你无法比较不同版本，更无法追溯错误。
|
||||
|
||||
| 应该稳定保存的定义 | 每次运行才生成的记录 |
|
||||
|---|---|
|
||||
| 问题、上下文、预期行为、类别、rubric 版本 | 模型名、提示词/系统版本、温度、trial、输出、延迟、评分结果 |
|
||||
| 为什么测这个 case | 这次系统到底做了什么 |
|
||||
| `datasets/` | `runs/` |
|
||||
这个区分就是 `Test Definition ≠ Test Execution`。它的意义与传统测试完全一样：测试用例不应随一次执行结果被改写；否则你无法比较不同版本，更无法追溯错误。两类内容各自应保存的字段与 JSONL 示例见 [[01-LLM-Evaluation-Roadmap]] 第五节（该 schema 为权威版本）。
|
||||
|
||||
保存 run 不是“为了看起来工程化”，而是为了保留实验条件。没有条件记录的结论无法重现；无法重现的结论，就不能指导后续修改。
|
||||
|
||||
@@ -290,7 +268,7 @@ Run 记录：这个版本的系统在某个时间、某个配置下实际输出
|
||||
比较 Judge 与人工不一致的 case
|
||||
```
|
||||
|
||||
这不是反对自动化，而是在建立自动化的基准。自动 Judge 的真正用途是把已被校准的判断放大，而不是代替你决定什么叫好。
|
||||
这不是反对自动化，而是在建立自动化的基准。自动 Judge 的真正用途是把已被校准的判断放大，而不是代替你决定什么叫好。校准实验的具体做法（混淆矩阵、failure precision / recall、接受阈值）见 [[01-LLM-Evaluation-Roadmap]] 第七节。
|
||||
|
||||
### 你此时真正学到什么
|
||||
|
||||
@@ -398,7 +376,7 @@ Run 记录：这个版本的系统在某个时间、某个配置下实际输出
|
||||
| 引用是否正确 | 参数、权限和状态是否正确 | 输出或动作能否被核对？ |
|
||||
| 最终回答 | 环境 outcome | 文字承诺是否与真实结果一致？ |
|
||||
|
||||
所以，等你准备做 Agent 项目时，不要先追求复杂的多工具流程。先实现三个无副作用的模拟工具，例如 `search_issue()`、`get_issue()`、`update_issue_draft()`，再构造“参数缺失、同名实体、权限不足、用户改意”这些 case。你会发现仍然是在重复同一条主线：**定义成功 → 构造边界 → 执行 → 评分 → 归因 → 回归。**
|
||||
所以，等你准备做 Agent 项目时，不要先追求复杂的多工具流程。先实现三个无副作用的模拟工具，例如 `search_issue()`、`get_issue()`、`update_issue_draft()`，再构造“参数缺失、同名实体、权限不足、用户改意”这些 case。你会发现仍然是在重复同一条主线：**定义成功 → 构造边界 → 执行 → 评分 → 归因 → 回归。**（Agent 评测的根因分类、trace 与 outcome 断言等实操见 [[01-LLM-Evaluation-Roadmap]] 第八节。）
|
||||
|
||||
---
|
||||
|
||||
@@ -414,11 +392,7 @@ Run 记录：这个版本的系统在某个时间、某个配置下实际输出
|
||||
|
||||
## 最后：现在第一步到底做什么
|
||||
|
||||
不要再打开新的课程或框架文档。任选一个动作，十分钟内完成：
|
||||
|
||||
- [ ] 从一份公开技术文档中复制一段 200—500 字的内容，并写出一个“文档能回答的问题”和一个“文档不能回答的问题”。
|
||||
- [ ] 在空白文档写下：“我的系统什么时候应该说‘我无法确认’？”
|
||||
- [ ] 写一条 rubric：`若答案包含上下文未支持的事实，则 groundedness = fail`。
|
||||
不要再打开新的课程或框架文档。任选 [[00-Start-Here|开始这里]] 或 [[02-First-Week-Worksheet|首周工作表]] 中的“十分钟动作”，十分钟内完成一个（例如：从公开文档复制一段 200—500 字并写一个“能回答/不能回答”的问题，或写一条 `若答案包含上下文未支持的事实，则 groundedness = fail` 规则）。
|
||||
|
||||
这个动作很小，但它会迫使你从“学习 AI 概念”切换到“定义 AI 的可验证行为”。后面的 case、盲评、脚本和回归，都是从这一步自然长出来的。
|
||||
|
||||
|
||||
Reference in New Issue
Block a user