完整题目
请介绍RAG（Retrieval-Augmented Generation）模型的主要分类方式，并比较不同类别之间的架构差异与适用场景。
本文目录
RAG 的三代演进架构
1. Naive RAG（基础架构）
架构：离线建索引 → 向量检索 → 直接拼接Prompt → LLM生成
核心特征：
- 检索与生成硬耦合，一次检索即生成
- 无反馈机制，检索错误直接传导到输出
- 代表：早期DPR+GPT-3方案
适用：事实性问答、内部文档查询等单跳、确定性场景
2. Advanced RAG（优化架构）
架构：检索前（查询改写/扩展）→ 检索中（重排序/混合检索）→ 检索后（上下文压缩/摘要）→ 生成
核心改进：
- 查询优化：HyDE（假设文档嵌入）、Query2Doc
- 精排策略：Cross-encoder重排、多路召回融合
- 上下文处理：Recomp压缩、选择性上下文
适用：企业知识库、产品手册等噪声多、需精排的场景
3. Modular RAG（模块化/Agent化）
架构：检索与生成解耦，支持多轮迭代、主动决策
关键能力：
| 模块 | 功能 |
|---|---|
| 检索器 | 可切换（向量/图谱/搜索引擎） |
| 调度器 | 判断是否需要检索、何时停止 |
| 生成器 | 支持Self-RAG（反思token）、FLARE（动态检索） |
代表：Self-RAG、ReAct、RAG-Fusion
适用：科研分析、多跳推理、开放域复杂任务
架构差异对比
| 维度 | Naive | Advanced | Modular |
|---|---|---|---|
| 延迟 | 低 | 中 | 高 |
| 准确性 | 依赖索引质量 | 显著提升 | 最高 |
| 灵活性 | 无 | 有限 | 高度可编排 |
| 运维成本 | 低 | 中 | 高 |
选型建议：从Naive快速验证→Advanced优化体验→Modular解决复杂任务，避免过度设计。
学习建议
建议先掌握向量运算和概率基础，再结合Transformer论文理解Attention的计算流程与意义。
换一种问法，检查是否真正理解
场景切入
假设我们做一个企业知识库问答系统，用户问“去年的财报数据”，系统直接搜回来一堆文档塞给大模型。但有时候搜到的内容很杂，回答质量不稳定。你觉得这种“搜了就直接回答”的方式有什么问题？有没有更好的演进思路？
层层追问
RAG 的基本流程你了解吧？就是检索加生成……那如果检索结果不准，比如用户问“退款政策”却搜到商品描述，怎么改善？……如果再进一步，想让模型自己决定什么时候需要再搜一次，这种架构又该怎么设计？
直球架构
请你介绍一下 RAG 的主要分类和架构差异。重点说说从 Naive 到 Advanced 再到 Modular，每一代改进了什么，分别适合什么场景？比如延迟、准确性、灵活性上的取舍。
练习口述回答 · 约4分钟
- 一句话定位：RAG分类本质是检索与生成耦合度演进
- Naive RAG：快速验证但硬耦合，适用单跳事实问答
- Advanced RAG：查询优化+重排，落地企业知识库时重点做上下文压缩
- Modular RAG：解耦+决策，适合多跳推理但成本高
- 边界划分与落地风险：Naive快速验证、Advanced优化、Modular解决复杂，常混合使用；前提是索引质量与延迟容忍度
面试官你好，这道题问[[RAG]]的分类，其实本质是在问检索和生成之间的耦合度是怎么演进的。我理解RAG不是一种固定的架构，它从最早的简单拼接，到后来加各种优化，再到最近模块化、[[Agent]]化，其实是检索和生成从硬耦合走向解耦的过程。
先说最早的一代，[[Naive RAG]]。它的流程很简单：离线把文档切成块、做 [[Embedding]] 存进 [[Vector Database]]，用户提问时检索出最相关的几个块，直接拼到Prompt里交给LLM生成。这个架构最大的问题是检索和生成是硬耦合的，一次检索结果就决定了输出质量，如果检索错了，模型只能硬着头皮基于错误信息来回答，就会出现 [[Hallucination]]。所以它只适合单跳、确定性强的场景，比如内部文档里的简单事实问答，像查员工手册里年假天数这种。换个场景，比如客服问退款政策，用户可能说'我买的东西降价了'，Naive RAG直接搜'降价'可能搜不到退款条款，这就挂了。
所以后来出现了Advanced RAG，它的核心是在检索的前、中、后都加优化。检索前做查询改写或扩展，比如用 HyDE 先生成一个假设文档再检索；检索中用 [[Hybrid Search]] 融合关键词和向量，再用 [[Cross-Encoder]] 做 [[重排]]；检索后做上下文压缩，把检索回来的长文本摘要成关键信息，避免把噪声带进生成。这里有一个关键点：不是所有场景都需要重排。如果知识库质量高、[[分块]]合理，直接用 [[BM25]] 加向量检索的混合就够用了；只有噪声多、需要精确排序的场景，比如企业合规文档，才需要加重排。我实际落地企业知识库时，最关注的是检索后的上下文压缩，因为LLM对输入长度敏感，压缩能直接提升生成的准确率和速度。但这里有个坑：压缩本身也会丢失信息，所以需要设计好压缩策略，比如只保留跟问题最相关的段落。
再后来就是[[Modular RAG]]，也叫[[Agentic RAG]]。它把检索和生成彻底解耦，引入一个调度器来决定什么时候检索、检索什么、要不要多轮迭代。比如 [[Self-RAG]] 让模型在生成时输出反思token，判断当前答案是否需要更多证据；[[ReAct]] 则是边推理边检索，像人类查资料一样一步步逼近答案。这个架构灵活性最高，但延迟和成本也最高。它的典型场景是科研分析或多跳推理，比如问'某药物对某疾病的疗效，对比传统疗法有哪些优势'，需要先查到药物数据，再查疾病背景，再对比，一次检索搞不定。
那么这三类怎么选呢？我的经验是：不要孤立地选一类，而是根据场景混合使用。比如做一个客服退款系统，可以先用Naive快速搭一个原型验证可行性；然后加上查询改写和重排，变成Advanced；如果遇到复杂退款纠纷需要查多份政策，再引入调度器做多轮检索。边界划分上，Naive适合单跳、确定性场景；Advanced适合噪声多但仍是单跳的场景；Modular适合多跳、开放域复杂任务。但真正落地时，我常常把Advanced和Modular结合，比如用Modular的调度器来控制Advanced的检索流程，而不是完全照搬论文。