logo

很多人上传完文档，测试几条问题，发现回答驴唇不对马嘴，就把锅甩给大模型。其实多半是知识库配错了。Dify RAG 管道有七八个配置点，任何一个没调好都会影响最终质量。这章把每个参数讲清楚，顺带给一个调优流程。

Dify hybrid search and rerank architecture

RAG 管道的五个阶段

先建一个心智模型，知道问题出在哪一层才能对症下药：

文档上传 → 分块 (Chunking) → 向量化 (Indexing) → 检索 (Retrieval) → 重排 (Reranking) → 生成 (Generation)

分块决定你存进去的信息粒度，检索决定能召回什么，reranking 决定送给模型的是不是真正相关的内容。三个环节相互影响，不能只盯着一个。

---

分块模式：三选一，选错就从头来

分块结构一旦保存无法修改。上传文档前想清楚用哪种模式，改错了只能删掉重传。

通用模式（General）

默认选项，适合大多数场景：产品文档、新闻、博客、说明书。按分隔符（换行、段落）切块，可以指定最大块长度（通常 512-1000 token）和重叠长度（overlap，通常 50-100 token）。

段落 A（1000 token）
  ↓ 切割
块 1: 第 1-512 token
块 2: 第 462-974 token  ← 50 token 重叠确保上下文连续
块 3: 第 924-1000 token

overlap 不要设 0。没有重叠时，切块边界处的信息很容易被两个块各分走一半，单独看都不完整。通常设总块长的 10%。

父子模式（Parent-Child）— Dify v0.15.0+

父子模式解决的是"精准匹配"和"上下文丰富"的矛盾。

  • 子块（Child chunk）：小，几十到一两百 token，用于向量相似度匹配——短文本的 embedding 更精准
  • 父块（Parent chunk）：大，几百 token 或整篇文档，检索命中后送给 LLM——保留足够上下文

工作流程：用户问题 → 和子块做相似度匹配 → 找到子块 → 返回对应的父块给模型。

两种父块策略：

  • 段落模式：按段落分父块，父块相对独立，适合有清晰段落结构的技术文档
  • 全文档模式：整个文档作为一个父块，适合内容密度高、前后关联强的合同、报告

父子模式只支持 High Quality 索引，不支持 Economy 模式。

Q&A 模式

文档上传后，Dify 用 LLM 自动从每个段落生成若干问答对，存储的不是原文而是问答对。检索时用用户问题和这些预生成问题做匹配。

适合场景非常具体：FAQ 文档、产品客服知识库、帮助中心。用户通常直接问"怎么退货""发货多久"这类问题，和预生成问题的相似度非常高，召回精度远高于通用模式。

不适合：技术文档、合同文本、需要综合多个段落来回答的问题。

Q&A 模式只支持 High Quality，而且处理成本比通用模式高很多——每个段落都要调一次 LLM 生成问答对。文档量大的时候算一下 token 消耗再决定。

---

索引质量：High Quality vs Economy

| | High Quality | Economy | |---|---|---| | 索引方式 | 调用 embedding 模型向量化 | 倒排索引（关键词） | | 检索精度 | 高，理解语义 | 低，只做关键词匹配 | | 成本 | 按 token 计费 | 免费 | | 支持的检索模式 | 向量 / 全文 / 混合 | 仅全文 | | 支持父子/Q&A 模式 | ✅ | ❌ |

生产环境没有理由用 Economy。Embedding 的成本不高——1MB 的文档用 text-embedding-3-small 处理大概花几美分。Economy 存在是给本地测试用的。

---

检索模式配置

三种检索模式

向量检索（Vector Search）：把用户问题也向量化，计算和文档块的余弦相似度，返回语义最接近的块。能处理同义词和表达方式不同的情况，但对专有名词、产品型号这类需要精确匹配的词效果不好。

全文检索（Full-text Search）：BM25 算法，关键词匹配。对 SKU、命令名称、专有名词精准，但不理解语义。

混合检索（Hybrid Search）：两者都跑，结果合并后排序。生产环境默认选混合，几乎总比单一模式强。

