前两篇聊的是思考，这篇来点干货——如何构建用来探测知识库缺口的小工具。文末有开源地址。
先一句话说清它干嘛：用问答当探针，批量灌一批测试题进去，把知识库答不出来的地方挑出来，生成一份"哪个场景缺、缺多少"的报告。
整条链路不复杂：文档清洗切片 → 建向量索引 → 检索 → 按阈值判定 → 出报告。但真正花心思、也真正决定它靠不靠谱的，有两个点。
· · · ✦ · · ·
一、最核心的设计：怎么判断"答不出来"
这是整个工具的灵魂，也是之前版本栽得最惨的地方。
最直觉的做法是：把测试题丢给问答系统，答出来算"有覆盖"，答不出来算"缺口"。我早期就是这么干的，结果第一版报告给了我一个完美的 100% 完善度、零缺口——而事实是一多半题根本没答好。报告在骗我。
后来定位到问题，是判定逻辑里一个特别隐蔽的坑，值得每个做检索的人记住：
向量检索有个特性——不管库里有没有相关内容，它永远会返回最接近的 top-K 条。你问一个库里压根没有的东西，它照样给你凑几条"距离最近但其实是噪声"的结果回来。
而第一版我把"检索返回了 N 条"当成了"库里有内容"，于是凡是答不出的都被解释成"内容明明有、模型没用好"，真缺口那个桶永远是空的，完善度自然虚高成 100%。
所以这版立了一条铁律：判定只看相似度分数，绝不看返回了几条。
具体做法简化成了一个干净的二分：
每道测试题 → 向量检索 → 取最高相似度分数
├─ 最高分 ≥ 阈值 → ✅ 有覆盖
└─ 最高分 < 阈值 → ❌ 真缺口
逻辑越简单越好维护，但这里有个绕不开的问题：阈值定多少？定高了漏报缺口，定低了误报。这个数绝对不能拍脑袋。
所以我专门做了个校准模式：准备一个小的"校准题集"，每道题手动标注好"库里确实有（1）/确实没有（0）"，让系统跑一遍，看这两组的相似度分数各自落在什么区间，自动算出一个能最干净地分开两组的分界点。
比如我这次跑出来，库里有的题分数在 0.61～0.74，库里没有的在 0.16～0.47，系统推荐阈值 0.605，这条线下误报和漏报都是 0。这个 0.605 才是有依据的，不是我猜的。
校准时的小心得：如果发现两组分数分不开（有覆盖的题和没覆盖的题分数混在一起），说明的不是阈值问题，而是你的 embedding 模型或切片策略本身有问题，得先去修那个。校准这一步顺带还帮你体检了检索质量。
· · · ✦ · · ·
二、最反直觉的决定：为知识图谱而来，用朴素向量检索收尾
这个项目最初的由头，其实是"上知识图谱"——领导觉得问答效果不好是知识库不够结构化，要用知识图谱改善检索。我也照着接了 LightRAG，搞实体抽取那一套。
但做着做着我把它关掉了，最后默认跑的是 ChromaDB + 本地 BGE 向量模型这种最朴素的方案。原因有两个：
一是目标根本不需要图谱。我要回答的是"这个业务点库里覆盖了没有"这种点状问题，而知识图谱的强项是"办了 A 还能不能办 B"这类跨文档推理。用图谱做点状检索，是杀鸡用牛刀，还得为这把牛刀的维护成本买单。
二是图谱的更新成本高到离谱。知识图谱里，一篇文档抽出的实体会和其他文档的实体在图里交织合并，你改一篇文档，想干净地撤掉它的旧贡献再换新的，极难。结果就是每次更新都倾向于全量重建。
退回纯向量后，白捡了一个巨大的好处：增量更新变得极其简单。向量库天然支持按 id 增删改单条，我用一个文件记下每个文档的 MD5 指纹，每次更新只对比哈希、只重算变动的文件，没变的零开销跳过。效果很直观——几十个文档里只改 1 个，重建时间从大几十分钟降到约 1 分钟。
这个取舍是整个项目最大的一个心得：先想清楚你要解决的问题需要什么，再选技术，而不是反过来。我差点就为了"领导说要上知识图谱"这句话，背上一整套我根本不需要的复杂度。
· · · ✦ · · ·
三、其余部分，够用就好
剩下的几块快速带过，重要，但没什么反直觉的：
文档清洗按类型分流。HTML 去标签还要清掉导航、页脚这些模板噪声，否则污染检索；Excel 转表格文本；PDF 抽文字。
文档按业务场景分子目录。报告就能以"场景"为维度出热力图，哪个场景红就是哪个缺得多，一眼定位。
每条真缺口都附上最高相似度分和最相似的那段原文。方便人工复核是不是误判。
· · · ✦ · · ·
最后，两句必须说的实话
这工具我在 README 里专门写了两条"诚实声明"，也搬到这里，因为它们比任何功能都重要：
第一，它只区分"有覆盖/真缺口"两类，不告诉你"是检索没找到还是模型没答好"。这是主动做的简化取舍——对"探测缺口"这个目标够用，但它不是诊断检索质量的工具，别拿它当全科医生。
第二，也是最关键的：这工具能告诉你"测到的地方缺什么"，但永远证明不了知识库"全了"。因为覆盖率完全取决于你的测试题出得全不全。它是探照灯，不是裁判。"应该有哪些内容"这个基准，得业务方来定，工具定不了。
