9 种 RAG 架构,每位 AI 开发者必学:完整实战指南

每个 AI 开发者必须了解的 9 种 RAG 架构(附示例完整指南)

超越基础 RAG,构建可靠的生产级 AI 系统

你的聊天机器人自信地告诉客户:退货政策是 90 天。但实际上是 30 天。它还描述了一些你的产品根本不存在的功能。

这就是"演示效果很好"和"真实生产系统"之间的差距。

语言模型即使错误,也会显得非常自信------而在生产环境中,这种错误代价极高。

这就是为什么严肃的 AI 团队会使用 RAG。

不是因为它流行,而是因为它能让模型基于真实信息。

但大多数人忽略了一点:
RAG 不止一种,而是多种架构。

选错架构,可能浪费数月时间。


什么是 RAG?为什么重要?

RAG通过让语言模型在生成回答前参考外部知识库来优化输出。模型不再纯粹依赖训练时学到的内容,而是从你们的文档、数据库或知识图谱中提取相关、最新的信息。

流程如下:

  1. 用户提问
  2. 系统从外部数据源检索相关信息
  3. 将问题 + 检索结果一起交给模型
  4. 模型基于这些真实信息生成答案

核心:不再只依赖模型训练数据, 而是使用最新、可验证的信息。


RAG 解决的核心问题

1. 标准 RAG(Standard RAG):从这里开始

这是最基础的 RAG 架构。

标准RAG是整个生态系统的"Hello World"。它将检索视为简单的单次查询。它的目的是在不进行微调开销的情况下,将模型扎根于特定数据,但它假设你的检索引擎是完美的。

工作原理:

  • 分块(Chunking) :文档被分割成小的、可消化的文本片段。
  • 嵌入(Embedding) :每个片段被转换成向量并存储在数据库中(如Pinecone或Weaviate)。
  • 检索(Retrieval) :用户查询被向量化,使用余弦相似度提取"Top-K"最相似的片段。
  • 生成(Generation) :这些片段作为"上下文"输入LLM,生成有依据的回答。

实际案例:一家小型创业公司的内部员工手册机器人。用户问:"我们的宠物政策是什么?"机器人从HR手册中检索特定段落来回答。

优点:

  • 亚秒级延迟。
  • 计算成本极低。
  • 易于调试和监控。

缺点:

  • 极易受"噪音"影响(检索到不相关的片段)。
  • 无法处理复杂的多部分问题。
  • 如果检索到的数据错误,缺乏自我纠正能力。

2. 对话式 RAG(Conversational RAG):加入记忆

对话式RAG解决"上下文盲视"问题。在标准设置中,如果用户问一个跟进问题"它多少钱?",系统不知道"它"指什么。这种架构添加了一个有状态的内存层,重新语境化聊天的每一轮。

工作原理:

  • 上下文加载:系统存储最近5-10轮对话。
  • 查询重写:LLM接收历史记录+新查询,生成一个"独立查询"(例如:"企业版计划的价格是多少?")。
  • 检索:使用这个扩展后的查询进行向量搜索。
  • 生成:使用新上下文生成答案。

实际案例:一家SaaS公司的客户支持机器人。用户说:"我的API密钥有问题",然后跟进:"你能重置它吗?"系统知道"它"指的是API密钥。

优点:

  • 提供自然、类似人类的聊天体验。
  • 防止用户不得不重复自己。

缺点:

  • 记忆漂移:10分钟前的不相关上下文可能污染当前搜索。
  • 由于"查询重写"步骤,token成本更高。

3. 纠正性RAG(CRAG):自我检查器

CRAG是一种为高风险环境设计的架构。它引入了一个"决策门" ,在检索到的文档到达生成器之前评估其质量。如果内部搜索质量差,它会触发回退到实时网络。

在部署CRAG风格评估器的团队报告的内部基准测试中,幻觉相比朴素基线显著降低。

工作原理:

  • 检索:从内部向量存储获取文档。
  • 评估:一个轻量级的"评分器"模型为每个文档片段分配分数(正确、模糊、错误)。
  • 触发门
    • 正确:继续进入生成器。
    • 错误:丢弃数据并触发外部API(如Google搜索或Tavily)。
  • 综合:使用验证过的内部或新鲜的外部数据生成答案。

