当前位置：首页 > news >正文

RAG技术大比拼：从Naive到Agentic，五种范式深度解析及选型指南

news 2026/6/16 5:30:14

大语言模型（LLM）虽能力强大，却长期受困于“幻觉”，尤其在高利害场景下，风险不容小觑。检索增强生成RAG（Retrieval-Augmented Generation）通过将生成过程与可验证的外部证据紧密耦合，直接解决了这一核心痛点。

自ChatGPT发布后，推理阶段的RAG方法大量涌现，并迅速演化出多种范式，技术生态呈现爆发态势。接下来将从范式演进的视角，系统梳理当前所有主流RAG方案，深入剖析各方案的核心思想、设计目标、典型示例及优劣势，并最终给出选型建议。

Naive RAG —— 起点：最简单的检索增强

1.1 核心思想

Naive RAG是RAG技术的原始形态。其工作流程极为直观：

索引构建：将文档切分为若干块（chunk），通过嵌入模型将每个chunk向量化后存入向量数据库；
查询检索：用户问题同样被向量化，在向量库中进行相似度检索，召回Top-K个最相似的文档块；
增强生成：将问题与检索到的文档块拼接，一起输入LLM生成最终答案。

┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ 文档库 │────▶│ 分块嵌入 │────▶│ 向量数据库 │ └─────────────┘ └─────────────┘ └──────┬──────┘ │ ┌─────────────┐ ┌─────────────┐ ┌──────▼──────┐ ┌─────────────┐ │ 用户查询 │────▶│ 向量化检索 │────▶│ 拼接上下文 │────▶│ LLM生成 │ └─────────────┘ └─────────────┘ └─────────────┘ └─────────────┘

1.2 目标

快速搭建一个基本的RAG原型，验证检索增强生成的技术可行性。适合开发者入门和简单的知识库问答场景。

1.3 示例

# Naive RAG 示例 from langchain.embeddings import OpenAIEmbeddings from langchain.vectorstores import Chroma from langchain.llms import OpenAI # 1. 构建索引 embeddings = OpenAIEmbeddings() vectorstore = Chroma.from_documents(docs, embeddings) # 2. 检索 + 生成 retriever = vectorstore.as_retriever(k=3) qa_chain = RetrievalQA.from_chain_type( llm=OpenAI(), retriever=retriever ) answer = qa_chain.run("RAG的核心优势是什么？")

1.4 优劣势

优势	劣势
实现简单，快速上手	语义感知不足，碎片化输出
适合简单的事实性问答	召回率低，准确率有限
计算开销小	缺乏端到端优化，可扩展性差
长文档推理能力弱

据CSDN技术博客的分析，Naive RAG在实际业务场景中测试效果并不理想，目前已很少在生产环境中单独使用。

Advanced RAG —— 进阶：全链路优化

2.1 核心思想

Advanced RAG在Naive RAG的基础上，针对“召回率不足、准确率不高”等核心痛点，进行了全链路的精细化优化。其优化思路贯穿RAG的三大核心环节：

检索前优化：

更精细的分块策略：语义分块（基于句法树动态切割，保留完整语义单元）、上下文增强（为每个块添加前后邻居段落）
元数据利用：为文档块添加标题、作者、时间戳等结构化信息

检索优化：

查询改写：用LLM生成同义问题，扩大检索覆盖面
混合检索：将稠密向量检索与稀疏关键词检索相结合，兼顾语义与字面匹配

检索后优化：

重排序：对Top-K结果用Cross-Encoder二次打分，提升召回精度
上下文压缩：剔除无关文本，降低Token消耗

┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ 文档预处理 │────▶│ 精细分块 │────▶│ 向量数据库 │ │ (元数据/摘要)│ │(语义/上下文)│ └──────┬──────┘ └─────────────┘ └─────────────┘ │ │ ┌─────────────┐ ┌─────────────┐ ┌──────▼──────┐ ┌─────────────┐ │ 查询改写 │────▶│ 混合检索 │────▶│ 重排序 │────▶│ LLM生成 │ └─────────────┘ └─────────────┘ └─────────────┘ └─────────────┘

2.2 目标

提升RAG系统的召回率、准确率和上下文理解能力，使其能够应对实际业务场景中的多样化需求。

2.3 示例

# Advanced RAG 示例：查询改写 + 重排序 from langchain.retrievers import MultiQueryRetriever from langchain.retrievers import ContextualCompressionRetriever from langchain.retrievers.document_compressors import CohereRerank # 查询改写：生成多个角度的问题 multi_query_retriever = MultiQueryRetriever.from_llm( retriever=base_retriever, llm=llm ) # 重排序：二次打分筛选最相关文档 compressor = CohereRerank(top_n=3) compression_retriever = ContextualCompressionRetriever( base_compressor=compressor, base_retriever=multi_query_retriever )

