企业官网建设流程全解析

RAG 技术全景：从朴素检索到混合检索与 GraphRAG 的演进之路

一、RAG 为什么成为大模型落地的主航道

大模型有一个与生俱来的矛盾：知识广博但边界模糊。它知道 2023 年之前的公开知识，却不知道你公司的产品文档；它擅长生成流畅的文本，却常常一本正经地编造事实。解决这个矛盾的主流方案就是 RAG——检索增强生成。

RAG 的基本思路很朴素：模型不"凭记忆"回答问题，而是先到外部知识库里检索相关资料，把检索结果作为上下文塞进提示词，让模型"看着资料说话"。这个机制由 Meta 团队在 2020 年正式提出，如今已成为企业知识库、智能客服、文档问答等场景的事实标准。

但"朴素 RAG"只是起点。经过多年演进，RAG 已经发展出一套完整的技术谱系：从朴素 RAG 到高级 RAG，再到模块化 RAG 和 GraphRAG。本文沿这条演进路径展开，讲清楚每一代 RAG 解决了什么问题、引入了什么技术、适合什么场景。

二、第一代：朴素 RAG 的架构与局限

朴素 RAG 的流水线只有三步：索引、检索、生成。

索引阶段，把文档切分成块（chunk），用嵌入模型（embedding model）把每个块转成向量，存入向量数据库。检索阶段，把用户问题也转成向量，在向量库里做相似度搜索，召回 Top-K 个相关块。生成阶段，把召回结果拼进提示词，交给大模型生成答案。

这个流程看似简单，实际落地时会暴露四个致命短板：

短板一，语义鸿沟。向量检索基于嵌入空间的相似度，但"语义相似"不等于"答案正确"。比如用户问"退货流程"，文档里写的是"售后政策"，两者向量相似度可能不达标，关键信息被漏掉。

短板二，块切分粗糙。切块大小直接影响检索质量：切大了噪声多、命中率低；切小了语义断裂、上下文不全。不同文档类型（合同、代码、表格）需要不同的切法，朴素 RAG 一刀切的做法必然损失质量。

短板三，检索不到就瞎编。当知识库里确实没有答案时，朴素 RAG 不会说"我不知道"，而是把不相关的片段拼凑出貌似合理的回答——这是幻觉的重灾区。

短板四，多跳问题无力。用户问"去年销量最高的产品是什么"，需要先检索产品销量数据，再检索产品详情，两步检索才能回答。朴素 RAG 只做一次检索，无法处理这种复合问题。

三、第二代：高级 RAG 的四大优化方向

高级 RAG 在朴素 RAG 的基础上，针对上述短板做了系统性优化，核心是"预检索、检索、后检索"三阶段的精细化。

3.1 预检索优化：让文档"更适合被检索"

预检索阶段的工作是提升索引质量。包括：文档清洗（去噪、去重、识别无效页）、文档结构解析（识别标题、段落、表格，构建层级结构）、元数据标注（给每个块打上来源、章节、日期标签，供检索时过滤）。

其中块切分策略是重头戏。实践沉淀出的经验包括：按语义边界切分（尽量在段落、标题处断句，避免切断语义）；重叠窗口（相邻块保留一定重叠，防止关键信息恰好落在切分缝上）；结构化块（表格、代码、列表单独处理）；动态块大小（根据文档结构自适应调整，而不是固定 500 token）。

3.2 检索优化：多路召回与混合检索

单一路径的检索永远有盲区。高级 RAG 的突破性改进是混合检索（Hybrid Search）：同时跑关键词检索（BM25）和向量检索，再把两路结果合并去重。

关键词检索擅长精确匹配：查"订单号 302"，BM25 能精准命中包含该字符串的文档；向量检索擅长语义匹配：查"这个接口怎么传参"，即使文档里没有同样的词，也能召回语义相近的段落。两者互补，覆盖的召回面远大于任何单一路径。

3.3 后检索优化：重排与压缩

检索回来的 Top-K 块质量参差不齐，直接塞给模型会稀释注意力。后检索阶段要做两件事：

重排（Rerank）：用专门的排序模型对候选块重新打分，把真正相关的排到前面。重排模型通常比嵌入模型更"聪明"（能理解细粒度相关性），但速度慢，所以策略是"向量库粗召回 50 条 → 重排模型精排 5 条"，用算力换精度。

压缩（Compression）：召回块里往往有大量冗余信息，直接拼接会超过上下文限制。做法包括：摘要压缩（把每个块压缩成要点）、上下文裁剪（只保留与问题相关的片段）、去重融合（多块内容合并去重）。

3.4 生成优化：让模型"有据可依"

生成阶段要解决"检索不到就瞎编"的问题。关键技术是引用溯源：要求模型在答案中标注每条信息的来源，当答案完全无法由检索上下文支持时，明确说"知识库中未找到相关信息"。配合 prompt 设计（明确"只能基于给定上下文回答"），能显著降低幻觉率。

四、第三代：模块化 RAG 与 GraphRAG

4.1 模块化 RAG：检索不再是单点

