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

万字长文深度解析 RAG

news 2026/8/9 19:28:00

1 为什么需要 RAG？

检索增强生成（Retrieval-Augmented Generation，RAG）是一种将大语言模型（LLM）与外部知识库相结合的技术范式，其核心目标在于：

知识局限：解决大模型知识局限于训练数据的问题（“参数中的知识”）
幻觉问题：缓解模型“幻觉”（无中生有地生成错误信息）
数据安全：在不上传私域数据至第三方平台的前提下，实现安全、可控的智能问答

1.2 RAG 的本质

RAG (开卷考试)

用户提问 Query

R: 检索 (Retrieval)
从图书馆/数据库查资料

A: 增强 (Augmented)
将相关资料放在模型案头

G: 生成 (Generation)
LLM 结合资料进行逻辑推导

✅ 优点：事实准确、引用溯源
实时性高、私有数据受控

传统 LLM (闭卷考试)

用户提问 Query

LLM 内部大脑
(参数化知识 Parametric Memory)

直接生成答案
(依赖模型记忆)

❌ 风险：幻觉、知识过时
无法访问私有文档

本质区别：知识存储与逻辑推理的解耦

RAG是“一场 LLM 的“开卷考试”

传统 LLM（闭卷考试）：模型依靠预训练阶段记忆在参数里的知识（Parametric Memory）来回答问题。如果考题涉及它没读过的私有文档或训练日期之后的时政，它就会为了“交卷”而编造答案，产生幻觉。
RAG（开卷考试）：在回答问题前，先允许模型去图书馆（外部知识库）查阅相关资料，把资料放在案头，再结合题目给出答案。

通过拆解R、A、G这三个字母，我们可以更深刻地看到这一技术的本质：

1.2.1 R（Retrieval / 检索）：解决“去哪找”的问题

R是整个流程的起点，它的本质是从海量非结构化数据中精准定位。

从“模糊”到“精确”：LLM 内部的知识是高度压缩且模糊的（概率预测），而外部检索到的文档是确定性的（事实）。
非参数化存储：R 将知识的存储从模型参数（很难更新）中剥离出来，转存到向量数据库或搜索引擎中（极易更新）。
核心挑战：检索的质量决定了 RAG 的上限。如果第一步找错了“参考书”，后面的回答就会南辕北辙。

1.2.2 A（Augmented / 增强）：解决“怎么用”的问题

A其实是 RAG 的灵魂纽带，它是联结检索结果与生成模型的“桥梁”。

上下文增强：检索回来的原始文档通常是零散、冗余甚至有噪声的。Augmented的过程就是对这些原始材料进行“精加工”——包括重排序（Rerank）、清洗、甚至长文本压缩。
Prompt 的重构：它将用户的问题（Query）与检索到的知识（Context）进行有机融合，构建出一个功能强大的 Prompt。
本质逻辑：它是通过注入外部上下文，改变了 LLM 的推理环境。它把一个简单的“问答”变成了一个“基于给定事实进行推理”的任务。

1.2.3 G（Generation / 生成）：解决“怎么说”的问题

G是最终的产出。此时的 LLM 不再扮演“百科全书”，而是扮演一个“具备逻辑分析能力的阅读理解专家”。

约束生成：在 RAG 场景下，我们对 G 的要求不是博学，而是忠实（Faithfulness）。我们希望它在给定的资料范围内组织语言，避免发散。
推理引擎：利用 LLM 强大的语言组织和逻辑推导能力，将碎片化的检索信息转化为连贯、易读、符合人类逻辑的答案。
本质转变：G 将 LLM 的角色从“知识库”转化为了“推理机”。

1.2.4 总结：RAG 的哲学公式

如果用一个公式来表达 RAG 的本质，那就是：

检索（寻找事实）增强（对齐上下文）生成（逻辑表达）检索（寻找事实）增强（对齐上下文）生成（逻辑表达）��=检索�（寻找事实）+增强�（对齐上下文）+生成�（逻辑表达）

没有 R：LLM 是无米之炊，容易一本正经胡说八道。
没有 A：知识与模型之间存在隔阂，容易出现“消化不良”。
没有 G：用户拿到的是一堆文档碎片，无法直接获取答案。

RAG 的出现，本质上是解耦了“知识存储”与“逻辑推理”：让数据库负责记住知识，让大模型负责理解和运用知识。

2. RAG 的演进

本章节将介绍RAG近些年的演进，同时向你展示当下RAG的几种主要形态