混合检索有个权重参数 α（通常 0-1），控制向量分数和全文分数的比重：

final_score = α × vector_score + (1 - α) × keyword_score
  • α = 1：纯向量
  • α = 0：纯关键词
  • α = 0.5：各占一半（默认，大多数场景合适）

文档里专有名词多、精确查询多的场景把 α 调低；通用问答场景 α = 0.5 或稍高。

TopK 和 Score Threshold

TopK：检索阶段返回多少个块送给下游（reranker 或直接给 LLM）。默认通常是 5。

TopK 不是越大越好：

  • 太小：漏掉相关内容
  • 太大：送给 LLM 的 context 里噪声变多，而且吃 token

经验值：混合检索 TopK 设 5-10，如果接了 reranker 可以设 15-20 让 reranker 从更多候选里挑。

Score Threshold：低于这个分数的块直接过滤掉，不送给 LLM。

用 Score Threshold 要小心——设太高容易什么都检索不到。建议先把 threshold 设 0（不过滤），观察检索到的块的分数分布，再决定合理的下限。

---

Reranking：召回率的最后一关

Reranker 是一个独立的评分模型，接受（用户问题, 候选块）对，重新打分并排序，输出真正相关的 Top N 给 LLM。

它解决的问题：向量相似度不等于实际相关性。两段话向量很近，但未必都能回答当前问题。Reranker 做的是精排，代价是计算量更大，只适合在 TopK 候选集上跑。

可选的 Reranker 模型

Cohere Rerank 3：商业 API，精度高，直接在 Dify 模型设置里填 API key 接入。对英文效果最好，中文效果也可以接受。按每次 rerank 调用的文档数计费。

BGE Reranker（BAAI/bge-reranker-v2-m3）：开源模型，中英双语，可以自部署在 Ollama 或 vLLM 上，自部署后没有 API 费用。中文场景优先考虑这个。

Dify 里接入 BGE Reranker 的配置示意：

# 在 Dify 模型提供商里添加自部署 rerank 端点
model_type: rerank
model: BAAI/bge-reranker-v2-m3
endpoint: http://your-server:8080/rerank  # vLLM 或 xinference 部署

接入后在知识库的检索设置里勾选「启用 Reranking」，选择对应模型，设置：

  • Rerank TopK：从候选里最终保留多少个块给 LLM（通常 3-5）
  • Score Threshold：reranker 分数低于此值的块丢弃（可选）

Reranker 调用流程

用户问题
    ↓
混合检索 → TopK=15 个候选块
    ↓
Reranker 对 15 个候选重打分
    ↓
按 Reranker 分数排序，取 Top 5
    ↓
送给 LLM 生成答案

检索 TopK 设大（15-20），Reranker TopK 设小（3-5），让精排模型承担过滤职责。

---

实战调优流程

遇到知识库回答质量差，不要乱调参数，按这个顺序排查：

第一步：确认内容在知识库里

在知识库页面直接搜索关键词，看有没有召回结果。没有召回说明分块出了问题，或者文档根本没被正确解析（PDF 的图片内容、扫描件默认无法提取文字）。

# Dify 支持测试检索，在知识库详情页 → 召回测试

输入用户的问题，观察返回的块和分数

第二步：看召回块是否包含答案

召回了内容，但回答还是不对，看一下召回的块里有没有答案。

  • 有答案但没用：LLM 忽略了相关内容，可能是 context 太长、噪声太多，降低 TopK 或开启 reranker
  • 没有答案：分块切得太碎把相关信息分散了，换父子模式，或者调大块长度

第三步：针对文档类型选分块策略

| 文档类型 | 推荐分块模式 | 推荐检索模式 | |---------|------------|------------| | 产品 FAQ / 帮助中心 | Q&A 模式 | 向量或混合 | | 技术文档（有层级结构） | 父子模式（段落） | 混合 + Reranker | | 合同 / 长报告 | 父子模式（全文档） | 混合 + Reranker | | 新闻 / 博客文章 | 通用模式 | 混合 | | 产品目录 / 含 SKU | 通用模式 | 混合，α 偏向关键词 |

第四步：调整参数组合

