从 RAG 到 Agentic RAG：让大模型真正"会思考"的信息检索

RAG 曾是弥补大模型知识缺陷的标准答案，但当幻觉问题遇上复杂推理，朴素的"检索-拼接"范式开始触及天花板。Agentic RAG 的出现，不是对 RAG 的否定，而是对它的一次认知升级。

---

1. RAG 是什么，为什么它曾经够用

RAG（Retrieval-Augmented Generation，检索增强生成）的基本逻辑很清晰：模型不知道的东西，就去外部知识库里找，找到了拼接进提示词，大模型接着往下说。

这套方案在 2023-2024 年大规模落地，解决了几个实际问题：

• 知识时效性：模型权重里的知识有截止日期，RAG 让它能读今天的文档。
• ** hallucinations 抑制**：给模型提供的参考资料有据可查，模型胡说八道的概率大幅降低。
• 成本可控：不需要为特定知识去做模型微调，用 API 调用的成本换精准度。

典型的 RAG Pipeline 大致是：

用户问题 → 向量检索（Embedding） → Top-K 文档 → 拼接进 Prompt → LLM 生成

Embedding 模型把文本切成语义块，存进向量数据库，查询时找语义最接近的 K 块，喂给大模型。这套方案在简单问答、文档摘要、客服等场景表现良好。

但它的局限也在实践中逐渐暴露。

---

2. RAG 的三个软肋

2.1 检索质量的天花板

向量检索依赖 Embedding 模型的语义理解能力。 Embedding 模型再好，也有它的表达能力边界——它只能捕捉"字面相似性"的某种抽象，一旦查询和文档在表述上差异较大，检索就会漏掉最相关的内容。

一个经典困境：用户问的是"公司去年Q3营收下滑的原因"，但文档里写的是"2024年第三季度收入同比下降 12%"。语义接近，但关键词错位。纯向量检索可能找不到。

2.2 只能回答"简单问题"

RAG 本质上是"一问一答"模式：用户提问 → 检索 → 回答。但现实中的问题往往不是这么简单：

• 需要多步推理：要先理解公司业务结构，再定位到具体产品线，再结合市场环境分析。
• 需要主动质疑：用户问题本身可能有前提错误，模型应该能反问或二次确认。
• 需要动态决策：要不要检索？检索什么？用哪个知识库？这些在 RAG 里是预设好的，没有"判断"环节。

2.3 幻觉并没有消失

RAG 确实减少了"模型自创知识"的幻觉，但引入了新的风险：检索到的内容本身可能是错的、过时的、或者与问题无关的。模型没有能力判断"这条检索结果靠不靠谱"，只能把检索结果当作真相来处理。

当 RAG 系统接入多个数据源时，这个问题更加突出——不同来源的数据可能相互矛盾，模型没有机制来解决这种冲突。

---

3. 什么是 Agentic RAG