---

🔥 个人主页：铁皮哥（欢迎关注）
📌 作者简介：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 RAG，Classic RAG 就过时了；也不是有了 Agentic RAG，前两种架构就没有意义了。

在很多真实项目里，它们甚至会组合在一起使用。

一个系统可以先用 Classic RAG 做基础文档问答，再用 Graph RAG 处理复杂关系分析，最后在少数开放任务中引入 Agentic RAG，让模型动态选择数据源和工具。

真正做架构选型时，应该先回到问题本身。

如果用户只是想快速查一段资料，Classic RAG 就足够。

如果用户关心的是多个对象之间的关系，Graph RAG 更合适。

如果用户的问题需要边查边判断，Agentic RAG 才真正有价值。

所以，RAG 的演进不是从低级到高级的线性升级，而是从“找文本”，走向“理解关系”，再走向“规划信息获取过程”。

最终要回答的不是哪种架构更先进，而是你的业务问题到底需要哪一种能力。

写在文后

期待您的一键三连！如果有什么问题或建议欢迎在评论区交流！