badcase 挖掘与归类流程
不要等问题自己冒出来，而是定期主动挖 badcase：抽样解析失败的样本、低置信度输出、重试成功的样本，以及回归集里勉强通过的样本。挖出来先归类计数，再决定修复顺序。没有归类的修复是打地鼠——跟着最近一次投诉走，同类问题下周还会再来一次。
基本信息
| 来源 | 解析失败、低置信度、重试样本、勉强通过的回归样本 |
|---|---|
| 周期 | 每周固定挖一轮，形成节奏而不是救火 |
| 归因 | 先归类再修复，按错误分类计数决定顺序 |
| 留存 | 典型 badcase 入回归集，防止修复后复发 |
典型使用场景
- 周度质量例会：用本周 badcase 的分类占比作为议题
- 字段抽取服务：解析失败样本集中出现，说明上游或提示有变
- 多轮对话产品：重试成功的样本往往暴露提示的边界问题
- 回归集维护：把典型 badcase 补进回归集，锁住修复效果
- 评测集扩充：从真实失败样本里挑代表进评测集，贴近线上分布
挖掘来源清单
挖掘来源清单
1) 解析失败与重试成功的样本
- 重试成功说明首次输出不稳，值得看提示的哪一处弱
2) 低置信度样本（若输出含置信度字段）
3) 线上抽检人工发现的错误
4) 回归集中「勉强通过」的样本
- 这些是下一批风险的先兆
输出：按错误分类计数 → 选高频类进入本轮迭代
# 抽样要按来源分层，只挖容易发现的错误会让同类问题反复出现
# 每轮挑 2-3 条代表性样本写进说明，其余归档来源与处置对照
| 来源 | 说明 | 处置 |
|---|---|---|
| 解析失败 | 输出无法被程序解析 | 先看上游输入变化，再看提示格式约束 |
| 低置信度 | 输出里带低分标记 | 按置信度分桶，看低分桶的共性 |
| 重试成功 | 首次失败、重试通过 | 定位首次失败原因，通常与格式或采样有关 |
| 人工抽检 | 抽检时发现的错误 | 记录到分类表，与自动指标交叉验证 |
| 勉强通过 | 回归集里低分通过 | 提升优先级，作为下一批风险的候选 |
只挖容易发现的错误（比如解析失败）会让难发现的正确性错误长期积压。按来源分层抽样，让各类问题都有一定曝光机会。
修复不回流回归集，几周后可能被其他改动带回来。每修完一类问题，补 3-5 条代表样本进回归集，是成本很低但效果明显的动作。