别让大模型“凭感觉编“：RAG，FDE对抗模型幻觉的工程武器

一、Prompt 解决了怎么回答但没解决凭什么回答上一篇拆解了提示词工程——FDE 跨入中层的第一道门槛。角色、指令、上下文、示例、约束五层结构把模型从乱说话调教到按规矩说话。但规矩再严也管不了一件事模型凭什么回答一个真实的交付场景金融行业智能客服项目Prompt 模板写了三天严谨到每个约束都反复推敲。Demo 时领导问了一个条款外的问题模型回答得有模有样——逻辑清晰、语气专业。业务专家皱眉这跟我们实际条款对不上。模型不是在回忆客户的产品条款而是在用训练数据里的通用金融知识编了一个看起来合理的答案。一本正经地胡说八道。这就是模型幻觉Hallucination。聊天场景无伤大雅业务场景致命。底层矛盾模型的知识来自训练数据不是客户的业务文档。你问本产品的冷静期是多久它回答的是训练数据里冷静期的统计概率不是条款里的真实规定。怎么办让模型回答之前先去客户文档里查一查。这就是 RAG。二、RAG闭卷考试变开卷考试RAG 全称 Retrieval-Augmented Generation检索增强生成。翻译成人话先检索再生成。没有 RAG 的模型是闭卷考试——靠记忆答题记不清就编加了 RAG 是开卷考试——先翻书找答案再组织语言。从 FDE 视角看RAG 不是技术选型是交付刚需。客户现场的每一个回答都要有出处——合规审核要求可追溯风控决策要求有依据客服回答要求与条款一致。没有 RAG合规那一关直接毙掉。三、RAG 五步链路FDE 必须知道出问题调哪里RAG 不是黑盒是一条清晰的工程链路。每一步都可能成为效果瓶颈。第一步文档解析——把 PDF、Word、Excel 变成可处理文本。现实是客户的文档千奇百怪扫描件需要 OCR表格混在段落里解析出错多栏排版顺序全乱。这是 RAG 落地的第一个坑也是最容易跟客户扯皮的环节。一句话垃圾进垃圾出。文档质量是效果的地基。第二步文档分块Chunking——长文档切成小段落。块太大检索不精准无关内容干扰模型块太小上下文碎片化语义断裂。没有万能分块策略——法律合同按条款分技术手册按章节分FAQ 按问答对分。选错策略效果直接掉一个档次。第三步向量化Embedding——文本变成数字向量让语义相近变成数学距离近。用户问冷静期多久文档写的是犹豫期 15 天可退——字面不同、语义相同关键词检索匹配不上向量化检索可以。核心价值理解意思一样而不是字一样。通用 Embedding 在专业领域表现往往不够需要领域微调或专业模型。这个选择FDE 必须做。第四步检索与重排——从向量库召回相关文档块再重排把最相关的提到前面。初筛求召回率宁多勿漏重排求精度最相关排最前。客户反馈搜不到或搜错了十有八九是这一步的问题——分块太碎向量模型选错重排没配好术语没做映射FDE 必须会排查。第五步生成回答——检索结果用户问题一起喂给模型。这一步必须配合 Prompt 工程在 System Prompt 中写入只能基于提供的文档内容回答没有相关信息则返回兜底回复不得编造。Prompt 控制怎么回答RAG 保障凭什么回答。五步全景文档→解析→分块→向量化→检索→重排→生成。每一步都是潜在瓶颈FDE 的价值就是出问题调哪里。四、四个落地坑与 FDE 填坑方案坑一文档质量差客户发来几百份 PDF80% 是扫描件表格嵌在段落里部分还加密。解析出来一塌糊涂基于这样的数据建 RAG检索质量可想而知。FDE 填坑系统化预处理——扫描件 OCR 校正、表格结构化提取、加密文档要求客户解密。更关键是跟客户讲清楚RAG 的效果上限由文档质量决定。这不是技术问题是数据治理问题。坑二分块不当金融合同用固定 800 字一刀切违约责任条款被拆成两块——检索只命中前半段违约金计算方式漏掉了。FDE 填坑按文档类型选策略——合同按条款分用标题编号做切分点手册按章节分FAQ 按问答对分。纯技术人员可能不知道违约责任和违约金计算必须在同一个块里FDE 基于业务理解来做这个决策。坑三术语不匹配客户问冷静期多久文档写的是犹豫期。字面不同向量模型在金融场景精度不够检索返回了一堆退保流程的间接相关文档。FDE 填坑建行业术语映射表。冷静期犹豫期无理由退款期向量化前做术语标准化处理。纯技术人员不知道这些术语是同义的FDE 做那个翻译者。坑四兜底缺失检索到的文档里没有答案模型硬编了一个。客户拿着去查条款对不上——信任崩塌。FDE 填坑Prompt 强制兜底——文档中没有相关信息则返回抱歉未找到相关信息建议咨询人工客服。生成环节加后处理校验模型回答在检索结果中找不到依据则拦截。宁可说不知道不能编——这是 FDE 的交付底线。五、GraphRAG从查文档到查关系传统 RAG 擅长文档里写了什么不擅长这些信息之间什么关系。冷静期多久——文档写了RAG 能查。犹豫期和保单贷款之间有什么关联——文档分别描述了两者但没有一段文字直接说关联是什么。传统 RAG 只能分别检索到两个片段无法推理关系。GraphRAG 的思路在文档之上构建知识图谱抽取实体和关系形成结构化知识网络让模型沿着关系链路做推理。不是所有项目都需要 GraphRAG。判断标准FAQ 为主→传统 RAG 足够涉及复杂业务流程、多实体交叉关联→GraphRAG 值得投入。还是那句话适配。选对工具比堆技术重要。六、LangChain从原理到落地的最后一公里道理都懂怎么搭出来LangChain。它是当前最主流的 RAG 开发框架把五步流程封装成五个组件文档加载器、文本分割器、向量数据库、检索器、LLM 调用链——一一对应。FDE 需要会写 LangChain 代码吗不一定要写每一行但必须能看懂。因为交付现场最常见的局面是RAG 效果不好开发团队说模型能力不行客户说你们产品不行。FDE 必须判断问题出在哪一步——文档解析差改加载器。分块不合理改分割器策略。检索不准改向量模型或加重排。模型还是编改 Prompt 加兜底。看不懂代码结构就无法定位问题只能在模型不行和产品不行之间和稀泥。FDE 的价值恰恰是精确定位问题给出解决方案。更实际的做法用 LangChain 快速搭 RAG 原型拿客户数据验证效果确认可行再交开发团队工程化。先验证再交付——这是 FDE 的工程方法论。七、技术栈决策框架Prompt→RAG→Agent把 RAG 放在 FDE 研发技术适配的框架里闭环提示词工程是第一层抓手——模型水土不服先用 Prompt 治。但 Prompt 装不下海量上下文。RAG 是第二层抓手——让模型从凭记忆答变成查资料答从可能编造变成有据可查。Prompt 控制怎么回答RAG 保障凭什么回答两者缺一不可。但 RAG 也不是万能的解决知识不足问题不解决逻辑推理问题——需要 CoT 和 Agent检索质量受限于文档质量和分块策略——需要持续迭代无法执行动作——下单、审批、调用系统需要 Agent 编排。FDE 技术栈决策框架场景简单、数据稳定 → 结构化 Prompt需要知识检索、有文档依据 → Prompt RAG需要推理决策、多步判断 → Prompt RAG CoT需要执行动作、调用工具 → Prompt RAG Agent核心洞察FDE 的价值不在于会搭 RAG而在于知道什么时候该用 RAG、什么时候不够用 RAG、怎么把效果调到客户满意。不是用什么技术而是为这个场景选什么技术组合。八、总结与预告RAG 是 FDE 对抗模型幻觉的工程武器——先检索再生成让每一个回答有出处、有依据。没有 RAG回答不担保真实性有了 RAG回答才具备业务可信的基础。RAG不是技术选型是交付刚需——合规可追溯、决策有依据是硬性要求没有RAG过不了验收。FDE必须理解五步链路的每个瓶颈点——知道出问题调哪里比会搭RAG更重要。但RAG解决的是回答有依据从原理到系统还差一步——怎么把五步链路搭成可运行的代码下一篇进入LangChain——从原理到落地的工程链路以及FDE如何用它快速验证、高效交付。模型内卷无出路落地能力定输赢。落地能力的第二层就是让每一个回答都有据可查。