从 Dify 配置页理解 RAG 的重要参数

RAG（Retrieval-Augmented Generation，检索增强生成）经常被一句话概括成"先检索，再回答"。这句话没有错，但如果真的要把一个知识库调到可用，仅仅理解这四个字还不够。真正影响答案质量的，往往是 Dify 知识库配置页里的那些看似普通的参数：chunk 怎么切、文本怎么清洗、索引用什么方式建、embedding 模型怎么选、检索时拿多少片段、要不要阈值、要不要 rerank。

这篇文章不从抽象架构图开始，而是从 Dify 的配置项出发，把 RAG 的链路拆成一条因果线：

text 复制代码

文档 -> 清洗 -> 切块 -> 向量化 -> 建索引 -> 检索 -> 拼上下文 -> 生成回答

RAG 链路总览
文档
清洗
切块
向量化
建索引
检索
拼上下文
回答

如果只记住一个原则，那就是：先让资料变成好的 chunk，再让检索拿回好的 chunk，最后让 LLM 只基于好的上下文回答。

先建立心智模型：RAG 分成两段流程

RAG 可以分成离线建库和在线检索两段。

离线建库发生在用户提问之前。你把文档上传到知识库，系统会清洗文本、切分 chunk、调用 embedding model 把文本转成向量，再把这些内容写入索引。这个阶段的核心问题是：资料有没有被切成合适的证据单元？向量能不能表达文本语义？索引能不能支持后续快速查找？

在线检索发生在用户提问之后。系统会把问题也转成可检索的形式，从知识库里找回 Top K 个候选片段，必要时做过滤、加权或 rerank，然后把这些片段拼进 prompt，让 LLM 生成回答。这个阶段的核心问题是：召回是否全面？噪声是否过多？拿回来的文本是否真的能回答问题？

很多 RAG 问题不是模型"不会回答"，而是模型根本没有拿到正确上下文。Dify 配置页里的参数，本质上都在影响这两段流程的质量、成本和可控性。
离线建库 vs 在线检索

离线建库

把资料变成可检索知识。重点看清洗是否保留实体、chunk 是否能独立成为证据、embedding 和索引是否稳定。

在线检索

用用户问题拿回上下文。重点看 Top K 是否足够、噪声是否过多、阈值和重排是否把真正相关片段放到前面。

Chunk Settings：定义检索的最小证据单元

切块不是简单地"把文档切小"。它是在定义检索系统未来能拿回来的最小证据单元。

一个好的 chunk 应该像一张可以被引用的小卡片：它有足够上下文，能独立支撑一个回答片段；同时又不会把太多主题混在一起，导致检索命中后带来噪声。
Chunk 粒度取舍
小块：精准但碎 适合 FAQ、字段说明、短问答。风险是跨段答案需要依赖 Top K 拼回来。
中块：默认起点 适合教程、政策、产品说明。通常以段落或小节作为语义单元。
大块：完整但噪 适合上下文依赖强的材料。风险是无关文字会稀释相似度。

Delimiter：按什么边界切

Delimiter 决定文本优先按照什么符号或结构切开。常见配置是按空行切分：

text 复制代码

\n\n

按空行切分通常比按固定字符硬切更自然，因为很多文档本来就是按段落组织的。对于教程、产品文档、制度说明、FAQ 这类材料，段落边界往往就是语义边界。

但 delimiter 不是越复杂越好。真正要看的是 Preview Chunk 的结果：切出来的块是否保留了完整意思？标题和正文有没有分离？列表项有没有被拆散？表格说明有没有丢失上下文？

Maximum chunk length：每个 chunk 最多多长

Maximum chunk length 控制单个 chunk 的最大长度。例如 PPT 中的示例配置是：

text 复制代码

Maximum chunk length = 1024 characters

chunk 越短，检索越容易命中非常具体的片段，噪声也更少。但它的代价是上下文可能被切碎。一个答案需要的信息如果分散在多个 chunk 里，就必须依赖 Top K 把它们一起召回。

chunk 越长，上下文越完整，适合长上下文依赖强的材料。但它也会带来另一个问题：一个 chunk 里可能混入很多无关文字，相似度被稀释，LLM 拿到上下文后也更容易受到无关内容干扰。