2020Naive RAG概念奠基检索-增强-生成线性架构2023Advanced RAG策略优化重排序 / 混合检索 /意图改写2023Modular RAG范式升级插件化模块 /路由分发 / 灵活编排2023GraphRAG拓扑增强知识图谱 / 社区发现/ 全局总结2024Agentic RAG智能进化自主规划 / 多步推理/ 自我修复RAG 技术演变简图

2.1 Naive RAG

摘自[2501.09136] Agentic Retrieval-Augmented Generation: A Survey on Agentic RAG

2.1.1 概念介绍

Naive RAG 是 RAG 技术最原始、最标准的形态。它出现于 2020 年左右（由 Lewis 等人提出），旨在通过一个简单的线性流水线，将外部静态知识库与预训练大语言模型（LLM）结合。它不涉及复杂的逻辑判断或多轮检索，只是机械地完成“搜索并喂给模型”的任务。

2.1.2 机制原理

Naive RAG 的工作流程是一个典型的线性单向流水线，分为两个阶段：

离线阶段（数据准备/索引）：
1. 清洗与分块（Chunking）：将原始文档（PDF、Markdown等）切分成固定大小的文本块（如每块 512 字符）。
2. 向量化（Embedding）：利用 Embedding 模型将每个文本块转换为高维向量。
3. 构建索引：将向量存入向量数据库（Vector DB），建立索引以备查询。
在线阶段（推理/生成）：
1. 检索（Retrieval）：将用户的提问（Query）转换成同样的向量，在数据库中进行余弦相似度计算，召回最相似的 Top-K 个文本块。
2. 增强（Augmentation）：将这 K 个文本块直接拼接到 Prompt 中，作为“背景知识”。
3. 生成（Generation）：LLM 阅读 Prompt 中的上下文，输出最终答案。

2.1.3 优点

实现简单：几乎不需要复杂的工程架构，利用 LangChain 或 LlamaIndex 几行代码即可搭建。
低成本：不涉及多轮推理或复杂的重排序模型，API 调用次数少，响应速度快。
透明度高：流程极其直观，容易追踪哪一部分文档被召回用于辅助生成。
通用性强：无需对模型进行微调（Fine-tuning），即可在不同领域的私有数据上快速上线。

2.1.4 缺点

检索精度低（Low Precision）：
- 由于仅依赖语义向量，容易召回与 Query 语义相近但事实无关的噪声内容。
- 语义偏差：向量搜索对关键词（如专有名词、产品型号）不够敏感。
召回率不足（Low Recall）：
- 如果相关的知识分散在多个分块中，固定长度的切分可能导致关键上下文断裂。
生成质量受限：
- 上下文过载：如果召回的 Top-K 内容相互矛盾或含有大量冗余，会导致模型产生“幻觉”或忽略关键信息（Lost in the middle）。
- 缺乏逻辑：无法处理需要多步推理的问题，因为它只进行一次性检索。
知识时效性滞后：虽然比纯模型好，但如果外部知识库很大，索引更新（增删改）的同步成本和一致性在 Naive 架构下较难处理。

Naive RAG 就像是一个“直肠子”：你问什么，它就去翻书，翻到哪页算哪页，然后一股脑念给你听。虽然解决了“从无到有”的问题，但在处理企业级复杂业务时，往往显得过于“笨拙”。这也是为什么后来演化出了 Advanced RAG。

2.2 Advanced RAG

摘自[2501.09136] Agentic Retrieval-Augmented Generation: A Survey on Agentic RAG

2.2.1 概念介绍

Advanced RAG 并非改变了 RAG 的基本范式，而是通过“精细化工程”对流水线的每一个环节进行了增强。它的核心逻辑是：不仅要搜到，还要搜得准；不仅要喂给模型，还要喂精华。它解决了向量检索在关键词匹配上的弱点，以及召回内容过多导致的干扰问题。

2.2.2 机制原理

Advanced RAG 在传统的 R-A-G 链路中插入了多个关键优化节点，下面简单介绍一些：

