把重复问题聚类：从处理个案到修一类问题

聚类能把个案处理变成系统修复。本文给出三种聚类粒度与建议顺序、每个簇要给出的五项、三个高频系统性根因（多不是模型问题）与一周半小时的持续做法。

一条条看日志，看不出系统性问题

用户问题成百上千 ✔，逐条处理永远处理不完 ✗。

**把重复问题聚类** ✔，就能从"处理个案"变成"修一类问题" ✔（收益高一个数量级 ✔）。

1. **按关键词/模板**（最便宜 ✔）：把问题归一化后按高频短语分组 ✔

（例如"为什么提示额度不足"出现 200 次 ✔）；

2. **按语义相似**（中等 ✔）：用嵌入把问题聚类 ✔，适合问法多样但本质相同的情况 ✔；

3. **按失败类型**（最可靠 ✔）：先按失败类型分类 ✔（见失败分类那篇 ✔），再在类内聚类 ✔。

**建议顺序**：先做 3（类型）+ 1（关键词）✔ —— 成本低、可解释 ✔；语义聚类留到后面 ✔。

每个簇要给出五项 ✔：

```

① 代表样本（3 条原文 ✔）

② 规模（多少条、占比、环比 ✔）

③ 影响（涉及多少用户/多少成本 ✔）

④ 归因（检索？提示词？界面引导？✔）

⑤ 建议动作与验证方式 ✔

```

**只给"Top 10 问题"是不够的** ✗ —— 必须带归因与动作 ✔。

**界面引导不足** ✗（用户在用不合适的入口问问题 ✔ → 改 UI ✔，见用户教育那篇）；

**数据/文档缺失** ✗（问的东西资料里根本没有 ✔ → 补资料或明确说明范围 ✔）；

**口径不清** ✗（同一概念系统理解与用户不同 ✔ → 明确术语，见术语一致性那篇 ✔）。

**注意**：这三类都**不是模型问题** ✔ —— 不聚类就永远在调模型 ✗。

1. 导出上周的负反馈与转人工记录（脱敏 ✔）；

2. 人工看 30~50 条，标类型 ✔；

3. 聚类，取 Top 3 簇 ✔；

4. 每簇写一个待办（谁、什么时候、怎么验证 ✔）；

5. 下周复查：**该簇规模是否下降** ✔。

**只做一次聚类** ✗（问题会变，聚类要持续 ✔）；

**聚类完没有 owner** ✗（报告发了没人管 ✔）。

> 上周的 Top 1 问题簇 ✔，这周规模下降了吗 ✔？

> 没有下降，说明聚类只是"报告"，没有变成"修复" ✗。