7.1 KiB
aliases, type, tags, status, created
| aliases | type | tags | status | created | |||
|---|---|---|---|---|---|---|---|
|
template |
|
active | 2026-08-21 |
LLM 评测入门：首周工作表
使用方法： 不要先研究工具。直接复制本文件，为一个公开文档问答小任务填写空白处。只要完成到“10 个 case + rubric + 一次盲评”，就已经完成了真正的第一步。
与路线图的关系： 本工作表是《LLM 评测工程实战路线图》Day 1—3 的填空版，按“首周最低 10 个 case”设计；若时间充裕，可按路线图扩展至 20 个。
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：资料不足处理 | 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 归因：
| 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。持续、可复盘地推进，比一次做很多更适合入门。