Version: Next

Agentic RAG：从固定管线到智能体

前面的 RAG 流程无论多复杂，本质仍是固定管线：检索次数、检索方式、何时停止，都在代码里写死。这带来三个天花板：

多跳问题："A 的作者和 B 的作者是否同属一个流派？"需要先查 A，再查 B，再查流派——检索次数事先不可知。
无法自我纠错：召回质量差时，管线只会把坏结果塞给模型硬答。
单一知识源：真实系统往往同时有向量库、知识图谱、数据库、搜索引擎，何时用哪个，无法静态穷举。

Agentic RAG 的答案是：把检索变成工具，把流程决策权交给 LLM。

核心转变

固定管线：  代码编排 ──→ 检索 ──→ 拼上下文 ──→ 生成
Agentic：  LLM 决策 ──→ 选择工具 ──→ 观察结果 ──→ 继续决策 or 回答

LLM 不再只是终点的"写作器"，而是全程的"决策者"：它决定要不要检索、用什么 query 检索、检索结果够不够好、要不要换一种方式再来一轮。这就是 Agent 的核心循环（感知 → 思考 → 行动 → 观察）在 RAG 上的应用，Agent 的通用原理见 Agents 分类。

最小实现

把检索封装为工具，交给支持函数调用的模型：

import json

tools = [
    {
        "type": "function",
        "function": {
            "name": "search_knowledge_base",
            "description": (
                "检索内部知识库。当问题涉及公司制度、产品文档、"
                "历史项目等私有知识时调用。"
            ),
            "parameters": {
                "type": "object",
                "properties": {
                    "query": {
                        "type": "string",
                        "description": "用于语义检索的查询语句",
                    }
                },
                "required": ["query"],
            },
        },
    }
]

messages = [
    {"role": "system", "content": "你是知识助手，优先用工具检索后再回答。"},
    {"role": "user", "content": "学院的定位是什么？教师的考勤制度是怎样规定的？"},
]

while True:
    response = llm.chat(messages=messages, tools=tools)
    if response.tool_calls:                 # 模型决定继续检索
        for call in response.tool_calls:
            result = retriever.retrieve(call.arguments["query"])
            messages.append({
                "role": "tool",
                "tool_call_id": call.id,
                "content": json.dumps(result[:3], ensure_ascii=False),
            })
    else:                                   # 模型认为信息足够，开始作答
        print(response.content)
        break

注意循环的终止由模型判断——这正是"动态流程"与"固定管线"的本质区别。工程上必须叠加最大轮数、最大 token 等护栏，防止模型陷入无限检索。

检索路由

多知识源场景下，先由 LLM（或轻量分类器）决定走哪条通道：

用户问题
   ↓
Router（LLM 判断）
   ├── 制度/文档类 ──→ 向量知识库
   ├── 结构化数据类 ──→ Text-to-SQL 查库
   ├── 关系推理类 ──→ 知识图谱查询
   ├── 时效热点类 ──→ 联网搜索
   └── 闲聊/常识 ──→ 直接回答

路由的价值不只是效果，还有成本：简单问题不必付出全套检索与生成的代价。

自我纠错检索

让模型评估自己的检索结果，质量不足时主动修正，代表性思路：

CRAG（Corrective RAG）：用轻量评估器给召回结果打分。高分直接使用；低分触发查询改写或转向网络搜索兜底；中等分数做知识精炼（去噪、压缩）。
Self-RAG：模型在生成过程中自我反思——现在需要检索吗？检索到的内容支持当前论断吗？通过特殊 token 输出这些判断，按需触发检索。

检索 → 质量评估 ──┬── 高 ──→ 直接生成
                  ├── 中 ──→ 精炼后生成
                  └── 低 ──→ 改写 query 重试 → 仍低 → 转外部搜索 / 拒答

这类模式显著提升多跳问题和知识库覆盖不足场景的表现，代价是单次回答的调用次数和延迟上升，适合对质量敏感、对延迟不敏感的场景。

迭代检索与子问题分解

复杂问题让 LLM 先拆解，再逐个检索：

问题："对比学院 2025 和 2026 年的教师培训制度变化"
  ↓ 分解
子问题 1："2025 年教师培训制度" ──→ 检索 ──→ 结果
子问题 2："2026 年教师培训制度" ──→ 检索 ──→ 结果
  ↓ 汇总
综合对比回答

分解可以一轮完成（静态分解），也可以边检索边分解（动态多跳，后者更接近人类的查资料过程）。

何时使用 Agentic RAG

维度	固定管线 RAG	Agentic RAG
延迟	低（1 次检索 + 1 次生成）	高（多次循环决策）
成本	低	高（多轮 LLM 调用）
可预测性	流程确定，易测试	轨迹动态，需轨迹级评测
复杂多跳问题	弱	强
自我纠错	无	有
适用场景	高并发 FAQ、延迟敏感	研究分析、深度问答

经验法则：80% 的流量用固定管线兜住成本和延迟，剩下 20% 的复杂问题才升级到 Agentic。先用简单方案验证，问题确实超出管线能力时再引入智能体，这与 Agent 构建的通用原则一致，见构建好 Agent 的设计原则。

核心转变​

最小实现​

检索路由​

自我纠错检索​

迭代检索与子问题分解​

何时使用 Agentic RAG​