首页 / 文章

ragretrievalllmai-architecturevector-search

16种RAG架构对比：哪种模式适合哪种问题

分为四个层级，介绍16种RAG模式，涵盖从标准与混合检索到智能体、图结构及联邦式设计等类型，并附有逐月的开发顺序。

发布者：REACTAPP.TOP阅读约 14 分钟3330 词

来源: I Built 16 RAG Systems From Scratch — Here’s What Actually Works

那些编造事实、忘记消息间的内容或无法找到正确文档的聊天机器人，通常都存在同一个根本问题：其检索流程设计得过于简单，无法胜任这项任务。目前共有16种RAG架构，从最简单的检索流程到能够保护隐私的联邦系统不等，每种架构都能解决特定的缺陷。下文将介绍这些架构的具体内容、适用场景以及它们之间的区别。

RAG背后的三个问题

大型语言模型虽然令人印象深刻，但存在三个基本缺陷，导致它们在实际应用中不可靠。

首先是无端编造。模型会自信地宣称虚假信息，而且并非偶尔为之，而是频繁出现，因为它没有意识到自己不知道什么。其次是知识截止问题：每个模型在训练结束后就会停止学习，因此无法知晓之后发生的事情。第三是对隐私数据的忽视。内部文件、产品数据库和客户合同从未被纳入其训练数据中。

RAG通过在模型回答问题之前提供真实文档的参考资料，解决了以上三个问题。对比一下这两种行为：在没有检索支持的情况下：

Without RAG:
  User: "What's our refund policy?"
  LLM:  "I believe you offer a 14-day return..." (guessing)

以及随之而来的：

With RAG:
  User: "What's our refund policy?"
  → Step 1: Search internal docs → Finds: "Refunds within 30 days..."
  → Step 2: LLM reads the doc and answers accurately
  LLM:  "Your refund policy allows returns within 30 days..."

这一概念很简单，效果也很显著，不过随着应用场景的增加，系统会变得越来越复杂。每种方案背后的四步流程分别是索引、检索、增强和生成。

四层结构中的十六种模式

根据实际应用影响程度对这些模式进行分类后可分为四层。第一层涵盖了大约80%的生产系统所需的功能，而后几层则用于解决更专业的问题。

第一层：必须掌握

1. 标准RAG，基础方案

难度：初级。适合初学者使用。每个RAG项目都是从这里开始的，该方案包含四个阶段：

  1. 索引：将文档分割成小块，将其转换为嵌入向量并存储在向量数据库中。
  2. 检索：将用户的查询转换为嵌入向量，然后查找相似的文档片段。
  3. 增强：把检索到的文档片段加入提示词中。
  4. 生成：大语言模型根据该真实上下文给出回答。

核心循环大约包含十行代码：

# The core loop in ~10 lines
query_embedding = embed(user_query)
relevant_docs = vector_store.search(query_embedding, top_k=5)
context = "\n".join(relevant_docs)
prompt = f"Answer using this context:\n{context}\n\nQuestion: {user_query}"
answer = llm.generate(prompt)

它非常简单，能够处理大多数实际应用场景，其他所有功能都是在其基础上发展而来的。在基于公司文档、PDF、支持工单或任何静态知识库构建首个问答机器人时，不妨选用它。

2. 混合式RAG：最大的质量提升

难度：初级。在检索质量至关重要的情况下最为适用。通过嵌入向量进行语义搜索会忽略精确的关键词匹配，而使用BM25的关键词搜索则无法理解含义，因此混合检索方式会同时运用这两种方法。

User: "React useState hook"
→ Semantic search finds: "state management in React components"
→ BM25 finds: docs with exact string "useState"
→ Hybrid (RRF fusion): gets the best of both

互斥排名融合（RRF）无需对两个排名列表的分数进行标准化处理即可将它们合并，因此既简洁又高效。许多团队仅通过采用该方法就能提升10%到20%的准确率。它适用于任何生产系统，尤其是那些对术语和含义都要求精确的代码文档、技术手册和法律文件。

3. 为对话设计的上下文检索RAG

难度：中等。当出现后续问题时再使用此方法。常见的错误情况是：有人先询问高级套餐的信息，随后又询问其价格。传统的RAG会搜索类似“价格”这样的关键词，却找不到有用的结果。而这种改进型方法会在搜索前利用对话历史重新构建查询语句。

