Dify 知识库检索不准怎么排查：从切块到重排的五个环节
「文档明明传进去了，一问就答非所问」——这是知识库落地时最常见的问题，也是最容易被归因错的问题。
大部分人的第一反应是换个更强的模型。但检索不准，问题基本不在生成环节。模型只能基于给它的材料回答，如果检索出来的片段本身就不对，再强的模型也只是把错误材料复述得更流畅。
这篇按检索链路逐环节拆，讲每一步会出什么问题、怎么验证。
Dify 的界面和选项会随版本调整，本文讲的是机制和排查思路，具体设置项以官方文档为准。
先做一件事：把检索结果单独看
排查的第一步不是调参数，而是把检索和生成分开看。
Dify 提供了检索测试的能力——输入一个问题，直接看召回了哪些片段，不经过模型生成。这一步能立刻把问题定位到一半：
- 召回的片段里根本没有正确答案 → 问题在检索环节，往下看第一到第四节
- 召回的片段里有正确答案，但回答还是错的 → 问题在生成环节，看第五节
跳过这一步直接调参数，基本是在瞎试。
环节一：文档有没有被正确解析
这是最底层、也最容易被忽略的一环。
PDF 是重灾区。扫描版 PDF 本质上是图片，没有文字层，解析出来可能是空的或者是乱码。你以为传进去了，其实系统什么也没读到。
Word 文档里的表格、页眉页脚、脚注，解析后的形态可能和你在编辑器里看到的完全不同。表格尤其麻烦——一个二维表被拉平成一行文字之后，行列关系就丢了，「张三的电话是多少」这种问题自然答不出来。
怎么验证：在知识库里直接看文档解析后的分段内容。如果你看到的是乱码、空白，或者表格被拉成了一串没有分隔的文字，那后面所有的调优都是徒劳。
怎么处理：扫描件先做 OCR。表格类内容，如果量不大，手工转成问答形式的文本，效果会比让系统猜好得多。
环节二：切块策略对不对
这是最被低估、也最能拉开效果差距的一环。
切块要解决的矛盾很简单：切得太碎，一个完整的意思被拆散，检索到半句话没有用；切得太大，一个片段里混了好几个主题，检索时相似度被稀释，而且塞进模型的无关内容变多。
不同类型的文档，合适的切法完全不同：
- 规章制度、技术规范：有清晰的条目结构，按条目切最合适。硬按固定长度切会把一条规定拦腰截断。
- FAQ、问答手册：本身就是一问一答，一组问答就是一个自然的块。
- 叙述型长文：按段落或语义切，但要注意上下文依赖——一段开头写着「上述三种情况」，单独拿出来就没法读了。
怎么验证：随便挑几个分段读一读。如果一个分段单独拿出来你自己都读不懂，模型也读不懂。 这个朴素的标准比任何参数都管用。
这里有个判断方案是否靠谱的关键指标：一个知识库方案能不能自己调切块策略。如果只能按固定长度切、没有任何调整余地，那它在结构化文档上的效果会明显受限。
环节三：嵌入模型合不合适
嵌入模型决定了「什么样的文本算意思相近」。
中文场景下这一环的影响比很多人以为的大，特别是专业术语密集的领域。通用嵌入模型可能不理解你行业里的黑话——两个在你看来是同义词的术语，在模型的向量空间里可能离得很远。
典型症状：用文档里的原话去问能查到，换个说法问就查不到了。这说明模型没有建立起同义关系。
怎么处理：换嵌入模型试试，中文场景优先试中文语料训练充分的。另一个更省事的办法是在文档里补上同义表述——直接把行业黑话和标准说法写在一起，比调模型见效快。
环节四：检索参数与检索方式
到这一步才轮到调参数，而且能调的空间其实不大。
召回数量：召回太少，正确答案可能就在第四条而你只取了前三条；召回太多，噪音进来了，模型容易被无关内容带偏。这是个需要按实际情况试的平衡点。
相似度阈值：设得太高，稍微换个说法就召回不到；设得太低，什么都能召回，等于没过滤。
检索方式：向量检索擅长理解语义，但对精确的专有名词、编号、型号不敏感——你问「XX-2024 号文件」，向量检索可能给你一堆语义相近但编号不对的东西。全文检索正好相反，认字面不认语义。两者结合通常比单用一种好。
重排序：在召回之后再做一轮排序，把最相关的顶上来。当你发现「正确答案确实被召回了，但排在很后面」时，这一步的价值最明显。
环节五：召回是对的，回答还是错
如果检索测试显示正确片段被召回了，问题就在生成环节。常见原因有三个：
上下文太长，关键信息被淹没。 召回了十个片段，正确答案在第七个，模型可能没抓住重点。减少召回数量或者加重排序。
提示词没有约束模型只用给定材料回答。 模型会自己发挥，把训练时学到的通用知识混进来。需要在提示词里明确要求「只依据提供的资料回答，资料里没有就说不知道」。
材料本身自相矛盾。 新旧两版制度都在知识库里，模型不知道该信哪个。这不是技术问题，是知识库管理问题——过期文档就该删掉。
有些问题调参数解决不了
说完能调的，说说调不动的。以下几种情况，再怎么调也到不了可用状态：
需要跨多个文档做推理的问题。 「对比一下 A 部门和 B 部门的报销标准有什么不同」——这需要分别检索、理解、对比。检索机制本身是找相似片段，不是做分析。这类需求要在应用层设计流程，不是调知识库参数。
答案不在文档里，而在人的经验里。 这是知识库的前提问题：你要先把知识写下来。很多组织真正的问题是知识从来没被记录过，上系统只是把这个问题暴露出来了。
数据不能出网。 Dify 可以自部署，但如果你配置的是在线大模型，提问和召回的片段仍然要发给模型厂商——数据依然出网。要做到全链路不出内网，模型也必须是本地部署的。这一点经常被「自部署」三个字掩盖过去，值得单独确认。
关于什么情况下平台层面已经不够用、需要转向定制开发，我们单独写了一篇：低代码 Agent 平台的能力边界。
排查顺序小结
按这个顺序走，别跳步：
- 用检索测试把问题定位到检索还是生成
- 看文档解析后的实际内容，确认没有乱码和结构丢失
- 读几个分段，确认单独拿出来能读懂
- 换个说法提问，判断是不是嵌入模型的问题
- 最后才调召回数量、阈值、检索方式和重排序
前三步能解决大部分问题，而它们都不需要调任何参数。