实际案例:一个金融顾问机器人。当被问及某个不在其2024年数据库中的具体股票价格时,CRAG意识到数据缺失,并从金融新闻API拉取实时价格。

优点:

  • 大幅降低幻觉。
  • 弥合内部数据与实时现实世界事实之间的差距。

缺点:

  • 延迟显著增加(增加2-4秒)。
  • 管理外部API成本和速率限制。

4. 自适应RAG:根据复杂度匹配投入

自适应RAG是"效率冠军"。它认识到并非每个查询都需要大炮。它使用一个路由器来判断用户意图的复杂度,并选择最便宜、最快的路径到达答案。

工作原理:

  • 复杂度分析:一个小型分类器模型路由查询。
  • 路径A(无需检索) :用于问候或LLM已知的通用知识。
  • 路径B(标准RAG) :用于简单的事实查询。
  • 路径C(多步骤智能体) :需要搜索多个来源的复杂分析问题。

实际案例:一个大学助手。如果学生说"你好",它直接回复。如果问"图书馆什么时候开放?",它进行简单搜索。如果问"比较CS项目过去5年的学费",它触发复杂分析。

优点:

  • 通过跳过不必要的检索实现大量成本节约。
  • 简单查询的最优延迟。

缺点:

  • 误分类风险:如果它认为难题是简单的,就会失败搜索。
  • 需要一个高度可靠的路由模型。

5. 自反 RAG(Self-RAG):模型自我审查

Self-RAG是一种复杂的架构,其中模型被训练来批评自己的推理。它不仅检索,还生成"反思令牌",作为对自己输出的实时审计。

工作原理:

  • 检索:由模型本身触发的标准搜索。
  • 带令牌生成:模型生成文本的同时生成特殊令牌,如[IsRel](这相关吗?)、[IsSup](这个主张有支持吗?)、[IsUse](这有帮助吗?)。
  • 自我纠正:如果模型输出[NoSup]令牌,它会暂停、重新检索并重写句子。

实际案例:一个法律研究工具。模型写了一个关于法庭案例的主张,意识到检索到的文档实际上不支持该主张,自动搜索不同的判例。

优点:

  • 最高级别的事实"扎根性"。
  • 推理过程内置透明度。

缺点:

  • 需要专门微调的模型(如Self-RAG Llama)。
  • 计算开销极高。

6. 融合RAG:多角度,更好结果

融合RAG解决"模糊性问题"。大多数用户不擅长搜索。融合RAG对单个查询从多个角度审视,以确保高召回率。

工作原理:

  • 查询扩展:生成用户问题的3-5个变体。
  • 并行检索:对所有变体进行向量数据库搜索。
  • 倒数排名融合(RRF) :使用数学公式重新排名结果:
  • 最终排名:在多个搜索中排名靠前的文档被提升到顶部。

实际案例:一位医学研究人员搜索"失眠的治疗方法"。融合RAG还会搜索"睡眠障碍药物"、"非药物失眠疗法"和"CBT-I方案",以确保不遗漏相关研究。

优点:

  • 卓越的召回率(找到单个查询会遗漏的文档)。
  • 对用户措辞不佳有鲁棒性。

缺点:

  • 搜索成本倍增(3-5倍)。
  • 由于重新排名计算,延迟更高。

7. HyDE:先生成答案,再找相似文档

HyDE是一种反直觉但 brilliant 的模式。它认识到"问题"和"答案"在语义上是不同的。它通过先生成一个"假"答案来在它们之间建立桥梁。

工作原理:

  • 假设:LLM写一个假的(假设的)答案来回应查询。
  • 嵌入:假答案被向量化。
  • 检索:使用该向量来查找看起来像假答案的真实文档。
  • 生成:使用真实文档写出最终回答。

实际案例:用户问一个模糊的问题,如"加州那个关于数字隐私的法律"。HyDE写一个CCPA的假摘要,用它找到实际的CCPA法律文本,并提供答案。

优点:

  • 对概念性或模糊查询的检索显著改善。
  • 不需要复杂的"智能体"逻辑。

缺点:

  • 偏见风险:如果"假答案"从根本上是错误的,搜索会被误导。
  • 对简单事实查询效率低下(例如"2+2等于多少?")。

8. 智能体RAG:编排专家