2.4 优劣势

优势	劣势
召回率和准确率显著提升	计算开销较大
语义理解能力增强	多步推理能力仍有局限
支持多种优化策略组合	调优复杂度增加

Modular RAG —— 灵活：模块化可组合架构

3.1 核心思想

Modular RAG将RAG系统抽象为一组可独立实现和替换的功能模块，支持根据具体业务场景灵活组合。

在实际的智能问答场景中，文档来源复杂、格式多样（Word/PDF/Excel/数据库/API），不同场景需要不同的处理流程和召回策略。Modular RAG通过模块化设计降低开发和维护成本——不同场景选择不同的模块组合即可，无需每次都重新开发。

其核心架构通常包含以下可插拔模块：

┌─────────────────────────────────────────────────────────────────────┐ │ Modular RAG 架构 │ ├─────────────────────────────────────────────────────────────────────┤ │ │ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌───────┐ │ │ │文档解析 │──▶│分块策略 │──▶│嵌入模型 │──▶│存储后端 │──▶ │ 索引 │ │ │ │模块 │ │模块 │ │模块 │ │模块 │ │ 模块 │ │ │ └─────────┘ └─────────┘ └─────────┘ └─────────┘ └───────┘ │ │ │ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌───────┐ │ │ │查询路由 │──▶│检索策略 │──▶│重排序 │──▶│上下文 │──▶│ 生成 │ │ │ │模块 │ │模块 │ │模块 │ │ 压缩模块 │ │ 模块 │ │ │ └─────────┘ └─────────┘ └─────────┘ └─────────┘ └───────┘ │ │ │ │ 支持迭代检索、自适应检索、递归检索等多种模式 │ └─────────────────────────────────────────────────────────────────────┘

3.2 目标

实现RAG系统的高度灵活性和可扩展性，支持多数据源、多格式、多场景的快速适配，降低重复开发成本。

3.3 示例

# Modular RAG 示例：根据文档类型选择不同模块 class ModularRAG: def __init__(self, config): self.parser = get_parser(config["doc_type"]) # 根据类型选择解析器 self.chunker = get_chunker(config["chunk_strategy"]) self.embedder = get_embedder(config["embed_model"]) self.retriever = get_retriever(config["retrieval_strategy"]) def query(self, question): # 路由：根据问题类型动态选择检索策略 if self.is_complex_query(question): return self.iterative_retrieval(question) # 迭代检索模式 else: return self.single_retrieval(question) # 单步检索模式

3.4 优劣势

优势	劣势
高度灵活，模块可插拔替换	架构复杂度较高
支持多数据源、多格式适配	需要精心设计模块接口
降低重复开发成本	模块间协调开销
易于迭代升级	对开发者架构能力要求较高

Graph RAG —— 深度：基于知识图谱的关系推理

4.1 核心思想

Graph RAG是RAG的第四种范式，由微软在2024年开源，通过引入知识图谱来赋予系统强大的多跳推理和全局理解能力。传统RAG聚焦于局部检索——根据查询语句在向量库中匹配部分知识——但面对需要“连接多个信息点”的复杂问题时力不从心。

Graph RAG的核心工作流程：

图谱构建：使用LLM从源文档中提取实体、关系和声明，构建知识图谱；
社区检测：使用Leiden算法进行层次聚类，为紧密相关的实体群体生成社区摘要；
多层次检索：支持全局检索（回答宏观问题）、局部检索（回答实体相关问题）和混合检索。

┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ 源文档 │────▶│ 实体/关系 │────▶│ 知识图谱 │ │ │ │ LLM提取 │ │ (节点+边) │ └─────────────┘ └─────────────┘ └──────┬──────┘ │ ▼ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ 社区检测 │────▶│ 社区摘要 │────▶│ 图遍历 │ │(Leiden聚类) │ │ 生成 │ │ 检索 │ └─────────────┘ └─────────────┘ └──────┬──────┘ │ ▼ ┌─────────────────────────────────┐ │ 全局检索 │ 局部检索 │ 混合检索 │ └─────────────────────────────────┘

以《仙逆》小说为例，如果你问“王林这一生有几个相好？”，传统RAG难以回答，因为答案需要综合全书多处信息。Graph RAG通过实体图谱和社区摘要，能够有效综合分散的信息，给出全局性的回答。

4.2 目标

解决复杂关系推理和全局理解问题，适用于多跳问答、跨文档推理、大型语料库的宏观分析等场景。基于图的检索支持直接的路径遍历（例如公司→供应商→ESG违规→财务影响），确保深层多跳查询的准确性。