一般可以把中等长度作为默认起点，然后根据材料类型调整：

FAQ、字段说明、接口参数：可以偏短。
教程、操作手册、政策说明：适合中等长度。
需要前后文才能理解的报告、合同、长文档：可以适当偏长。

Chunk overlap：给边界留缓冲

Chunk overlap 表示相邻 chunk 之间共享多少文本。PPT 中的示例是：

text 复制代码

Chunk overlap = 50 characters

overlap 的价值在于减少"答案正好跨段被切断"的风险。比如一个步骤的前半部分在 Chunk A，注意事项在 Chunk B，如果完全没有 overlap，检索可能只拿回其中一半。适度 overlap 能让边界附近的信息被两个 chunk 同时携带。

overlap 也不是越大越好。过大的 overlap 会让索引里出现大量重复内容，增加存储和检索成本，还可能让多个高度相似的 chunk 同时被召回，挤占真正有价值的候选位置。

一个实用判断标准是：每个 chunk 是否能独立回答一个小问题？如果经常缺前因后果，优先增大 chunk length 或 overlap；如果经常命中一大段但答案不聚焦，优先缩短 chunk。

Text Pre-processing：先清掉检索噪声

预处理发生在切块之前。它的目的不是把文本变得"干净漂亮"，而是减少会干扰检索的格式噪声，同时保留用户可能会问到的实体信息。

Dify 里常见的预处理选项包括把连续空格、换行、制表符统一处理。这类选项通常适合开启，尤其是资料来自网页、PDF、Word 或复制粘贴内容时，原始文本里经常有很多无意义的换行和缩进。

但有些清理项要谨慎，例如删除所有 URL 和邮箱地址。URL、邮箱、编号、API path、产品型号、错误码，这些看起来不像自然语言，却可能正是用户要查询的答案。

经验法则可以这样记：

会妨碍语义理解的格式噪声，应该清理。
用户可能会按原样提问或需要原样引用的实体，不要轻易删除。
对产品文档、API 文档、客服资料来说，链接、邮箱、编号经常是答案的一部分。

如果预处理误删了关键实体，后面无论 embedding、Top K、rerank 怎么调，都很难把不存在的信息召回来。
预处理判断
应该清理 连续空格、无意义换行、复制粘贴带来的制表符和版式噪声。
谨慎删除 URL、邮箱、编号、API path、错误码、产品型号等可被用户直接查询的实体。
先看命中 如果实体搜不到，先回到预处理和 chunk 预览，不要急着调生成模型。

Index Method：决定知识库如何被查找

Index Method 决定知识库用什么方式支持检索。原始文档本身不能直接高效回答问题，它需要先变成可检索的索引。

可以把索引理解成两类能力的组合。

第一类是语义检索能力。系统把 chunk 转成向量，用户问题也转成向量，然后比较二者在向量空间里的距离。这样即使用户没有使用文档里的原词，只要意思接近，也有机会命中。

第二类是关键词检索能力。系统保留文本、术语、编号、专有名词等关键词索引，用户问题里出现精确词时，可以更稳定地找到对应内容。

企业知识库里经常同时需要这两种能力。员工问"怎样调整召回数量"，语义检索可能命中 "Top K 表示召回数量"；但员工问"ERR_AUTH_401 怎么处理"，关键词和编号匹配往往更可靠。
两类检索能力

语义检索

更擅长处理同义表达、口语问题和"意思接近但词不一样"的查询。

关键词检索

更擅长处理错误码、接口名、编号、型号、法规条款等需要精确命中的查询。

Embedding Model：RAG 的语义坐标系

Embedding model 会把文本压缩成高维数字向量。数字本身不可读，但向量之间的距离代表语义接近程度。

可以把它想象成一个语义坐标系：文档 chunk 在这个坐标系里有位置，用户问题也有位置。检索时，系统会找离问题最近的一批 chunk。

这带来三个重要结论。

第一，文档和问题需要放在同一个语义空间里比较。通常同一知识库的文档索引和查询向量应该使用兼容的 embedding 模型。

