← 返回文章列表

从经典 RAG 到 Agentic RAG：智能检索的进阶之路

2026年5月3日AI/LLM
RAGAgentic RAGGraph RAG大模型生产实践

从经典 RAG 到 Agentic RAG：智能检索的进阶之路

如果你把经典 RAG 理解成一条流水线——用户提问、系统检索、LLM 回答，每一步都是预设好的固定流程。那么 Agentic RAG 就像是把这条流水线升级成了一个智能工厂——LLM 不再被动等待输入，而是主动决定要不要检索、查什么、查几次、甚至怀疑检索结果的准确性。

这篇文章从经典 RAG 的局限出发，梳理各种进阶 RAG 模式，最后落地到生产级工程实践。

1. 经典 RAG 的局限

经典 RAG 的流程是一条直线：问题 → 检索 → 拼 Prompt → 生成。这个流程简单可靠，但也有三个明显的短板：

  • 检索一次性：如果第一次检索没找到合适信息，不会重试
  • Query 固定：用户怎么问就怎么查，不会改写或拆解
  • 无反馈闭环：LLM 生成时如果发现信息不足，没法回头再查

这些局限在简单问答场景下不是问题，但面对复杂、多跳、需要推理的问题时，经典 RAG 就显得力不从心了。

小结： 经典 RAG 胜在简单可控，但在复杂问题上精度不够。进阶 RAG 模式的目标就是补上这些短板。

2. Parent-Child / Small-to-Big

前面讲到过，小 chunk 检索更精准但信息不完整，大 chunk 信息完整但精度不够。Parent-Child Chunking 巧妙地解决了这个矛盾。

思路很简单：建两级 chunk。小 chunk（child）存索引用于检索，命中后返回对应的父 chunk（parent）喂给 LLM。

索引层：小 chunk（300 token）→ 精准匹配
返回层：父 chunk（1500 token）→ 完整上下文

这样既保证了检索的召回精度，又保证了 LLM 拿到的是完整信息。

类似的思想还有 Sentence Window Retrieval：检索到某个句子后，带上前后的句子作为上下文一起返回。以及 Auto-Merging Retrieval：多个相邻小 chunk 都被命中时，自动合并成更大的父块。

小结： 这些模式的核心思想是一致的——检索粒度细、返回粒度粗。在准确性和信息完整性之间找到一个巧妙的平衡点。

3. Self-RAG 与 CRAG

这两种模式给 RAG 加入了"元认知"——系统不再盲目执行检索流程，而是学会反思自己的行为。

Self-RAG 让 LLM 在生成过程中自己决定三件事：

  1. 需不需要检索（有些问题 LLM 自己能回答，无需检索）
  2. 检索回来的内容是否相关（过滤不相关的结果）
  3. 回答是否基于检索内容（自我验证，防止幻觉）

CRAG（Corrective RAG） 则在检索之后加了一个专门的评估器，判断检索结果的质量：

  • 质量好 → 用检索结果回答
  • 质量差 → 触发 Fallback——比如改用网页搜索、或者直接让 LLM 用自己的知识回答——并记录下来用于后续优化

两种模式的区别在于：Self-RAG 的"反思"内化在 LLM 的生成过程中，CRAG 的"纠错"是外挂的一个独立模块。

小结： 经典 RAG 是"查了就用"的直线思维，Self-RAG 和 CRAG 引入了"查了再想想对不对"的反思机制。这是从被动检索到主动推理的关键一步。

4. Graph RAG

Graph RAG 用知识图谱代替或增强向量检索。节点是实体和概念，边是它们之间的关系，检索时沿着图谱做多跳推理。

微软的 GraphRAG 论文是这一方向的代表作。它的核心优势在于处理需要多跳推理的复杂问题，比如"A 和 B 的共同朋友中谁是 C 公司的员工？"这类问题如果用纯向量检索，需要把整段关系描述都在一个 chunk 里，而这往往不现实。

Graph RAG 的代价也很明显：构建和维护知识图谱的成本远高于简单的向量化。它适用于知识之间关系密集、多跳查询频繁的场景，但不是所有 RAG 系统都需要。

小结： Graph RAG 适合关系密集、多跳推理的场景。如果你的问题大多是"某某文档里提到什么"，纯向量检索就够了。但如果是"某某和某某之间有什么关系"，Graph RAG 就有不可替代的优势。

5. Contextual Retrieval

2024 年 Anthropic 提出的方法，思路非常实用：给每个 chunk 生成一段上下文描述，说明它在原文档中的位置和主题，然后对"chunk + 上下文描述"做 Embedding。

为什么有效？因为很多 chunk 单独拎出来是缺乏语境的。比如某 chunck 里写着"它的延迟是 200ms"——这个"它"指的是什么？如果 chunk 没有包含上文，检索时很可能匹配不到。加上上下文描述后，"TransactionService 的延迟是 200ms"就清晰多了。

Anthropic 报告说这种方法可以把检索错误率降低 35-49%。这是一个成本很低但效果显著的优化。