4.3 示例

# Graph RAG 示例：基于知识图谱的多跳推理 from neo4j import GraphDatabase class GraphRAG: def query_entity_relations(self, entity_name, relation_type=None): # Cypher查询遍历图谱关系 query = """ MATCH (e:Entity {name: $name})-[r]->(related) RETURN e, r, related """ # 执行图遍历检索 with self.driver.session() as session: result = session.run(query, name=entity_name) return self._format_graph_context(result) def global_search(self, topic): # 社区摘要检索 summaries = self._retrieve_community_summaries(topic) return self._synthesize_global_answer(summaries)

4.4 优劣势

优势	劣势
强大的多跳推理能力	前期LLM构建成本高
全局理解能力卓越	图谱维护开销大，需定期刷新
可解释性强，可追溯推理路径	Schema设计复杂，需精确本体设计
适合关系密集型领域	检索延迟高于向量检索

企业实践表明，VectorRAG与GraphRAG并非互斥关系。混合架构可利用向量相似性进行候选选择，再通过图谱验证结构化关系，在150-200ms的编排开销下可获得15-25%的精度提升。

Agentic RAG —— 智能：具备自主决策能力的主动式RAG

5.1 核心思想

Agentic RAG是RAG的第五种范式，出现于2024年下半年，被视为前四种范式的集大成者。与传统RAG的被动式流程不同，Agentic RAG引入AI智能体（Agent）主动编排检索过程——智能体可以分析查询并决定何时检索、使用什么工具（向量搜索、Web搜索、API调用等）以及如何制定最佳查询。

核心特征：

自主决策：Agent自主判断是否需要检索外部知识。遇到简单问题或模型自己能解决的问题，可以跳过检索流程，直接回答，从而提升响应速度
工具调用：可动态选择多种检索工具（向量库、搜索引擎、知识图谱、API等）
多步规划：支持复杂任务的任务分解和迭代执行
反思与修正：评估检索结果质量，必要时调整策略

┌─────────────────────────────────────────────────────────────────────┐ │ Agentic RAG 工作流程 │ ├─────────────────────────────────────────────────────────────────────┤ │ │ │ ┌─────────────┐ │ │ │ 用户查询 │ │ │ └──────┬──────┘ │ │ ▼ │ │ ┌──────────────────────────────────────────────────────────────┐ │ │ │ Agent (智能体) │ │ │ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │ │ │ │分析查询 │─▶│ 规划 │─▶│ 工具调用│─▶│ 评估反思 │ │ │ │ │ └─────────┘ └─────────┘ └────┬────┘ └─────────┘ │ │ │ └─────────────────────────────────┼────────────────────────────┘ │ │ │ │ │ ┌──────────────────────────┼──────────────────────────┐ │ │ ▼ ▼ ▼ │ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐│ │ │ 向量数据库 │ │ Web搜索 │ │ 知识图谱 ││ │ └─────────────┘ └─────────────┘ └─────────────┘│ │ │ │ ▼ │ │ ┌─────────────────┐ │ │ │ LLM 合成回答 │ │ │ └─────────────────┘ │ └─────────────────────────────────────────────────────────────────────┘

5.2 目标

将RAG系统从静态流水线升级为动态推理引擎，实现复杂任务的自主决策和自适应执行，为构建真正智能的AI应用奠定基础。

5.3 示例

# Agentic RAG 示例：智能体自主规划检索 from langchain.agents import initialize_agent, Tool from langchain.agents import AgentType tools = [ Tool(name="VectorSearch", func=vector_search, description="私有文档向量检索"), Tool(name="WebSearch", func=web_search, description="互联网实时信息检索"), Tool(name="KGQuery", func=kg_query, description="知识图谱关系查询") ] agent = initialize_agent( tools=tools, llm=llm, agent=AgentType.ZERO_SHOT_REACT_DESCRIPTION, verbose=True ) # Agent自主决定使用哪些工具 response = agent.run("2025年RAG领域有哪些突破性进展？需要结合最新论文和行业动态回答。")

5.4 优劣势

优势	劣势
自主决策，高度智能化	系统复杂度最高
支持多工具协同	推理链较长时延迟增加
可处理复杂、开放域问题	对LLM推理能力要求高
具备反思和自我修正能力	调试和监控难度大

其他重要RAG方案

除了上述五大范式，RAG技术生态中还涌现了多个值得关注的前沿方向：

6.1 Self-RAG & CRAG —— 自我反思与纠错

Self-RAG让LLM在生成过程中自主判断是否需要检索外部知识。模型会评估自身知识是否足够回答问题，如果不足则触发检索流程。

