主流RAG技术全景 -- 从Naive到Agentic

搞过RAG的同学对这些名词应该不陌生了：Naive RAG、Advanced RAG、Graph RAG、Agentic RAG、Self-RAG……名字一个比一个唬人，论文一篇比一篇复杂。但真要用的时候，很多人就懵了——这么多技术路线，到底有什么区别？哪些是花架子，哪些是真能提升效果的？对投标书编写这个场景，选哪种最合适？

RAG技术在2024到2026年间经历了一轮爆发式演进。从最初简单的"检索+生成"两段式，发展到现在融合了图结构、多智能体协作、自反思纠错等复杂机制的多元化技术版图。每一种技术的提出，都是为了解决某类特定场景下的特定问题。

这篇文章就来系统梳理当前主流RAG技术的全貌。我们不会深入每篇论文的细节，而是聚焦每类技术的核心思想、解决的问题、适用场景和局限性。看完你应该能：

• • 搞清楚Naive RAG到Agentic RAG的技术演进脉络
• • 理解Graph RAG、Self-RAG、Modular RAG等各类技术解决的核心问题
• • 能够根据实际场景（特别是投标书编写）做出合理的技术选型
• • 对各类技术的组合使用有清晰的思路

如果你正在选型RAG技术栈，或者想了解各种RAG技术到底在解决什么问题，这篇文章应该能帮到你。

一、RAG技术的演进脉络

1.1 Naive RAG：起点

Naive RAG是最基础的形式，也是理解一切后续技术的起点。它的流程非常直接：索引文档→用户提问→检索相关块→拼接提示词→大模型生成。

这种方式的优点显而易见：实现简单，成本低，架构清晰。很多团队的第一版RAG系统就是Naive RAG，几周就能跑通。

但Naive RAG的痛点也很明显。第一，检索质量不稳定——向量相似度不等于语义相关性，经常检索到"看起来相关但其实无关"的内容。第二，无法处理复杂问题——如果一个问题的答案需要从三份文档中分别提取信息然后整合，Naive RAG只能靠大模型的"理解"来拼凑，效果不稳定。第三，缺乏纠错能力——检索错了就是错了，系统没有办法自我检查和纠正。

尽管有这些局限，Naive RAG并不应该被轻视。对于一个文档量不大（几百到几千块）、问题类型单一（主要是事实检索）的场景，Naive RAG配合一个质量还可以的嵌入模型，效果已经能打动不少人。把它做好、做稳定，比盲目追求高大上的新技术更务实。

1.2 Advanced RAG：在管道上加环节

Advanced RAG的思路是在Naive RAG的基础上，在检索前和检索后增加优化环节，而不是推倒重来。这种增量式的改进在实际工程中非常受欢迎，因为它不改变系统的整体架构，每个环节都可以独立测试和优化。

检索前的优化主要包括：查询改写（把用户的模糊问题转成更精准的检索语句）、查询分解（把复杂问题拆成多个子问题分别检索）、和假设文档嵌入（先生成一个假设的完美答案，再用这个假设答案去检索）。这些技术本质上都是在"帮用户把问题问好"。

检索后的优化主要包括：重排序（用更强的模型对初次检索结果进行精筛）、上下文压缩（把检索到的大段文字压缩成关键信息，节省上下文空间）、和结果融合（把多个检索通道的结果按一定策略合并）。这些技术都在"帮模型把信息消化好"。

Advanced RAG在实践中是最被广泛采用的路线。原因很简单：它累积了Naive RAG的经验和组件，在关键节点上优化，风险可控，效果提升明显。

1.3 技术选型的核心判断维度

面对这么多RAG技术，选型的关键不是哪个"更先进"，而是哪个"更适合"。判断一个RAG技术是否适合你的场景，核心看四个维度。

需求复杂度。如果你的场景主要是简单的事实检索（"X产品参数是什么"），Naive RAG + 重排序就够了。如果涉及多文档融合和推理（"对比A和B在金融行业的适用性"），需要更复杂的机制如查询分解和Agentic RAG。

数据特点。如果你的知识库是高度结构化的参数表，Graph RAG可能非常合适。如果是长篇的技术白皮书，层级分块 + 语义检索是更好的选择。如果知识库有大量实体关系（产品-方案-案例之间的关联），知识图谱增强会有效果。

延迟容忍度。有些技术虽然效果好，但会增加显著的延迟。Self-RAG的自我反思需要多轮模型调用，Agentic RAG的多智能体协作可能需要几十秒甚至几分钟。对于实时问答场景这不可接受，但对于投标书生成这种异步场景完全没问题。

开发维护成本。技术越复杂，开发和维护成本就越高。Graph RAG需要构建和维护知识图谱，Agentic RAG需要设计和调试多智能体协作逻辑。在资源有限的情况下，把Advanced RAG做精做好，可能比搞一个半生不熟的Agentic RAG效果更好。

二、Graph RAG：用图结构增强检索

2.1 核心思想

传统的RAG是"点对点"检索：问题和文档块在向量空间里做相似度匹配。但现实中的知识是有结构的——产品A被用在方案B中，方案B服务了客户C，客户C属于行业D。这些实体之间的关系信息，在传统的向量检索中几乎被完全丢失了。

