# LLM 评测入门：首周工作表

**使用方法：** 不要先研究工具。直接复制本文件，为一个公开文档问答小任务填写空白处。只要完成到“10 个 case + rubric + 一次盲评”，就已经完成了真正的第一步。

## 0. 先确定范围：你到底在评什么

> **为什么先填这一页：** 你不是在评价“模型总体能力”，而是在评价一个明确的系统行为。范围越明确，后面的 case 与评分越可信。

| 项目 | 你的填写 |
|---|---|
| 任务名称 | 例如：公开文档约束下的技术问答 |
| 用户输入 | 例如：一个问题 + 1—3 段文档片段 |
| 系统输出 | 例如：简短回答 + 文档引用位置 |
| 一句话成功条件 | 例如：关键事实可由文档支持；资料不足时明确说明 |
| 三类失败 | 例如：无依据事实；遗漏限制；把未知说成确定 |
| 非目标 | 例如：不评价文档外的常识正确性 |
| 数据来源 / 许可 | 例如：Python 官方文档某页面，记录 URL 与日期 |

### 停下来检查

如果你仍写的是“回答要专业”或“Agent 要聪明”，说明范围还不够小。把它改成一个可观察行为：引用、拒答、工具参数、权限、状态变化或可执行性。

---

## 1. 写 rubric v0.1：先让“怎么判”有答案

> **为什么这一步比写参考答案更早：** 参考答案只是一个可能的表述；rubric 才说明你要保护的行为边界。

| 维度 | 通过条件 | 失败条件 | 正例 | 反例 |
|---|---|---|---|---|
| 有据性 |  |  |  |  |
| 资料不足处理 |  |  |  |  |
| 核心任务完成度 |  |  |  |  |

**推荐起步标签：** 有据性和资料不足处理用 `pass / fail`；完成度用 `0 / 1 / 2`。第一周不要再增加维度。

### 停下来检查

让另一位同事只读此表、不看你的解释。他或她能否判断你给的一正一反例？如果不能，优先改文字，不要增加更多指标。

---

## 2. 写 10 个 case：让不同类型的失败有机会出现

> **为什么不是“随便写 10 个问题”：** 评测数据集的价值来自覆盖不同风险，而不是来自问题数量。

| 编号 | 类别 | 问题 | 文档能否完整回答 | 你预期系统应该怎样做 |
|---:|---|---|---|---|
| 01 | 正常路径 |  | 是 |  |
| 02 | 正常路径 |  | 是 |  |
| 03 | 正常路径 |  | 是 |  |
| 04 | 资料不足 |  | 否 |  |
| 05 | 资料不足 |  | 否 |  |
| 06 | 部分支持 |  | 部分 |  |
| 07 | 多证据 |  | 是 |  |
| 08 | 幻觉诱发 |  | 否 / 部分 |  |
| 09 | 格式约束 |  | 是 |  |
| 10 | 边界条件 |  | 视情况 |  |

### 资料不足问题的写法

不要写完全无关的问题。写“只差一小块信息就能回答”的问题，例如文档讲了配置字段但没有给默认值；再问“默认值是多少”。这样才能测试模型会不会合理地补全空白。

---

## 3. 生成两个候选：目标不是找冠军，而是制造比较

> **为什么要有 A/B：** 人更擅长比较两个候选，也更容易发现你自己的判断规则是否含混。

请选择一种做法：

- [ ] 两个不同模型；
- [ ] 同一模型的两个提示词；
- [ ] 自己手写一个“较好答案”和一个“带隐蔽错误的答案”；
- [ ] 使用公开数据集中已有的两份候选回答。

记录生成条件：

| 项目 | A | B |
|---|---|---|
| 模型 / 来源 |  |  |
| 系统提示词版本 |  |  |
| 温度 / 生成设置 |  |  |
| 运行日期 |  |  |

**重要：** 先把来源隐藏，随机叫 A 和 B；在完成判断之前，不要看真实来源。

---

## 4. 盲评 10 个 case：把“感觉”改成可复核理由

> **为什么要求写理由：** 标签告诉你“发生了什么”，理由才告诉你“为什么”。没有理由，后面无法判断是模型问题、规则问题还是数据问题。

| Case | A：有据性 | A：完成度 | 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 归因：

| Case | 为什么难判 | 下一步动作 |
|---|---|---|
|  | rubric 模糊 / 文档不完整 / 问题本身有歧义 / 自己标错 | 改规则 / 补证据 / 移出自动评分 / 请人复核 |

---

## 5. 写最小失败分类：不要把所有错误叫“幻觉”

> **为什么分类：** 错误类型决定修复路径。检索错、规则错、提示词错和评分错，不应使用同一修复手段。

| Case | 失败类型 | 证据 | 你准备先检查什么 |
|---|---|---|---|
|  | 无依据事实 / 漏限制 / 不当确定 / 格式 / 规则不确定 |  | prompt / 文档 / rubric / grader |

第一周只用 4—5 个类型即可。分类表的目的不是“全面”，而是帮助你找到下一次唯一值得改的地方。

---

## 6. 做一次小修改并回归：证明不是“碰巧更好”

| 你修改了什么 | 为什么改它 | 预期改善哪些 case | 必须不变差的 case | 修改后结果 |
|---|---|---|---|---|
| 例如：提示词加入“资料不足时不得推测” | 资料不足类频繁出现无依据补全 | 04、05、08 | 01、02、03 |  |

### 完成标准

你不需要所有 case 都通过。首周完成的定义是：你能指出一个失败模式，改一个可解释因素，重跑原有 case，并说明“改善了什么、又牺牲了什么”。

---

## 首周优先级：只保留最重要的四件事

| 必做 | 为什么 | 暂不做 |
|---|---|---|
| 任务边界 | 没有边界就没有可靠判断 | 换很多模型 |
| 10 个有结构的 case | 没有边界/负例就没有真正测试 | 写 100 条随机问题 |
| rubric + 人工理由 | 没有规则就无法知道得分含义 | 先上 LLM Judge |
| 一次修改 + 回归 | 没有闭环就只是看热闹 | 先搭仪表盘、CI 或大框架 |

## 今日十分钟动作

- [ ] 选一段公开文档。
- [ ] 写一个文档能回答的问题。
- [ ] 写一个文档不能回答的问题。
- [ ] 写一句判定规则：`答案中出现文档未支持的关键事实，则有据性 = fail`。

完成后就停止。明天再做第 2 个 case。持续、可复盘地推进，比一次做很多更适合入门。