知识库检索不准，先检查数据、切分还是模型？

知识库检索不准时先保留失败问题和期望答案再按“原始资料、切分结果、检索候选、最终回答”四层检查。不要一上来就换 Embedding 模型。资料缺失、权限过滤、切分断裂和查询表达偏差都可能让正确内容根本进不了候选集。排查的目标也要分清。用户说“回答不准”可能是没有检索到相关片段也可能是片段已经出现模型却理解错了。两种问题需要不同处理。概念示意图从原始资料一路检查到检索候选和最终回答定位内容在哪一层丢失。从失败样本开始先收集二十到五十个真实问题记录期望引用的文件和段落。样本要覆盖常见问法、缩写、旧称、跨段问题和权限差异。没有标注的样本只能看到系统返回了内容很难判断它是否找对。每个问题保留当时使用的查询、用户身份、资料版本、候选片段和最终答案。后续调整切分或模型时用同一批样本重跑才能知道变化来自哪里。“能返回一段内容”不能叫召回率。召回率需要已知相关答案集合并计算相关内容被找回的比例。数据还没标注时可以记录命中情况和人工判断但不要把它包装成正式检索指标。找到答案在哪一步消失拿一条失败问题把原文件和解析文本放在一起看。原页明明有答案解析结果里却缺了一列、少了表头或者整张扫描页没有被识别这时应当停在入库环节。切分长度和 Embedding 模型还没有参与继续调整只会绕远路。文件数量说明不了解析质量。抽几份真正会被提问的资料打开解析结果顺着标题往下读段落有没有串页表格还能不能对应页码和版本时间是否保留下来。检索真正处理的是解析文本人眼看到的 PDF 页面不会直接进入候选。同一个问题用管理员账号能命中换成普通账号却没有候选可以沿着权限过滤去查。普通账号若看到了超出权限的片段应先收紧资料范围再继续测试检索效果。确认答案已经进入索引后把失败问题对应的几个片段直接摊开。定义留在上一段适用条件被切到下一段表头单独成块数据行失去含义接口参数离开接口说明。看到这类断点比纠结切成 500 字还是 800 字更容易找到问题。资料结构不同切法也要跟着变。制度文件尽量保留标题层级FAQ 让问题和答案待在一起接口文档让参数表跟着对应接口。重叠窗口可以补回一点上下文开得太大前几名又可能被几段近似内容占满。最后打开检索候选。正确片段完全没有出现需要排查查询改写、过滤条件、关键词检索和向量检索正确片段已经出现只是排位靠后可以检查候选数量和重排。型号、编号、专有名词通常更依赖关键词口语问法和同义表达更依赖语义匹配。混合检索把两类信号放在一起具体权重仍要用失败样本来定。若正确片段已经排在前面最终回答仍然错误问题转到生成层。检查提示词是否要求基于资料回答模型有没有忽略日期和版本多个片段冲突时是否展示来源。把排查过程放进可重复的工作流ZGI 提供知识与数据接入、检索工作流和可自托管 Agent Runtime可用来组织资料、查询与回答链路。对这类平台做 PoC 时重点看能否查看解析文本、候选片段、来源和权限范围不能只看最终回答页面。在 ZGI 中可以把语义检索、混合检索和多语言能力接入同一条知识库工作流。准备一组带有期望答案的真实问题每次调整后重新运行观察正确片段能否进入候选前列。测试结果会更贴近企业自己的资料、权限和用户问法。排查时按四层建立记录资料是否存在片段是否完整候选是否命中回答是否忠于来源。每次只改一个变量再用同一批问题重跑。这样才能找到真正起作用的调整。GitHubhttps://github.com/zgiai/zgiGiteehttps://gitee.com/zgiai/zgi