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

RAGRetrieval-Augmented Generation检索增强生成经常被一句话概括成“先检索再回答”。这句话没有错但如果真的要把一个知识库调到可用仅仅理解这四个字还不够。真正影响答案质量的往往是 Dify 知识库配置页里的那些看似普通的参数chunk 怎么切、文本怎么清洗、索引用什么方式建、embedding 模型怎么选、检索时拿多少片段、要不要阈值、要不要 rerank。这篇文章不从抽象架构图开始而是从 Dify 的配置项出发把 RAG 的链路拆成一条因果线文档 - 清洗 - 切块 - 向量化 - 建索引 - 检索 - 拼上下文 - 生成回答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 决定文本优先按照什么符号或结构切开。常见配置是按空行切分\n\n按空行切分通常比按固定字符硬切更自然因为很多文档本来就是按段落组织的。对于教程、产品文档、制度说明、FAQ 这类材料段落边界往往就是语义边界。但 delimiter 不是越复杂越好。真正要看的是 Preview Chunk 的结果切出来的块是否保留了完整意思标题和正文有没有分离列表项有没有被拆散表格说明有没有丢失上下文Maximum chunk length每个 chunk 最多多长Maximum chunk length 控制单个 chunk 的最大长度。例如 PPT 中的示例配置是Maximum chunk length 1024 characterschunk 越短检索越容易命中非常具体的片段噪声也更少。但它的代价是上下文可能被切碎。一个答案需要的信息如果分散在多个 chunk 里就必须依赖 Top K 把它们一起召回。chunk 越长上下文越完整适合长上下文依赖强的材料。但它也会带来另一个问题一个 chunk 里可能混入很多无关文字相似度被稀释LLM 拿到上下文后也更容易受到无关内容干扰。一般可以把中等长度作为默认起点然后根据材料类型调整FAQ、字段说明、接口参数可以偏短。教程、操作手册、政策说明适合中等长度。需要前后文才能理解的报告、合同、长文档可以适当偏长。Chunk overlap给边界留缓冲Chunk overlap 表示相邻 chunk 之间共享多少文本。PPT 中的示例是Chunk overlap 50 charactersoverlap 的价值在于减少“答案正好跨段被切断”的风险。比如一个步骤的前半部分在 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 ModelRAG 的语义坐标系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 权重更高例如Semantic 0.7 Keyword 0.3如果资料包含大量编号、术语、API、错误码、产品型号可以提高 keyword 权重让精确匹配更有存在感。Hybrid Search 权重示意教程 / 制度 / 知识文章Semantic 70%Retrieval 参数控制上下文质量检索不是把“最相关的一段”拿回来就结束。Top K、Score Threshold、Weighted Score、Rerank Model 共同决定最终进入 prompt 的上下文质量。Top K最多拿回多少个候选 chunkTop K 表示最多取回多少个候选 chunk。例如Top K 3Top K 小噪声少prompt 更短成本更低。但如果答案需要多个片段拼起来Top K 太小就会缺上下文。Top K 大召回更全更容易覆盖跨段问题。但它也会带来更多噪声让 LLM 在无关内容里分心同时增加 prompt 长度和调用成本。一个常见起点是 3 到 5。对 FAQ 或短问答可以更小对教程、政策、长文档问答可以适当增大。Score Threshold低于阈值就不要Score Threshold 用来过滤相关性太低的结果。例如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 知识库可以先用一组保守默认值再根据测试集调整。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 的很多复杂环节做成了配置项但这些参数背后仍然是一条完整的因果链Chunk - Embedding - Index - Retrieval - Answerchunk 决定知识被拆成什么形状embedding 决定语义如何被比较index method 决定知识如何被查找retrieval setting 决定哪些片段进入上下文最后LLM 只能基于拿到的上下文生成答案。所以调 RAG 时不要只盯着最终回答。先看 chunk 预览再看召回结果最后才看生成质量。只要这条证据链稳定下来RAG 系统的回答质量、可解释性和可控性都会明显提升。