一文看懂三种 RAG 架构：Classic RAG、Graph RAG 与 Agentic RAG

很多团队第一次把大模型接进业务系统时都会问同一个问题「能不能让 AI 回答我们公司内部文档里的问题」比如员工手册里的假期政策、产品文档里的功能说明、客服知识库里的标准话术、会议纪要里的决策记录甚至是业务系统里的客户、供应商、订单信息。这个需求听起来很自然。既然资料已经在那里为什么不能让大模型读完之后直接回答问题在于普通大模型并不知道你的内部资料。它可能知道很多通用知识但不知道你公司最新的制度、私有产品细节、部门例外规则也不知道昨天刚更新的会议纪要。更麻烦的是当它不知道答案时也可能生成一段看起来很流畅、但其实没有依据的回答。这就是 RAG 出现的原因。RAG全称是 Retrieval-Augmented Generation中文一般叫「检索增强生成」。它的基本思路很简单先把相关资料找出来再让大模型基于这些资料回答。这些知识源可以是文档、手册、FAQ、工单、数据库也可以是企业内部的各种业务系统。也就是说RAG 不是让模型只靠参数里的「记忆」回答而是先给它一份可参考的上下文。这样大模型就从「凭印象回答」变成了「带着资料回答」。不过RAG 发展到现在已经不只是「向量检索 大模型」这一种形态。常见的架构至少有三类Classic RAG、Graph RAG 和 Agentic RAG。理解它们其实不用一上来就记复杂概念。抓住三个动词就够了•Classic RAGretrieves检索。•Graph RAGconnects连接。•Agentic RAGreasons推理。Classic RAG 负责「找资料」Graph RAG 负责「找关系」Agentic RAG 负责「决定下一步该查什么」。下面这张图可以先建立一个整体印象三种架构的左侧都从同一批知识资料出发真正的差异发生在问题到来之后。pic三种 RAG 架构的核心区别Classic RAG先把相似内容找出来Classic RAG 是最经典、也最容易落地的 RAG 形式。它做的事情可以概括成一句话把用户问题转成向量再从知识库里找出最相似的文本片段最后交给大模型生成答案。这里的关键是「相似」。传统关键词搜索更像是在找字面匹配比如用户搜「育儿假」系统就去找包含「育儿假」的段落。而向量搜索会把文本转成一组数字也就是 embedding用来表示语义。这样一来即使用户问的是「孩子出生后可以休多久假」系统也可能找到「育儿假政策」相关内容因为两者在语义上接近。Classic RAG 的典型流程是这样的先把文档切成多个文本块也就是 chunk把每个 chunk 转成 embedding把这些 embedding 存入向量数据库用户提问时把问题也转成 embedding在向量库里检索 top K 个相似片段把问题和检索到的片段一起交给大模型由大模型生成最终答案。这里有一个容易误解的点不是只把问题做 embedding而是文档在入库时已经提前 embedding问题是在查询时实时 embedding。所以Classic RAG 的核心成本分成两部分一部分在知识库准备阶段一部分在用户查询阶段。举个例子。员工问「育儿假申请截止日期是什么时候」Classic RAG 会去 HR 政策、员工手册、公司制度文档里找最相关的段落然后把这些段落交给大模型让它生成一段自然语言回答。这类问题非常适合 Classic RAG因为答案通常就在某个文档片段里。系统不需要复杂推理只要把材料找准回答就不会差太多。所以在这些场景里Classic RAG 往往是第一选择• FAQ 问答• 政策查询• 产品手册问答• 客服知识库• 员工制度查询• 内部文档检索助手。它的优势也很明显简单、快、成本低、工具链成熟而且行为相对可预测。对于很多企业知识库来说先把 Classic RAG 做好已经能解决大量高频问题。但它的局限也来自同一个地方它本质上是在找「相似文本」。如果答案就在某个段落里它表现很好但如果答案藏在多个文档、多个实体、多个关系之间它就容易卡住。比如这个问题「A 的经理的经理是谁」这个问题可能需要先查员工 A 属于哪个团队再查 A 的直属经理是谁再继续查这个经理的上级是谁。答案不一定在一个段落里而是藏在组织关系链里。Classic RAG 可能能找到员工目录也可能找到组织调整通知但它不一定能稳定地沿着关系一步步走到答案。再比如供应链场景「哪些产品会受到某个芯片短缺影响」这个答案可能分散在产品文档、零部件清单、供应商资料和库存系统里。单纯靠相似度检索很可能只拿到「相关但不完整」的片段。这就是 Classic RAG 的边界。Classic RAG 擅长「找到相关内容」但不擅长「沿着关系继续往下找」。当答案不是「在文档里」而是「在文档之间」时就需要 Graph RAG。Graph RAG不只找文本还要找关系Graph RAG 的重点不是把 Classic RAG 推倒重来而是在文本检索之外增加一层「关系结构」。它不只是问「哪些文本和用户问题最相似」它还会问「这些人、产品、零件、部门、供应商之间到底是什么关系」这层关系结构通常叫知识图谱。知识图谱的表达方式很直观。它会把知识拆成实体和关系。实体可以是• 人• 产品• 零件• 团队• 部门• 供应商• 客户• 系统模块。关系可以是• 员工 A 汇报给经理 B• 产品 X 使用零件 Y• 零件 Y 来自供应商 Z• 团队 M 负责系统 N• 客户 C 购买了产品 P。这样系统看到的就不只是一堆文本片段而是一张可以遍历的关系网。Graph RAG 的基本流程可以理解为两条线并行文本仍然可以被切块、embedding并放进向量库系统还会从文本中抽取实体和关系构建知识图谱。当用户提问时系统既可以做文本检索也可以沿着图谱关系查找。举个更具体的例子。用户问「哪些产品会受到半导体短缺影响」相关事实可能分散在不同资料里• 产品 X 使用电路板 Y• 电路板 Y 需要芯片 Z• 芯片 Z 来自供应商 S• 供应商 S 当前受到半导体短缺影响。如果只用 Classic RAG它可能会检索到几段关于「半导体短缺」或「供应商 S」的内容但不一定能把「供应商 → 芯片 → 电路板 → 产品」这条链路完整串起来。Graph RAG 的优势就在这里它可以沿着图谱路径走下去找到受影响的产品范围。所以Graph RAG 特别适合这些问题• 影响分析一个变化会影响哪些下游对象• 依赖分析某个系统、组件、供应商被哪些对象依赖• 组织关系查询某个人属于哪个团队汇报链是什么• 审批链查询一个流程要经过哪些角色• 供应链分析某个零件短缺会影响哪些产品• 因果链解释一个事件如何在系统中传播你会发现这些问题有一个共同点答案不是孤立段落而是一条路径、一张网、一组连接关系。这也是 Graph RAG 和 Classic RAG 的核心差异。Classic RAG 更像是在资料库里找相似页面Graph RAG 更像是在地图上看路线。Graph RAG 解决的是「信息之间如何连接」的问题。当然Graph RAG 也不是免费的午餐。它的成本主要在「建图」和「维护图」。首先系统要从原始文本里抽取实体和关系这一步需要足够准确。如果实体识别错了关系抽取错了后面的图谱遍历就会跟着错。其次业务世界一直在变化。团队会调整产品会改版供应商会替换客户状态会变化。只要现实关系变了图谱也要持续更新。最后图谱只能遍历已经建模的节点和边。如果某个领域没有被建进图谱系统就没有路径可走。它不能凭空连接一个不存在的关系。所以Graph RAG 不是用来替代 Classic RAG 的而是用来增强那些「关系密集型」问题的。如果你的业务问题主要是文档问答用 Classic RAG 就够了如果你的问题经常涉及产品、组织、供应链、审批流、依赖关系那么 Graph RAG 的价值才会明显起来。Agentic RAG让系统决定下一步该查什么如果说 Classic RAG 的关键词是「检索」Graph RAG 的关键词是「连接」那么 Agentic RAG 的关键词就是「行动」。它不再只是执行一次固定检索流程而是让 Agent 根据问题目标自己判断下一步该查什么、用什么工具、证据够不够、要不要重新规划。你可以把它理解成一个会调查问题的助手。Classic RAG 像是你问它一句它去资料库里找几段相关内容。Graph RAG 像是它不仅看资料还会沿着关系网查路径。Agentic RAG 则更进一步它会先想一想这个问题到底应该怎么查。比如用户问「为什么我们的产品销量下降了」这个问题很难靠一次检索回答。因为它没有一个明确的资料入口。答案可能和销售数据有关也可能和价格调整有关可能和竞品活动有关可能和库存有关也可能和客服投诉、营销投放、渠道政策都有关系。这时候Agentic RAG 可能会做这样的事情先拆解问题销量下降发生在哪个产品、哪个地区、哪个时间段查询销售数据库看下降趋势是否真实存在查询价格历史看是否有调价查询营销活动记录看投放是否减少查询客服工单看是否出现集中投诉查询库存系统看是否有缺货如果证据不足继续选择新的工具或数据源最后综合多个来源给出原因假设和证据链。这就是 Agentic RAG 和前两者最大的区别它不是固定地「检索一次然后回答」而是围绕目标不断规划、查询、验证和重规划。在这个过程中Agent 可以调用不同工具比如• 内部文档搜索• 向量数据库• 知识图谱查询• SQL 数据库• Web API• 表格读取器• 工单系统• 日志系统• BI 报表。所以Agentic RAG 特别适合路径不确定的问题。典型场景包括• 复杂问题分析• 业务异常归因• 跨系统调查• 多数据源综合判断• 技术排障• 竞品分析• 投资研究• 运营复盘。这些问题的共同特点是你很难提前写死一套检索流程。有时第一步查完才知道第二步该查什么第二步查完又发现需要回头验证第一步的假设。Agentic RAG 的价值就在这里。它把 RAG 从「固定管道」变成了「动态调查」。Agentic RAG 解决的是「面对复杂问题系统下一步该怎么行动」的问题。但也正因为它更灵活代价也更高。首先它通常需要更多次 LLM 调用。每一次规划、工具选择、结果判断、重新规划都可能消耗 token。其次它的延迟更难预测。Classic RAG 可能一次检索就结束而 Agentic RAG 可能要跑好几轮工具调用。再次它更难调试。当答案错了你不只要看检索结果对不对还要看 Agent 为什么选了这个工具为什么跳过另一个数据源为什么认为证据已经足够。所以Agentic RAG 不是默认更高级也不是所有场景都应该上。如果只是 FAQ 问答用 Agentic RAG 就像为了拧一颗螺丝搬来一台挖掘机。能做但没必要。真正需要它的是那些模糊、多步骤、跨系统、无法提前定义查询路径的问题。到底该怎么选看问题形状不看架构名字很多人讨论 RAG 架构时容易陷入一个误区总想问哪个更先进。但更实用的问题应该是「我的业务问题长什么样」选择 RAG 架构不是看名字新不新而是看问题的形状。第一看问题能否一步命中答案如果问题可以直接从一个文档片段中回答优先 Classic RAG。比如• 产品 A 的保修期多久• 年假申请截止日期是什么时候• 某个功能怎么配置• 某条政策的适用范围是什么这类问题通常有明确答案材料也相对集中。用 Classic RAG 足够简单、便宜、稳定。不要一开始就把系统做复杂。第二看答案是否依赖关系链如果问题需要跨实体、跨文档、跨关系查找就考虑 Graph RAG。比如• 哪些产品依赖某个组件• 某个供应商变化会影响哪些下游产品• 某个审批链上有哪些人• 某个客户和哪些项目、合同、团队有关这类问题的重点不是某段文字而是对象之间的关系。如果你发现用户经常问「谁影响谁」「谁依赖谁」「谁和谁有关」那就说明你的系统可能需要图谱能力。第三看查询路径能否提前定义如果你一开始就不知道该查哪个系统、哪类数据、哪条线索就考虑 Agentic RAG。比如• 分析销量下降原因• 调查某个客服问题的背景• 判断一个业务异常来自哪个环节• 对一批竞品做综合研究• 排查线上故障的可能原因。这类问题不是「找一段资料」就能结束而是需要系统边查边判断。Agentic RAG 适合这种任务但前提是你能接受更高成本、更长延迟和更复杂的调试。可以用一张表总结三者差异架构核心动作适合问题主要优势典型代价Classic RAG检索一跳问答、文档查询、FAQ快、简单、成本低、工具链成熟不擅长关系链和多跳问题Graph RAG连接依赖分析、影响分析、组织关系、供应链能沿关系路径查找和解释建图与维护成本高Agentic RAG推理多步骤调查、复杂归因、跨系统分析灵活能动态选择工具延迟高、成本高、调试难如果只记一句话可以这样记Classic RAG 解决「资料在哪里」Graph RAG 解决「资料之间怎么连」Agentic RAG 解决「下一步该查什么」。从 Classic RAG 到 Graph RAG再到 Agentic RAG系统的灵活性越来越强但延迟、成本和调试难度也会同步上升。所以现实中的最佳方案往往不是三选一而是混合架构。一个更稳妥的路径是先用 Classic RAG 解决高频、明确、低成本的问题遇到关系链和依赖链问题再引入 Graph RAG遇到开放式、多步骤、跨系统调查再交给 Agentic RAG。这也符合工程实践里的一个基本原则先用简单方案解决 80 的问题再为真正复杂的问题增加复杂度。不要为了追新概念而上复杂架构。架构的价值不在于名字而在于它能不能匹配你的问题。最后再回到开头那三个动词• Classic RAG retrieves它负责检索• Graph RAG connects它负责连接• Agentic RAG reasons它负责推理。当你遇到一个新的 RAG 方案时也可以用这三个问题判断它是否适合你它到底在检索什么它到底在连接什么它到底在推理什么把动词看清楚架构选择就没那么复杂了。如果你正在做企业知识库你现在最需要解决的是「找资料」「理关系」还是「多步骤调查」你更倾向从 Classic RAG 起步还是直接尝试 Graph RAG / Agentic RAG学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】