M6第 1 课 · 辅导 / 客服 RAGM6-L1.4

参考实现：n8n 版客服 RAG

一句话概括： 把 Technical Design 做成三条 n8n 工作流（入库、问答、评测），每个闸门都是确定性节点，每条引用都由代码校验，并明确列出 n8n 不会替你做的事。

教学参考。 本页为 handbook 而写，补上 Lesson 1 缺少的”当前实现”一节，把参考设计映射到 n8n 上。节点名称按 n8n 文档写，版本更新后可能变化。

1. 标准场景

教育行业的案例，只是 FDE 最常收到的那类 AI 需求的一个实例。把行业去掉，剩下的形状到处都一样：

维度	通常的样子
知识来源	FAQ、产品文档、政策与条款、历史工单、内部 wiki。答案已经有了，只是没人能快速找到
提问者	客户、学员、员工、一线人员、经销商
渠道	网页聊天窗、企业微信 / 飞书 / Slack / Teams、邮件，或现有工单系统里的机器人入口
转人工去向	已经存在的客服邮箱或工单队列
典型行业	电商售后、SaaS 技术支持、教育、HR 和 IT 服务台、政务咨询、保险和银行 FAQ
客户的说法	“做一个能回答客户问题的 AI”
客户实际需要的	检索、引用、拒答、转人工，以及一条知识更新路径

案例概览里的三个条件决定这个方案适不适用：答案已经成文、不写回任何系统、每个回答都能带上自己的证据。三条都满足，就做这个；缺一条，先读延伸（加工具）或 Lesson 2（拆角色），再决定要不要加机器。

为什么 n8n 在这里是一个合理的默认选项：渠道、工单系统、向量库都有现成节点；路由和校验这两步是普通的确定性节点，正是设计希望它们待的地方；客户自己的团队不用读代码也能看懂工作流。

2. 三条工作流

设计把入库、问答、评测分开。落地时也保持三条独立工作流，共用一个数据库和一个向量库，不要画成一张大画布。

入库    触发器（文件夹 / 云盘变更，或手动）
        → 解析文档 → 按标题切块 → 加上下文头
        → 去除个人信息（代码）→ 向量化 → 写入向量库，带 {doc_id, version, effective_from}
        → 对预发布索引跑"评测"流 → IF 通过 → 标记版本上线，退役被替代文档

问答    Chat Trigger 或 Webhook（前面接渠道适配器）
        → 路由（代码：从配置表读升级主题）
        → 检索 top-k（向量库，过滤 version = live）→ 可选重排
        → LLM 结构化输出 {answer, citations[], route}
        → 引用校验（代码）→ Switch：回答 / 未覆盖 / 转人工
        → 回复 · 或 · 建工单（HTTP / 工单系统节点）
        → 追加回答日志（数据库）

评测    Evaluation Trigger（数据集放在 Data Table 或表格里）
        → 以子工作流方式执行"问答"流 → 打分（代码或 LLM 裁判）
        → Evaluation 节点：写入指标 → 与阈值比较 → 告警 / 阻止上线

3. 组件对照

每一行是 Technical Design 第 2 节里的一个组件，以及它在这个实现里落在哪。

设计组件	n8n 实现	说明
入库	Default Data Loader、文本切分器，加一个 Code 节点做上下文头和个人信息去除	按标题切，不按字符数切；上下文头只有一行
知识库	Postgres（或 Supabase）表：`doc_id, owner, version, effective_from, superseded_by, live`	n8n 没有文档版本管理，这张表要你自己设计
索引	向量库节点（PGVector、Qdrant、Pinecone），元数据过滤 `live = true`	关键词检索可以用同一个 Postgres；混合检索是后续项
路由	Code 或 Switch 节点，读升级主题表和分数阈值	配置放在表里，永远不放在 prompt 里
回答服务	Basic LLM Chain + Structured Output Parser，prompt 限定只能用检索到的段落	返回 `{answer, citations[], route}`；解析器拒绝格式不对的输出
引用校验	Code 节点：每个引用 ID 必须在检索结果集里，且引用文本要和回答有重叠	校验失败走”未覆盖”，并记一次 grounding 失败
转人工适配器	工单系统节点（Zendesk、Jira Service Management、Freshdesk）或 HTTP Request	用对话 ID 做幂等键
回答日志	Postgres 插入：问题、知识库版本、段落 ID、路由、延迟、成本	只追加不修改；这是任何回答可审计的基础
评测	Evaluation Trigger + Evaluation 节点；数据集放 Data Table 或 Google Sheet	轻量评测把输出写回数据集；带指标的评测需要付费计划

