企业知识库上线两周客服转来一个典型问题。用户问支持离线部署且有审计日志的是哪个版本系统回复找不到相关资料。人工一查资料都在库里只是散在三份文档里每一份都只覆盖一半条件。换个问法离线部署 审计日志反而搜出来了。检索质量的问题不能全记在大模型头上。这篇把漏检的排查顺序和几种重排方案整理成一张对照表。漏检环节典型表现先查什么解析与切块表格打散、条件丢失原始文档到片段的中间产物单向量表示多条件被平均掉同一问题的多条件检索测试召回阶段正确答案没进候选先扩大召回数量再看排序阶段进了候选但排太后看正确片段的名次分布一、先排查解析与切块排查顺序从原始文档开始而不是先换模型。内容有没有被完整读取表格的行列关系有没有保住图片里的条件有没有被提取旧版本有没有覆盖新版本。进入向量模型之前正确证据可能已经丢了这时候再大的 Embedding 模型也只是替上游背锅。切块粒度要拿真实问题试。切太碎前提和结论分了家切太大细节被整体主题淹没。我们的经验是切块之后跑一遍历史问题集看有多少问题的答案片段被切断这个数字比对着切块大小拍脑袋可靠。二、单向量为什么漏掉条件常见检索把查询和片段各压成一个向量再比相似度。一个片段里同时有实体、条件和例外时固定长度表示必须把它们合在一起整体主题相似单个条件未必对得上。用户问的是同时满足两个条件的版本召回的却是一份只讲条件一、一份只讲条件二。多条件问题是我们漏检的重灾区。换更大的 Embedding 模型只解决一部分条件混合取决于表示方式加参数解决不了。三、多向量与 MaxSim 做细粒度匹配Late Interaction 的思路是查询和片段都保留多个 token 向量到评分阶段再逐对匹配。一种常用评分叫 MaxSim对每个查询 token 在片段里找最相似的 token取最大值再求和。多个线索各自寻找自己的最佳匹配位置条件被平均掉的问题减轻了。代价要知道。十万条片段每条留 200 个 128 维向量按每个数值两个字节算原始数据约 5GB同样规模的单向量方案约 150MB差三十多倍。索引结构、量化压缩还会再加开销。所以我们的做法是分阶段关键词和单向量先粗召回一两百条再用多向量精排前几十条。四、评测口径要写准不要从演示里挑几道效果好的问题下结论。建一份覆盖真实需求的小评测集每道题标注支撑答案的证据片段允许多个正确来源。指标里 RecallK 和 HitK 经常混用。一道题有四个相关片段前五找回两个Recall5 是二分之一前五里至少有一个那是 Hit5两者回答的是不同问题。失败样本再分类完全没匹配上、匹配上但缺条件、正确片段排太后、证据正确但回答跑偏分别对应解析、表示、排序、生成四个环节。五、实测账指标改造前改造后多条件问题的 Hit571%89%正确片段平均名次8.43.1单次检索 P95 延迟120ms380ms索引体积基准4.2 倍口径说明。数字来自自己项目的内部知识库问题集覆盖三百道真实提问改造内容是解析修复加分阶段召回排序。场景不同差别很大套用前先建自己的评测集。380 毫秒的 P95 延迟是精排换来的离线场景可以再放宽候选数量在线场景我把精排候选压到三十条延迟和效果的平衡点因业务而异。六、踩坑记录坑一先换了 Embedding 模型。第一版排查直接升级向量模型漏检率没动。回头查解析层表格条件在切块时就打散了。先修解析再谈表示。坑二权限过滤放错了位置。把无权访问的文档也召回给模型指望提示词约束别说出去。正确做法是在检索阶段就过滤缓存和引用一起遵守权限。坑三把检索到的文本当可信指令。文档里出现过忽略以上要求这类文字被模型当成了指令执行。检索文本只作证据用这条边界要在系统提示里写死注入防护的做法安全护栏篇里展开。七、总结环节一句话解析先查中间产物再谈模型表示多条件问题看多向量方案召回粗召回放宽精排收紧评测RecallK 和 HitK 分开报边界权限在检索层过滤证据不当指令结合系列。网页进 RAG 篇讲的是抓取、提取与切块这篇接着讲进了库之后怎么搜得到。RAG 评测篇的评测集口径在这里直接复用。语义缓存篇的缓存命中要跟着权限走跟这篇是同一个约束。来源。单向量的信息混合与 Late Interaction 的思路参考了公开的技术解析枫叶丹4 的《知识库为什么搜不到答案》成本量级与评测口径按公开资料整理实测数字按自己的项目口径套用前建议重跑。觉得有用点个关注。