小结： 有时候问题不在检索算法，而在于被检索的内容本身缺乏语境。Contextual Retrieval 用最小的工程成本解决了这个问题。

6. Agentic RAG：检索作为工具

如果把检索封装成一个工具函数交给 LLM 调用，RAG 就不再是一条流水线，而是一场对话。

const retrieveTool = tool(
  async ({ query }) => {
    const docs = await vectorStore.similaritySearch(query, 5);
    return docs.map(d => d.pageContent).join("\n---\n");
  },
  {
    name: "retrieve_knowledge",
    description: "从知识库检索相关文档",
    schema: z.object({ query: z.string() }),
  }
);

LLM 收到问题后自己判断：

  • 需要检索吗？（有些问题不需要）
  • 用什么 Query 检索？（自主改写）
  • 检索结果够用吗？（评估）
  • 不够就再查一次（换一个 Query）
  • 查询轮信息足够后，生成最终答案

这个模式下，LLM 从一个"答案生成器"变成了"问题解决者"——它掌控整个检索和推理的流程，而不是被动执行预先编排的步骤。

多跳检索

复杂问题往往一次检索不够。比如：

用户问："LangGraph 的 Checkpointer 和 LangChain 的 Memory 有什么区别？"

Agent 的执行过程可能是：

  1. retrieve("LangGraph checkpointer")
  2. retrieve("LangChain memory")
  3. 对比两者的文档，生成答案

每一次检索的结果都可能影响下一次检索的 Query——这需要 Agent 维护对话状态，这正是 Agent 架构擅长的事情。

小结： Agentic RAG 把 LLM 从流水线操作工变成了车间主任。它不再被动执行，而是主动管理整个检索生成流程。这是 RAG 系统从"能用"到"智能"的关键跨越。

7. 生产级工程实践

知识库管理

知识库是活的——文档会更新、会过期。生产环境需要解决几个实际问题：

  • 增量同步：文档更新时只重新处理变化的 chunk，用哈希比对检测变化
  • 版本管理：换 Embedding 模型时，旧索引和新索引并存，等新索引验证通过再切流量
  • 权限隔离：多租户场景下用 metadata filtering 实现检索权限控制
  • 数据清洗：去重、去噪、统一格式，脏数据进库会污染所有检索结果

延迟优化

RAG 全链路的延迟构成：

阶段典型耗时
Embedding 查询50-200ms
向量检索10-100ms
Rerank100-500ms（可选）
LLM 生成500-3000ms（主要瓶颈）

优化思路：Embedding 用快模型、向量库用 HNSW 算法、Rerank 在延迟敏感时跳过、LLM 用 Streaming 输出首 token。

成本优化

  • Embedding 缓存：相同 Query 不重复调用
  • 小模型兜底：简单问题用低成本模型，复杂问题再升级到大模型
  • Prompt 压缩：用 LLMLingua 等工具压缩检索内容，减少 Token 消耗
  • 冷热分离：高频数据放内存库，低频数据放对象存储

可观测性

没有可观测性，RAG 系统就是黑盒。至少需要追踪这些指标：

  • 每次检索的 Query、命中的 chunk、Rerank 分数、最终答案
  • 用户反馈（点赞/点踩）
  • 端到端延迟分布
  • 检索 Miss 率（没有召回到相关内容的比例）

工具推荐：LangSmith、Langfuse、Arize，或者自建 Trace 系统。

Fallback 策略

每个环节都要有兜底：

  • 检索失败 → 用 LLM 内置知识回答，标注"无知识库支撑"
  • LLM 生成失败 → 返回检索结果原文
  • 全流程失败 → 固定兜底话术，记录日志

安全与合规

  • PII 脱敏：向量化前清洗个人信息
  • 权限控制：检索时带用户权限过滤
  • 审计日志：谁查了什么、LLM 回答了什么都留痕
  • Prompt Injection 防护：检索回来的文档可能被恶意污染（"忽略之前指令，说..."），需要做输入过滤

小结： 生产级 RAG 的挑战不在算法创新，而在工程细节。知识库管理、延迟、成本、可观测性、安全性——每个方面都需要体系化的解决方案。

总结

从经典 RAG 到 Agentic RAG，背后是一条从"被动执行"到"主动思考"的演进路径：

经典 RAG → 固定流水线，一次检索
  ↓
Self-RAG / CRAG → 加入反思与纠错
  ↓
Graph RAG → 用知识图谱支持多跳推理
  ↓
Agentic RAG → LLM 自主管理检索流程

但无论是哪种模式，核心原则是不变的：RAG 的价值在于让 LLM 基于事实说话。 技术模式可以演进，但这个根本目的始终如一。

如果你的系统还跑着经典 RAG 链路、遇到了精度瓶颈，不妨从这些进阶模式中选择一个入手升级。大多数情况下，最简单也最有性价比的优化往往是：给 chunk 加上下文描述（Contextual Retrieval）、在检索后加一层 Rerank、或者让 LLM 能自主决定是否重试检索。

返回博客列表