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