RAG架构全解析：从基础到高级，打造你的企业级知识库问答系统！

本文详细介绍了RAG（Retrieval-Augmented Generation）架构的多种变体，从基础的Naive RAG和Standard RAG开始，逐步深入到Advanced RAG、Hybrid Search RAG、Rerank型RAG、文档增强型RAG、Agentic RAG、Router RAG、GraphRAG、RAPTOR/Hierarchical RAG、Structured RAG以及Multimodal RAG等高级架构。文章涵盖了每种架构的流程、应用依据、适合场景和局限性，并提供了典型产品组合和应用案例，旨在帮助企业构建高效、精准的知识库问答系统，提升信息检索和生成的效果。

一. 基础知识库RAG：Naive RAG / Standard RAG

1.1 架构流程

最基础，最常见的 RAG 架构。

文档上传 → 文档解析 → 文本切块 Chunking → Embedding 向量化 → 写入向量库 / 搜索索引 → 用户提问 → 向量检索 Top-K → 拼接上下文 → LLM 生成答案

技术核心

大模型本身不一定知道企业私有知识，所以先从外部知识库检索相关内容，再把检索结果作为上下文交给模型生成答案。

这类架构通常包括 4 个主要组件：

1.2 应用依据

Dify 的 Knowledge 文档中已经包含 Hybrid Search、Rerank、Parent-child Retrieval、Metadata Filtering 等知识库增强能力，说明它不只是基础 RAG，而是逐步向生产级 RAG 发展。RAGFlow 官方也强调其高精度 hybrid search，结合 vector search、BM25、自定义 scoring 和 reranking。

1.3 适用场景

1.4 局限

1. 检索结果不一定准
2. Chunk 切分可能破坏上下文
3. 只做向量检索时，对专有名词、编号、代码、日期不稳定
4. Top-K 召回可能带入噪声
5. 大模型可能忽略证据，自行发挥
6. 很难处理复杂多跳问题

二. Advanced RAG：增强型 RAG

2.1 架构流程

Advanced RAG 是目前企业落地最常用的架构。

文档解析 → 语义切块 → Embedding + 倒排索引 → 用户问题 → Query Rewrite / Query Expansion → Hybrid Search → Metadata Filter → Rerank → Context Compression → LLM Grounded Generation → Citation / Source Attribution → 评估与监控

2.2 和基础 RAG 的区别

2.3 应用依据

Azure AI Search 官方 RAG 文档同时支持 classic hybrid search 和 agentic retrieval；它的 hybrid search 文档说明，混合搜索会在一个请求里同时执行 full-text 和 vector 查询，并用 RRF 融合结果。AWS Bedrock Knowledge Bases 也支持 hybrid search，作为 semantic search 之外的查询选项。

开源和搜索引擎侧也有类似实现。Haystack 官方教程把 hybrid retrieval 定义为结合 keyword-based 和 embedding-based retrieval；Elastic 官方 RAG 文档强调 Elasticsearch 支持 full-text search、vector search、hybrid search、filtering、aggregations 和 security；OpenSearch 官方文档也说明 hybrid search 结合 keyword 和 semantic search，并通过 search pipeline 归一化和合并分数。

2.4 典型产品组合

三. Hybrid Search RAG：关键词 + 向量混合检索

3.1 架构流程

用户问题 → Query Rewrite → 向量检索 → BM25 / 关键词检索 → 元数据过滤 → RRF / 加权融合 → Rerank → 返回上下文 → 生成答案

3.2 应用依据

Azure AI Search 的 hybrid search 是一个官方能力，文档说明它在同一请求里同时运行全文查询和向量查询，并用 Reciprocal Rank Fusion 融合结果。Elastic、OpenSearch、Haystack、Dify、RAGFlow 也都把 hybrid search 作为 RAG 或检索增强的重要能力。

3.3 适合场景

3.4 局限