智能体RAG不是盲目获取文档,而是引入一个自主智能体,在生成答案之前规划、推理并决定如何以及在哪里检索信息。

它将信息检索视为研究,而非查找。

工作原理:

  • 分析:智能体首先解释用户查询,判断它是简单的、多步骤的、模糊的还是需要实时数据的。
  • 规划:它将查询分解为子任务并决定策略。例如:应该先进行向量搜索?网络搜索?调用API?问跟进问题?
  • 行动:智能体通过调用工具执行这些步骤,如向量数据库、网络搜索、内部API或计算器。
  • 迭代:基于中间结果,智能体可能优化查询、获取更多数据或验证来源。
  • 生成:一旦收集到足够的证据,LLM生成一个有依据、上下文感知的最终回答。

实际案例:

用户问:"在印度法规下,金融科技应用使用LLM进行贷款审批安全吗?"

智能体RAG可能:

  • 检测这是一个监管+政策+风险问题
  • 通过网络工具搜索RBI指南
  • 检索内部合规文档
  • 交叉检查最新监管更新
  • 综合一个带有引用和警告的结构化答案

传统RAG可能只会检索语义相似的文档并一次性回答。

优点:

  • 处理复杂、多部分和模糊的查询
  • 通过验证和迭代减少幻觉
  • 可以访问实时和外部数据源
  • 更能适应变化的上下文和需求

缺点:

  • 由于多步骤执行,延迟更高
  • 比简单RAG运行更昂贵
  • 需要仔细的工具和智能体编排
  • 对直接的事实查询来说过于复杂

9. 图RAG:关系推理器

虽然之前所有架构都基于语义相似度检索文档,图RAG检索实体以及它们之间的显式关系。

它不是问"什么文本看起来相似",而是问"什么是有联系的,以及如何联系的?"

工作原理:

  • 图构建:知识被建模为图,其中节点是实体(人、组织、概念、事件),边是关系(影响、依赖于、由...资助、由...监管)。
  • 查询解析:分析用户查询以识别关键实体和关系类型,而非仅关键词。
  • 图遍历:系统遍历图以找到跨多跳连接实体的有意义路径。
  • 可选混合检索:向量搜索通常与图一起使用,以将实体扎根于非结构化文本。
  • 生成:LLM将发现的关系路径转换为结构化、可解释的答案。

实际案例:

查询:"美联储利率决策如何影响科技初创公司估值?"

图RAG遍历:

  • 美联储 → 利率决策 → 加息
  • 加息 → 影响 → VC资本可用性
  • VC可用性减少 → 影响 → 早期阶段估值
  • 科技初创公司 → 由...资助 → 风险投资

答案从关系链中浮现,而非文档相似度。

为何不同:

  • 向量RAG:"哪些文档与我的查询相似?"
  • 图RAG:"哪些实体重要,它们如何相互影响?"

这使图RAG在因果、多跳和确定性推理方面强大得多。

结合结构化分类法的图RAG系统在确定性搜索任务中已达到接近99%的准确率。

优点:

  • 擅长因果推理
  • 由于显式关系,输出高度可解释
  • 在结构化和规则繁重的领域表现强劲
  • 减少语义相似度导致的误报

缺点:

  • 构建和维护知识图的前期成本高
  • 图构建可能计算昂贵
  • 领域变化时更难演进
  • 对开放式或对话式查询过于复杂

如何实际选择(决策框架)

第一步:从标准RAG开始

认真地说。除非你有具体证据证明它不行,否则从这里开始。标准RAG迫使你掌握基础:

  • 高质量的文档分块
  • 好的嵌入模型
  • 适当的评估
  • 监控

如果标准RAG效果不好,复杂性救不了你。你只会得到一个仍然糟糕的复杂系统。

第二步:仅在需要时添加记忆

用户问跟进问题?添加对话式RAG。否则,跳过它。

第三步:将架构与实际问题匹配

看真实查询,而非理想查询:

  • 查询相似且直接?保持标准RAG。
  • 复杂度差异很大?添加自适应路由。
  • 准确性关乎生死?使用纠正性RAG,尽管有成本。医疗RAG系统显示诊断错误减少15%。
  • 开放式研究?自我RAG或智能体RAG。
  • 术语模糊?融合RAG。
  • 丰富的关系数据?如果你能负担图构建,使用图RAG。

