"失败了 23 条"不是可行动的信息
评测跑完报"23 条失败" ✗ —— 接下来该干嘛 ✔？没有分类，就只能一条条看 ✔，
而人一忙就只看前几条 ✔，剩下的长期没人管 ✔。
把失败分成"可行动的类型" ✔，每类对应一个明确的修复方向 ✔。
一、一张实用的失败类型表（8~12 类）
① 格式不符（要 JSON 给了散文 / 字段缺失 ✔）
② 事实错误（与资料冲突 ✔）
③ 编造（资料里没有却断言 ✔）★最危险
④ 漏答（该说的没说 ✔）
⑤ 理解偏差（答非所问 ✔）
⑥ 拒答过度（该答却说不确定 ✔）
⑦ 未标注不确定（推断当事实 ✔）
⑧ 引用错误（引用不支持结论 ✔）
⑨ 延迟/超时 ✔
⑩ 越权/合规（不该答却答 ✔）★高危
要点：类型要互斥且可判定 ✗ ✔ —— 一条失败只归一类（选最主要的 ✔），
否则统计会重叠 ✔，谁也说不清该先修哪类 ✔。
二、每类要配"修复方向"（这才是可行动的关键）
| 类型 | 优先查哪里 |
|---|---|
| ① 格式不符 | 输出 schema、示例、校验与重试 ✔ |
| ② 事实错误 | 检索召回与片段质量（先查资料 ✔） |
| ③ 编造 | 证据表、引用校验、拒答标准 ✔ |
| ④ 漏答 | 检索覆盖、上下文截断 ✔ |
| ⑤ 理解偏差 | 任务说明与澄清机制 ✔ |
| ⑥ 拒答过度 | 拒绝阈值、提示词过保守 ✔ |
| ⑦ 未标注不确定 | 不确定性传递 ✔ |
| ⑧ 引用错误 | 引用一致性校验 ✔ |
| ⑨ 延迟 | 并行化、输出长度、缓存 ✔ |
| ⑩ 越权 | 权限模型与检索层过滤 ✔ |
注意 ② 与 ③ 的区别 ✗：② 是"资料里有正确信息但答错" ✔；③ 是"资料里根本没有却说了" ✔。
两者的修法完全不同 ✔（前者改检索，后者加引用校验与拒答 ✔）——
分不清这两类，就会一直在换模型 ✗。
三、怎么让分类"真的被执行"
- 报告里只给 Top 3 类型 ✔（每类给 1 条样例原文 + 建议动作 ✔）；
- 每周例会只看类型分布变化 ✔（不看总量 ✔）；
- 每类指定一个"待办" ✔（谁、什么时候、怎么验证 ✔）；
- 修复后重跑，确认该类下降且其它类没有上升 ✔（常见副作用 ✔）。
四、三个反模式
- 只统计总失败数 ✗；
- 类型太多（30 类） ✗ → 没人记得住，标注也不一致 ✔；
- 类型不改 ✗ → 系统变了，失败模式也变了 ✔（每季度校准一次 ✔）。
一条判据
看到"本周失败率上升 2 个点" ✔，你能否立刻说出"是第 3 类上升了" ✔ 以及"该改哪里" ✔？
不能，说明失败没有被分类 ✗。