30秒快速回答： Adaptive RAG（自适应检索增强生成）的核心思想很简单——别再对所有问题都用同一套检索流程。它先让一个”查询分类器”判断问题有多难，再据此自动选择最合适的策略：简单问题跳过检索直接生成答案（省 Token、省延迟），中等问题做一次检索，复杂问题才触发多轮检索。2026 年业界普遍认为它是延迟与成本之间平衡最好的默认方案。

核心价值一句话： 如果你觉得当前 RAG 系统”不该检索的也在检索、该深挖的又挖不够”，Adaptive RAG 能像一位老手一样给每类问题分配合适的”力”，在准确率几乎不降的前提下，明显压低延迟和 Token 消耗。

为什么需要 Adaptive RAG？”一刀切”检索的两头吃亏

传统 RAG 的流程固定为：检索 → 拼接上下文 → 生成。这套流程对”今天北京天气”“公司年假政策是什么”这类简单事实查询，属于杀鸡用牛刀——白白多花一次向量检索的延迟和几千 Token 的上下文占用；而对”对比这三份合同的违约条款差异并给出风险结论”这类需要多步推理的复杂问题，检索一次往往不够，答案会明显变差。

也就是说，固定流程在两个方向上同时吃亏：

Adaptive RAG 的出现，就是要用”路由器”解决这个矛盾：按问题的复杂度分配检索强度。

核心原理：查询分类器 + 策略路由

Adaptive RAG 的完整流程可以拆成三步：

用户查询
   │
   ▼
┌─────────────────────────────┐
│  查询分类器（Query Classifier）│  ← 判断问题复杂度
│  无检索 / 单次检索 / 多轮检索    │
└─────────────────────────────┘
   │              │              │
   ▼              ▼              ▼
直接生成       一次检索+生成    迭代检索(如 RAG-CoT)
   │              │              │
   └──────────────┴──────────────┘
           最终答案（带证据）

1. 查询分类器：通常用一个小模型（或同一 LLM 的一次低成本调用）把问题分成”不需要检索 / 简单 / 复杂”等层级。分类依据可以是是否需要外部知识、是否涉及多步推理、是否跨多个实体。
2. 策略路由：按分类结果走不同分支——无需检索直接生成；简单问题检索一次；复杂问题进入多轮检索循环（例如把每一步的中间答案作为下一步检索的线索）。
3. 反馈增强（可选进阶）：生成后做一次自评，若发现答案与证据矛盾或置信度过低，触发补检——这其实就是把 Self-RAG 的反思能力叠加上来。

工程上怎么落地分类器？ 最朴素的做法是基于规则（命中关键词/实体数阈值），更稳的是微调一个小分类模型，或者直接用带结构化输出的提示词让 LLM 打分。关键在于分类成本必须远低于”多检一轮”的代价，否则就本末倒置了。

主流方案横向对比：该选哪一个？

理解 Adaptive RAG 的定位，最好的方式是把它放进 RAG 家族里横向比较。下表来自 2026 年业界实测，数字为相对”无检索直接生成”的开销倍数：

可以看到，Adaptive RAG 用”该省则省、该花则花”的策略，在延迟和 Token 两方面都拿到了最佳平衡——这正是它成为 2026 年生产环境推荐默认值的原因。如果需求特别强调答案可靠，可以在 Adaptive 之上叠加 Self-RAG 的反思；如果上游文档质量很差，再加 CRAG 的纠错。RAG 家族并不是互斥选择，而是可以组合的积木。

LangGraph 落地示例：一个最小的路由骨架

用 LangGraph 实现 Adaptive RAG 的开销很低，核心就是”条件边”按分类结果分流：

from langgraph.graph import StateGraph, END
from langgraph.graph import MessagesState

def classify_query(state):
    q = state["messages"][-1].content
    # 简化：根据问题是否含"对比/为什么会/如果…会怎样"等词判断复杂度
    if any(k in q for k in ("对比", "为什么", "如果", "总结这三"):
        level = "complex"
    elif "什么是" in q or len(q) < 20:
        level = "simple"
    else:
        level = "retrieve"
    return {"level": level}

def no_retrieve(state):   # 直接生成
    return {"messages": [llm.invoke(state["messages"])]}

def retrieve_once(state): # 单次检索
    docs = vectorstore.search(state["messages"][-1].content, k=4)
    return {"messages": [llm.invoke(rag_prompt(state, docs))]}

def multi_hop(state):     # 多轮检索（示意）
    return {"messages": [agent.invoke(state["messages"])]}

g = StateGraph(MessagesState)
g.add_node("classify", classify_query)
g.add_node("no_retrieve", no_retrieve)
g.add_node("retrieve_once", retrieve_once)
g.add_node("multi_hop", multi_hop)
g.set_entry_point("classify")
g.add_conditional_edges("classify",
    lambda s: s["level"],
    {"simple": "no_retrieve", "retrieve": "retrieve_once", "complex": "multi_hop"})
g.add_edge("no_retrieve", END)
g.add_edge("retrieve_once", END)
g.add_edge("multi_hop", END)
app = g.compile()

真实生产里，你还需要三件配套：分类结果的置信度阈值（不确定就降级到检索，宁可多检不可漏检）、Token 预算护栏（单个查询最多检索几轮），以及检索质量的可观测性（每类查询的成功率、延迟、成本分开埋点），否则路由失效时很难定位。

何时该上 Adaptive RAG？落地建议

强烈建议升级的场景：查询类型差异大（既有”什么是”类，也有”对比分析”类）、RAG 月 Token 成本开始成为关注点、或偶发出现”简单问题被错误检索带偏”的情况。这三种任意命中一个，就值得把路由层加上。

建议慎用的场景：所有查询都高度同质（比如纯政策条款问答）、或团队尚无任何可观测性埋点——此时路由带来的收益很难被量化，反而增加维护成本。

组合拳路线图：先上 Adaptive RAG 拿下基线 → 若答案可靠性不足，叠加 Self-RAG 反思 → 若检索源噪声大，再加 CRAG 纠错 → 最后用评测集（如 RAGAS）对每类查询单独评估，持续迭代。

总结

• 核心机制：用查询分类器把问题按复杂度分层，再按层路由到”直接生成 / 单次检索 / 多轮检索”，避免一刀切。
• 性价比：以约 1.2–2 倍延迟、1.5–2 倍 Token 的开销换取多数场景的准确率，是 RAG 方案里延迟与成本平衡最好的默认选择。
• 工程要点：分类成本要足够低、要有置信度兜底、配 Token 护栏与可观测性，并与 Self-RAG / CRAG 按需组合。

延伸阅读：本站的《什么是 RAG？一文搞懂检索增强生成》帮你打基础，《什么是 Agentic RAG》讲了从”被动检索”到”自主检索”的演进，《什么是混合检索与重排序》覆盖了检索质量的上游，再结合本文的《Adaptive RAG》，基本就集齐了 2026 年 RAG 生产全家桶。