把检索日志用起来：从查询分布发现内容缺口

查询日志是内容缺口的地图。本文给出该记录的查询信息、四类信号与对应动作（重点：命中高却被拒答常是阈值问题）、把缺口变成待办的五步闭环与三个反模式。

查询日志是"内容缺口"的地图

检索日志里藏着最有价值的运营信息 ✗→✔：**用户在问什么** ✔。

如果某个问题被反复问、但资料里没有 ✔ —— 那不是模型问题 ✔，是**内容缺口** ✔。

**把查询日志用起来** ✔，就能从"调模型"转向"补内容" ✔（后者收益往往更大 ✔）。

```

query 原文（脱敏 ✔）｜归一化后的 query（去标点/统一大小写 ✔）

命中数（召回了几条 ✔）｜最高相似度｜是否触发拒答 ✔

用户后续行为（追问 / 点踩 / 离开 ✔）

```

**"命中数"与"是否拒答"最关键** ✗→✔：`命中数 = 0` 或 `拒绝回答` 的查询，

就是内容缺口的第一候选 ✔。

| 信号 | 含义 | 动作 |

|---|---|---|

| **零命中且高频** | 资料里确实没有 ✔ | 补文档（或明确声明范围 ✔） |

| **零命中但低频** | 可能是个别问法 ✔ | 先观察，或做同义扩展 ✔ |

| **命中高但被拒答** | 阈值太紧或缺少"允许回答"的提示 ✔ | 调阈值/提示词 ✔ |

| **命中高但用户追问** | 答非所问或不够具体 ✔ | 看片段质量与排序 ✔ |

**注意第三类** ✗：它常被误判为"资料不足" ✔，实际是**阈值或提示词过保守** ✔。

```

① 每周导出"零命中 Top 20"（按归一化 query 聚类 ✔）

② 人工看：哪些是真的缺口、哪些只是问法问题 ✔

③ 按业务价值排序（高频 + 高价值优先 ✔）

④ 每项写待办：补哪份文档 / 加什么同义扩展 / 明确声明不支持 ✔

⑤ 下周复查该 query 是否已有命中 ✔

```

**要点**：第 ⑤ 步是闭环 ✗→✔（没有它，缺口清单会越积越多 ✔）。

**只统计命中率不看待答清单** ✗；

**把缺口当模型问题** ✗（换模型解决不了"资料里没有" ✔）；

**补了文档不验证** ✗（新文档可能切分有问题，仍然检索不到 ✔）。

> 你能否说出**本周 Top 5 的内容缺口** ✔，以及各自的责任人与处理状态 ✔？

> 说不出，说明查询日志还没变成运营输入 ✗。