服务端阅读 05月31日 17:20
Dify 知识库是怎么检索的？如何提升召回和答案准确率？
Dify 知识库的核心不是“把文档丢给大模型”，而是先把文档切成块、转成向量、存进检索系统，再在用户提问时找出最相关的片段交给模型生成回答。真正影响效果的通常有四件事：文档清洗是否干净、分块是否合适、Embedding 模型是否稳定、召回后的重排和提示词是否把边界说清楚。一个常见流程是：上传 PDF、Markdown、网页或纯文本后，Dify 会抽取正文，按规则切分为多个 chunk；每个 chunk 通过 Embedding 模型转成向量；用户提问也会转成查询向量；系统根据相似度召回片段，再把片段作为上下文传给 LLM。这里的取舍很明显：块太大，召回内容容易夹带无关信息；块太小，上下文被拆散，模型可能看不到完整结论。配置时可以先用一个保守起点：chunk size 设在 500-800 字符，overlap 设在 50-120 字符，Top K 设为 3-6，score threshold 不要一开始调得太高。中文资料建议优先选择中文语义表现稳定的 Embedding 模型，并用同一批 FAQ 做回归测试。不要只看“能不能回答”，还要看答案是否引用了正确段落、是否把过期制度和现行制度混在一起。追问为什么知识库检索效果差，明明文档里有答案却召回不到？最常见原因是切分把问题和答案拆开了，向量库里每个片段都只保留了一半语义。另一个原因是文档里有大量页眉、目录、免责声明，Embedding 被噪声稀释，查询向量自然匹配不到关键内容。实际排查时不要先换大模型，而要先看命中的 chunk，确认它是否真的包含答案。边界是：如果用户问的是需要推理、汇总或跨文档比较的问题，单纯提高 Top K 只能缓解，不能保证稳定。chunk size、overlap 和 Top K 应该怎么取舍？chunk size 决定每个片段的信息密度，overlap 决定上下文是否连续，Top K 决定给模型看的候选范围。产品手册、政策制度适合中等 chunk 加少量 overlap；代码文档、API 文档则更依赖标题层级和较小片段。Top K 太低会漏召回，太高会把不相关片段塞进上下文，让模型开始“综合发挥”。踩坑点是只调一个参数看效果，最好固定测试集后成组调整。Dify 里要不要开启混合检索或重排模型？如果知识库里有大量专有名词、编号、版本号或短问答，混合检索通常比纯向量检索更稳，因为关键词匹配能补上向量语义的盲区。重排模型适合候选片段多、内容相似度高的场景，它会在召回后重新排序，把真正相关的片段推到前面。代价是延迟和成本会上升，尤其在高并发客服场景里要评估响应时间。比较稳的做法是先用纯向量建立基线，再对高频失败问题开启重排做 A/B 对比。如何判断是知识库问题还是提示词问题？先看检索日志，如果召回片段里没有答案，就是知识库侧的问题；如果片段正确但模型答偏了，才重点看提示词和模型能力。提示词里最好明确“只能依据知识库回答，缺少依据时说明不知道”，否则模型会用通用知识补洞。这里的边界是用户问题本身含糊时，即使知识库没问题也可能召回泛化片段。实践里可以让答案带引用来源，这样业务方能快速判断问题出在检索还是生成。知识库上线后应该怎么持续优化？不要把知识库当一次性导入任务，它更像搜索系统，需要持续看命中率、无答案率和用户追问。每次业务制度更新后，要删除旧版本或加上有效期，否则模型可能同时看到两套冲突规则。高频失败问题可以反向补充 FAQ，用用户真实问法写标题和正文。踩坑最多的是只追加新文档不清理旧文档，短期看资料更多，长期看答案反而更乱。