第二，换 embedding model 往往不是只改一个下拉框。因为旧文档的向量是用旧模型生成的，换模型后通常需要重新处理文档索引。

第三，相似度高不等于答案一定正确。Embedding 只能说明"这段文本看起来可能相关"，后面仍然需要 Top K、Score Threshold、Rerank 和 prompt 约束来共同保证答案质量。

选择 embedding model 时，不只看模型名字，还要看语言能力、成本、向量维度、延迟，以及它是否适合你的文档类型。中文知识库尤其要关注模型对中文语义、专有名词和中英混合文本的表现。

Retrieval Setting：关键词、语义和混合检索

检索方式决定在线阶段如何从知识库里拿回候选 chunk。Dify 常见的方式可以理解为三类。

Vector Search：向量检索

Vector Search 会把用户问题转成向量，然后找语义最接近的 chunk。它的优势是能处理同义表达、口语表达和不完全匹配的问题。

例如文档里写的是"Top K 表示召回数量"，用户问的是"怎么让系统多找几段上下文"，向量检索仍然可能命中相关 chunk。

它的风险是对精确实体不一定稳定。错误码、订单号、接口名、型号、版本号这些内容，有时并不依赖语义相似，而是依赖精确匹配。

Full-Text Search：全文检索

Full-Text Search 更接近传统搜索，按关键词、术语、编号、专有名词匹配。它的优势是精确词更稳，尤其适合 API 文档、运维手册、错误码、型号、法规条款等材料。

它的弱点是对同义改写不够敏感。如果用户不用文档里的原词，全文检索可能召回不到。

Hybrid Search：混合检索

Hybrid Search 会同时使用语义检索和关键词检索，再通过合并、加权或重排得到最终结果。对于企业知识库，它通常是一个很好的默认起点。

混合检索里的 semantic weight 和 keyword weight 不是在判断"哪个技术更高级"，而是在回答一个更实际的问题：这个知识库更依赖语义相似，还是更依赖精确词命中？

如果资料是教程、制度、知识文章，可以让 semantic 权重更高，例如：

text 复制代码

Semantic = 0.7
Keyword = 0.3

如果资料包含大量编号、术语、API、错误码、产品型号，可以提高 keyword 权重，让精确匹配更有存在感。
Hybrid Search 权重示意
教程 / 制度 / 知识文章Semantic 70%

Retrieval 参数：控制上下文质量

检索不是把"最相关的一段"拿回来就结束。Top K、Score Threshold、Weighted Score、Rerank Model 共同决定最终进入 prompt 的上下文质量。

Top K：最多拿回多少个候选 chunk

Top K 表示最多取回多少个候选 chunk。例如：

text 复制代码

Top K = 3

Top K 小，噪声少，prompt 更短，成本更低。但如果答案需要多个片段拼起来，Top K 太小就会缺上下文。

Top K 大，召回更全，更容易覆盖跨段问题。但它也会带来更多噪声，让 LLM 在无关内容里分心，同时增加 prompt 长度和调用成本。

一个常见起点是 3 到 5。对 FAQ 或短问答可以更小；对教程、政策、长文档问答可以适当增大。

Score Threshold：低于阈值就不要

Score Threshold 用来过滤相关性太低的结果。例如：

text 复制代码

Score Threshold = 0.5

阈值越高，检索越保守，进入上下文的内容更少但更可靠。阈值越低，召回更宽松，更容易找到边缘相关内容，但噪声也会增加。

如果你的机器人经常引用明显不相关的片段，可以考虑打开或提高 Score Threshold。如果它经常回答"没有找到相关信息"，但你确认知识库里有答案，就可能需要降低阈值或检查 chunk、embedding、关键词权重。

Weighted Score：手动控制语义和关键词倾向

Weighted Score 通常出现在混合检索中，用于按权重融合向量分数和关键词分数。它适合你已经知道知识库特征，并希望手动控制检索倾向的场景。

例如教程类文档更依赖语义理解，可以提高 semantic 权重；错误码和接口文档更依赖精确命中，可以提高 keyword 权重。