Hybrid Search 会提升召回，但也会带来：

1. 检索链路更复杂
2. 需要调 BM25、向量权重、RRF 参数
3. 多路召回后噪声更多，通常必须配 Rerank
4. 成本和延迟比单路向量检索更高

四. Rerank 型 RAG：召回后精排

4.1 架构流程

Query → Retriever 召回大量候选 → Reranker 逐条计算 query-document 相关性 → 重新排序 → 选择最相关片段 → 生成答案

4.2 应用依据

Pinecone 官方文档把 reranking 描述为 two-stage vector retrieval 的一部分：先查询 index 得到候选结果，再把 query 和候选文档交给 reranking model 重新评分，提升 RAG pipeline 的质量。NVIDIA NeMo Retriever 也提供 reranking API，并把它用于企业 RAG 应用中的相关数据查找。

腾讯云知识引擎原子能力的 API 文档也把 RAG 链路拆成文档解析、拆分、embedding、多轮改写、重排序等能力；RAGFlow 的检索组件文档也明确支持 rerank model，并提示 rerank 会增加响应时间。

4.3 Rerank 类型

4.4 适合场景

1. 知识库规模大
2. Top-K 经常有噪声
3. 答案经常引用错来源
4. 同一问题召回多个相似文档
5. 要求高准确率
6. 愿意接受额外延迟

4.5 局限

1. 会增加延迟
2. 会增加模型调用成本
3. Rerank 输入文档数量不能过大
4. Reranker 本身也需要评测和调参

五. 文档增强型 RAG：Document-aware RAG

这一类架构重点不在检索算法，而在文档解析、切块、结构保留和上下文回填。

5.1 典型流程

PDF / Word / PPT / HTML / Excel → OCR / Layout Analysis → 标题、表格、图片、页眉页脚识别 → 语义切块 → Parent-child chunk → 元数据写入 → 检索 child chunk → 回填 parent context → 生成答案

5.2 关键方法

5.3 应用依据

Unstructured 官方说明其平台和工具用于 ingest 和 process 非结构化文档，以增强 RAG；其文档处理逻辑包括把文档拆解成结构化元素。腾讯云知识引擎原子能力也提供文档解析和文档拆分，支持把 PDF、DOCX、TXT 等解析为结构化数据，并提到表格、公式、图片、标题、段落、页眉页脚等内容元素的解析能力。

Dify 的 Knowledge 文档中列出了 Parent-child Retrieval、Metadata Filtering、Hybrid Search、Rerank 等能力，这说明文档增强和上下文管理已经被产品化。

5.4 适合场景

• PDF 多
• PPT 多
• 合同多
• 政策制度多
• 报告很长
• 表格和图片多
• 扫描件多
• 答案需要页码和引用

5.5 局限

1. 文档解析成本高
2. PDF 版式复杂时容易解析错
3. 表格、图片、公式处理难度大
4. 需要根据业务文档类型定制 chunk 策略

六. Agentic RAG：Agent 驱动的 RAG

6.1 核心思想

Agentic RAG 是让 Agent 自己决定：

• 要不要检索？
• 查哪个知识库？
• 是否拆成多个子问题？
• 是否调用数据库/API？
• 检索结果够不够？
• 是否需要重查？

6.2 架构流程

用户问题 → Planner / Agent → 意图识别 → Query Decomposition → Router 选择工具 ├─ 文档知识库 ├─ 数据库 ├─ API ├─ Web Search └─ 业务系统 → 多轮检索 / 工具调用 → 证据整合 → 自我检查 → 最终回答

6.3 应用依据

Azure AI Search 的 agentic retrieval 官方文档把它定义为面向复杂问题的 multi-query pipeline，用于 chat、copilot apps 和 agent-to-agent workflows；它会用 LLM 把复杂查询拆成更小、更聚焦的子查询。LangChain 官方文档也把 Agentic RAG 定义为让 Agent 在交互中决定何时、如何检索；LangGraph 官方教程提供了 retrieval agent 示例，让 LLM 决定是否从 vectorstore 检索上下文。