预检索优化 (Pre-Retrieval Strategies)：
- 查询重写 (Query Rewriting)：利用 LLM 将用户模糊的提问转化为更适合检索的表达。
- 多查询并行 (Multi-Query)：从不同角度生成多个相似问题并行检索，扩大搜索范围。
- 假设性文档嵌入 (HyDE)：让 LLM 先生成一个“虚假但理想”的答案，再用这个答案去向量库搜真正的参考文档（解决 Query 与 Doc 之间的语义鸿沟）。
索引增强 (Indexing Optimization)：
- 混合检索 (Hybrid Search)：结合向量检索（语义）与关键词检索（BM25/全文搜索），确保专有名词不丢失。
- 精细化分块：采用滑动窗口或父子分块（Parent-Document Retrieval），检索小块以保证精度，返回大块以保证上下文完整。
后检索处理 (Post-Retrieval Strategies)：
- 重排序 (Reranking)：这是 Advanced RAG 的灵魂。先粗筛出 100 条，再利用高精度的Cross-Encoder 模型对其进行精排，只取前 5-10 条。
- 上下文压缩 (Context Compression)：剔除召回文档中的废话，只保留与问题最相关的句子，减少 Token 消耗并降低干扰。

2.2.3 优点

检索精度极高：通过 Rerank 和混合检索，大幅降低了无关噪声的干扰。
解决“中间失落”问题：通过压缩和精选，避免了由于输入上下文过长导致 LLM 忽略中间有效信息的现象（Lost in the Middle）。
更好的语义对齐：HyDE 和 Query Rewrite 让模型能更好地理解用户的真实意图，即便用户问得很模糊。
工程落地成熟：是目前大多数企业级 RAG 应用的主流选择，平衡了性能与复杂度。

2.2.4 缺点

响应延迟增加：Query 重写、多次检索以及 Rerank 都会消耗额外的时间，首字响应（TTFT）显著变慢。
Token 成本上升：在生成最终答案前，往往需要多次调用 LLM 进行重写或压缩，增加了 API 费用。
流水线复杂化：需要维护多个模型（Embedding, Reranker, LLM）以及复杂的业务逻辑，对系统稳定性挑战更大。
依然是线性思维：虽然环节变多了，但本质还是“一次性”的流水线，难以处理需要多步拆解或全局总结的极复杂任务。

如果说 Naive RAG 是在图书馆里随便找书，Advanced RAG 就是先请一位专家帮你优化搜索词，找出一堆书后再由专人精读、划重点，最后把精华笔记交到你手上。这显著提升了答案的靠谱程度，但也意味着你得支付更多的“专家费”并等待更久。

2.3 GraphRAG

摘自[2501.09136] Agentic Retrieval-Augmented Generation: A Survey on Agentic RAG

2.3.1 概念介绍

GraphRAG 是由微软（Microsoft）等机构推向主流的一种范式，旨在解决传统向量 RAG 的两个核心局限：缺乏全局理解力和难以处理跨文档的多跳逻辑。

传统的向量 RAG 擅长处理“局部”信息（点对点检索），而 GraphRAG 通过引入知识图谱（Knowledge Graph, KG），将非结构化的文本转化为结构化的语义网络。它不仅能找到具体的“点”，还能理解点与点之间的“线”，甚至是通过社区发现（Community Detection）技术看清全局的“面”。

2.3.2 机制原理

GraphRAG 的本质是“以图聚类，以文摘要”。其核心架构可以拆解为两个阶段：层次化索引构建与多模态查询策略。

2.3.2.1 索引阶段：从非结构化文本到语义社区

这是 GraphRAG 最耗时也最核心的部分，分为四个关键层级：

实体与关系提取（Extraction）：
- 利用 LLM 扫描原始文本块，提取出实体（Entities）、关系（Relationships）和声明（Claims）。
- 关键技术：实体消歧（Entity Resolution）。例如，将文中出现的“马斯克”和“Elon Musk”识别并归并为同一个节点。
图谱构建与图压缩（Graph Construction）：
- 将提取的实体作为节点，关系作为边，构建初始图谱。
- 计算节点权重（度数）和边的重要性，对图进行精简。
社区发现（Community Detection）：
- 使用Leiden 算法或Louvain 算法对图进行层次化聚类。
  - Louvain 算法：这是一种基于“模块化（Modularity）最大化”的经典贪心算法，通过不断迭代合并邻近节点来发现图谱中的社区结构，以极高的计算效率在大规模网络中挖掘出紧密的关联群体。
  - Leiden 算法：作为 Louvain 的升级版，它通过引入重构机制解决了 Louvain 可能产生不连贯或低质量社区的缺陷，能够以更快的速度识别出逻辑更严密、结构更合理的语义社区。