CRAG（Corrective RAG）引入轻量级检索评估器，对检索到的文档进行相关性评分，根据评分触发三种动作：

Correct：文档相关，但需进一步精炼（分解→过滤→重组）
Incorrect：文档不相关，转向Web搜索获取新知识
Ambiguous：信心不足，同时执行上述两种动作

这两种方案通过引入“元认知”能力，让RAG系统能够自我评估和自我修正，显著提升了答案的可靠性。

6.2 RAPTOR —— 分层树形检索

RAPTOR（Recursive Abstractive Processing for Tree-Organized Retrieval）通过递归嵌入、聚类和摘要技术，创建分层树结构，支持在不同抽象层级检索信息。

传统RAG在扁平化的文档块上搜索，而RAPTOR构建多层级树——每一层包含越来越抽象的摘要。实验数据表明，对最终检索做出贡献的大部分节点来自非叶子层，凸显了分层摘要在检索过程中的重要性。RAPTOR特别适合处理长文档和多文档综合分析场景。

6.3 Multimodal RAG —— 多模态扩展

随着多模态大语言模型的兴起，RAG也扩展到了多模态领域。MM-RAG（Multimodal RAG）旨在将检索增强生成能力扩展到文本、表格、图表、图像和布局等多种模态。

代表性的方案包括：

MHier-RAG：针对富视觉文档问答，通过层次化和多粒度推理定位和整合多模态证据
M³KG-RAG：将多模态知识图谱引入RAG，提升多模态大语言模型的推理深度和答案忠实度

6.4 CAG —— 缓存增强生成的轻量级替代

Cache-Augmented Generation（CAG）作为RAG的轻量级替代方案，将所有相关上下文预加载到模型的大上下文窗口中并缓存其运行时参数。CAG避免了每次查询都进行实时检索，从而最小化检索延迟并简化系统设计。

RAG与CAG的核心区别：RAG为每次查询实时检索最新信息，而CAG依赖预先存储的数据。CAG适合数据更新频率低、上下文总量可控的场景。

6.5 Causal RAG —— 因果推理增强

CausalRAG将因果图集成到检索增强生成框架中，显式识别外部知识中的因果关系，保留上下文连贯性，同时捕获底层因果依赖关系。相比普通RAG和图谱RAG，CausalRAG在知识密集型任务中展现出更好的检索精度和可解释性。

6.6 Hybrid RAG —— 混合架构的融合之道

Hybrid RAG并非单一技术，而是一种设计理念——将向量检索、知识图谱、全文引擎和结构化数据库统一到单一检索平面，动态路由和融合多源证据以最大化召回率、精度和上下文保真度。代表性方案如HetaRAG通过跨异构数据存储的协同编排，实现了对多模态证据的统一检索与融合。

五大范式核心对比

对比维度	Naive RAG	Advanced RAG	Modular RAG	Graph RAG	Agentic RAG
复杂度	★☆☆☆☆	★★☆☆☆	★★★☆☆	★★★★☆	★★★★★
检索精度	低	中高	中高	高（关系推理）	高（自适应）
推理能力	单跳	单跳为主	单跳/多跳	多跳	多跳+规划
全局理解	弱	中	中	强	强
灵活性	低	中	高	中	极高
计算成本	低	中	中	高	高
维护成本	低	中	中	高	高
可解释性	低	中	中	高	中高
适用场景	简单问答/原型	企业知识库	多源异构数据	关系推理/宏观分析	复杂开放域任务

总结：谁才是RAG最佳选择？

经过对五大范式及多种变体的深入分析，答案很明确：没有绝对的“最佳”，只有最适合你业务场景的选择。

快速原型验证→Naive RAG：如果你只是想快速验证RAG的技术可行性，Naive RAG是最简单的起点。
企业知识库问答→Advanced RAG：面向生产环境的企业文档问答，Advanced RAG通过查询改写、重排序等优化手段，能在可控成本下获得良好的准确率。
多源异构数据整合→Modular RAG：当你的数据来自Word、PDF、Excel、数据库等多个渠道，Modular RAG的模块化设计能帮你快速适配不同场景，避免重复造轮子。
复杂关系推理→Graph RAG：如果你的业务涉及多跳推理（如供应链分析、组织架构查询、法规影响追溯），Graph RAG凭借知识图谱的结构化表达能力，能提供传统向量检索无法企及的推理深度。
智能体驱动的高复杂度任务→Agentic RAG：面向需要自主规划、多工具协同的复杂场景，Agentic RAG提供了最灵活、最智能的解决方案，但同时也带来最高的系统复杂度。