LlamaIndex 的 Router Query Engine 则提供了另一种实现：在多个 query engine 中选择合适的一个执行查询，这适合把“摘要引擎、向量检索、SQL 查询、图检索”等统一到一个路由层。

6.4 适合场景

企业 Copilot

投研助手

法务助手

复杂客服 Agent

多知识库问答

需要查数据库 + 文档 + API 的场景

需要多步分析和综合判断的任务

6.5 局限

Agentic RAG 很强，但复杂度也高：

1. 调用链路长，延迟高
2. Agent 规划可能不稳定
3. 成本不可控
4. 需要工具权限管理
5. Debug 难度大
6. 需要 tracing、日志、评估体系

七. Router RAG / Multi-source RAG：多知识源路由架构

7.1 核心思想

企业知识不是都在一个知识库里，通常分布在：

1. 制度文档
2. 产品手册
3. 工单系统
4. 数据库
5. CRM
6. ERP
7. 代码库
8. Wiki
9. SharePoint
10. Confluence
11. Slack / 飞书 / 企业微信

Router RAG 的目标是：先判断问题应该去哪查。

7.2 架构流程

用户问题 → Intent Classifier / Router → 选择数据源 ├─ 文档知识库 ├─ SQL 数据库 ├─ 图数据库 ├─ 搜索引擎 ├─ API └─ Web → 执行对应查询 → 汇总证据 → 生成答案

7.3 应用依据

LlamaIndex Router Query Engine 官方文档说明它可以从多个候选 query engine 中选择一个来执行查询；LangChain Agentic RAG 文档则强调 Agent 只需要能够访问一个或多个外部知识工具，就可以形成 RAG 行为。

7.4 局限

1. Router 判断错会导致整条链路失败
2. 多数据源权限管理复杂
3. 需要统一 metadata 和 schema
4. 多源结果合并需要去重、冲突处理和可信度排序

八. GraphRAG：知识图谱增强 RAG

8.1 核心思想

普通 RAG 主要基于 chunk 相似度检索。GraphRAG 则把文档中的实体和关系抽取出来，构建知识图谱，再基于图结构做检索和推理。

8.2 架构流程

文档集合 → 实体抽取 → 关系抽取 → 构建知识图谱 → 社区发现 / 图聚类 → 社区摘要 → 用户问题 → 图检索 + 文本检索 → 生成答案

8.3 应用依据

Microsoft GraphRAG 官方文档把 GraphRAG 定义为一种结构化、层级化的 RAG 方法：从原始文本中抽取知识图谱，构建 community hierarchy，生成 community summaries，然后用于 RAG 任务。Microsoft 的 GitHub 项目也说明 GraphRAG 是一个数据 pipeline 和 transformation suite，用 LLM 从非结构化文本中抽取结构化数据。

LightRAG 是另一个重要开源项目，其官方说明包括 document indexing、knowledge graph exploration 和 RAG query interface；Neo4j 也有官方 GraphRAG Python package，用于构建基于 Neo4j 的 GraphRAG 应用。

8.4 GraphRAG 适合的问题

普通 RAG 擅长回答：

“某个制度怎么规定？” “某个产品参数是什么？” “某个流程怎么操作？”

GraphRAG 更适合回答：

“这些公司之间有什么关系？” “某个风险是如何传播的？” “这个项目涉及哪些部门和依赖？” “这批文档反映出哪些共同主题？” “某个政策变化对哪些业务线产生影响？”

8.5 相关项目

8.6 适合场景

投研分析 法律案件分析 企业知识网络 供应链风险分析 医疗诊断辅助 组织关系分析 复杂项目依赖分析 舆情传播路径分析

8.7 局限