一个在大多数场景表现稳定的配置：

分块模式: 父子模式（段落）
索引质量: High Quality
检索模式: 混合检索，α=0.5
检索 TopK: 15
Reranker: BGE-reranker-v2-m3（中文场景）或 Cohere Rerank 3（英文场景）
Reranker TopK: 5
Score Threshold: 0.3（先跑几轮再调）

这不是最优解，是个稳健的起点。根据你的文档类型和问答模式，每个参数都可能需要调整。

---

几个容易踩的坑

分块后不能改模式：选错了只能删重传，大文档要重新 embedding，代价不小。第一次上传小样本测试清楚再批量导入。

PDF 扫描件无法检索：扫描 PDF 里的文字是图片，Dify 默认不做 OCR。要么换成文字版 PDF，要么用支持 OCR 的 parser（Dify 的知识管道里可以配置）。

Reranker 和 Embedding 要语言匹配：用了中文 embedding 模型（比如 text-embedding-3-small 支持多语言），但 Reranker 选了只支持英文的版本，中文结果排序会乱。中文场景 Reranker 用 BGE 或 Cohere v3（支持多语言）。

知识库版本和应用绑定：一个知识库可以绑定多个 Dify 应用，更新文档后所有绑定的应用都会受影响。生产环境的知识库更新前先在测试应用里验证。

父子模式的索引成本：父子模式存了子块又存父块，索引存储量是通用模式的 2 倍左右。不是成本问题，但向量数据库容量要留余量。

JR Academy · Blog职业洞察

Dify 实战手册：用可视化拖拽搭建 AI 应用 — Dify RAG 知识库实战：分块策略、检索调优与 reranking

三种分块模式（通用/父子/Q&A）的选择逻辑、向量与混合检索参数调优、reranker 接入与 TopK 配置——系统性把召回率从 60% 拉到 90%+

发布日期
阅读时长2 分钟
作者

快速导航

很多人上传完文档，测试几条问题，发现回答驴唇不对马嘴，就把锅甩给大模型。其实多半是知识库配错了。Dify RAG 管道有七八个配置点，任何一个没调好都会影响最终质量。这章把每个参数讲清楚，顺带给一个调优流程。

Dify hybrid search and rerank architecture

RAG 管道的五个阶段

先建一个心智模型，知道问题出在哪一层才能对症下药：

文档上传 → 分块 (Chunking) → 向量化 (Indexing) → 检索 (Retrieval) → 重排 (Reranking) → 生成 (Generation)

分块决定你存进去的信息粒度，检索决定能召回什么，reranking 决定送给模型的是不是真正相关的内容。三个环节相互影响，不能只盯着一个。

---

分块模式：三选一，选错就从头来

分块结构一旦保存无法修改。上传文档前想清楚用哪种模式，改错了只能删掉重传。

通用模式（General）

默认选项，适合大多数场景：产品文档、新闻、博客、说明书。按分隔符（换行、段落）切块，可以指定最大块长度（通常 512-1000 token）和重叠长度（overlap，通常 50-100 token）。

段落 A（1000 token）
  ↓ 切割
块 1: 第 1-512 token
块 2: 第 462-974 token  ← 50 token 重叠确保上下文连续
块 3: 第 924-1000 token

overlap 不要设 0。没有重叠时，切块边界处的信息很容易被两个块各分走一半，单独看都不完整。通常设总块长的 10%。

父子模式（Parent-Child）— Dify v0.15.0+

父子模式解决的是"精准匹配"和"上下文丰富"的矛盾。

  • 子块（Child chunk）：小，几十到一两百 token，用于向量相似度匹配——短文本的 embedding 更精准
  • 父块（Parent chunk）：大，几百 token 或整篇文档，检索命中后送给 LLM——保留足够上下文

工作流程：用户问题 → 和子块做相似度匹配 → 找到子块 → 返回对应的父块给模型。

两种父块策略：

  • 段落模式：按段落分父块，父块相对独立，适合有清晰段落结构的技术文档
  • 全文档模式：整个文档作为一个父块，适合内容密度高、前后关联强的合同、报告

