【Agent 开发】一文看懂三种 RAG 架构：Classic RAG、Graph RAG 与 Agentic RAG

文章目录前言一、Classic RAG先检索再生成1.1 Classic RAG 的基本链路1.2 Classic RAG 适合什么场景1.3 Classic RAG 的边界在哪里二、Graph RAG把知识从文本片段变成关系网络2.1 Graph RAG 的核心实体与关系2.2 Graph RAG 如何参与回答2.3 Graph RAG 的适用边界三、Agentic RAG让模型自己决定怎么找资料3.1 Agentic RAG 的核心规划、行动与反馈3.2 Agentic RAG 的关键不是自由而是可控3.3 三种 RAG 架构该怎么选写在文后 个人主页铁皮哥欢迎关注 作者简介28届校招生后端开发/Agent 方向在学 学习内容Java、Python、计算机视觉、大语言模型、Agent开发 专栏内容从零开始的Claude Code零代码生活持续更新中✨不只背八股更想搞懂为什么这样设计前言这两年只要聊大模型应用RAG几乎是绕不开的话题。最早大家理解RAG通常是把它看成一个“给大模型外挂知识库”的方案用户提出问题之后系统先去知识库里检索相关内容再把检索结果和用户问题一起塞进Prompt最后让大模型基于这些材料生成回答。这个理解没有错但它只解释了最基础的Classic RAG。在很多早期场景里这套方案已经足够好用。比如产品文档问答、接口说明查询、企业制度检索、FAQ 客服机器人本质上都是把原本分散在文档里的知识找出来再交给大模型重新组织成自然语言回答。但问题也很快暴露出来了。当用户的问题越来越复杂RAG的瓶颈就不再只是“能不能检索到相关文本”而是检索到的内容能不能真正支撑回答。比如用户问某个系统的上线风险为什么会受到另一个系统改造的影响这个问题看起来只是在问风险实际上背后可能涉及系统依赖、接口调用链、历史故障、版本排期、负责人变更、业务流程改造等多层信息。如果这些信息散落在不同文档里传统的向量检索可能只能找出几段语义相似的文本却不一定能把它们之间的关系串起来。这时单纯的Classic RAG就开始显得不够用了。于是我们会看到Graph RAG的出现。它不再只把知识看成一个个孤立的文本片段而是尝试把文档中的实体、概念和关系抽取出来组织成一张知识网络。这样系统回答问题时就不只是“找相似文本”还可以沿着关系链路去理解不同信息之间的连接。但即使有了知识图谱也不代表所有问题都能一次解决。有些任务天然就需要多步推理。模型可能要先理解用户意图再拆解问题接着决定查哪些资料、调用哪些工具、是否需要继续检索最后再综合多个中间结果给出答案。这时候RAG就不再是一条固定流水线而更像是一个由模型参与调度的信息获取过程。这就是Agentic RAG关注的方向。一、Classic RAG先检索再生成Classic RAG的核心思路很简单大模型本身不一定知道业务系统里的私有知识也不一定掌握最新资料所以在回答问题之前先从外部知识库里找出相关内容再把这些内容作为上下文交给大模型。换句话说Classic RAG并不是让模型“重新学习”这些知识而是在模型回答时临时把资料递给它。这也是它和模型微调最大的区别。微调更像是把知识或能力写进模型参数里而RAG更像是在每次回答之前先给模型打开一份参考资料。模型并不真正拥有这份资料但它可以在当前上下文窗口里使用这些资料。1.1 Classic RAG 的基本链路一个典型的Classic RAG系统通常可以拆成两个阶段离线建库和在线问答。离线建库阶段系统会先处理原始文档。这些文档可能是产品说明、接口文档、项目方案、规章制度也可能是数据库导出的文本、Markdown 文件、PDF 文件或者网页内容。系统会先对这些资料进行解析然后按照一定规则切分成多个较小的文本片段也就是常说的chunk。切分之后每个chunk会被送入Embedding Model转换成一个向量。这个向量可以理解成文本在语义空间中的位置。语义相近的文本它们对应的向量距离通常也会更近。最后这些文本片段和对应向量会一起存入向量数据库形成一个可检索的知识库。在线问答阶段用户提出问题后系统也会把这个问题转换成向量然后拿这个问题向量去向量数据库里做相似度检索。检索系统会返回若干个和问题最相关的文本片段。接下来应用层会把用户问题、检索到的文本片段以及必要的提示词模板拼接成最终的Prompt交给大模型生成回答。整个过程可以概括成一条固定流水线文档解析 → 文本切分 → 向量化入库 → 问题向量化 → 相似度检索 → 上下文拼接 → 大模型生成从工程实现上看Classic RAG的架构并不复杂。它的关键组件主要包括文档加载器、文本切分器、Embedding Model、向量数据库、检索器、提示词模板和大模型。这些组件组合起来之后系统就能实现一个最基础的知识库问答能力。1.2 Classic RAG 适合什么场景Classic RAG最适合处理资料相对明确、答案可以从局部文本中找到的问题。比如用户问这个接口的请求参数有哪些或者某个产品功能支持哪些配置项再比如公司报销制度里对交通费有什么要求这些问题的共同特点是答案通常已经写在某份文档里系统要做的主要是把对应片段找出来再让大模型把它整理成更自然的表达。在这类场景下Classic RAG的效果往往很好。因为它不需要系统理解非常复杂的关系也不要求模型进行长链路推理。只要文档质量足够好切分粒度合适检索召回比较准确模型就可以基于检索内容生成一个相对可靠的答案。这也是为什么很多企业知识库、智能客服、文档问答系统最开始都会选择Classic RAG。它足够直接也足够容易落地。对于工程团队来说Classic RAG还有一个很大的优势它的链路稳定问题容易定位。如果回答效果不好通常可以沿着这条链路逐步排查。是原始文档解析错了还是文本切分不合理是Embedding表达能力不够还是检索结果召回不准是上下文拼接太长还是提示词没有约束模型基于材料回答。1.3 Classic RAG 的边界在哪里Classic RAG的问题往往不是它完全找不到内容而是它只能找到“看起来相关”的内容。向量检索擅长处理语义相似问题。用户问“怎么申请报销”系统很容易找到“报销流程”“报销材料”“费用审批”之类的文本片段。但当问题开始涉及多个对象之间的关系时单纯依赖相似度检索就会变得吃力。比如用户问为什么 A 系统的改造会影响 B 系统的上线风险这个问题并不是简单地找一段包含“A 系统”和“B 系统”的文本就能回答。它可能需要先知道 A 系统改了什么再知道 B 系统依赖了 A 系统哪些接口还要结合上线时间、历史故障、调用链路和业务流程最后才能判断风险来自哪里。如果这些信息分散在不同文档里Classic RAG可能会检索到几段相关内容但它不一定知道这些内容之间应该如何连接。这就是Classic RAG的核心边界。它把知识组织成一个个文本片段然后通过相似度把片段找回来。它擅长回答“某个问题对应哪段资料”但不擅长回答“多个资料之间是什么关系”。所以Classic RAG更像是一个检索增强系统而不是一个真正理解知识结构的系统。在简单问答场景里这已经足够。但在复杂业务场景里问题常常不是缺少某一段文本而是缺少一张能把信息串起来的关系网络。二、Graph RAG把知识从文本片段变成关系网络在Classic RAG里知识通常是以chunk的形式存在的。系统会把文档切成一段一段文本然后通过向量检索找出和用户问题最相似的片段。这个方式很适合处理局部知识问答但它有一个天然限制每个文本片段都是相对孤立的。Classic RAG更关注“哪段文本和问题相似”而不是“这些知识之间有什么关系”。可是在真实业务里很多问题并不是靠某一段文本就能回答的。尤其是企业知识库、代码系统、项目文档、风控资料这类场景信息之间往往存在大量关联。一个系统可能依赖另一个系统。一个接口可能影响多个业务流程。一个项目延期可能牵连多个团队。一次故障可能同时涉及服务调用、配置变更、版本发布和历史问题。这些信息如果只被切成孤立的文本块系统就很难理解它们之间的连接方式。于是Graph RAG开始出现。它试图解决的问题不再只是“怎么找到相关文本”而是“怎么把知识之间的关系也组织起来”。2.1 Graph RAG 的核心实体与关系Graph RAG的关键是把原始文档中的知识抽取成图结构。在图结构里知识不再只是一个个文本片段而是由节点和边组成。节点通常表示实体或概念比如一个系统、一个接口、一个人员、一个项目、一个业务流程、一个故障事件。边则表示这些实体之间的关系比如依赖、调用、负责、影响、属于、导致、关联。举一个简单例子。原始文档里可能写着订单服务在支付环节会调用支付服务支付服务依赖风控服务完成交易校验。如果风控服务响应超时可能导致订单支付失败。在Classic RAG里这段内容可能只是一个chunk。但在Graph RAG里它可以被抽取成这样的关系订单服务 → 调用 → 支付服务支付服务 → 依赖 → 风控服务风控服务响应超时 → 可能导致 → 订单支付失败这样处理之后系统获得的不只是文本内容还有知识之间的连接路径。当用户问“订单支付失败可能和哪些服务有关”时系统就不只是查找包含“订单支付失败”的文本而是可以沿着图谱关系从“订单支付失败”反向找到“风控服务响应超时”“支付服务依赖风控服务”“订单服务调用支付服务”等相关信息。2.2 Graph RAG 如何参与回答Graph RAG并不是完全抛弃向量检索。在很多实际系统里它往往会和向量检索结合使用。向量检索负责找到语义相关的文本图谱检索负责补充实体关系和上下游路径。两者结合后模型拿到的上下文就不再只是几段孤立材料而是一组带有结构的信息。一个比较典型的Graph RAG流程可以理解为识别问题中的关键实体 → 在图谱中定位节点 → 沿关系边扩展相关节点 → 找到对应原文材料 → 组织上下文 → 交给大模型生成回答这里最重要的是“沿关系边扩展相关节点”。比如用户问A 系统改造为什么会影响 B 系统上线如果只靠向量检索系统可能会找到几段包含“A 系统”“B 系统”“上线”的文本。但如果有图谱系统可以先定位A 系统和B 系统再查它们之间是否存在依赖、调用、数据同步、共同下游服务、共同负责人或历史故障关联。这样一来回答就不只是基于几段相似文本做总结而是可以围绕关系链路展开A 系统改造了某个接口而 B 系统上线依赖这个接口这个接口又影响某个核心业务流程历史上类似接口变更曾经造成过联调失败所以 B 系统上线风险并不只来自自身代码而来自上游依赖变化。这类回答的质量往往取决于系统能不能找到“连接信息的路径”。所以Graph RAG的价值不是让检索结果更多而是让检索结果更有结构。它让大模型不只是看到一堆材料而是看到材料之间的关系。2.3 Graph RAG 的适用边界Graph RAG适合关系密度高的场景。如果知识本身主要是说明书、FAQ、接口字段解释很多问题都能从局部文本中直接找到答案那么使用Classic RAG就已经足够。强行引入知识图谱反而可能增加系统复杂度。但如果业务问题经常涉及跨文档、跨实体、跨系统的关联分析Graph RAG的价值就会变得明显。比如企业内部知识管理用户问的常常不是“某条制度是什么”而是“某个流程为什么会影响另一个流程”。比如代码仓库理解开发者关心的也不只是“这个函数在哪里”而是“这个函数被谁调用它变更后会影响哪些模块”。再比如风控、供应链、项目管理这类场景问题背后往往存在大量实体关系。单纯检索几个相似文本片段很难支撑完整判断。不过Graph RAG也不是没有代价。它需要额外做实体抽取、关系抽取、图谱构建和图谱维护。如果抽取质量不高图谱里就可能出现错误关系如果业务变化很快图谱更新不及时模型拿到的结构信息也可能过期。所以Graph RAG不是Classic RAG的无脑升级版。它更像是为复杂关系场景增加了一层知识组织方式当问题的关键不只是“哪段文本相关”而是“多个信息之间如何连接”时图结构才真正有价值。到这里RAG已经从“找文本”走到了“找关系”。但还剩下一个问题。无论是Classic RAG还是Graph RAG很多时候系统流程仍然是提前设计好的先检索什么、再扩展什么、最后怎么拼接上下文基本都由工程师预先规定。如果用户问题本身非常开放需要系统边查边判断、边判断边调整下一步那么固定流程又会显得不够灵活。这就引出了第三种架构Agentic RAG。三、Agentic RAG让模型自己决定怎么找资料如果说Classic RAG解决的是“从外部知识库里找文本”Graph RAG解决的是“把分散知识组织成关系网络”那么Agentic RAG关注的就是另一个问题当一次检索不够时模型能不能自己决定下一步该查什么在前两种架构里RAG的流程通常还是由工程师提前设计好的。Classic RAG一般是用户提问后直接检索文本再把检索结果交给模型生成回答。Graph RAG虽然引入了图谱关系但很多流程仍然是固定的比如先识别实体再扩展关系再组织上下文。这种方式稳定、清晰也更容易控制。但它的局限也很明显如果用户的问题本身比较开放或者答案需要多轮查找、逐步判断固定流程就不一定够用了。比如用户问最近这次接口超时可能和哪些代码改动有关这个问题并不是检索“接口超时”几个字就能解决的。系统可能需要先查看异常日志确认超时发生在哪个接口再根据接口名称找到对应服务接着查看最近的代码提交、配置变更、依赖服务状态如果发现某个下游服务也有异常还要继续追查调用链路。也就是说解决这个问题需要一个动态过程。模型不能只等着工程师提前写好检索路径而要在获取信息的过程中不断判断当前材料够不够下一步应该查日志、查文档、查代码还是查监控指标。这就是Agentic RAG和传统RAG最大的区别。它把模型从“最后负责生成答案的角色”推进到了“参与信息获取过程的角色”。3.1 Agentic RAG 的核心规划、行动与反馈在传统RAG中模型通常只在最后一步出现。前面的检索策略、召回数量、数据源选择、上下文拼接方式基本都由系统预先决定。模型拿到什么材料就基于什么材料回答。但在Agentic RAG中模型会参与中间过程。它可能会先分析用户问题判断这是一个单步问答还是一个需要拆解的复杂任务。然后它会把问题拆成几个子问题再根据子问题选择合适的数据源或工具。比如面对“接口超时和哪些代码改动有关”这个问题模型可能会拆出这样的路径先确认异常接口 → 再查看接口所属服务 → 再查询最近提交记录 → 再比对变更内容 → 再关联日志和监控 → 最后给出可能原因这个过程不是一次完成的。模型每获得一部分信息就会基于当前结果判断下一步是否继续。查到日志之后它可能发现超时集中在某个时间段于是继续查这个时间段附近的发布记录。查到发布记录之后它可能发现某个依赖库版本发生变化于是继续查这个依赖库是否影响网络请求。这就形成了一个循环思考当前问题 → 选择工具或数据源 → 获取信息 → 判断信息是否足够 → 决定继续检索还是生成答案在这个循环里RAG不再是一条固定流水线而是变成了一个可以迭代的信息获取过程。这也是Agentic RAG的价值所在。它适合处理那些一开始并不知道该查哪里、需要边查边判断的问题。3.2 Agentic RAG 的关键不是自由而是可控Agentic RAG听起来更智能但它并不意味着可以让模型无限自由地搜索和调用工具。恰恰相反越是让模型参与决策系统越需要约束它的行为。因为一旦模型可以自己决定下一步做什么就会引入新的工程风险。它可能反复检索相似内容导致成本失控也可能因为第一步判断错误沿着错误方向不断深入还可能在信息不足时过早生成结论给出一个看起来完整但并不可靠的回答。所以Agentic RAG的工程重点不是“让模型想查什么就查什么”而是设计一个可控的执行框架。这个框架至少要回答几个问题。第一模型可以使用哪些工具它能不能查知识库能不能查数据库能不能读代码仓库能不能访问日志平台能不能调用外部 API。不同工具对应不同权限也对应不同风险。第二模型最多能执行多少步如果没有步数限制模型可能会陷入无效循环。一个可靠的Agentic RAG系统通常需要设置最大轮数、最大检索次数、最大上下文长度和超时机制。第三模型如何判断信息是否足够如果系统没有明确的停止条件模型很容易在“不确定”和“继续查”之间摇摆。比较好的做法是让模型在每一步都记录当前结论、证据来源和缺失信息最后再判断是否已经足够回答用户问题。第四结果如何验证Agentic RAG的回答最好能够保留引用来源、中间判断和结论边界。尤其是在代码排查、故障分析、金融风控、企业决策这类场景里答案不能只是“我觉得可能是这样”而应该告诉用户依据是什么哪些信息已经确认哪些地方仍然只是推测。因此Agentic RAG并不是把系统交给模型自由发挥。它更像是在一个受控环境里让模型具备一定的自主检索、工具调用和过程调整能力。3.3 三种 RAG 架构该怎么选到这里三种RAG架构的差异就比较清楚了。Classic RAG更像是一条固定的知识问答流水线。它适合资料明确、答案集中、流程稳定的场景。只要能把相关文本找回来模型就可以基于这些材料组织回答。Graph RAG更像是在知识库之上增加了一张关系地图。它适合处理跨实体、跨文档、跨系统的问题。当答案不只藏在某一段文本里而是藏在多个信息之间的连接关系里图结构就会变得有价值。Agentic RAG更像是让模型拥有一个可控的调查过程。它适合任务开放、路径不确定、需要多轮检索和动态决策的场景。模型不只是被动接收检索结果而是会根据当前信息决定下一步该查什么。所以这三种架构并不是简单的替代关系。不是有了Graph RAGClassic RAG就过时了也不是有了Agentic RAG前两种架构就没有意义了。在很多真实项目里它们甚至会组合在一起使用。一个系统可以先用Classic RAG做基础文档问答再用Graph RAG处理复杂关系分析最后在少数开放任务中引入Agentic RAG让模型动态选择数据源和工具。真正做架构选型时应该先回到问题本身。如果用户只是想快速查一段资料Classic RAG就足够。如果用户关心的是多个对象之间的关系Graph RAG更合适。如果用户的问题需要边查边判断Agentic RAG才真正有价值。所以RAG的演进不是从低级到高级的线性升级而是从“找文本”走向“理解关系”再走向“规划信息获取过程”。最终要回答的不是哪种架构更先进而是你的业务问题到底需要哪一种能力。写在文后期待您的一键三连如果有什么问题或建议欢迎在评论区交流