User turn 1: "Tell me about the Premium plan"
User turn 2: "How much does it cost?"

Before search, rewrite → "How much does the Premium plan cost?"
Now retrieve → finds the pricing document ✓

那一步重写操作通常被称为查询上下文化，在任何多轮对话型机器人中都至关重要，因为一旦有人使用代词，对话就会中断。如果用户能够提出后续问题，这就显得必不可少。

第二层级：竞争优势

4. 智能代理型RAG——2025与2026年的热门趋势

难度：中等。当你的机器人需要执行的任务不仅仅是搜索时，这种技术最为适用。传统RAG仅能获取文档，而智能代理型RAG则为模型提供一系列工具，使其能够自行选择使用哪些工具。

User: "What was NVDA's stock return last quarter vs its historical average?"

Agentic RAG decides:
  → Use web_search tool for current stock data
  → Use calculator tool for return calculation
  → Use document_retrieval tool for historical reports
  → Synthesize all three into one answer

该代理遵循ReAct模式，即先进行推理再采取行动：思考该做什么，执行动作，观察结果，然后再次思考。这实际上是一个循环中的规划与信息检索过程。它适用于金融助手、研究工具以及开发工具，凡是涉及多个数据源或实时信息的场景都适用。

5. 自主RAG，用于错误不可接受的情况

难度：高级。在准确性至关重要的场景下最为适用。该系统在处理流程中就内置了质量控制机制，不会在检索后盲目给出答案，而是要经过四道关卡。检索关卡会判断该查询是否真的需要检索；相关性关卡会判断获取的文档是否确实相关；忠实度关卡会判断答案是否基于检索到的事实；实用性关卡则会判断答案是否有帮助。若未能通过任何一道关卡，系统就会重新检索、修改答案或拒绝作答。医疗系统、法律人工智能以及金融顾问领域正是这类系统的理想应用场景，因为在这些领域，错误的答案可能会造成实际危害。

6. HyDE RAG：词汇桥接技术

难度：高级。当用户的语言与文档中的语言不同时效果最佳。HyDE即“假设性文档嵌入”之意。设想有用户询问物体为何会下落，而文档中却只提到9.81米/秒²的引力加速度。两者几乎没有共同的词汇，因此常规的嵌入搜索很可能会找不到相关结果。HyDE的巧妙之处在于先生成一个假答案，再以此进行搜索。

User: "Why do things fall down?"
→ LLM generates hypothesis: "Objects fall due to gravitational force..."
→ Search with the hypothesis (technical vocabulary)
→ Find the actual document about gravitational acceleration
→ Answer using the real document

无需任何训练，可直接与任何大语言模型配合使用。它非常适合那些面向普通用户、需要他们查询技术文档的产品。

第三级：高影响力专家

7. 图形RAG，用于关系推理

难度：中等。当需要回答X与Y之间存在何种关系时最为适用。向量搜索虽然能找到相似的文档，但无法回答诸如“哪些公司通过至少两名董事会成员与某个人有关联”这类需要图遍历才能解答的问题。图形RAG会从文档中构建知识图谱，以实体作为节点、关系作为边，然后通过查询在該图谱中寻找答案。

Text: "Dr. Chen collaborated with Dr. Patel on a 2022 study funded by NIH."

Graph nodes: Dr. Chen, Dr. Patel, 2022 study, NIH
Graph edges: COLLABORATED_WITH, FUNDED_BYQuery: "Who funded Dr. Chen's work?" → traverse: Chen → study → NIH

合规性、知识管理、科学文献以及组织网络受益最大。

8. 带记忆功能的RAG——会记住你的机器人

难度：中等。当聊天机器人需要在不同会话间记住用户信息时最为适用。普通机器人每次对话都从零开始，而这种版本增加了三种记忆机制：用于当前对话的对话记忆、存储用户偏好等信息的语义记忆，以及记录过去会话内容的情景记忆，比如两周前关于某个主题的提问。

user_profile = memory.get_user_facts(user_id)
recent_context = memory.get_recent_conversations(user_id, k=3)
answer = rag_with_context(query, user_profile, recent_context)
memory.update(user_id, query, answer)

辅导应用、客户成功机器人以及个人生产力助手受益最大。

9. 模块化RAG：无需重写即可更换任意组件