1. 构建成本高
2. 实体关系抽取质量决定效果
3. 图谱更新复杂
4. 小规模 FAQ 没必要用
5. 对实时性强的知识库不一定划算

九. RAPTOR / Hierarchical RAG：层级摘要树 RAG

9.1 核心思想

原始 chunk → 向量化 → 聚类 → 每组生成摘要 → 摘要继续聚类 → 继续生成更高层摘要 → 构建树状索引

9.2 架构流程

文档 → 切块 → Embedding → Clustering → Summary → Recursive Summary Tree → Query → 检索相关节点 → 组合细节 + 摘要 → LLM 回答

9.3 应用依据

RAPTOR 论文说明，传统 RAG 多数只检索短连续文本片段，限制了对整体文档上下文的理解；RAPTOR 通过递归 embedding、clustering 和 summarizing 构建不同摘要层级的树结构。其官方实现也说明 RAPTOR 通过从文档构建 recursive tree structure 来改进长文本检索。

9.4 和 GraphRAG 的区别

9.5 局限

1. 构建索引成本高
2. 摘要质量会影响答案
3. 更新文档时可能需要重建树
4. 对短文档价值不大

十. Structured RAG：结构化数据 RAG / Text-to-SQL RAG

10.1 核心思想

很多企业知识不在 PDF，而在数据库、表格、CRM、ERP、BI 系统里。Structured RAG 的重点不是“检索文本 chunk”，而是把自然语言问题转成结构化查询。

10.2 架构流程

用户问题 → 意图识别 → 找相关数据表 / 字段 / 指标口径 → 生成 SQL / API 请求 → 执行查询 → 返回结构化结果 → LLM 解释和总结

10.3 典型变体

10.4 应用依据

LlamaIndex 有 Router Query Engine，可在多个 query engine 中选择执行对象；它也有 SQL Router Query Engine 的实践，用于在 SQL 数据库和向量数据库之间路由。LangChain 生态中也有 SQL Agent 和 retrieval agent 的实现路径。

10.5 适合场景

销售数据问答 财务报表分析 库存查询 订单查询 CRM 客户信息问答 ERP 业务查询 经营指标解释 BI Copilot

10.6 局限

1. SQL 生成错误可能带来严重后果
2. 需要权限控制和行列级安全
3. 指标口径必须清晰
4. Schema 复杂时需要 schema linking
5. 不适合完全非结构化知识

十一. Multimodal RAG：多模态 RAG

11.1 核心思想

企业文档不只是文本，还包括：

1. 图片
2. 图表
3. PPT
4. 扫描件
5. 表格
6. 流程图
7. 架构图
8. 医学影像说明
9. 产品手册截图

Multimodal RAG 的目标是同时检索和理解文本与视觉信息。

11.2 架构流程

PDF / PPT / 图片 / 扫描件 → OCR → Layout Analysis → 表格识别 → 图片描述 / 图表理解 → 文本 embedding + 图像 embedding → 多模态检索 → 多模态 LLM 生成答案

11.3 应用依据

Azure AI Search 官方文档说明其可用于 text、vector 和 multimodal content 的检索，并在 RAG 场景中支持对图片和 PDF 做 OCR、image analysis、document extraction 等处理。NVIDIA NeMo Retriever 官方定位为用于构建和扩展 multimodal data extraction、embedding 和 reranking pipelines 的微服务集合。LlamaParse 也有 multimodal RAG 能力，支持从复杂文档中索引和检索 text 与 image chunks。

11.4 适合场景

1. 财报分析
2. PPT
3. 问答
4. 扫描合同
5. 保险理赔材料
6. 制造业产品手册
7. 医学/科研图表
8. 包含大量图表的咨询报告

11.5 局限

1. 文档解析成本高
2. 图片和表格理解仍然容易出错
3. 多模态 embedding 成本较高
4. 引用溯源比纯文本更复杂
5. 对模型能力要求更高

十二. Modular RAG：模块化 RAG

