很多人第一次看到“8种 RAG 架构”时会下意识地问哪一种最先进是不是应该从 Naive RAG 一路升级到 Agentic RAG答案是RAG 不是一条从初级到高级的升级路线而是一组可以叠加的设计选择。最近三条推文放在一起看刚好能拼出一张更完整的地图第一条比较了标准 RAG、Graph RAG 和 Agentic RAG重点是“如何找到信息”第二条列出了 8 种常见 RAG重点是“检索、查询改写和编排分别怎么增强”第三条介绍 Pathway 的实时 RAG重点则是“知识库能不能跟着源数据变化”。真正需要回答的不是“我该选哪一种 RAG”而是四个问题知识以什么单位被索引用什么方式检索查询过程需要多少判断数据多久必须更新一、先看最基础的 RAG它到底在做什么标准 RAGRetrieval-Augmented Generation检索增强生成通常有五步把文档切成若干片段用 Embedding 模型把片段转换成向量把向量存进向量索引把用户问题也转换成向量找出相似片段把问题和检索结果一起交给 LLM 生成回答。它适合“答案就在某一段文字里”的问题例如“报销上限是多少”如果知识库里有一段明确写着报销上限语义相似度检索通常就能把它找出来。它的优点是结构简单、延迟低、容易评估也是很多系统应该先做好的基线。但向量相似不等于事实关系。问题一旦需要把多个文档里的信息串起来单纯 Top-K 检索就可能漏掉中间环节。下面这张动图用同一个问题展示了三条路径标准 RAG 依赖向量相似度Graph RAG 依赖实体关系Agentic RAG 则让 Agent 决定调用哪些工具、以什么顺序调用。图akshay_pachaar 对标准 RAG、Graph RAG 和 Agentic RAG 的对比。动图来自原推文。二、三条主路径相似度、关系和行动1. 标准 RAG找到“像问题”的片段假设知识库里有三条事实Checkout 服务调用 Payments APIPayments API 运行在 cluster-3cluster-3 周五维护。现在问“周五维护会影响 Checkout 服务吗”向量检索可能找到第一条和第三条因为它们分别接近“Checkout”和“周五维护”。但第二条只提到 Payments API 和 cluster-3和问题表面上的词都不太相似可能被 Top-K 排除。这只是一个说明机制的例子不是说向量检索必然找不到第二条。切块方式、Top-K、重排模型、元数据过滤和查询改写都会改变结果。它真正揭示的是相似度检索擅长找局部相关文本不天然表示跨文档关系。2. Graph RAG先把事实变成关系网络Graph RAG 会在索引阶段抽取实体和关系把它们组织成知识图谱查询阶段再围绕实体、邻居和关系进行检索或遍历。在上面的例子中系统可以沿着Checkout 服务 → Payments API → cluster-3 → 周五维护找到完整路径因此更适合多跳问题、依赖关系、组织关系和影响分析。不过Graph RAG 不是“有了图数据库就自动会推理”。图谱抽取可能出错关系类型可能过于粗糙图遍历也可能带来大量无关上下文。微软 GraphRAG 的实现还会构建社区层级和社区摘要并提供 Local Search、Global Search、DRIFT Search 以及基础向量搜索等不同查询模式。实际系统经常是“向量检索 图检索 原文片段”的组合而不是只查图、不查文本。3. Agentic RAG让 Agent 决定怎么查Agentic RAG 的变化不一定是换了某种数据库而是把固定流程变成了可决策的工作流。Agent 可以根据问题决定先查内部文档还是先查数据库是否需要搜索网页或调用 API是否把问题拆成多个子问题是否需要再次检索、验证或追问用户。因此它适合“多来源、强工具依赖、步骤不固定”的任务例如调查一个线上故障先读部署文档再查监控再查工单最后给出带证据链的判断。代价也很明显调用次数更多、延迟和成本更难预测错误路径更难调试。如果问题只是“密码策略是什么”用 Agent 往往是过度设计。三、“8种 RAG”其实来自不同维度第二条推文的价值不在于把 8 个名词排成榜单而在于提醒我们这些名字并不处于同一层级。图akshay_pachaar 总结的 8 种 RAG。图中把不同增强方式放在了一张架构图里便于建立直觉实际工程中它们可以组合。第一维你索引和检索的是什么Naive RAG以文本片段为主按向量相似度检索。Multimodal RAG同时处理文字、图片、音频、表格或图表。它不一定意味着所有模态共享同一个向量空间也可能是不同编码器检索后再融合上下文。Graph RAG把实体、关系和社区结构纳入检索。Hybrid RAG把多种检索信号结合起来。推文强调的是向量检索与图检索但工程实践里“Hybrid”也常指向量检索与 BM25 等关键词检索的融合。第二维你如何改变用户的问题HyDEHypothetical Document Embeddings假设文档嵌入 先让 LLM 根据问题生成一段“假设答案”再把这段假设文档做向量化用它去检索真实文档。它解决的是“用户问题的写法”和“文档的写法”差距很大。例如用户问的是一句口语而文档是一篇技术规范。假设答案可能更接近文档的表达方式从而改善召回。但假设答案本身可能包含错误事实。HyDE 的关键不是把假答案直接交给用户而是把它当作检索探针最终仍要以真实文档为依据同时它增加了一次 LLM 调用。第三维你如何检查检索质量Corrective RAG纠错式 RAG会先评估检索结果的质量。结果不可靠时可以过滤无关内容、重新检索或转向外部搜索。这比“检索到什么就全部塞给 LLM”更稳健但“外部搜索”不等于“可信来源”。生产系统还需要域名白名单、来源评级、时间范围、引用要求和权限控制。纠错模块本身也可能误判所以它应该被评测而不能只靠一个看起来合理的分数。第四维你如何决定检索路径Adaptive RAG根据问题难度在直接检索、多轮检索和问题拆解之间动态选择Agentic RAG进一步把检索放进 Agent 工作流由 Agent 规划、调用工具和组合多个来源。可以把两者理解为Adaptive RAG 更像“动态路由器”Agentic RAG 更像“能够执行任务的调度者”。两者边界并不总是严格很多系统会同时使用。所以8 种 RAG 更适合画成一个组合矩阵而不是一条技术等级链知识表示文本 / 多模态 / 图 检索信号向量 / 关键词 / 图遍历 / 混合 查询处理原问题 / HyDE / 子问题拆解 质量控制重排 / Corrective / 引用与验证 流程编排固定链路 / Adaptive / Agentic四、一个经常被忽略的上游问题切块可能就是错的第一、第二条推文都引用了 Akshay 的另一篇文章观点很尖锐很多 RAG 团队一直在调 Embedding、Reranker 和 Top-K却很少重新审视“一个 chunk 是否是正确的知识单位”。普通切块通常只知道字符数或 Token 数不知道一个观点从哪里开始、在哪里结束当前段落属于哪个版本这条信息谁可以访问结论依赖哪些上下文。于是系统可能召回半张表、没有前提的结论或者把当前版本和废弃版本一起交给模型。文章提出的 IdeaBlock 可以理解成一种“问答数据包”一个问题、一个经过验证的答案再加上来源、版本、权限等级等结构化字段。它把治理信息放在知识单元本身而不是全部留给应用层补丁。这个方向值得借鉴但文中的 2.29 倍、13.55% 等数字来自作者所述的内部 benchmark并不等于所有数据集、模型和切块策略都能复现同样结果。推文还提到“语料缩小 40 倍、查询 Token 减少 3 倍、相关性提升 2.3 倍”这些应当看作项目方的宣传性结果不能直接当成通用承诺。更稳妥的做法是在自己的数据上比较“普通切块”和“结构化知识单元”同时评估召回率、答案正确率、权限过滤、更新成本和人工审核成本。RAG 的很多问题发生在向量库之前。如果索引里充满重复、过期、无边界的片段后面叠加再多 Agent 和 Graph也只是更复杂地处理脏数据。五、Pathway 提醒我们的另一件事知识必须保持新鲜第三条推文介绍了 Pathway 的 llm-app把实时数据源、文档处理、向量检索和 LLM 管道放在同一套实时数据流里。官方文档的核心说法是文件或数据源发生变化时Pipeline 自动更新文档存储和索引而不是每次都手工跑 ETL、重新嵌入和同步。图CycleDecoded 推文中的 Pathway 实时数据框架示意。这解决的是“检索到的内容是不是最新版本”与 Graph RAG 或 Agentic RAG 解决的问题不同。一个系统完全可以同时是实时数据接入 ↓ 结构化解析与去重 ↓ 向量 关键词 图的混合检索 ↓ 低质量结果触发纠错或外部验证 ↓ LLM / Agent 生成带引用的回答但“实时”不等于“瞬间、零成本、永远正确”。上线前至少要确认源数据更新到索引的延迟是多少删除和权限变更是否同样实时重嵌入和重算图谱的成本如何控制内存索引是否满足持久化、规模和故障恢复要求数据源本身是否可信更新是否需要人工审核。因此Pathway 更像是在提醒我们补齐 RAG 的“数据流和新鲜度”一层而不是宣称所有场景都不再需要专用向量数据库。六、实际项目应该怎么选可以先按问题类型做一个粗略决策问题特征优先考虑原因单文档、直接事实标准 RAG简单、快、容易评估文字、图片、表格混合Multimodal RAG召回跨模态证据实体关系、多跳影响分析Graph 或 Hybrid RAG保留关系路径用户问题和文档表达差异大HyDE、查询改写缩小查询与文档的表达鸿沟数据经常失效或需要外部事实Corrective 实时索引先保证新鲜再验证质量需要查多个系统并执行步骤Adaptive / Agentic RAG让流程按任务动态展开文档重复、版本混乱、权限复杂结构化知识单元 元数据在索引层解决治理问题一个企业内部知识助手通常不需要一开始就做成“全套 RAG”先用高质量解析、合理切块和权限元数据做好标准 RAG用一组真实问题建立召回和答案评测集发现多跳关系问题再加图或混合检索发现数据过期再建设实时更新和删除传播只有任务确实跨系统、跨步骤时才引入 Agent对高风险回答增加来源引用、纠错和人工审核。这条顺序的好处是每次只引入一种复杂性也能知道效果变化究竟来自哪里。结语不要问“哪种 RAG 最先进”把三条推文合在一起RAG 的完整问题空间可以这样理解索引层决定知识单元是否清晰、去重、可治理检索层决定系统依据相似度、关键词、关系还是多模态信号找资料查询层决定是否需要 HyDE、拆题、纠错和动态路由编排层决定是否由 Agent 调用多个工具数据层决定知识是否能跟着源系统实时更新。所以Naive RAG、Graph RAG、Agentic RAG、HyDE、Corrective RAG、Multimodal RAG 和实时 RAG 并不是互相排斥的“流派”。它们回答的是不同问题也可以组合成一条完整的生产链路。先把知识单元和数据新鲜度做好再按真实失败案例增加图、纠错或 Agent。这通常比直接追逐一个听起来更高级的 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%免费】