- 将联系紧密的实体划分为不同的社区（Communities）。这一步模拟了人类对知识的分类（如：从“特斯拉”延伸出“电动汽车社区”、“财报分析社区”、“自动驾驶技术社区”）。
层次化社区摘要（Community Summarization）：
- 自下而上生成：针对每个社区及其包含的边和节点，利用 LLM 生成一份详尽的报告（Summary）。
- 这些摘要分层存储（从微观社区到中观社区再到宏观主题），形成了知识库的“全局大纲”。

2.3.2.2 查询阶段：双路径检索模型

根据用户问题的粒度，GraphRAG 动态选择两种检索路径：

路径 A：全局查询（Global Search）—— 处理概括性/宏观问题
- 场景：如“这个项目的核心风险点有哪些？”
- 机制：采用类似Map-Reduce的逻辑。
  - Map：并行检索所有预生成的社区摘要，生成中间回答。
  - Reduce：对所有中间回答进行评分和汇总，生成最终的全局综述。
路径 B：局部查询（Local Search）—— 处理具体事实/多跳问题
- 场景：如“A 公司的 CTO 是如何评价 B 技术的？”
- 机制：结合向量检索与图遍历。
  - 起始点：通过向量搜索找到与 Query 相关的实体节点。
  - 顺藤摸瓜：沿着图谱的边扩展，寻找相邻节点、关联关系及相关的原始文档块。
  - 融合生成：将找到的结构化图数据与非结构化文本块组合，作为上下文喂给 LLM。

2.3.3 优点

全局视野（Global Understanding）：它是目前回答总结性、对比性问题表现最好的 RAG 架构。
复杂推理链条（Multi-hop Reasoning）：通过图谱的“边”，它能轻松连接原本分布在不同文档、不同页码的信息片段。
抗噪声能力强：社区摘要过程本质上是一种“去粗取精”的信息过滤，降低了低相关文档对生成的干扰。
数据可溯源性：每一个生成的结论都可以精准定位到图谱中的特定节点（实体）和边（关系），提供了比纯向量检索更强的可解释性。

2.3.4 缺点

极高的计算开销（Cost & Time）：
- 索引阶段需要 LLM 扫描每一行文本并提取关系，其 Token 消耗量通常是传统 RAG 的50x - 100x。
- 对于海量文档，构建一次索引可能耗时数天且成本昂贵。
索引更新困难：由于图谱和社区摘要是全局耦合的，新增文档时往往难以进行“增量更新”，有时需要重构部分社区，维护成本高。
提取阶段的信息损耗：如果 LLM 在初期提取实体和关系时出错（Schema 偏移或漏掉关键关系），后续的检索无论多么精妙也无法补救。
技术栈异构化：需要管理向量数据库（如 Milvus）和图数据库（如 Neo4j/NebulaGraph），增加了运维复杂性。

如果说传统的向量 RAG 是一本地图册，你可以查到具体的坐标（经纬度）；那么 GraphRAG 就是一个城市大脑，它不仅知道每个建筑的位置，还深谙它们之间的交通流向、隶属关系以及整个城市的区域划分。它让大模型真正具备了“全局观”，但你必须为构建这个大脑支付高昂的计算电费。

2.4 Modular RAG

原文地址：[2407.21059] Modular RAG: Transforming RAG Systems into LEGO-like Reconfigurable Frameworks
编写参考：【RAG技术论文】《模块化RAG（Modular RAG）: 将RAG系统转变为乐高玩具一样的可重构框架》 - 知乎

摘自[2501.09136] Agentic Retrieval-Augmented Generation: A Survey on Agentic RAG

摘自论文：[2407.21059] Modular RAG: Transforming RAG Systems into LEGO-like Reconfigurable Frameworks

2.4.1 概念介绍

Modular RAG 是在 RAG 技术走向成熟过程中提出的更高阶范式。它的核心思想是：将复杂的 RAG（检索增强生成）系统解耦为独立、可复用的功能单元，并通过编排（Orchestration）这些单元来构建灵活多变的处理流程（称为 RAG Flow）。它不再局限于传统的“检索-然后-生成”线性范式，而是提供了一个类似“乐高积木”的可重构框架。

这种架构允许开发者针对不同的业务场景，灵活地插入、替换或重复某些处理步骤。

2.4.2 机制原理

Modular RAG 的运作不再是“一条路走到底”，而是基于模块化组件进行流程编排：

论文中给出的一个典型示例

2.4.2.1 三层架构设计

