导航 RAG 架构全景：实践者指南

Source: Dev.to

检索增强生成（RAG）概览

RAG 已从单一蓝图发展为多样化的架构生态系统，每种架构都针对特定的性能、可扩展性和准确性需求进行调优。选择合适的 RAG 模式对系统成功至关重要。本指南拆解了主要的 RAG 架构——它们的工作原理、适用场景、失效情况以及可考虑的替代方案。

1. Naive RAG

工作原理

• 对用户查询进行嵌入。
• 从向量数据库中检索相关片段。
• 将检索到的片段与提示模板一起传递给 LLM，以实现基于事实的生成。

最佳使用场景

• 原型设计或构建 MVP。
• 领域定义明确且文档干净、结构化。
• 简单性和低延迟是优先考虑的因素。

失效情况

• 检索质量下降 → 上下文不相关导致幻觉。
• 对多跳或复杂推理查询表现不佳。
• 没有纠正过时或错误信息的机制。

可替代方案

• Adaptive RAG：实现更智能的路由。
• Corrective RAG：在准确性至关重要时进行自我批评式检索。

2. HyDE（Hypothetical Document Embeddings）

工作原理

• 首先让 LLM 生成一个 假设答案。
• 将该假设答案进行嵌入，并用于检索，旨在匹配理想答案的“形状”。

最佳使用场景

• 查询简短或含糊。
• 查询与语料库之间存在词汇不匹配。
• 标准查询嵌入导致召回率低。

失效情况

• 初始生成可能出现幻觉，污染检索结果。
• 增加一次额外的 LLM 调用，导致延迟上升。
• 极度依赖假设生成的质量。

可替代方案

• Hybrid RAG：结合词汇搜索解决词汇问题。
• Multimodal RAG：如果查询本身是多模态的。

3. Corrective RAG（CRAG）

工作原理

• 增加纠正步骤：对检索到的文档进行相关性/置信度打分。
• 若置信度低，系统可在生成前触发网页搜索或使用其他来源。

最佳使用场景

• 事实准确性至关重要（医疗、法律、金融）。
• 知识库是动态的或部分不可靠。
• 需要最大限度降低陈旧知识导致的幻觉。

失效情况

• 由于打分 + 外部搜索，导致更高的延迟和复杂度。
• 网页搜索会引入成本和不可预测性。
• 打分器本身可能成为单点故障。

可替代方案

• Graph RAG：适用于需要内置可验证性的结构化领域。
• 对于更简单的需求，可使用调优良好的 Naive RAG 并进行强评估。

4. Graph RAG

工作原理

• 使用知识图谱（从文档中抽取）代替或与向量数据库并行。
• 检索时遍历实体之间的关系，实现多跳推理。

最佳使用场景

• 领域充满关系（研究、欺诈检测、知识图谱）。
• 查询需要多跳推理。
• 检索路径的可解释性很重要。

失效情况

• 图谱构建/维护的前期成本高。
• 在广义语义搜索上可能不如向量检索表现。
• 不适合叙事性或结构松散的文本。

可替代方案

• Hybrid RAG：将图谱与向量搜索相结合。
• 对于结构较弱的数据，可使用切分良好的 Naive RAG。

5. Hybrid RAG

工作原理

• 结合稠密向量搜索和稀疏（关键词）词汇搜索。
• 在生成前合并结果（通常使用 Reciprocal Rank Fusion）。

最佳使用场景

• 需要同时具备召回率（词汇）和语义理解（向量）。
• 面临词汇不匹配问题。
• 语料库中既有精确关键词又有概念性内容。

失效情况

• 调优和平衡更为复杂。
• 双重检索导致计算成本上升。
• 合并逻辑需要仔细校准。

可替代方案

• 如果 ke（未完）… (此处原文截断，后续内容请参照原始文档继续翻译)

Source: …

yword search 是主要需求，在全面混合之前先使用 query expansion 或 BM25。

6. Adaptive RAG

工作原理

• 基于 LLM 的编排器会对查询复杂度进行分类并相应地调整检索方式：
  • 简单查询 → 直接回答。
  • 复杂查询 → 完整的 RAG。
  • 多跳查询 → 可能触发网页搜索。

适用场景

• 查询复杂度差异很大。
• 成本/延迟优化至关重要。
• 你已经拥有明确的查询类型分类体系。

局限

• 路由误分类会导致性能下降。
• 增加系统复杂度。
• 引入新的单点故障。

可替代方案

• 如果查询复杂度相对统一，优化良好的 Naive 或 Hybrid RAG 可能已经足够。

7. Multimodal RAG

工作原理

• 将检索扩展到多模态（文本、图像、音频）。
• 多模态查询检索多模态块，随后多模态 LLM 生成答案。

适用场景

• 知识库和查询本身就是多模态的（带图示的手册、医学影像、产品目录）。
• 答案需要跨模态综合。

局限

• 对齐、切块和融合的复杂度高。
• 成本和延迟显著提升。
• 工具链仍处于早期阶段。

可替代方案

• 对于以文本为主的任务，可使用 text RAG，并配合独立的图像描述或目标检测流水线。

8. Agentic RAG

工作原理

• 将 RAG 嵌入到代理框架中。
• 具备规划（如 ReAct）和记忆的代理将 RAG 作为工具，用于跨来源（本地、云端、通过 MCP 服务器的网页）进行多步骤研究。

适用场景

• 任务需要自主的多步骤研究（尽职调查、竞争分析）。
• 问题范围广泛，不能局限于单一知识库。
• 需要跨会话的长期记忆。

局限

• 复杂度最高且不可预测性强。
• 容易出现目标漂移或无限循环。
• 运营成本极高。

可替代方案

• 对于确定性的知识查询，使用更简单的 RAG 更可靠且成本更低。
• Agentic RAG 仅在开放式探索时才使用。

结论：从简开始，审慎扩展

• 没有一种适用于所有场景的 RAG。最佳选择取决于你对准确性、延迟、成本和复杂性的具体需求。
• 从 Naive RAG 开始，并投入数据准备和评估工作。
• 确定你的瓶颈：
  • 检索质量 → HyDE / Hybrid。
  • 推理 → Graph。
  • 事实性 → Corrective。
• 仅在出现明确的生产需求时，才转向 Adaptive 或 Agentic。

满足你 accuracy‑latency‑cost 权衡的最简 RAG 通常是最可持续的选择。

准确性、延迟和成本约束通常是正确的选择。

进一步阅读

• Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks
• Gao et al., Precise Zero-Shot Dense Retrieval without Relevance Labels
• Sarthi et al., Corrective Retrieval Augmented Generation
• Wu et al., Knowledge Graph-Augmented Language Models for Knowledge-Grounded Dialogue