父子模式只支持 High Quality 索引，不支持 Economy 模式。

Q&A 模式

文档上传后，Dify 用 LLM 自动从每个段落生成若干问答对，存储的不是原文而是问答对。检索时用用户问题和这些预生成问题做匹配。

适合场景非常具体：FAQ 文档、产品客服知识库、帮助中心。用户通常直接问"怎么退货""发货多久"这类问题，和预生成问题的相似度非常高，召回精度远高于通用模式。

不适合：技术文档、合同文本、需要综合多个段落来回答的问题。

Q&A 模式只支持 High Quality，而且处理成本比通用模式高很多——每个段落都要调一次 LLM 生成问答对。文档量大的时候算一下 token 消耗再决定。

---

索引质量：High Quality vs Economy

| | High Quality | Economy | |---|---|---| | 索引方式 | 调用 embedding 模型向量化 | 倒排索引（关键词） | | 检索精度 | 高，理解语义 | 低，只做关键词匹配 | | 成本 | 按 token 计费 | 免费 | | 支持的检索模式 | 向量 / 全文 / 混合 | 仅全文 | | 支持父子/Q&A 模式 | ✅ | ❌ |

生产环境没有理由用 Economy。Embedding 的成本不高——1MB 的文档用 text-embedding-3-small 处理大概花几美分。Economy 存在是给本地测试用的。

---

检索模式配置

三种检索模式

向量检索（Vector Search）：把用户问题也向量化，计算和文档块的余弦相似度，返回语义最接近的块。能处理同义词和表达方式不同的情况，但对专有名词、产品型号这类需要精确匹配的词效果不好。

全文检索（Full-text Search）：BM25 算法，关键词匹配。对 SKU、命令名称、专有名词精准，但不理解语义。

混合检索（Hybrid Search）：两者都跑，结果合并后排序。生产环境默认选混合，几乎总比单一模式强。

混合检索有个权重参数 α（通常 0-1），控制向量分数和全文分数的比重：

final_score = α × vector_score + (1 - α) × keyword_score
  • α = 1：纯向量
  • α = 0：纯关键词
  • α = 0.5：各占一半（默认，大多数场景合适）

文档里专有名词多、精确查询多的场景把 α 调低；通用问答场景 α = 0.5 或稍高。

TopK 和 Score Threshold

TopK：检索阶段返回多少个块送给下游（reranker 或直接给 LLM）。默认通常是 5。

TopK 不是越大越好：

  • 太小：漏掉相关内容
  • 太大：送给 LLM 的 context 里噪声变多，而且吃 token

经验值：混合检索 TopK 设 5-10，如果接了 reranker 可以设 15-20 让 reranker 从更多候选里挑。

Score Threshold：低于这个分数的块直接过滤掉，不送给 LLM。

用 Score Threshold 要小心——设太高容易什么都检索不到。建议先把 threshold 设 0（不过滤），观察检索到的块的分数分布，再决定合理的下限。

---

Reranking：召回率的最后一关

Reranker 是一个独立的评分模型，接受（用户问题, 候选块）对，重新打分并排序，输出真正相关的 Top N 给 LLM。

它解决的问题：向量相似度不等于实际相关性。两段话向量很近，但未必都能回答当前问题。Reranker 做的是精排，代价是计算量更大，只适合在 TopK 候选集上跑。

可选的 Reranker 模型

Cohere Rerank 3：商业 API，精度高，直接在 Dify 模型设置里填 API key 接入。对英文效果最好，中文效果也可以接受。按每次 rerank 调用的文档数计费。

BGE Reranker（BAAI/bge-reranker-v2-m3）：开源模型，中英双语，可以自部署在 Ollama 或 vLLM 上，自部署后没有 API 费用。中文场景优先考虑这个。

Dify 里接入 BGE Reranker 的配置示意：

# 在 Dify 模型提供商里添加自部署 rerank 端点
model_type: rerank
model: BAAI/bge-reranker-v2-m3
endpoint: http://your-server:8080/rerank  # vLLM 或 xinference 部署

