查询日志是"内容缺口"的地图
检索日志里藏着最有价值的运营信息 ✗→✔：用户在问什么 ✔。
如果某个问题被反复问、但资料里没有 ✔ —— 那不是模型问题 ✔，是内容缺口 ✔。
把查询日志用起来 ✔，就能从"调模型"转向"补内容" ✔（后者收益往往更大 ✔）。
一、该记录的查询信息
query 原文（脱敏 ✔）｜ 归一化后的 query（去标点/统一大小写 ✔）
命中数（召回了几条 ✔）｜ 最高相似度 ｜ 是否触发拒答 ✔
用户后续行为（追问 / 点踩 / 离开 ✔）
"命中数"与"是否拒答"最关键 ✗→✔：命中数 = 0 或 拒绝回答 的查询，
就是内容缺口的第一候选 ✔。
二、四类信号与对应动作
| 信号 | 含义 | 动作 |
|---|---|---|
| 零命中且高频 | 资料里确实没有 ✔ | 补文档（或明确声明范围 ✔） |
| 零命中但低频 | 可能是个别问法 ✔ | 先观察，或做同义扩展 ✔ |
| 命中高但被拒答 | 阈值太紧或缺少"允许回答"的提示 ✔ | 调阈值/提示词 ✔ |
| 命中高但用户追问 | 答非所问或不够具体 ✔ | 看片段质量与排序 ✔ |
注意第三类 ✗：它常被误判为"资料不足" ✔，实际是阈值或提示词过保守 ✔。
三、把缺口变成待办
① 每周导出"零命中 Top 20"（按归一化 query 聚类 ✔）
② 人工看：哪些是真的缺口、哪些只是问法问题 ✔
③ 按业务价值排序（高频 + 高价值优先 ✔）
④ 每项写待办：补哪份文档 / 加什么同义扩展 / 明确声明不支持 ✔
⑤ 下周复查该 query 是否已有命中 ✔
要点：第 ⑤ 步是闭环 ✗→✔（没有它，缺口清单会越积越多 ✔）。
四、三个反模式
- 只统计命中率不看待答清单 ✗；
- 把缺口当模型问题 ✗（换模型解决不了"资料里没有" ✔）；
- 补了文档不验证 ✗（新文档可能切分有问题，仍然检索不到 ✔）。
一条判据
你能否说出本周 Top 5 的内容缺口 ✔，以及各自的责任人与处理状态 ✔？
说不出，说明查询日志还没变成运营输入 ✗。