难度：中等。在需要快速迭代时最为适用。这是一种架构理念，允许独立更换每个流程组件。从FAISS切换到ChromaDB只需一行代码，而对BM25与密集检索方式进行A/B测试也无需重构。

Standard RAG:   [fixed retriever] → [fixed reranker] → [fixed LLM]

Modular RAG:    [pluggable retriever] → [pluggable reranker] → [pluggable LLM]
                     ↑ swap anytime         ↑ swap anytime        ↑ swap anytime

那些积极进行实验、研究各种配置的团队，以及那些技术架构预计会不断演变的各类项目，都是目标受众。

10. 为特定行业打造的领域专用RAG

难度：高级。适用于医学、法律或金融领域。缩写MI在心脏病专家看来是指心脏病发作，但缺乏领域知识的聊天机器人却会将其理解为密歇根州。通用型RAG在专业领域表现不佳，并非因为信息检索有误，而是系统无法理解相关术语、监管要求或安全限制。要解决这一问题，需要三项补充：包含该领域专用术语、缩写及同义词的领域词汇表；诸如每次都必须附加免责声明并注明来源之类的合规规则；以及安全防护机制，例如拒绝提供具体剂量建议并引导用户咨询专业人士。其典型应用包括临床决策支持、法律研究、金融分析以及合规监控。

11. 改进型RAG：三个来源一个答案

难度：高级。在需要同时处理结构化数据与非结构化数据时最为适用。通过单个查询，可结合SQL或其他结构化数据库获取精确数值，利用知识图谱处理数据间的关联关系，再借助文档嵌入技术获取叙事背景信息。

Query: "Tell me about the Mars Exploration Program"

→ SQL: "Mars: 1.52 AU from sun, 687-day orbit"
→ Graph: Mars → explored_by → Curiosity Rover, Perseverance
→ Text: "Mars is the fourth planet... known as the Red Planet..."→ Fused Answer: Combines all three for comprehensive, expert-level response

各类科学研究工具、金融分析平台以及包含多种数据类型的企业知识库都能从中受益。

12. 递归或多步骤RAG，用于处理复杂问题

难度：高级。当单次查询无法解答问题时请选择此方法。某些问题需要通过一系列知识关联来解答。例如，晶体管的发明如何推动现代人工智能的发展，至少需要经过五个环节：晶体管、集成电路、CPU、GPU、深度学习、大语言模型。递归RAG会不断检索、学习，然后再次检索。

Round 1: Retrieve about transistors → learn about miniaturization
Round 2: Retrieve about integrated circuits → learn about computing power
Round 3: Retrieve about GPUs → learn about parallel processing
Round 4: Retrieve about deep learning → learn about compute requirements
Round 5: Synthesize the full chain into a coherent answer

研究助理、学术工具、战略分析以及任何需要多步骤推理的问题都适用此技术。

第4级：专用场景

13. ODQA RAG，可回答任何问题

难度：中等。当知识库规模庞大且问题具有开放性时效果最佳。开放领域问题解答即是大规模应用的RAG技术，涵盖科学、历史、地理和文化等领域。其挑战不在于信息检索的质量，而在于如何处理庞大的信息量以及判断何时无法找到答案。ODQA加入了置信度评分功能，因此当检索到的文档中没有合适答案时，系统会承认自己缺乏信心而不会编造答案。通用助手、知识问答机器人、研究平台以及跨领域的内部知识库都在使用该技术。

14. 多模态RAG，整合文本、图像和音频

难度：高级。当知识库包含图片、图表或音频时效果最佳。大多数RAG系统仅能处理文本，而真实的知识还以解剖图、产品照片、录音和图表等形式存在。多模态系统会构建一个跨所有模态共享的嵌入空间，这样文本查询就能找到图片，图片查询也能找到文档。

User (text): "Show me the anatomy of the heart"
→ Retrieves both: text descriptions AND anatomical diagrams
→ Response includes both text explanation and relevant image

医学教育、产品目录、在线学习平台以及媒体档案都是合适的应用场景。

15. 流式RAG，实时知识

难度：中等。适用于信息每隔几分钟就会变化的情况。如果在上午9点提出一个问题，而在上午11点再次提问，只要底层数据发生了变化，就应该得到不同的答案。流式RAG能够维持持续更新的知识库，随时为新到达的文档建立索引。

