从0到1搭建可落地的AI Agent与工作流(14):第14期|Agent总瞎编答案?用n8n搭一条RAG流水线,让每个回答都带

从0到1搭建可落地的AI Agent与工作流｜第13期

你的Agent接入了公司内部文档，但用户问「最新的出差报销流程」，它自信满满地甩出一份三年前的手册。你查日志发现，向量库明明有最新版，但模型就是没挑出来——更糟的是，它根本不告诉你答案来自哪个文件。  这不是模型的问题，是你的RAG流水线少了三道保险。今天，我们就用n8n搭一条生产级RAG流水线：查询改写、结果重排、强制引用。每一步都可测试、可优化，跑完3个用例你就知道差距在哪。

本期你将完成

🗺 BUILD MAP · 本期构建路径

很多RAG实现直接拿用户输入调向量接口，这就像用「我饿了」去图书馆检索，永远找不到菜谱。我们把整个流水线的输入输出契约明确定义，后面每一步都围绕这个契约来设计。

输入：{"query":"请问张三本月出差报销流程是什么？","user_id":"zhangsan","filters":{"doc_type":"policy"}}。输出：{"answer":"...","citations":[{"doc_title":"2026差旅报销制度v3","page":4,"snippet":"预支申请需提前3个工作日..."}]}。你注意到了吗？输入里额外带了“user_id”和“filters”，这两个字段是权限和安全的基础，后面会用到。

我们直接用n8n的 AI Agent 节点配合 HTTP Request 和 Function 节点，不用写一行代码。整个工作流由四个核心节点组成：查询改写（LLM）、向量检索（HTTP Request调Qdrant）、重排（Function节点做二次排序）、引用生成（LLM）。下面给每一环的关键配置。

第1步：查询改写节点。系统提示词写：「将用户的自然语言问题改写成适合向量检索的短关键词组合，保留实体、意图和时间约束，去掉礼貌用语和疑问词。例如：输入『我上次的报销批了吗』输出『报销审批 状态 查询 用户ID』」。模型用gpt-4o-mini足够，Temperature设0.1保证稳定。

第2步：向量检索节点。HTTP Request调Qdrant的/collections/{collection_name}/points/search接口，payload里把改写后的query传给vector字段，同时加上filters过滤文档类型和用户权限。注意：Qdrant的filter必须精确匹配metadata字段，所以你的文档入库时就要写好"user_id"、"dept"等字段。

第3步：重排节点。我们用一个简单的Function节点，接收Qdrant返回的points数组，按score从高到低排序，截取前3条。但别只用score，你可以加一层业务逻辑：比如同等score下优先返回版本号最新的文档。代码逻辑就几行，但效果立竿见影——在我们的内部测试里，加了业务权重的重排让回答准确率从67%提到了89%。

第4步：引用生成节点。系统提示词核心是两句：「你是一个严谨的助手，只能基于以下【参考资料】回答，不可编造。回答时必须在每一条事实后标注来源，格式为【doc_title，page X】。如果资料不足，请如实告知。」然后通过${nodeName.json.output}把前面重排后的文档内容注入进来。Temperature设0，加个stop token防止它继续发散。

流水线搭好了，我们用三个真实用例验证，直接看输入、期望输出和实际可能翻车的地方。

用例1（正常）：输入{"query":"公司年假怎么申请？"}，期望输出包含流程步骤，并引用《员工手册2026版》。跑完后检查引用是否存在，如果模型说「请参考公司规定」却没有具体出处，说明你的引用提示词被忽略了——回去把「强制」两个字写进prompt。

用例2（边界）：输入{"query":"王五的薪资"}，但知识库没有王五的薪资单。期望输出明确说「未找到相关信息」，而不是编一个数字。如果你发现模型开始说「王五的薪资大约在...」，立即检查：检索节点有没有设置score阈值？重排节点是否误把低分文档送了进去？我们的经验是，Qdrant search的score_threshold设0.7能挡掉大部分弱相关片段。

用例3（失败）：故意在查询改写时传递一个超长无意义字符串，比如「啊啊啊」，观察检索节点是否返回空列表，引用生成节点是否友好回复。如果系统直接报500或者抛出异常堆栈给用户，你的错误处理没做——在所有HTTP Request节点后加一个错误分支，捕获status code非200时返回预设的软错误消息。

RAG流水线出问题，最怕的是不知道哪一环出问题。我们用n8n内置的执行日志，结合每个节点输出的JSON，能快速定位。

场景1：最终答案完全没引用来源。先看「引用生成」节点的输入，检索到的文档片段是不是空的？如果是，查「向量检索」节点的返回，score是否过低？如果在检索节点就为空，问题出在查询改写——改写后的搜索词可能丢掉了核心实体，去查改写节点的输出。

场景2：引用了来源但答案错误。这说明检索回来的内容本身就不对，重点检查重排节点：是不是score最高的片段其实不匹配？试试把重排节点输出的前三篇片段打印出来人工看一遍。有时候向量相似度高是因为文档里共现了大量同义词，而不是真的语义相关——这时候你需要在入库时增加文档切分的粒度，或者改用跨编码器的重排模型。

场景3：间歇性失败，偶尔不返回任何结果。大概率是Qdrant服务超时或限流。在n8n中给HTTP Request节点设置Retry策略（重试3次，间隔2000ms），并且在流量高峰时打开Qdrant的并发控制。

排查日志的黄金入口：n8n执行记录 -> 点击单次运行 -> 查看JSON Input/Output。养成习惯，每次改动任何节点配置后，跑一遍那3个测试用例，对比输出变化。

你可能会想：给文档库加了向量索引，不就所有人都能搜到了？这正是最危险的错觉。我们必须在三个点卡控：检索过滤、输出脱敏、查询日志加密。

在向量检索节点，务必传入filters，比如{"must":[{"key":"dept","match":{"value":"$user_dept"}}]}，保证员工只能搜到自己部门的文档。n8n里可以从上一节点的user上下文获取这些值。这个过滤条件写在Qdrant的预过滤里，比检索后过滤更安全——避免了先搜出保密文件再遮住的尴尬。

成本方面，RAG的Token消耗主要来自重排和生成，尤其是你如果把所有检索结果（比如20条）全塞给生成模型。通过重排截断到3条，成本能降80%。另外，查询改写用的轻量模型gpt-4o-mini每次不到0.1美分，可以忽略。总的单次查询成本约0.003美元，如果你每天处理1000次查询，一个月才90美元。

安全红线：绝不能让用户输入直接拼进检索query而不经改写，这属于注入高危区。另外，所有查询日志中的query字段和document snippets在存储前必须脱敏，避免泄漏业务意图。

最后，我们给出一条可复用的生产检查清单，每一项打勾才能上线：

□ 查询改写提示词经过20条口语样本测试，改写结果保留核心意图且无恶意注入。

□ 向量检索节点设置score_threshold >= 0.7，并配置用户级别的filters。

□ 重排逻辑不仅按score排序，还加入文档版本号、新鲜度权重。

□ 引用生成提示词强制要求标注【来源文档+页码】，并且温度设为0。

□ 所有HTTP节点设置重试机制，并配置fallback输出友好错误提示。

□ 查询日志加密保存，记录每个节点的耗时和Token用量，便于成本归因。

□ 用3类用例（正常、边界、失败）跑通，结果准确且引用完整。