论文提出了一个清晰的三层架构，从宏观到微观定义了系统的组成：

L1: 模块 (Module)：这是最高层级，关注RAG系统中的关键阶段，将每个阶段视为独立模块，继承了高级RAG的主要流程并引入了编排模块来协调流程：
- 索引 (Indexing)：处理文档的分块、向量化和存储。支持高级策略如分层索引、知识图谱索引等。
- 检索前 (Pre-retrieval)：优化查询本身，如查询重写（Rewrite）、查询扩展（Multi-Query）、假设性文档嵌入（HyDE）、查询构造（Text-to-SQL/Cypher）等。
- 检索 (Retrieval)：执行实际的检索操作。支持多种检索器（稀疏、稠密、混合）以及微调策略（监督微调、语言模型监督微调、适配器等）。
- 检索后 (Post-retrieval)：对检索结果进行后处理，如重排序（Rerank）、压缩（Compression）和选择（Selection），以去除噪声、冗余并提升关键信息的可见性。
- 生成 (Generation)：利用 LLM 和检索到的上下文生成答案。支持生成器的微调（指令微调、强化学习）和验证（基于知识库或模型的验证）。
- 编排 (Orchestration)：这是 Modular RAG 的“大脑”，负责动态控制整个流程的走向。
L2: 子模块 (Sub-module)：在每个模块内部，功能可以被进一步细化为子模块，用于更精细的优化。
L3: 操作符 (Operator)：这是最基础的执行单元，是具体功能的实现。例如，在“检索前”模块中，HyDE、Query Rewrite等都是独立的操作符。这些操作符是系统可维护性和可理解性的基石。

2.4.2.2 编排控制机制

这是 Modular RAG 超越线性架构的关键，由三个核心组件构成：

路由 (Routing)：
- 概念：RAG系统根据不同查询将其路由到特定处理管道，这是适应多场景RAG架构的关键功能。需要决策机制来确定将使用哪些模块，依据模型输入或元数据信息进行选择。不同提示或组件有不同的路由机制。例如：一个关于法律的问题可能被路由到一个包含法律知识图谱索引和专业法律验证的流程，而一个普通常识问题则走一个更通用的流程。
- 路由机制：
  - 元数据路由：从查询中提取关键术语或实体，并结合块中的元数据优化路由。
  - 语义路由：根据查询的语义信息，将其路由到不同的模块。
  - 混合路由：结合语义分析和基于元数据的路由方法，以改进查询路由。
调度 (Scheduling)：
- 概念：随着RAG系统的复杂性和适应性的提升，调度模块能够有效地管理整个流程。它在模块化RAG系统中发挥着关键作用，帮助识别需要外部数据检索的关键时刻，评估生成结果的质量，并决定是否需要进一步的处理。调度模块常用于递归、迭代和自适应检索场景，确保系统能够在合适的时机停止生成或启动新的检索过程。
- 判断机制：
  - 规则判断：后续步骤由一组预设规则控制。如根据结果的置信度阈值判断是否继续。
  - LLM判断：LLM能够独立判断后续操作的流程。通过提示词工程或者微调LLM，使其生成特定的token来触发操作。
  - 知识引导调度：利用知识图谱引导检索和生成流程，具体做法是从知识图谱中提取与问题相关的信息并构建推理链。推理链由一系列逻辑相关的节点组成，每个节点提供解决问题的关键信息。基于这些节点的信息，可以分别执行检索和内容生成。这种方法不仅提高了问题解决的效率和准确性，还使生成的解释更加清晰。
融合 (Fusion)：
- 概念：随着RAG流程超越了传统的线性模式，常常需要扩展检索范围或通过多个处理管道来增加多样性。因此，在扩展到不同分支后，融合模块用于整合信息，确保生成的回答全面且一致。融合模块不仅合并答案，还确保输出内容丰富，并能充分反映问题的多维度特性。
- 融合机制：
  - LLM融合：多分支信息整合的一种直接方法是利用LLM强大的能力，分析并整合来自不同分支的信息。答案长度超出上下文窗口限制时，先逐个进行总结，在长度限制内保留关键信息，再进行融合。
  - 加权集成：根据不同分支生成的token加权，进行最终答案的选择。权重由召回结果（result）和查询（query）的相似度得分决定
  - 互惠排序融合（RRF）：RRF采用加权平均的方法，提升整体预测性能和排名精度。其优势在于动态调整权重，基于分支间的相互作用来优化输出。RRF在模型或数据源异质性较大的情况下，表现出色，能够显著提高预测的准确性。

