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

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和向量检索再把两路结果合并去重。关键词检索擅长精确匹配查订单号 302BM25 能精准命中包含该字符串的文档向量检索擅长语义匹配查这个接口怎么传参即使文档里没有同样的词也能召回语义相近的段落。两者互补覆盖的召回面远大于任何单一路径。3.3 后检索优化重排与压缩检索回来的 Top-K 块质量参差不齐直接塞给模型会稀释注意力。后检索阶段要做两件事重排Rerank用专门的排序模型对候选块重新打分把真正相关的排到前面。重排模型通常比嵌入模型更聪明能理解细粒度相关性但速度慢所以策略是向量库粗召回 50 条 → 重排模型精排 5 条用算力换精度。压缩Compression召回块里往往有大量冗余信息直接拼接会超过上下文限制。做法包括摘要压缩把每个块压缩成要点、上下文裁剪只保留与问题相关的片段、去重融合多块内容合并去重。3.4 生成优化让模型有据可依生成阶段要解决检索不到就瞎编的问题。关键技术是引用溯源要求模型在答案中标注每条信息的来源当答案完全无法由检索上下文支持时明确说知识库中未找到相关信息。配合 prompt 设计明确只能基于给定上下文回答能显著降低幻觉率。四、第三代模块化 RAG 与 GraphRAG4.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 RAGRAG 并非孤立技术它正在与另外两条技术线深度融合。第一条是长上下文——当模型上下文窗口足够大时“检索后整篇注入成为可能检索的角色从找答案演变为控制成本”检索仍然必要因为直接全量注入会烧光预算。第二条是 Agent——Agentic RAG 让检索不再是一次性的查而是多轮、带反馈的搜模型先检索一轮发现信息不足就改写查询再搜搜到答案后还要验证信息是否矛盾、是否需要二次检索补充。这种检索-评估-再检索的循环把 RAG 从检索增强生成升级为检索增强推理是当前工程实践中最值得关注的方向之一。七、结语RAG 的演进史本质上是如何让模型有据可依的工程探索史。从朴素 RAG 的三步流水线到高级 RAG 的三阶段精细化再到模块化 RAG 与 GraphRAG 的能力扩展每一步都是在补齐前一代的短板。今天的 RAG 已经不是一个固定的技术而是一套可以按场景裁剪的技术组合拳轻量场景用朴素 RAG 就够了复杂关系场景上 GraphRAG成本敏感场景靠混合检索加缓存。理解了演进脉络你就知道自己的系统处于哪个阶段、下一步该往哪走。