接入后在知识库的检索设置里勾选「启用 Reranking」，选择对应模型，设置：

  • Rerank TopK：从候选里最终保留多少个块给 LLM（通常 3-5）
  • Score Threshold：reranker 分数低于此值的块丢弃（可选）

Reranker 调用流程

用户问题
    ↓
混合检索 → TopK=15 个候选块
    ↓
Reranker 对 15 个候选重打分
    ↓
按 Reranker 分数排序，取 Top 5
    ↓
送给 LLM 生成答案

检索 TopK 设大（15-20），Reranker TopK 设小（3-5），让精排模型承担过滤职责。

---

实战调优流程

遇到知识库回答质量差，不要乱调参数，按这个顺序排查：

第一步：确认内容在知识库里

在知识库页面直接搜索关键词，看有没有召回结果。没有召回说明分块出了问题，或者文档根本没被正确解析（PDF 的图片内容、扫描件默认无法提取文字）。

# Dify 支持测试检索，在知识库详情页 → 召回测试

输入用户的问题，观察返回的块和分数

第二步：看召回块是否包含答案

召回了内容，但回答还是不对，看一下召回的块里有没有答案。

  • 有答案但没用：LLM 忽略了相关内容，可能是 context 太长、噪声太多，降低 TopK 或开启 reranker
  • 没有答案：分块切得太碎把相关信息分散了，换父子模式，或者调大块长度

第三步：针对文档类型选分块策略

| 文档类型 | 推荐分块模式 | 推荐检索模式 | |---------|------------|------------| | 产品 FAQ / 帮助中心 | Q&A 模式 | 向量或混合 | | 技术文档（有层级结构） | 父子模式（段落） | 混合 + Reranker | | 合同 / 长报告 | 父子模式（全文档） | 混合 + Reranker | | 新闻 / 博客文章 | 通用模式 | 混合 | | 产品目录 / 含 SKU | 通用模式 | 混合，α 偏向关键词 |

第四步：调整参数组合

一个在大多数场景表现稳定的配置：

分块模式: 父子模式（段落）
索引质量: High Quality
检索模式: 混合检索，α=0.5
检索 TopK: 15
Reranker: BGE-reranker-v2-m3（中文场景）或 Cohere Rerank 3（英文场景）
Reranker TopK: 5
Score Threshold: 0.3（先跑几轮再调）

这不是最优解，是个稳健的起点。根据你的文档类型和问答模式，每个参数都可能需要调整。

---

几个容易踩的坑

分块后不能改模式：选错了只能删重传，大文档要重新 embedding，代价不小。第一次上传小样本测试清楚再批量导入。

PDF 扫描件无法检索：扫描 PDF 里的文字是图片，Dify 默认不做 OCR。要么换成文字版 PDF，要么用支持 OCR 的 parser（Dify 的知识管道里可以配置）。

Reranker 和 Embedding 要语言匹配：用了中文 embedding 模型（比如 text-embedding-3-small 支持多语言），但 Reranker 选了只支持英文的版本，中文结果排序会乱。中文场景 Reranker 用 BGE 或 Cohere v3（支持多语言）。

知识库版本和应用绑定：一个知识库可以绑定多个 Dify 应用，更新文档后所有绑定的应用都会受影响。生产环境的知识库更新前先在测试应用里验证。

父子模式的索引成本：父子模式存了子块又存父块，索引存储量是通用模式的 2 倍左右。不是成本问题，但向量数据库容量要留余量。

作者
一键分享或复制链接

相关文章推荐

Opus 4.7+SpaceX 算力 / DeepSeek 500 亿 / DeepMind 破数学难题 / 百度文心 5.1 / Meta 裁员被诉

GitHub Copilot 实战指南 — 常见问题、定价与选型建议

GitHub Copilot 实战指南 — 进阶玩法：Coding Agent、自定义指令与 MCP

GitHub Copilot 实战指南 — 核心功能深度解析：补全、Chat 与 Agent Mode

GitHub Copilot 实战指南 — 快速上手：注册免费版 + 第一次 AI 编程

GitHub Copilot 实战指南 — GitHub Copilot 是什么：全球最大的 AI 编程助手

查看全部文章 →