Agentic RAG

把检索做成 Agent 的一个工具，由 LLM 自己决定何时检索、用什么词检索。本质是 ReAct + RAG 的结合。

一、核心思想

Naive RAG 每次都检索，但有些问题不需要检索（如"你好""现在几点"）。Agentic RAG 把检索做成工具，LLM 像人一样判断：这个问题需要查资料吗？查的话用什么关键词？

用户问题 → LLM 判断 → 需要检索？
                    ├─ 是 → 调检索工具(query) → 拿到文档 → 生成
                    └─ 否 → 直接回答

二、完整流程

1. 用户问题进入 ReAct agent
2. LLM 看到工具列表（含"检索知识库"工具）
3. LLM 判断: 这个问题要不要查资料?
   - 不需要 → 直接回答
   - 需要 → 决定调检索工具, 并自己写一个检索词 query
4. 检索工具(query) 执行:
   - query 向量化
   - 向量检索 top-k 文档
5. 检索到的文档作为 ToolMessage 返回 LLM
6. LLM 看到 ToolMessage, 基于文档生成回答

三、两个关键特征

1. LLM 自己写 query（不是独立改写模型）

LLM 调检索工具时要填参数（tool_call 的 args）。检索工具的参数就是 query: str，LLM 得自己决定填什么。

@tool
def retrieve_knowledge(query: str):    # ← LLM 自己填这个 query
    """从知识库中检索相关信息..."""

LLM 看到参数名 query + 工具描述，就明白要填一个检索词。然后根据用户问题，自己提炼一个检索词。

和用户原话不同：用户问"帮我找下禅院飞鸟相关的内容"，LLM 可能提炼出 query="禅院飞鸟" 去检索。这个提炼是 LLM 调工具时顺手干的，不是独立的 query 改写步骤（Advanced RAG 才有专门的改写）。

2. 检索结果走 ToolMessage（不是拼 context）

Naive RAG 把检索结果拼进 prompt context。Agentic RAG 把检索结果作为 ToolMessage，在 ReAct 循环里给 LLM：

ReAct 循环里的消息序列:
  HumanMessage:   用户问题
  AIMessage:      tool_calls=[retrieve_knowledge("禅院飞鸟")]   ← LLM 决定调工具
  ToolMessage:    [检索到的文档内容]                            ← 工具结果
  AIMessage:      基于文档的回答                                ← 最终回答

LLM 在循环里看到 ToolMessage（文档），基于它生成回答。

四、对比 Naive RAG

	Naive RAG	Agentic RAG
检索时机	每次必检索	LLM 判断要不要检索
检索词	用户原话 / 简单改写	LLM 自定（作为工具参数）
检索结果去哪	拼进 prompt context	作为 ToolMessage
不需要检索时	也检索（浪费）	不检索，直接回答
架构	检索流程硬编码	检索是 Agent 的一个工具

五、背后的机制

Agentic RAG 依赖两个底层能力：

Function Calling：LLM 能输出结构化的工具调用请求（name + args），这是 LLM 调工具的前提。
ReAct 范式：思考→调工具→看结果→再思考的循环，让 LLM 自主决定调工具。

详细概念见 function-calling-mcp-notes.md 和 agent-learning-notes.md。

六、优缺点

优点：

灵活：LLM 判断要不要检索，避免无脑检索
智能：LLM 自定检索词，比用户原话可能更准
可扩展：检索只是工具之一，可挂更多工具（查时间、查数据库、调 API）

缺点：

LLM 可能不调：该检索时不调，瞎回答
LLM 可能乱调：检索词写得差，检索不到
ToolMessage 不充分使用：相比直接拼 context，LLM 在 ReAct 循环里可能没充分利用文档
不确定性高：LLM 自主决策，行为难预测

七、适用场景

问题多样（有的需要检索，有的不需要）
需要多工具协作（检索 + 查时间 + 查数据库等）
想要 Agent 风格的智能交互

八、实验观察（工具选择行为）

实际调试 Agentic RAG 时发现的现象：

LLM 选工具看三件套：工具的 name + description + args 共同决定 LLM 是否选用。改这三件套影响 LLM 决策。
对话历史是强信号：历史里调过某工具，LLM 会沿用，甚至抄历史里的参数名，盖过当前 schema。
LLM 选工具不是精确匹配：是需求驱动 + 排除法 + 试探。描述太宽泛（如"处理数据"）会被当兜底工具试探调用。
要让 LLM 不调某工具：描述要「明确不相关」，而非「模糊宽泛」。

这些说明 Agentic RAG 的行为比 Naive RAG 难预测，调试时要隔离变量（清历史、换会话）。

九、关键认知

Agentic RAG = ReAct + RAG，检索是 Agent 的一个工具。
LLM 自己决定调不调、用什么 query（不是独立改写模型）。
检索结果走 ToolMessage，非拼 context。
灵活智能，但行为不确定性高，调试要注意历史污染。
工具选择看 name+description+args 三件套 + 对话历史。

Agentic RAG 解决了 Naive RAG "无脑检索"的问题，但没解决"检索质量"问题——检索精度仍靠单次向量检索，这催生了 Advanced RAG（专门优化检索质量）。

目录CONTENT

rag-agentic