2.4.2.3 RAG Flow与模式（Pattern）

通过组合模块和操作符，并应用编排逻辑，可以构建出不同的 RAG Flow。论文总结了四种典型模式：

线性模式(Linear)：最简单的顺序执行，即 Naive 或 Advanced RAG。
条件模式(Conditional)：根据路由结果，选择一条特定的流程执行。
分支模式(Branching)：并行执行多条流程（如多查询检索或多文档分别生成），最后进行融合。
循环模式(Looping)：包括迭代（固定轮次）、递归（树状结构深度探索）和自适应/主动（由 LLM 动态决定何时检索和终止）三种形式。
调优模式(Tuning): RAG系统持续整合更多与LLM相关的技术。在模块化RAG中，许多组件由可训练的语言模型组成。通过微调，可以进一步优化组件性能，并增强其与整体流程的协调性。

2.4.3 优点

极高的灵活性与可扩展性：可以根据业务需求，像插拔组件一样更换 Embedding 模型、Rerank 模型或数据源，而无需重构整个系统。
多源异构数据融合：能够同时处理结构化（SQL）、非结构化（Doc）和实时（Web）数据，适用范围极广。
针对性优化：可以针对流程中的瓶颈点（如某类问题的检索率低）单独增加一个模块进行补强，而不影响其他环节。
工程化友好：符合现代软件工程的微服务/模块化思想，便于团队协作和版本迭代。

2.4.4 缺点

系统复杂性急剧增加：多个模块之间的接口标准、数据流转逻辑需要精细设计，开发成本远高于前两种。
调试与追踪困难：当结果出错时，很难一眼看出是 Routing 选错了路，还是 Rewrite 改错了词，亦或是 Rerank 过滤掉了正确信息。
潜在的延迟累积：模块越多，意味着处理链路越长。如果编排不当（例如串行运行过多的 LLM 处理节点），会导致用户等待时间过长。
冗余计算：如果不加控制，复杂的模块编排可能会导致多次重复检索或多次 LLM 调用，推高成本。

如果说 Naive RAG 是一条单向传送带，Modular RAG 就是一个配备了自动分拣系统、多条支线轨道和循环回路的现代化物流中心。它不预设路径，而是根据快递（Query）的类型，自动决定它该去哪个窗口处理，甚至可以送回上一个工序重跑。它是走向 Agentic RAG（智能体 RAG）的关键阶梯。

2.5 Agentic RAG

摘自[2501.09136] Agentic Retrieval-Augmented Generation: A Survey on Agentic RAG

2.5.1 概念介绍

Agentic RAG 是 RAG 演进的终极形态。如果说 Modular RAG 是配置精良的“自动化流水线”，那么 Agentic RAG 就是一个“拥有自主意识的资深研究员”。

它将大模型（LLM）从被动的“信息加工者”转变为主动的“系统控制器（Controller）”。在 Agentic RAG 中，系统不再遵循预设的线性或分支路径，而是由 Agent 根据用户的问题，自主决定检索时机、选择检索工具、评估检索质量，并决定是否需要多轮迭代。它本质上是AI Agent（智能体）与 RAG 技术的深度融合。

2.5.2 机制原理

Agentic RAG 的核心逻辑在于“推理（Reasoning）与行动（Acting）的循环”。

2.5.2.1 核心架构组件

参考智能体通用架构，Agentic RAG 同样可以拆解为以下三个关键层级：

L1：大脑（The Brain / Planner）：
- 由强大的 LLM担任，负责意图解析与任务拆解。它不直接检索，而是先思考：“为了回答这个问题，我需要分几步？每一步需要什么工具？”
L2：工具箱（Toolbox / Skill Set）：
- Agent 调用的具体功能单元，包括但不限于：
  - Vector Search Tool：检索私有向量库。
  - Web Search Tool：访问互联网获取最新时政。
  - Code Interpreter：执行 Python 代码进行数据统计分析。
  - Knowledge Graph Tool：查询实体间的复杂关系。
L3：反思机制（Self-Reflection / Critic）：
- 这是 Agentic RAG 的灵魂。Agent 会对检索到的内容进行“质检”：
  - 相关性评估：搜到的东西有用吗？
  - 完备性评估：信息够了吗？还需要再搜别的吗？
  - 忠实度评估：生成的结果是否基于事实而非幻觉？