RAG 与 Agent 性能深度解析：从架构对比到工程优化

RAG（检索增强生成）与 Agent（智能体）是当前大模型应用的两大核心范式。RAG 通过外挂知识库为模型提供事实依据，Agent 则通过自主规划与工具调用完成复杂任务。两者并非对立，而是互补——Agentic RAG 正是二者的融合形态。本文从性能视角切入，通过架构对比、数据分析和实战代码，系统梳理各自的性能瓶颈与优化路径。

1. 架构差异：单轮固定 vs 多轮迭代

传统 RAG 执行固定、单次的检索-生成流程：Query → 检索 Top-K → 拼接上下文 → LLM 生成。其性能瓶颈主要集中在检索延迟和上下文长度上。

Agent 则引入自主决策循环：思考 → 调用工具/检索 → 观察结果 → 继续思考，直至完成任务。这种多轮迭代带来了更强的能力，但也引入了显著的开销。

性能数据对比：一项针对 7B-8B 参数模型的系统研究表明，在 31 种配置的对比实验中，单 Agent RAG 的基线性能显著优于多 Agent 协调方案。多 Agent 架构的性能下降幅度在 4.39% 到 35.31% 之间，其中协调开销（Coordination Overhead）是比检索不一致性更主要的限制因素。另一项对比研究显示，MISTRAL 模型在基础模式下准确率为 58.11%，RAG 增强后提升至 67.05%，而 Agent 架构进一步升至 72.00%——Agent 带来了更高的精度上限，但也伴随着更大的系统复杂度。

2. RAG 性能优化的四个层次

2.1 检索层：向量索引与混合检索

检索速度是 RAG 的首道瓶颈。使用 HNSW 索引可实现毫秒级检索，实测相比 Flat 索引查询速度提升 15 倍。同时，混合检索（Dense + BM25）能兼顾语义理解与关键词匹配：

from langchain.retrievers import BM25Retriever, EnsembleRetriever

bm25_retriever = BM25Retriever.from_documents(documents)
dense_retriever = vectorstore.as_retriever(search_type="mmr")

ensemble_retriever = EnsembleRetriever(
    retrievers=[dense_retriever, bm25_retriever],
    weights=[0.6, 0.4]  # 语义优先，关键词为辅
)

混合检索可使响应效率提升约 50%。

2.2 精排层：Rerank 降本增效

初检召回 Top-100 后，通过 Cross-encoder 精排至 Top-5，在精度几乎不损失的前提下将送入 LLM 的上下文压缩 90%。典型的延迟预算为：召回 <100ms，精排 <200ms。

2.3 上下文压缩：Token 减量

使用 ContextualCompressionRetriever 对检索结果进行压缩，可减少 40%-60% 的文档体积。另有实践表明，基于 LLM 的上下文压缩可将 API Token 负载降低近 80%。

from langchain.retrievers import ContextualCompressionRetriever
from langchain.retrievers.document_compressors import LLMChainExtractor

compressor = LLMChainExtractor.from_llm(llm)
compression_retriever = ContextualCompressionRetriever(
    base_compressor=compressor,
    base_retriever=vectorstore.as_retriever()
)

2.4 缓存层：语义缓存

对高频 Query 实施语义缓存——相似问句直接返回缓存结果，跳过检索与生成链路。配合 TTL 失效逻辑，可在保证数据新鲜度的同时大幅降低延迟。

3. Agent 性能优化的核心策略

Agent 的性能开销主要来自上下文膨胀和多轮循环。

3.1 上下文压缩：Token 减半

在一次 LangGraph Agent 实践中，通过优化上下文管理，单次代理的 Token 使用量从约 120k 降至 60k，减少了近一半。具体手段包括：限制工具定义的长度、压缩历史对话、使用更精简的 prompt 模板。

3.2 子代理架构：上下文隔离

Anthropic 的多代理研究表明，具有隔离上下文的多代理架构相比单代理系统性能提升 90.2%，因为每个子代理专注于更窄的子任务。但需注意，多代理系统的 Token 消耗可能比单代理增加 15 倍。

from langgraph.prebuilt import create_react_agent
from langgraph_supervisor import create_supervisor

# 创建两个专用子代理：数学专家 + 研究专家
math_agent = create_react_agent(llm, tools=[add, multiply])
research_agent = create_react_agent(llm, tools=[web_search])

# 监督者负责路由和协调
supervisor = create_supervisor(
    agents=[math_agent, research_agent],
    model=llm
)

3.3 工具调用优化：代码替代直接调用

Anthropic 的研究指出，直接工具调用会在上下文中重复携带工具定义和返回结果。更好的做法是让 Agent 编写代码来调用工具，这样能以更少的 Token 处理更多的工具。

4. Agentic RAG：融合架构的性能权衡

Agentic RAG 将 Agent 的规划能力与 RAG 的检索能力融合。一个典型的实现是 Router → Retriever → Reranker → Answerer → Critic 流水线，并限制循环次数（如最多 2-3 次迭代）以控制延迟。

关键设计原则：

• 无界 Agent 循环是性能杀手，必须设置最大迭代次数
• Query Rewrite：当首次检索结果不佳时，让 LLM 重写 Query 并重新检索（最多 2 次）
• Adaptive Retrieval：根据检索结果的相关性评分（Document Grading）动态决定是否继续检索

5. 性能数据总览

结语

RAG 与 Agent 的性能优化并非零和博弈。RAG 侧重检索效率——索引、精排、压缩、缓存；Agent 侧重推理效率——上下文精简、子代理隔离、工具调用优化。而在 Agentic RAG 的融合架构中，两者需要协同设计：用 RAG 保证事实准确性，用 Agent 处理复杂多步推理。

实践中，建议从单 Agent RAG 起步，在性能基线清晰后再逐步引入多 Agent 协调。当需要多 Agent 时，Sequential 和 Hierarchical 策略的性能损耗远小于 Collaborative 策略。性能优化的本质是在能力上限与系统开销之间找到最优平衡点。