12.1 核心思想

Modular RAG 不是一种单一算法，而是一种工程架构：把 RAG 拆成多个可替换模块。

Query Rewriter Router Retriever Reranker Compressor Generator Citation Builder Evaluator Guardrail Memory Tool Caller

12.2 典型架构

用户问题 → Query Understanding → Router → Retriever 1 / Retriever 2 / SQL / API / Graph → Rerank → Context Builder → Generator → Verifier → Citation → Monitor

12.3 应用依据

LangChain 官方把 retrieval 和 Agentic RAG 作为构建问答应用的重要模块；LangGraph 提供更底层的图式 Agent 编排；LlamaIndex 的 query engine、router、retriever 体系也体现了模块化组合能力。

12.4 适合场景

1. 生产级企业 AI 助手
2. 多数据源知识平台
3. 复杂业务系统集成
4. 需要持续迭代检索策略
5. 需要 A/B 测试和评估体系

12.5 局限

1. 系统复杂度高
2. 需要工程团队长期维护
3. 每个模块都需要评估
4. 出错链路更难排查

说真的，这两年看着身边一个个搞Java、C++、前端、数据、架构的开始卷大模型，挺唏嘘的。大家最开始都是写接口、搞Spring Boot、连数据库、配Redis，稳稳当当过日子。

结果GPT、DeepSeek火了之后，整条线上的人都开始有点慌了，大家都在想：“我是不是要学大模型，不然这饭碗还能保多久？”

我先给出最直接的答案：一定要把现有的技术和大模型结合起来，而不是抛弃你们现有技术！掌握AI能力的Java工程师比纯Java岗要吃香的多。

即使现在裁员、降薪、团队解散的比比皆是……但后续的趋势一定是AI应用落地！大模型方向才是实现职业升级、提升薪资待遇的绝佳机遇！

这绝非空谈。数据说话

2025年的最后一个月，脉脉高聘发布了《2025年度人才迁徙报告》，披露了2025年前10个月的招聘市场现状。

AI领域的人才需求呈现出极为迫切的“井喷”态势

2025年前10个月，新发AI岗位量同比增长543%，9月单月同比增幅超11倍。同时，在薪资方面，AI领域也显著领先。其中，月薪排名前20的高薪岗位平均月薪均超过6万元，而这些席位大部分被AI研发岗占据。

与此相对应，市场为AI人才支付了显著的溢价：算法工程师中，专攻AIGC方向的岗位平均薪资较普通算法工程师高出近18%；产品经理岗位中，AI方向的产品经理薪资也领先约20%。

当你意识到“技术+AI”是个人突围的最佳路径时，整个就业市场的数据也印证了同一个事实：AI大模型正成为高薪机会的最大源头。

最后

我在一线科技企业深耕十二载，见证过太多因技术卡位而跃迁的案例。那些率先拥抱 AI 的同事，早已在效率与薪资上形成代际优势，我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在大模型的学习中的很多困惑。

我整理出这套 AI 大模型突围资料包【允许白嫖】：

• ✅从入门到精通的全套视频教程
• ✅AI大模型学习路线图（0基础到项目实战仅需90天）
• ✅大模型书籍与技术文档PDF
• ✅各大厂大模型面试题目详解
• ✅640套AI大模型报告合集
• ✅大模型入门实战训练

这份完整版的大模型 AI 学习和面试资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】

①从入门到精通的全套视频教程

包含提示词工程、RAG、Agent等技术点

② AI大模型学习路线图（0基础到项目实战仅需90天）

全过程AI大模型学习路线

③学习电子书籍和技术文档

市面上的大模型书籍确实太多了，这些是我精选出来的

④各大厂大模型面试题目详解

⑤640套AI大模型报告合集

⑥大模型入门实战训练

👉获取方式：
有需要的小伙伴，可以保存图片到wx扫描二v码免费领取【保证100%免费】🆓