#知识库

知识库是 Dify 的 RAG 层：把文档切成块、做成向量（或倒排索引），再在问答时检索相关片段塞进提示词。思想与 LangChain RAG 相同——Loader → Split → Embed → Retrieve → Generate——只是 Dify 把流水线收成控制台流程，而不是 Python 类。

flowchart LR
  U[上传文档] --> C[分块]
  C --> E[Embedding / 索引]
  E --> V[向量库等]
  Q[用户问题] --> R[检索]
  V --> R
  R --> P[作为上下文]
  P --> M[LLM]
  M --> A[回答 + 引用]

界面分区名称随版本微调；下面按流程讲，不依赖某一版按钮原文。

#创建与导入

在 Knowledge 里新建知识库，然后导入数据。常见来源：

• 本地文件（PDF、Markdown、TXT 等，具体格式以当前版本文档为准）
• 网页导入、Notion 同步（需授权）
• 高级：知识流水线（Knowledge Pipeline） 自己编排解析；或 外部知识库 API 对接已有 RAG

第一份知识库用「本地上传一份你自己写的 FAQ / 制度说明」最容易验收：里面要有网上搜不到的专有名词或虚构条款，否则你分不清模型是在检索还是在背训练数据。

#分块、索引、检索（概念）

上传后进入处理配置，通常要决定三件事：

1. 分块模式

块太大：检索噪声多。块太碎：答案缺上下文。预览里应能看到切出来的段落，先扫一遍有没有把表格或标题切烂。

2. 索引方法

混合检索会同时做向量与全文，再按权重或 Rerank 模型 合并。关键词型制度条文可加大全文权重；同义改写多的问题加大语义权重。

3. 检索过滤

常见旋钮：Top K（取几段）、Score 阈值（太低的丢掉）。工作流里的 Knowledge Retrieval 节点还有第二层设置：知识库先粗召回，节点再裁一次。多知识库时先各库检索再合并。

处理完成后，用知识库自带的 检索测试：只问文档里有、模型不该猜的事实。召回空或全错，先调分块与混合权重，再改应用提示词。

#接到应用

提示词里写明：只根据检索到的资料回答；没有依据就说不知道；列出引用。 Dify 会把命中片段作为上下文，回答里常带引用来源（具体展示方式随 Web App / 节点配置而变）。不要在提示词里假装「已经有全文」——模型只能看见被检索进来的块。

#质量与运维

与 LangChain 对照：Dify 的「知识库设置」≈ VectorStore + Retriever 配置；「Knowledge Retrieval 节点」≈ 链上的 retriever 步骤；Agent 挂知识库 ≈ 把检索做成工具让模型决定何时调用。

#常见问题

一直处理中？ 看 Embedding 供应商额度与 worker 容器是否健康。

能检索、回答却跑偏？ 提高阈值、减小 K、提示词加「禁止使用未引用知识」。

引用对、结论错？ 块里信息不足或被截断，改 Parent-child 或增大块。

#下一步

• 工作流
• 实战案例
• LangChain RAG