调权重时不要只看一次命中结果。最好准备一组典型问题，覆盖普通问法、同义改写、编号查询、专有名词查询，再看整体效果。

Rerank Model：用额外模型重排候选结果

Rerank Model 会在初步召回后，用额外模型重新判断候选 chunk 和问题的相关性。它通常比单纯向量相似度更准确，尤其适合高价值问答、候选片段很多、相似文本容易混淆的场景。

代价也很明确：更慢，更贵，链路更复杂。因此 rerank 不是所有知识库都必须开启。可以先用混合检索、Top K 和阈值把基础效果调稳；如果仍然存在相似片段排序不准的问题，再考虑 rerank。
检索参数影响面
Top K 控制召回数量。增大它通常能补上下文，但也会把更多噪声放进 prompt。
Score Threshold 控制最低相关性。提高它会更保守，降低它会更容易召回边缘内容。
Rerank 控制候选排序质量。更准，但更慢、更贵，适合高价值问答。

按症状调参：不要一次调所有参数

RAG 调参最忌讳一次改很多配置。更稳的方法是先观察症状，再定位它属于哪一段链路。
症状到参数的定位图
缺上下文 优先看 Top K、chunk length、overlap，以及 chunk 是否能独立成为证据。
噪声太多 优先看 Top K 是否过大、Score Threshold 是否太低、是否需要 rerank。
实体搜不到 优先看预处理是否误删实体，再看 keyword 权重和全文检索命中。

症状一：答案总是缺上下文

这通常说明召回不够全，或者 chunk 切得太碎。

可以按这个顺序尝试：

先增大 Top K，让系统拿回更多候选 chunk。
如果仍然缺上下文，检查 Preview Chunk，看一个 chunk 是否能独立表达完整证据。
如果 chunk 太碎，增大 maximum chunk length 或 chunk overlap。
如果答案依赖多个章节，考虑让文档结构更清晰，例如保留标题、编号和小节上下文。

症状二：答案引用了不相关片段

这通常说明召回噪声太多，或者排序不够准。

可以按这个顺序尝试：

降低 Top K，减少进入 prompt 的候选数量。
打开或提高 Score Threshold，过滤低相关片段。
如果是混合检索，调整 semantic 和 keyword 权重。
如果相似片段很多、排序经常错，再考虑开启 Rerank Model。

症状三：专有名词、编号、URL 搜不到

这通常不是 LLM 的问题，而是精确实体在预处理、切块或检索权重中被削弱了。

可以按这个顺序尝试：

检查预处理是否删除了 URL、邮箱、编号、错误码或 API path。
检查 chunk 是否把实体和解释切到了不同片段里。
在 Hybrid Search 中提高 keyword 权重。
准备包含专有名词和编号的测试问题，确认全文检索是否能稳定命中。

一个实用的默认起点

如果你刚开始配置 Dify 知识库，可以先用一组保守默认值，再根据测试集调整。

text 复制代码

Delimiter: 按段落或空行切分
Maximum chunk length: 800 到 1200 characters
Chunk overlap: 50 到 100 characters
Index method: Hybrid Search
Semantic weight: 0.6 到 0.8
Keyword weight: 0.2 到 0.4
Top K: 3 到 5
Score Threshold: 先关闭或设置为较宽松阈值，再根据噪声逐步提高
Rerank Model: 基础检索稳定后再评估是否开启

这不是标准答案，而是调试起点。真正的标准答案来自你的文档类型、用户问题和实际命中结果。

结论：RAG 的关键不是"接上知识库"，而是让证据链稳定

Dify 把 RAG 的很多复杂环节做成了配置项，但这些参数背后仍然是一条完整的因果链：

text 复制代码

Chunk -> Embedding -> Index -> Retrieval -> Answer

chunk 决定知识被拆成什么形状；embedding 决定语义如何被比较；index method 决定知识如何被查找；retrieval setting 决定哪些片段进入上下文；最后，LLM 只能基于拿到的上下文生成答案。

所以调 RAG 时，不要只盯着最终回答。先看 chunk 预览，再看召回结果，最后才看生成质量。只要这条证据链稳定下来，RAG 系统的回答质量、可解释性和可控性都会明显提升。