模块化 RAG 把检索流程拆成可自由组合的模块：查询改写（把复杂问题拆成多个子查询）、查询路由（根据问题类型选择不同的检索路径）、迭代检索（检索→生成→发现信息不足→再检索）、递归检索（把大问题逐层分解检索）。

以查询改写为例：用户问"华为和小米手机的性价比对比"，直接检索效果很差，但改写成两个子查询"华为手机性价比"和"小米手机性价比"分别检索，再合并结果，召回质量会大幅提升。这种"先改写、再检索、后融合"的流程，让 RAG 从"一次检索"进化成"检索策略"。

4.2 GraphRAG：从"碎片召回"到"关系推理"

传统 RAG 把文档切成碎片分别检索，割裂了信息之间的关联。GraphRAG 的解法是：先抽取文档中的实体（公司、产品、人物、事件）和关系，构建知识图谱；检索时既做向量召回，也沿图谱关系做推理——比如查"A 公司的供应商有哪些"，图谱可以直接沿"供应"关系找到答案，这是纯向量检索做不到的。

GraphRAG 的优势在于多跳问题和聚合问题：涉及实体关系的复杂查询，准确率显著高于纯向量 RAG；代价是构建图谱的成本高、对文档质量要求高。它适合知识密度高、关系复杂的企业知识库（如金融研报、法务文档），而不适合轻量级的场景。

4.3 时代演进中的新变数：长上下文与缓存

模型上下文窗口的不断增大，给 RAG 带来了新的可能性。一种思路是"全文注入"：上下文窗口足够大时，直接把整份文档塞给模型，省去检索环节——这在小规模场景下效果很好。但成本是现实约束，检索的价值依然存在：检索不是为了"找得到"，而是为了"低成本地找得到"。另一种思路是上下文缓存：长文档的公共前缀可以缓存复用，显著降低多轮问答的成本。RAG 与长上下文并非替代关系，而是互补关系——前者控成本、提精度，后者兜底极端场景。

五、RAG 评测：怎么知道系统好不好

RAG 系统迭代最大的障碍是"不知道改没改好"。建立评测体系是 RAG 工程化的前提，核心指标有四类：

检索质量：召回率（正确答案是否在召回集中）、命中位置（正确答案排第几，影响重排的必要性）。

生成质量：答案准确率（事实是否正确）、忠实度（答案是否都有上下文支撑）、引用正确率。

端到端质量：用户问题是否有满意回答、兜底率（无法回答时是否正确拒绝）。

工程指标：端到端延迟（检索耗时、重排耗时、生成耗时）、单次问答成本（token 消耗）。

评测集要覆盖不同类型的问题：事实型（有明确答案）、推理型（需要多步推理）、否定型（知识库中不存在答案，正确行为是拒绝回答）、长尾型（罕见问法）。每类问题的表现都要分开统计，才能定位优化方向。

六、RAG 落地的避坑清单

结合大量项目的实战教训，整理出六条高频踩坑点：

坑一，跳过文档清洗。脏数据直接入库，检索质量全线崩塌——清洗的投入回报比远高于调参。

坑二，块切分一刀切。所有文档用同一套切块参数，表格被切断、代码被割裂。不同文档类型要设计不同的切分策略。

坑三，只做向量检索。忽略了关键词检索的价值，精确匹配类问题大量漏检。混合检索是性价比最高的升级。

坑四，不重视重排。Top-K 直接拼进 prompt，噪声稀释注意力。粗召回+精排是成熟的工程组合。

坑五，没有评测集。凭感觉迭代，改一次 embedding 模型不知道是变好还是变坏。

坑六，忽视权限。知识库直接全量开放，敏感数据经模型泄露。检索层必须带权限过滤。

6.1 RAG 与长上下文、Agent 的组合：Agentic RAG

RAG 并非孤立技术，它正在与另外两条技术线深度融合。第一条是长上下文——当模型上下文窗口足够大时，“检索后整篇注入"成为可能，检索的角色从"找答案"演变为"控制成本”：检索仍然必要，因为直接全量注入会烧光预算。第二条是 Agent——Agentic RAG 让检索不再是"一次性的查"，而是"多轮、带反馈的搜"：模型先检索一轮，发现信息不足就改写查询再搜；搜到答案后还要验证信息是否矛盾、是否需要二次检索补充。这种"检索-评估-再检索"的循环，把 RAG 从检索增强生成升级为检索增强推理，是当前工程实践中最值得关注的方向之一。

七、结语

RAG 的演进史，本质上是"如何让模型有据可依"的工程探索史。从朴素 RAG 的三步流水线，到高级 RAG 的三阶段精细化，再到模块化 RAG 与 GraphRAG 的能力扩展，每一步都是在补齐前一代的短板。今天的 RAG 已经不是一个固定的技术，而是一套可以按场景裁剪的技术组合拳：轻量场景用朴素 RAG 就够了，复杂关系场景上 GraphRAG，成本敏感场景靠混合检索加缓存。理解了演进脉络，你就知道自己的系统处于哪个阶段、下一步该往哪走。