Time 9:00 AM: "What's happening with NVDA?"
→ Retrieves this morning's earnings report

Time 11:30 AM (after news breaks): "What's happening with NVDA?"
→ Retrieves the breaking news from 11:15 AM

财经新闻助手、实时支持机器人、活动监控与运营控制面板都依赖它。

16. 联邦式RAG、隐私优先与多源整合

难度：高级。适用于数据无法离开其来源的场景。它解决了企业人工智能中的一个基本矛盾：多个数据所有者希望使用共享系统，但没人愿意共享原始数据。为医疗助手提供数据的医院就是典型例子，因为患者记录无法集中管理。每个数据源都会运行自己的本地检索器，查询会同时发送到所有数据源，只有检索到的片段而非原始数据会传送到中央系统。

Central Query: "What's the survival rate for treatment X?"

→ Hospital A retriever: returns relevant anonymized snippets
→ Hospital B retriever: returns relevant anonymized snippets
→ Hospital C retriever: returns relevant anonymized snippets
→ Central LLM synthesizes — never saw raw patient recordsResult: HIPAA/GDPR compliant, collaborative AI

医疗网络、金融联盟、法律数据库以及任何有数据治理需求的多组织架构都是目标对象。

逐月实施计划

第一天并不需要全部十六项功能。大多数生产系统都是逐步扩展的。

Month 1:  Standard RAG           ← Get something working
Month 2:  + Hybrid RAG            ← Biggest retrieval quality win
Month 3:  + Contextual Retrieval  ← Multi-turn conversations work now
Month 4:  + Self-RAG              ← Stop hallucinations
Month 5:  + Agentic capabilities  ← Tools beyond just search

This covers 80-90% of production RAG needs.

模式组合

生产系统几乎总是混合使用多种模式。以下是几种常见组合：

  • 企业聊天机器人会结合标准模式、混合模式、上下文模式以及记忆模式，以实现多轮对话、高效信息检索和个性化服务。
  • 医疗辅助工具会采用领域专用模式、自建RAG模式以及增强模式，因为准确性至关重要且涉及结构化数据。
  • 研究工具会结合代理模式、混合模式以及递归模式，以应对复杂问题、多步骤处理及多种工具的使用需求。
  • 客户支持系统会使用标准模式、上下文模式以及流式处理模式，以便进行后续跟进和实时更新。
  • 法律研究工具会结合领域专用模式、图结构模式以及混合模式，用于分析实体关系并实现精确引用。
  • 新闻分析工具会采用流式处理模式、ODQA模式以及多模态模式，以处理实时数据、广泛的主题内容及图片信息。

快速选择指南

对于首个基于文档的问答机器人，可从标准RAG开始。若需在生产环境中实现更出色的搜索功能，可加入混合式RAG。多轮对话机器人需要上下文检索功能，而需要调用工具或API的机器人则适合使用代理型RAG。在医学或法律领域需要高精度处理的场景适合使用自研RAG，而面对技术文档的普通用户则适合使用HyDE。涉及关系型数据的查询需使用图结构RAG，个性化助手场景适合记忆增强型RAG，模块化系统可尝试不同组合的RAG方案，受监管行业则适合领域专用型RAG。混合结构化与非结构化数据适合增强型RAG，多跳查询适合递归RAG，通用问答场景则适合ODQA。处理图像和音频数据需使用多模态RAG，实时数据则适合流式RAG，而在HIPAA或GDPR规范下的多组织环境则适合联邦式RAG。

运行示例

每种实现都可直接运行：克隆仓库，安装所需依赖，设置 OpenAI API 密钥，然后从第一个示例开始使用。

# Clone the repo
git clone https://github.com/Manjunadh86/RAG-Materials.git
cd RAG-Materials

# Install dependencies
pip install -r requirements.txt# Set your OpenAI API key
export OPENAI_API_KEY="sk-your-key-here"# Run your first RAG system
cd 01-Standard-RAG
python hands_on.py

每个模块都包含一份README，说明其概念、架构及适用场景，同时还提供可运行的脚本供修改，每一步都有注释说明。

RAG发展迅猛。代理系统功能日益强大，多模态检索技术不断成熟，而随着人工智能治理要求的日益严格，联邦式方法也变得愈发重要。学习RAG的最佳方式就是亲自构建它。