Graph RAG的核心思想就是把这些关系显式化：在传统向量检索之外，构建一个知识图谱，用图结构来表示实体之间的关系。检索时既做向量相似度匹配，也做图遍历——沿着关系边找到关联的知识。

2024年微软提出的GraphRAG方案引起了广泛关注。它的做法是先从文档中自动提取实体和关系，构建一个实体-关系图，然后将这个图分成多个"社区"（语义上紧密相关的一组实体），最后对每个社区生成一个摘要。检索时同时查询向量库和图社区摘要，把图结构信息和文本语义信息结合起来。

2.2 适用场景与局限

Graph RAG最擅长的场景是对"全局性问题"的回答。比如"我们公司在金融行业有什么竞争优势"，这个问题的答案分散在多份文档中——产品文档的技术参数、案例文档的客户反馈、方案文档的行业分析。Graph RAG可以通过图中的"产品→方案→行业→案例"路径，把这些分散的信息串联起来。

但它也有明显的局限。首先是构建成本高：从非结构化文档中自动抽取实体和关系，准确率很难做到100%，往往需要人工校验。其次，对于不涉及实体关系的问题（如"产品V3.0的安装步骤是什么"），Graph RAG的图结构没有额外帮助，反而增加了不必要的复杂度。

在投标书编写场景中，Graph RAG在"方案推荐"和"案例匹配"这两个环节有独特的价值。它可以帮助系统理解"这个客户属于金融行业，金融行业需要等保三级，我们有哪些产品通过了等保三级，这些产品在类似客户那里有什么成功案例"——这种跨实体多跳推理正是图结构的强项。

三、Self-RAG与Corrective RAG：让系统学会反思

3.1 Self-RAG：自我评估与按需检索

传统RAG的一个痛点是每次都检索，然后不管检索结果好坏都硬着头皮生成。Self-RAG（2023年底提出，2024-2025年广泛实践）改变了这个范式。

Self-RAG的核心机制是在大模型生成过程中插入"反思标记"。模型在生成每个片段之前，先评估一下：我需要检索更多信息吗？当前检索到的内容是否相关、是否支持我的下一个观点？如果评估结果是需要检索，就触发一次新的检索；如果评估结果是不需要或检索内容不相关，就跳过或重新检索。

这个机制的巧妙之处在于，检索不再是"一刀切"的，而是按需进行的。对于模型已经很有把握的内容（比如常见的行业知识），它可以直接生成而不用检索。对于那些需要精确数据支持的内容（比如具体的产品参数），它会主动触发检索。

Self-RAG的实现需要一个经过特殊训练的模型，能够在生成过程中输出反思标记。2024年有一些基于LLaMA系列微调的Self-RAG模型，2025年之后，部分大模型（如Claude Sonnet 4）已经在系统层面内建了类似的自我反思能力。

3.2 Corrective RAG：检索后纠错

Corrective RAG（CRAG）是另一种反思思路，但它的纠错发生在检索之后、生成之前。它的流程是：检索到一批文档块后，先用一个评估器判断这批内容的质量。如果质量高，直接用于生成；如果质量一般，对检索结果做知识精炼（提取关键信息、去除冗余）；如果质量很差，触发重新检索或者直接调用网络搜索作为补充。

CRAG比Self-RAG更容易实现，因为它不需要修改大模型本身，只需要在管道中加一个评估和纠错模块。这个评估器可以是一个小型的分类模型，也可以是用大模型的少数样本提示来做判断。

在投标书场景中，CRAG的纠错逻辑非常有价值。对于一个技术参数的查询，如果检索到的是旧版本文档中的描述，CRAG可以识别出这个不一致，并触发重新检索最新版本的文档。

3.3 两者的对比

Self-RAG是"边生成边反思"，CRAG是"检索后、生成前"的一次性纠错。前者更灵活但实现更复杂，后者更简洁但纠错深度有限。实践中，两者可以结合使用：CRAG做检索阶段的质量把控，Self-RAG做生成阶段的按需补充检索。

四、Agentic RAG：多智能体协作

4.1 从管道到智能体

前述所有RAG技术，本质上都是在优化一个固定的处理管道。但真实世界的复杂问题往往不是一个固定管道能处理的。比如"根据这份招标文件，帮我写一份技术方案"，这涉及理解招标文件内容、检索匹配的产品信息、查找相关案例、组织方案结构、生成文本内容——这是一系列需要规划和决策的复杂任务。

Agentic RAG把大模型从一个"内容生成器"升级为一个"任务规划者和执行者"。它不再被动地等待检索结果然后生成，而是自主规划需要做什么、按什么顺序做、中间结果是否满意、是否需要重新执行某个步骤。

基于LangGraph、CrewAI等框架，Agentic RAG的实现方式通常是定义多个专门的智能体——比如一个"检索智能体"负责查询知识库，一个"评估智能体"负责判断检索质量，一个"生成智能体"负责内容撰写，一个"审查智能体"负责检查生成内容的一致性。这些智能体按照一定的协作流程（顺序、并行、条件分支）协同完成任务。

