一、传统RAG架构解析

1.1 传统RAG的工作原理

传统RAG（Standard RAG）是一种通过检索外部知识库来增强大语言模型（LLM）能力的架构。它并非单纯的“检索+生成”，而是一个包含数据索引（Indexing）、**检索（Retrieval）和生成（Generation）**三个核心阶段的闭环系统。

传统RAG遵循“检索-阅读-生成”的线性流程，其架构可以用以下树形结构表示：

在这里插入图片描述

  1. 详细步骤解析

    传统RAG的运行机制可以拆解为以下七个关键技术环节：

    1. 切片与索引（Chunking & Indexing）：
      • 这是RAG的“地基”。系统首先加载私有数据（PDF、Word、Markdown等），将其清洗后按特定策略（如固定字符数、滑动窗口、语义分割）切分为较小的文本块（Chunks）。
      • 随后，利用Embedding模型（如OpenAI text-embedding-3, BGE-M3等）将文本块转化为高维向量，并存入Milvus、Pinecone或Chroma等向量数据库中。
    2. 查询向量化（Query Embedding）：
      • 当用户输入问题时，系统使用与索引阶段相同的Embedding模型，将自然语言问题（Query）转化为数值向量，将其映射到同一语义空间。
    3. 相似度检索（Similarity Search）：
      • 在向量数据库中，计算Query向量与所有文档块向量之间的距离（通常使用余弦相似度或欧几里得距离）。
      • 系统快速定位在语义上最接近Query的Top-K个文本片段。
    4. （可选）重排序（Re-ranking）：
      • 注：这是进阶版传统RAG的标配。 向量检索基于语义模糊匹配，召回范围广但精度可能不足。通常会引入一个Cross-Encoder重排序模型，对Top-K结果进行精细打分，剔除不相关文档，保留Top-N个高质量片段。
    5. 上下文与Prompt构建（Prompt Engineering）：
      • 系统将检索到的文本块作为“背景知识（Context）”，填入预设的System Prompt模板中。例如：“请仅基于以下上下文回答用户问题：[Context]…”。
    6. LLM 生成（Generation）：
      • 大模型接收包含“用户问题 + 检索到的上下文”的完整Prompt。此时，LLM的作用类似于阅读理解——它利用其语言能力，归纳上下文中包含的信息来生成答案。

1.2 传统RAG的局限性

尽管传统RAG解决了LLM“幻觉”和“知识过时”的问题，但其线性、静态的架构设计在面对复杂现实场景时，存在明显的“能力天花板”。这些局限性主要体现在以下四个维度：

1. 单向依赖与容错率低（Single-Hop Failure）

  • 问题描述：传统RAG是一锤子买卖。如果第一步检索到的文档不相关（检索噪声），或者漏掉了关键文档（召回率低），LLM后续没有任何补救机会。
  • 后果：由于输入了错误的上下文，LLM会基于错误信息一本正经地胡说八道（Context-driven Hallucination）。

2. 碎片化信息无法整合（Lack of Synthesis）

  • 问题描述：对于“多跳（Multi-hop）”问题，传统RAG往往无能为力。
    • 例子：“马斯克收购Twitter那年的美国通胀率是多少？”
    • 传统RAG困境：它可能检索到“马斯克2022年收购Twitter”的文档，也可能检索到“2022年通胀率”的文档。但如果这两个信息不在同一个Chunk里，传统RAG很难自动关联这两个孤立的知识点来推导出答案，因为它缺乏“先查年份，再查该年份通胀率”的推理规划能力。

3. 上下文“中间丢失”现象（Lost in the Middle）

  • 问题描述：为了提高召回率，传统RAG倾向于检索大量文档（Top-10或Top-20）并将它们全部塞入Prompt。
  • 后果：研究表明，当相关信息位于长Prompt的中间位置时，LLM的注意力机制容易忽略这些信息，导致回答遗漏关键细节。这就陷入了“检索得少不够用，检索得多记不住”的矛盾。

4. 静态策略无法适配动态问题

  • 问题描述：无论用户问的是简单的“今天天气如何”还是复杂的“请分析2024年半导体行业趋势”，传统RAG都执行同一套“检索-生成”流程。
  • 后果：
    • 对于简单问题，检索是多余的，增加了延迟。
    • 对于复杂问题，简单的关键词匹配或语义检索远远不够，导致回答肤浅。系统缺乏根据问题难度动态选择工具（如联网搜索、代码解释器、SQL查询）的能力。

二、Agent Skills RAG架构