4. 闸门落在节点上

设计里的四条信任边界可以直接对应：

模型输出未经校验不可信： LLM 节点之后的 Code 节点是通往回复的唯一路径。LLM 节点到渠道之间没有连线。
路由是配置： 路由节点读一张表；一个问题改不了一张表。
发布是人工闸门： 入库流末尾是一个 Wait 节点（审批链接或表单），评测通过之后才把版本翻成上线。
不写任何记录系统： 问答流只有一个对外写操作，就是建工单。加一个检查”仓库里不存在其他写节点”很便宜，值得做。

5. n8n 不会替你做的事

对客户要像 PRD 对范围那样说清楚。

版本和退役是一张你自己设计和维护的表；向量库只按你放进去的字段过滤。验收标准 2（“永远不引用退役版本”）靠过滤条件加测试用例证明，不靠工具本身。
测试：校验器、路由、去个人信息这三步，在画布上比在代码里更难测。把它们写成小脚本或一个很小的服务，由 n8n 调用，这样它们可以有单元测试，并和导出的工作流 JSON 一起进 Git。
本地文件和命令需要自托管实例。云端 n8n 读不到客户机器上的文件夹。
许可证：n8n 的 Sustainable Use License 允许内部使用；如果打算把这套工作流作为托管服务转售给多个客户，先查许可条款。
可观测性默认是按单次执行看的。设计要求的看板（未覆盖率、转人工率、延迟、成本）来自回答日志表，不来自 n8n。

6. 这个方案到哪里为止

客户一问”它能查我的报名状态吗”，你就已经离开这一页了。先是限定到单个用户的读工具，再是带确认和审计的写工具，这是延伸的内容。n8n 可以承载这些工具，但真正要紧的问题（查询前先确认身份、幂等、审批额度）是设计问题；而当助手需要和人持续对话而不是回答一个问题时，带对话界面的 agent 平台（比如 Lesson 2 到 4 用的 Puffo space）才开始显出价值。

常见误区

“工作流就是设计。” 画布展示的是数据流。设计是职责表、闸门和测试。两个团队可以画出同一张画布，交付出完全不同的系统。
“向量库负责新鲜度。” 它负责相似度。新鲜度是 live 标记、退役步骤，以及那条问去年政策的测试用例。
“n8n 的评测功能替代了评测集。” 它只是运行评测集。评测集本身，从真实问题和复核队列的纠错中长出来，仍然是知识负责人的工作。
“低代码意味着客户可以自己维护。” 他们可以维护渠道和 prompt。校验器、表结构和评测阈值仍然需要工程师。

典型面试问题

为什么把引用校验放在 Code 节点，而不是让模型自己检查？

和 Technical Design 给的理由一样：指令不是保证。在 n8n 里这一点是结构性的：LLM 节点没有连到回复节点的边，唯一的出口是校验器。prompt 注入可以改变模型说什么，改变不了下一个运行的节点是哪个。

客户团队已经在用 n8n 做营销自动化。这是否就决定了平台选型？

如果三个条件成立，它决定第一个版本。说清楚它买到了什么（渠道、工单系统、团队看得懂的画布）和没买到什么（版本管理、单元测试、看板），并把两者都写进 PRD 的范围里。第一个工具被提出来的时候再重新评估。

在这个实现里，怎么证明验收标准 5（错误引用会被拦截）？

在数据集里加一行，期望路由是”未覆盖”，并设计一个测试问题，诱导模型引用一个没有被检索到的段落 ID。跑评测；校验器必须把它路由到”未覆盖”，回答日志里必须出现一条 grounding 失败。这一行永远留着。