4.2 适用场景

Agentic RAG的代价是延迟和成本显著增加——一次完整的任务执行可能涉及十几次甚至几十次大模型调用。所以它适合对延迟不敏感但任务复杂度高的场景。

投标书编写恰好就是这样的场景。一套完整的投标书从理解招标要求到生成技术方案，可能需要几分钟甚至更长时间，但相比人工撰写所需要的数天时间，这完全是可接受的。而且多智能体协作的灵活性可以让系统处理各种不同类型的招标文件——有的重点考察技术方案，有的重点考察项目团队，有的要求大量资质证明——Agentic RAG可以根据招标文件的具体要求动态调整工作流程。

4.3 实际落地的注意事项

Agentic RAG听起来很强大，但落地时坑也不少。最大的坑是多智能体之间的协调——如果两个智能体的输出不一致怎么办？如果一个智能体执行失败了怎么恢复？这些都需要仔细设计错误处理和回退机制。

另一个坑是成本控制。每次大模型调用都是真金白银，多智能体多次调用下来，一次复杂的投标书生成可能花费数元甚至数十元。所以要设置合理的调用上限，在成本和效果之间找到平衡。

五、Modular RAG与HyDE：模式创新

5.1 Modular RAG：可插拔的架构

Modular RAG不是一种具体的算法，而是一种架构思想——把RAG的各个环节模块化，每个模块可以独立替换和升级。检索模块、生成模块、重排序模块、查询改写模块、记忆模块……每个模块有自己的接口，可以根据场景需求灵活组合。

这种模块化思路在2025-2026年得到广泛认同。LangChain和LlamaIndex等框架本质上就是在践行Modular RAG的思想。对于工程团队来说，模块化意味着可以分阶段优化——这周优化检索模块，下周升级重排序模型，而不需要动整个系统。

5.2 HyDE：用假设答案来检索

HyDE（Hypothetical Document Embeddings）是一个非常巧妙的思路：不直接用用户问题去检索，而是先让大模型根据问题生成一个"假设性的答案"，然后用这个假设答案的向量去检索。

为什么这样效果更好？因为用户的提问和知识库中的文档在语言风格上有很大差异。用户问的是"你们产品快不快"，而知识库里写的是"系统响应时间小于100毫秒，QPS达10万"。如果直接用问句去检索，语义匹配效果可能不理想。但如果先让模型生成一个假设答案"我们的产品性能强劲，响应时间在毫秒级别，支持高并发处理"，这个假设答案的表述风格与知识库中的文档更接近，检索匹配度自然更高。

HyDE在2024年后被广泛应用，在多个测评中表现出对检索召回率10-15%的提升。它的额外成本只是一次轻量级的生成调用（可以用小模型来做假设答案的生成），性价比较高。

六、技术对比与选型建议

6.1 主流RAG技术对比

各种RAG技术在效果、成本、延迟、复杂度上各有侧重，选型需要综合考虑场景需求。

Naive RAG适合起步阶段和简单问答场景。它的实现成本最低，但面对复杂问题和多文档知识库时效果有限。Advanced RAG在Naive RAG基础上加入了查询优化、重排序等环节，是目前工业界采用最广泛的方案。对于大多数企业文档问答场景，Advanced RAG的效果已经能满足需求。

Graph RAG适合知识之间有明确实体关系、需要多跳推理的场景。但在知识主要是描述性文档而非实体关系图的场景中，Graph RAG的额外成本可能不划算。Self-RAG和CRAG适合对准确性要求极高的场景，通过自我纠错机制降低幻觉风险。Agentic RAG适合复杂多步骤任务，但延迟和成本较高。

6.2 投标书编写场景的技术选型建议

投标书编写是一个对准确性和多维度整合能力要求都极高的场景。基于前面的技术分析，一个务实的技术路线建议如下。

基础层采用Advanced RAG：查询改写 + 语义分块 + 重排序。这能保证基本的检索精度和生成质量。大部分"产品参数是什么""公司有哪些资质"之类的基础问题都能覆盖。

增强层引入Graph RAG用于方案推荐和案例匹配。当招标文件指定了行业和需求场景时，Graph RAG可以沿着"行业→方案→产品→案例"的路径，自动匹配最相关的方案和案例，为生成提供结构化的参考素材。

决策层采用Agentic RAG处理复杂的多步骤任务。比如"解析招标文件→提取关键需求→匹配合适方案→生成技术章节→检查一致性→输出完整标书"这样一条完整的流水线，通过多智能体协作来完成。

纠错层用CRAG做检索质量的最后把关。在生成关键章节（如技术参数、资质证明）之前，进行一次检索结果的验证和纠错，确保引用的数据准确无误。

最后，搭配一个评估体系（RAGAS等框架）对每个环节的效果进行量化监控。这四个层次的组合，能在复杂度可控的前提下，覆盖投标书编写的核心需求。

这一切都建立在高质量的知识库和精心设计的数据集之上。没有这个基础，技术选型再精妙也只是空中楼阁。下一篇会聚焦到具体的投标书编写场景，深入探讨如何将RAG技术应用到实际的标书生成中。