2.1 Agentic RAG的核心概念

Agent Skills RAG（Agentic RAG）代表了从**“静态流水线”到“动态认知循环”**的范式转移。

  • 传统 RAG 是“查完即答”，类似于开卷考试中学生翻书抄答案，如果书里没答案或翻错了页，考试就挂了。
  • Agentic RAG 引入了自主智能体（Autonomous Agent），类似于一位专业的研究员。它不急于回答，而是先拆解问题，制定调研计划，使用不同工具（Skill）获取信息，如果不满意结果，还会自我反思并调整搜索关键词，直到收集到足够证据才生成报告。

根据Grand View Research的研究，全球RAG市场预计从2025年到2030年将以49.1%的复合年增长率增长。其中，具备复杂推理能力的Agentic架构将成为解决企业级复杂知识问答（Complex QA）的主要驱动力。

2.2 Agent Skills RAG架构详解

![外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传](https://img-home.csdnimg.cn/images/20230724024159.png?origin_url=C%3A%5CUsers%5Cacer%5CAppData%5CRoaming%5CTypora%5Ctypora-user-images%5Cimage-20260203113904561.png&pos_id=img-XaTG67Ah-1770090964828在这里插入图片描述

2.3 核心组件详解

2.3.1 Agent 编排层（The Brain）

编排层是系统的决策中枢，它不再是线性的代码逻辑，而是基于LLM的动态推理过程。

  • Planner（规划器）： 负责“谋定而后动”。
    • 功能：它接收复杂查询（如“分析A公司和B公司过去三年的财报差异”），将其拆解为有序的子任务序列（Task Chain）：1. 检索A公司财报 -> 2. 检索B公司财报 -> 3. 调用代码工具计算差异 -> 4. 生成分析。
    • 技术：常采用 ReAct (Reason + Act) 或 Plan-and-Solve 提示策略。
  • Router（路由器）： 负责“术业有专攻”。
    • 功能：基于子任务的语义，精准选择最合适的工具。例如，遇到“2023年销售额”这类数据问题，路由给SQL Skill；遇到“产品原理”这类文本问题，路由给向量检索 Skill。
  • Reflector（反思/批评家）： （新增关键组件）
    • 功能：这是Agentic RAG的“质检员”。它会检查检索到的文档是否真的回答了问题。如果发现检索结果相关性低或缺失，它会触发**重试（Retry）**机制，改写查询关键词重新检索，而不是强行生成。

2.3.2 Skills 工具集（The Hands）

Skills 是封装好的原子能力（Atomic Capabilities），Agent 通过标准化的 API 接口调用它们。

Skill 类型 具体功能实例 适用场景
基础检索 Skill Dense Retrieval (向量), Sparse Retrieval (关键词) 通用文档查询
高级检索 Skill Graph RAG (知识图谱), Web Search (联网) 复杂实体关系、获取最新信息
逻辑计算 Skill Python Code Interpreter, SQL Executor 数学计算、数据聚合、图表绘制
操作类 Skill Send Email, CRM API 触发外部业务流程

2.3.3 记忆与状态管理（The Context）

为了支持多轮推理和自我修正，Agent 必须维护复杂的状态。

  1. 短期记忆 (Short-term / Scratchpad)：
    • 记录当前思考链（Chain-of-Thought）。例如：“我已经查到了A的价格，现在需要查B的价格…”。这是Agent保持任务连续性的关键。
  2. 工作记忆 (Working Memory)：
    • 存储检索到的中间结果（Intermediate Knowledge）。不同于传统RAG直接丢进Prompt，Agent会清洗、摘要这些中间结果，只保留有效信息，避免Context Window爆炸。
  3. 长期记忆 (Long-term / Episodic)：
    • 存储用户的偏好设置（如“总是用表格形式回答”）和历史对话摘要，确保跨会话的体验一致性。

三、核心能力对比

3.1 架构对比

在这里插入图片描述

上图清晰展示了两种架构的核心差异：传统RAG是线性的一次性流程，而Agent Skills RAG支持迭代循环，Agent可以根据中间结果决定是否需要进一步检索或调整策略。

传统 RAG（左图）：像一条传送带。无论输入是什么，都经历相同的步骤。如果中间检索到了错误文档，下游的生成环节没有任何纠错机制，只能“将错就错”。

Agent Skills RAG（右图）：像一个交通环岛。Agent 在 执行-观察-评估 的循环中运作。它拥有“拒绝回答”和“重新查找”的权利，直到收集到足以支撑回答的证据。

3.2 能力对比表

特性 传统RAG Agent Skills RAG
架构模式 线性流水线 循环迭代+动态决策
检索策略 单次检索 多轮迭代检索
推理能力 无 多步规划与推理
工具使用 固定 动态选择Skills
错误处理 无自我修正 反思+重试机制
上下文理解 有限 深度意图理解
响应延迟 低（1-2秒） 中（3-5秒）
Token消耗 低 高（迭代成本）

3.3 性能指标对比

在这里插入图片描述

根据IRJET 2025年发表的研究成果，Agentic系统相比传统RAG在多项指标上有显著提升：内容相关性提升36.8%，内容深度提升33.4%，用户满意度提升41.5%。根据 IRJET 2025 发表的研究成果，在处理复杂知识密集型任务（Knowledge-Intensive Tasks）时，Agentic 系统的质量优势压倒了成本劣势：

质量提升指标

  • 📈 内容相关性 (Relevance): +36.8% —— 得益于Agent的重试机制，过滤了大量噪声文档。
  • 📈 内容深度 (Depth): +33.4% —— 得益于多跳检索，答案不再浮于表面，能涵盖多源信息。
  • 📈 用户满意度 (CSAT): +41.5% —— 用户更倾向于等待几秒钟以获得一个准确、结构化的答案，而不是立刻得到一个模糊的回复。

“不可能三角”的权衡

在实际落地中，我们必须面对 速度 (Speed)、成本 (Cost) 和 质量 (Quality) 的权衡：

  • 传统 RAG 占据了 速度 和 成本 的优势，适合高并发、低延迟的C端场景（如智能客服）。
  • Agent Skills RAG 占据了 质量 的制高点，适合专家级、高价值的B端场景（如金融研报分析、法律合规审查）。

3.4 选型决策指南（什么时候用什么？）

为了帮助架构师做决策，我们提供以下决策树：

  1. 问题是否需要多步推理？
    • 是 (“比较A和B并分析原因”) -> Agentic RAG
    • 否 (“A的定义是什么”) -> 传统 RAG
  2. 是否需要外部工具（非文本能力）？
    • 是 (“计算平均增长率”, “查询实时股价”) -> Agentic RAG
    • 否 -> 传统 RAG
  3. 用户对延迟的容忍度？
    • 低 (<3秒) -> 传统 RAG (或简化版Agent)
    • 高 (>10秒) -> Agentic RAG

四、实际案例分析

在本章中，我们将通过三个具体场景，深入对比传统 RAG 与 Agentic RAG 的执行差异。我们将结合 时序图（Sequence Diagram） 和 Python 伪代码，展示 Agent 是如何像程序员一样思考和调用工具的。

4.1 案例一：多跳推理与竞品对比分析

场景： 用户询问 “分析 iPhone 15 Pro 和 Samsung S24 Ultra 的电池续航差异，并计算每毫安时(mAh)的效能比。”

这是一个典型的多跳（Multi-hop）+ 计算问题。

1. 传统 RAG 的处理困境

传统 RAG 会根据关键词 iPhone 15, Samsung S24, 电池 进行一次性检索。

  • 结果：它可能检索到两者的参数页，但 LLM 数学很差，往往算错“效能比”；或者它只能机械地罗列参数，无法进行深度的归因分析。

2. Agent Skills RAG 的处理流程

Agent 不会急于回答，而是先生成一个执行计划。

核心流程时序图

代码段

sequenceDiagram
    participant User
    participant Agent as 🤖 Agent Core
    participant Search as 🔎 Search Skill
    participant Code as 🐍 Code Interpreter
    
    User->>Agent: 询问电池差异与效能比
    
    Note over Agent: 思考阶段 (Planning)<br/>1. 查 iPhone 电池数据<br/>2. 查 Samsung 电池数据<br/>3. 写代码计算效能比
    
    Agent->>Search: 调用检索(query="iPhone 15 Pro battery capacity")
    Search-->>Agent: 返回: 3274 mAh, 视频播放 23h
    
    Agent->>Search: 调用检索(query="Samsung S24 Ultra battery capacity")
    Search-->>Agent: 返回: 5000 mAh, 视频播放 30h
    
    Note over Agent: 获取数据完毕，<br/>准备进行数学计算
    
    Agent->>Code: 执行 Python 代码(计算效能比)
    Code-->>Agent: 返回: iPhone=0.0070 h/mAh, Samsung=0.0060 h/mAh
    
    Agent->>User: 生成最终深度对比报告
代码级实现逻辑（伪代码）

在 Agentic RAG 中，LLM 会输出类似以下的 函数调用（Function Calling） 序列：

class ComparativeAgent:
    def run(self, user_query):
        # Step 1: 规划 - 识别出需要两个产品的具体参数
        plan = self.planner.make_plan(user_query)
        # plan = ["get_specs('iPhone 15 Pro')", "get_specs('S24 Ultra')", "compare_metrics()"]
        
        # Step 2: 执行检索 Skill
        context_a = self.tools.search.run("iPhone 15 Pro battery capacity video playback time")
        # Output: "iPhone 15 Pro: 3274mAh, 23 hours video playback"
        
        context_b = self.tools.search.run("Samsung S24 Ultra battery capacity video playback time")
        # Output: "S24 Ultra: 5000mAh, 30 hours video playback"
        
        # Step 3: 执行计算 Skill (解决 LLM 算术不准的问题)
        # Agent 自主编写并执行 Python 代码来计算“每 mAh 效能”
        code = """
        iphone_cap = 3274
        iphone_time = 23
        samsung_cap = 5000
        samsung_time = 30
        
        iphone_eff = iphone_time / iphone_cap
        samsung_eff = samsung_time / samsung_cap
        print(f'{iphone_eff=}, {samsung_eff=}')
        """
        result = self.tools.code_interpreter.run(code)
        
        # Step 4: 综合生成
        return self.synthesizer.generate(context_a, context_b, result)

效果提升： Agent 不仅给出了数据，还通过计算得出结论——“尽管 S24 总续航更长，但 iPhone 15 Pro 的单位电量利用效率（效能比）高出约 16%。” 这种洞察是传统 RAG 无法提供的。

4.2 案例二：模糊意图识别（Human-in-the-Loop）

场景： 用户询问 “这个多少钱？” （在多轮对话中，或者上下文缺失时）。

传统 RAG 可能会盲目检索，返回错误结果。而 Agentic RAG 引入了 Human-in-the-Loop (人机回环) 机制。下方的树形图展示了系统如何在遇到歧义时，挂起任务、请求用户澄清并恢复执行的完整 Pipeline。

Agent Skills RAG Execution Pipeline (Case: Ambiguous Query)

Agentic RAG Execution Pipeline
│
├── 【用户输入 (User Input)】
│   ├── 文本指令: "这个多少钱？" (Query: "How much is this?")
│   ├── (隐式输入) 会话ID: "Session_8849"
│   └── (隐式输入) 用户配置: "Enterprise_User"
│
▼
[1. 感知与上下文加载 (Perception & Context Loading)] ───────────┐
│   (由此文件总控: 🐍 agent_orchestrator.py)                    │
│                                                              │
├── A. 记忆检索 (Memory Retrieval)                             │
│   ├── <连接数据库>: 🗄️ Redis / VectorDB                      │
│   ├── <加载短期记忆>: Short-term Memory (Recent Dialogues)   │
│   │    (内容: "User discussed Cloud & On-Premise options")   │
│   └── <加载长期记忆>: Long-term Memory (User Preferences)    │
│        (内容: "User prefers annual billing")                 │
│                                                              │
├── B. 提示词构建 (Prompt Construction)                        │
│   ├── <读取模板>: 📜 system_prompt_agent.jinja               │
│   │    (作用: 定义 Agent 的人设、工具描述、ReAct 格式规范)   │
│   └── <注入上下文>: 将记忆片段注入 Context Window            │
│                                                              │
└── > 合并输入: LLM Input (System Prompt + Memory + Query) ────┘
         │
         ▼
[2. 大脑规划与路由 (Cognitive Planning & Routing)] ────────────┐
│                                                              │
├── <推理核心>: 🧠 LLM (GPT-4 / Claude 3.5 / DeepSeek)         │
│                                                              │
├── Step 1: 意图识别 (Intent Classification)                   │
│   ├── <思考过程 (Internal Monologue)>:                       │
│   │    "<thinking> 用户询问价格，但上下文中有两个产品        │
│   │     (SaaS 和 私有化)。指代不明确，不能直接检索。</thinking>" │
│   │                                                          │
│   └── <路由决策>: 🚦 Router (Semantic Router)                │
│        ├── 路径 A: 直接检索 (Direct Retrieval) -> ❌         │
│        └── 路径 B: 澄清意图 (Clarification)    -> ✅         │
│                                                              │
└── > 输出状态: 需要调用工具 `AskUser`                         │
         │
         ▼
[3. 工具执行与循环 (Tool Execution & Loop)] <★ 核心差异点> ────┐
│                                                              │
├── Step 1: 工具调用 (Function Calling)                        │
│   ├── <解析指令>: JSON Parser 解析 LLM 输出                  │
│   │    { "tool": "AskUser", "args": { "options": [...] } }   │
│   ├── <执行模块>: 🐍 skills/interaction_skill.py             │
│   └── <动作>: 生成反问句                                     │
│        "请问您是指 SaaS 云服务订阅，还是私有化部署授权？"    │
│                                                              │
├── Step 2: 挂起与回调 (Suspend & Callback)                    │
│   ├── <状态保存>: 将当前 Stack 序列化存入 Redis              │
│   ├── <系统动作>: ⏸️ 暂停执行 (Awaiting User Input)          │
│   └── > 推送前端: 显示澄清问题                               │
│                                                              │
├── [中断: 用户回复 "是指企业版 (Private Cloud)"] ─────────────┤
│                                                              │
├── Step 3: 恢复与更新 (Resume & Update)                       │
│   ├── <状态恢复>: 从 Redis 读取之前的思考链                  │
│   ├── <更新查询>: Query Rewrite -> "企业版私有化部署 价格"   │
│   └── <重新路由>: 此时意图清晰 -> 进入检索分支               │
│                                                              │
└── > 跳转至: 🔍 检索技能 (Retrieval Skill)                    │
         │
         ▼
[4. 最终响应生成 (Synthesis & Response)] ──────────────────────┐
│                                                              │
├── <执行检索>: 🔎 Vector Search (Query="Enterprise Price")    │
│   └── Result: "私有化部署基础授权费为 $50k/年..."            │
│                                                              │
├── <综合生成>: 📝 Synthesizer                                 │
│   ├── 输入: 澄清后的意图 + 检索到的精准价格                  │
│   └── 动作: 生成最终自然语言回复                             │
│                                                              │
└── > 最终输出:                                                │
      "针对您的企业版私有化部署需求，基础授权费为每年 5 万美元 │
       ..."                                                    │
└──────────────────────────────────────────────────────────────┘

解析： 此图清晰地展示了 Agentic RAG 的状态机特性。传统 RAG 是一次性跑完的（Stateless），而 Agent 是有状态的（Stateful），可以将执行挂起（Suspend），等待外部输入后再恢复（Resume），这是处理模糊查询的关键。

4.3 案例三：复杂数据可视化（Code Interpreter）

场景： 用户询问 “根据知识库里的 2024 销售数据，画一个季度增长趋势图。”

这是传统 RAG 的死穴——传统 RAG 只能输出文本，无法画图。

Agent Skills RAG 的处理流程

Agent 调用 Python 环境（如 Sandboxed Jupyter Kernel）来处理数据并绘图。

  1. 检索（Retrieve）： 从数据库中提取 CSV 格式的销售数据片段。
  2. 编码（Coding）： Agent 编写 Pandas 和 Matplotlib 代码。
  3. 执行（Execute）： 在沙箱中运行代码，生成 .png 图片文件。
  4. 展示（Display）： 将图片嵌入到最终回答中。
代码生成示例
# Agent 自动生成的代码
import pandas as pd
import matplotlib.pyplot as plt

data = {
    'Quarter': ['Q1', 'Q2', 'Q3', 'Q4'],
    'Revenue': [120, 150, 170, 210] # 数据来自检索步骤
}
df = pd.DataFrame(data)

plt.figure(figsize=(10, 6))
plt.plot(df['Quarter'], df['Revenue'], marker='o')
plt.title('2024 Revenue Growth Trend')
plt.savefig('growth_chart.png') # Agent 将文件路径返回给用户

核心价值： 这种能力将 RAG 系统从“文档问答机器人”升级为“数据分析助手”。

# 人工智能 # 语言模型 # 回归 # 架构
Logo
2048 AI社区

有“AI”的1024 = 2048，欢迎大家加入2048 AI社区

更多推荐

cover

技术博客：基于 Flutter × OpenHarmony 开发高校会议室管理系统——推荐会议室功能

avatar 2048 AI社区
cover

告别低效排版！10款宝藏PPT模板网站推荐：直接套用，职场/学生党必备

avatar 2048 AI社区
cover

构建基于 Flutter × OpenHarmony 的入侵检测系统：数据结构与 UI 设计详解

avatar 2048 AI社区