企业官网建设流程全解析

一、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 填坑方案

坑一：文档质量差

客户发来几百份 PDF，80% 是扫描件，表格嵌在段落里，部分还加密。解析出来一塌糊涂，基于这样的数据建 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如何用它快速验证、高效交付。

模型内卷无出路，落地能力定输赢。落地能力的第二层，就是让每一个回答都有据可查。