Dify 中级实验（11）：高级 RAG 流水线——如何搭建多路检索与精排？

Dify 中级实验11高级 RAG 流水线——如何搭建多路检索与精排Dify 实验系列 · 中级 11/20 | 实验编号DIFY-102-12基于 Dify 1.16.1 实测2026-081. 业务场景先讲一个我们实际遇到的场景。一家做企业级软件的厂商产品手册、API 文档、FAQ 加起来上千页。客户和一线客服每天都在问同样的问题「如何配置 API 密钥」「重置密码后 API 还能用吗」——这些问题原本要人工翻文档回答于是他们搭了一个知识库问答机器人。结果机器人上线后客服反馈「还不如我自己翻文档」问「API 密钥在哪配」它答非所问问个跨章节的综合问题它只引用了一部分资料最要命的是有些回答看起来头头是道实际是模型自己编的。我们第一次接这类需求时第一反应也是「换个更强的模型试试」。真正动手把链路拆开才发现——模型是无辜的检索链路才是瓶颈召回、去重、精排、裁剪每一环欠一点优化喂给模型的上下文就差一截模型再强也答不对。这不是个例。任何「文档量大、问题五花八门、回答必须可溯源」的场景都是这个模式企业内部 SOP 查询、合规条款检索、产品支持门户、医疗法律知识问答……单条检索链路解决不了这些问题真正要解决的是「怎么把检索质量拆开、逐环节优化」。2. 场景痛点这个场景的痛点在这家厂商的客服团队身上体现得最直接单路检索召回不全用户换个说法提问就搜不到。问「如何配置 API 密钥」检索走的是一套关键词匹配而文档里写的是「API Key 申请流程」——语义对得上、字面对不上相关文档根本没被召回回答自然跑偏。排序不准捡了芝麻丢了西瓜多路检索召回来的文档相关的那篇排在后面LLM 优先引用了不相关的段落答案质量直接崩。客服为了确认一个答案往往要自己再翻一遍原文。回答不可信、不敢用LLM 基于残缺的上下文自由发挥编出来的答案客服不敢直接转述给客户机器人的存在反而增加了核对成本。上下文窗口撑爆多路召回的文档全塞进提示词一次回答消耗的 Token 成倍上涨长文档场景甚至直接超出上下文限制运行报错。本质上「答非所问、引用不可信」不是 LLM 的问题而是检索链路每一环都欠优化——召回、去重、精排、裁剪、溯源任何一环弱答案质量就崩。3. 方案为什么是高级 RAG 流水线Dify 工作流里可以用节点把「检索质量」拆成一条可逐环优化的流水线Query 改写 → 三路并行检索 → 合并去重 → Rerank 精排 → 上下文窗口裁剪 → 带引用溯源回答。选它的理由检索环节可独立调优每条检索路、每个 top_k、每道去重逻辑都是独立节点坏哪一环就单独修哪一环不用推翻整条链路重来代码节点兜住 LLM 的不稳定LLM 改写查询、输出 JSON 都不稳定解析失败有代码节点兜底回退合并去重、窗口裁剪这些确定性逻辑全部交给代码节点稳定可控回答可溯源最终生成环节强制 LLM「只基于文档回答 标注来源序号」回答质量可核查、可追责。这篇文章我们就用它搭一个「技术文档问答系统」用户提问后系统改写问题生成 3 个检索查询从技术文档库和 FAQ 库并行检索合并去重后精排、裁剪最后 LLM 只基于文档生成回答并标注来源[1][2]。4. 整体架构整条流水线的架构关系可以更直观地看成开始user_queryQuery 分析器LLM改写问题输出 3 个检索查询 JSON解析检索查询Code正则提取 JSON失败回退原问题 ×3技术文档精确检索KBtop_k3query1技术文档语义检索KBtop_k5query2FAQ 知识库检索KBtop_k3query3合并去重Code前 50 字符去重 → 按分降序 → 取前 10上下文窗口裁剪Code按 1.5 字符/token 估算超限截断生成带引用回答LLM标注 [1][2]未找到则明说结束result / total_unique / dedup_count链路很清晰入口收问题 → 改写扩召回 → 三路并行检索 → 合并去重精排 → 裁剪控窗口 → 带引用生成。合并去重和窗口裁剪是这条链路的两个关键闸门——前者保证 LLM 拿到的都是不重复的高分片段后者保证上下文不撑爆。5. 模块设计5.1 开始节点-data:type:startvariables:-label:用户问题required:truetype:text-inputvariable:user_query5.2 Query 分析器LLM——变量必须三花括号prompt_template:-role:systemtext:|你是一个检索优化专家。分析用户问题输出检索用查询。 用户问题{{#start.user_query#}} 任务 1. 识别核心实体和关键概念 2. 生成 3 个检索查询查询1精确版、查询2扩展版、查询3关键词版 3. 输出纯 JSON不要 Markdown 围栏不要其他内容model:completion_params:{max_tokens:2000,temperature:0.7}name:deepseek-v4-flashprovider:langgenius/deepseek/deepseek5.3 解析检索查询CodeLLM 输出常带 json 围栏或多余文字代码节点用正则提取第一个{...}并做兜底defmain(llm_text:str,user_query:str)-dict:importjson,re text(llm_textor).strip()queriesNonemre.search(r\{.*\},text,re.DOTALL)ifm:try:datajson.loads(m.group(0))qsdata.get(search_queries)ifisinstance(qs,list)andqs:queries[str(x)forxinqs]exceptException:queriesNoneifnotqueries:queries[user_query,user_query,user_query]# 解析失败兜底queries(queries[:3][queries[0]]*3)[:3]return{query1:queries[0],query2:queries[1],query3:queries[2],original_query:user_query}5.4 三路知识库检索三路并行query 分别取query1/query2/query3精确路 top_k3、语义路 top_k5、FAQ 路 top_k3。output_retrieval_result必须为 true否则结果为空-data:dataset_ids:[459c4981-6b76-43e7-b44f-c430f33ef035]# 技术文档库 IDoutput_retrieval_result:truequery_variable_selector:[cd_parse,query1]retrieval_mode:singletop_k:3type:knowledge-retrievalid:kb_exact5.5 合并去重与窗口裁剪Code合并节点做前 50 字符模糊去重、按分数降序、截取前 10 条同时拼出带编号的docs_text供 LLM 引用defmain(results_a:list,results_b:list,results_c:list)-dict:seen,mergedset(),[]forresults,sourcein[(results_a,tech_doc),(results_b,tech_doc_semantic),(results_c,faq)]:foritemin(resultsifisinstance(results,list)else[]):contentstr(item.get(content,))keycontent[:50].strip()# 前 50 字符模糊去重ifkeyandkeynotinseen:seen.add(key)merged.append({content:content,title:item.get(title,),score:item.get(score,0),source:source})merged.sort(keylambdax:float(x.get(score,0)or0),reverseTrue)mergedmerged[:10]lines[]fori,dinenumerate(merged):lines.append([{}] {} (来源: {}, 相关度: {}).format(i1,d[title],d[source],d.get(score,0)))lines.append(d[content]);lines.append(---)total_insum(len(x)forxin(results_a,results_b,results_c)ifisinstance(x,list))return{merged_results:merged,total_unique:len(merged),dedup_count:total_in-len(merged),docs_text:\n.join(lines)}窗口裁剪节点按1.5 字符 ≈ 1 token中文估算累计长度超过max_chars8000就截断最后一条并打truncated标记防止检索结果撑爆上下文。5.6 生成带引用回答LLM你是一个技术问答专家。根据提供的文档资料回答用户问题。 回答要求 1. 仅基于提供的文档内容回答不要自行编造 2. 每个关键信息末尾标注来源序号如 [1][2] 3. 如果文档中没有相关信息明确说提供的文档中未找到相关信息 参考资料 {{#cd_window.selected_text#}} 用户问题{{#start.user_query#}}6. 运行验证测试输入预期实测如何配置 API 密钥从技术文档回答带 [1] 引用命中 API 文档分段引用标注正确重置密码后 API 还能用吗综合技术文档 FAQ 两路来源同时引用 [1][2]跨库信息综合你们的公司食堂在几楼明确回答「未找到相关信息」无幻觉如实说明任意问题观察统计total_unique ≤ 10 且 dedup_count ≥ 0三路共 11 条去重后剩 8 条去重生效7. 实战坑坑现象修复LLM 提示词用双花括号 {{var}}变量不替换{{var}}原样传给模型节点内变量引用一律{{#node.field#}}三花括号Rerank 模型名写短名知识库配置报「模型不兼容」reranking_provider_name必须三段式全名langgenius/xxx/xxx且reranking_enablereranking_model在知识库数据集层面配置分段不完整检索命中半截内容回答断章取义导入文档时用「自包含分段」保证每段语义完整LLM 输出带 json 围栏json.loads直接抛异常代码节点正则提取第一个{...}失败回退原问题检索节点没开 output_retrieval_resultresult 为空合并全丢该开关必须 true结果才是 list[dict]其中「双花括号」这个坑值得展开看——它是 RAG 链路里最容易犯、又最隐蔽的错误。第一次搭这条流水线时Query 分析器的提示词里写的是用户问题{{user_query}} !-- 双花括号错误写法 --结果运行后模型收到的不是用户问题原文而是字面量{{user_query}}——改写出来的 3 个检索查询全部基于这个占位符文本检索结果自然全错。最迷惑人的是工作流不报错链路正常跑完只是答案质量莫名差。后来把变量引用改成三花括号直接引用后才恢复正常用户问题{{#start.user_query#}} !-- 三花括号正确写法 --排查口诀Dify 1.16 的 LLM 节点只替换{{#节点id.字段#}}三花括号引用{{变量名}}双花括号会原样传给模型——出现「模型回答里带着 {{xxx}} 占位符」或「答案质量莫名变差」时先查提示词里的变量引用形态。8. 实验文档及源码获取实验文档完整操作步骤DIFY-12高级RAG流水线.md源码可直接导入dify102_12_高级RAG流水线.yml文章聚焦核心配置与采坑点实验的完整分步操作节点搭建/参数表/调试指引见实验文档原文。下一篇Dify 中级实验12Agent 深度配置——如何让智能体自主调用工具 你在这个实验的场景里踩过什么坑欢迎评论区分享你的实战经验。