相关阅读

  • 为何 AI 分析代理需要语义层而非原始 SQL —— 直接在原始仓库表上实现文本转 SQL 会自行创建指标并忽略访问规则。了解如何通过 Cube 这类语义层结合 MCP 为代理赋予受管控的业务含义。
  • Claude 托管代理：实际功能、定价与自托管替代方案 —— Claude 托管代理能提供什么功能，每会话小时的成本是多少，存在哪些锁定与隐私风险，以及何时选择 Multica 等开源工具更为合适。
  • 实用指南：RAG系统：从零到精通的完整指南（2026年版） — 该指南的详细操作流程说明，包括适用于采用此模式的团队的相关合同、检查项以及可直接插入的代码片段。
  • 在65本葡萄酒相关书籍上测试RAG-Anything：图检索的优缺点 — 对RAG-Anything的知识图谱在65份葡萄酒PDF文件上的表现进行实际测试，涵盖解析器选择、成本分析、图检索与向量检索的答案差异，以及起泡酒相关的检测盲点。
  • 实用笔记：我基于SEC文件构建了混合式RAG管道——详情如下 — 该实用笔记的详细操作指南：包括合同、检查项以及供采用该模式的团队直接使用的代码片段。
  • 实用笔记：2026年从零学习RAG的途径：课程推荐 — 该实用笔记的详细操作指南：包括合同、检查项以及供采用该模式的团队直接使用的代码片段。
  • RAG的工作原理：嵌入、向量数据库与分块 —— 跟踪一段文本从分词到池化再到余弦相似度搜索的全过程，了解为何分块方式以及嵌入模型的匹配效果决定了RAG的质量。
  • 无需API费用即可用Python构建本地RAG流程 —— 通过实际操作教程，使用sentence-transformers、numpy和Flan-T5在CPU上实现检索增强生成功能，涵盖文本分块、搜索以及A/B测试等内容。
  • 将MCP服务器迁移至2026-07-28版本：二十分钟逐步指南 — 无需中断服务即可完成迁移。了解MCP 2026-07-28版本的变更内容、分五步完成的Python SDK 2.0迁移流程、MRTR的重写方式以及“废弃”概念的含义。
  • 从演示版到生产环境RAG：分块处理、pgvector、重排序与FastAPI — 生产环境RAG后端的实际构成：ETL与分块处理、pgvector中的嵌入向量、HNSW索引、交叉编码器重排序机制以及FastAPI协调器。
  • 从初步尝试到基于SEC 10-K文件的实用RAG系统：分块处理与混合搜索 — 为何传统的RAG流程在300页长的10-K文件上会失败，以及相应的解决方案：基于章节划分的分块、混合检索方式、交叉编码器重排序、验证机制与元数据引用。
  • TypeScript 7及其对Go语言的借鉴：更快的构建速度、更优的内存效率与编辑器反馈 — TypeScript 7采用了原生的Go引擎替代原有编译器，实现了并行构建、更低的内存占用，同时还带来了新的语言服务器，以及迁移时需要注意的若干事项。
  • 四种多智能体架构对比：子智能体、技能、任务交接与路由器 — 对四种核心多智能体架构进行实际对比，分析每种架构的代价、适用场景，以及如何选择以避免功能冗余。
  • AI智能体与传统后端应用：控制流程、成本与故障模式 — 通过退款示例对比确定性后端与基于大语言模型智能体的架构：延迟、令牌成本、上下文规模、故障模式，以及混合设计的最佳应用场景。
  • 在8 GB内存的笔记本电脑上从零开始训练小型大语言模型 —— 如何在配置较低的硬件上为Transformer模型的训练搭建完整的数据处理流程：BPE分词器、TinyStories、基于磁盘的令牌存储以及下一个令牌批量处理方法。
  • MCP究竟解决了什么问题：从N x M集成模式到N + M模式 —— 用通俗语言解释MCP存在的意义、发现机制与组合机制与REST的区别、为何人工智能不会驻留在服务器端，以及安全与信任问题仍需由谁来负责。
  • MCP、RAG与LLM：它们在您已熟悉的开发应用中各自承担的功能，以及何时需要采用标准化的工具协议来增加额外层次。 —— 详细讲解MCP、RAG和LLM分别为您已掌握的开发方式带来什么价值，以及何时有必要通过标准化工具协议来增加新的功能层次。
    • ← 全部文章发送简报