第四步:考虑你的约束

  • 预算紧张? 标准RAG,优化检索。避免自我RAG和智能体RAG。
  • 速度关键? 标准或自适应。DoorDash语音达到2.5秒响应延迟,但聊天需要低于1秒。
  • 准确性关键? 纠正性或图RAG,尽管有成本。

第五步:混合架构

生产系统结合方法:

  • 标准 + 纠正性:快速标准检索,对低置信度进行纠正回退。95%快速,5%验证。
  • 自适应 + 图RAG:简单查询用向量,复杂查询用图。
  • 融合 + 对话式:带记忆的查询变体。

结合密集嵌入与BM25等稀疏方法的混合搜索,对于语义意义加精确匹配几乎是标准配置。


简单类比

把LLM想象成一个聪明但记忆力极差的员工。

  • 标准RAG就像给他们一个文件柜。他们抽出一个文件夹,阅读并回答。
  • 对话式RAG是同一个员工在会议中做笔记,这样他们就不会重复问同样的问题。
  • 纠正性RAG增加了一位高级审核员,在答案发出前检查:"我们实际上有证据证明这个吗?"
  • 自适应RAG是一位经理决定投入程度。简单问题快速回复,难题全力研究。
  • 自我RAG是员工大声思考,不确定时停下来查阅资料。
  • 融合RAG是用五种不同方式问五个同事同样的问题,相信他们一致认同的内容。
  • HyDE是员工先起草一个理想答案,然后搜索匹配该解释的文档。
  • 智能体RAG是一个专家团队。法律、财务和运营各回答自己的部分,然后有人整合在一起。
  • 图RAG是使用关系白板而非文档。谁影响谁,如何影响。

杀死项目的红旗

  • 过度工程:对FAQ使用智能体RAG就像用法拉利买杂货。浪费。
  • 忽视检索质量:高召回率检索器仍然是每个RAG系统的支柱。糟糕的检索 = 糟糕的生成,无论架构如何。
  • 没有评估:你无法改进你不衡量的东西。从第一天起跟踪精确度、正确性、延迟、成本、满意度。
  • 追逐论文:仅2024年就有超过1,200篇RAG论文出现在arXiv上。你不可能全部实现。专注于针对你具体问题的经过验证的方法。
  • 跳过用户:用户真正需要什么?与他们交谈。许多团队为用户没有的问题构建 elaborate 解决方案,同时忽视真正的问题。

RAG不是魔法。它不会修复糟糕的设计或垃圾数据。但如果经过深思熟虑地实施,它能将语言模型从自信的骗子转变为可靠的信息系统。

在2025年,RAG作为企业的战略要务,提供企业安全采用生成式AI所需的信心层。这八种架构解决不同问题:

  • 标准:快速、简单,从这里开始
  • 对话式:为多轮对话增加记忆
  • 纠正性:验证质量,高准确性
  • 自适应:根据复杂度匹配资源
  • 自我RAG:自主推理,非常昂贵
  • 融合:对模糊查询多角度处理
  • HyDE:概念上弥合语义差距
  • 智能体:编排专家,最复杂
  • 图RAG:连接数据的关系推理

最后-9种对比

最好的系统不是最复杂的。而是在你的约束内可靠服务用户的那个。从简单开始。衡量一切。仅在明确证据表明需要时才扩展复杂性。先掌握基础。

本文到此结束:感谢阅读。

原文地址:9 RAG Architectures Every AI Developer Must Know: A Complete Guide with Examples

相关推荐
小江的记录本3 小时前
【Kafka核心】架构模型:Producer、Broker、Consumer、Consumer Group、Topic、Partition、Replica
java·数据库·分布式·后端·搜索引擎·架构·kafka
止语Lab3 小时前
从手动到框架:Go DI 演进的三个拐点
开发语言·后端·golang
Daybreak5 小时前
Elasticsearch 里的索引和 Mapping,到底是什么关系?
后端
Lee川5 小时前
Prisma 实战指南:像搭积木一样设计古诗词数据库
前端·数据库·后端
李小狼lee6 小时前
深入浅出sse协议,用代码自己实现
后端
SamDeepThinking6 小时前
并发量就算只有2,该上锁还得上呀
java·后端·架构
永远不会的CC11 小时前
浙江华昱欣实习(4月23日~ 4月19日)
后端·学习