RAG路由全景：一个问题走到岔路口，谁来指路

RAG路由全景：一个问题走到岔路口，谁来指路

一个 RAG 系统里，既有自己的知识库，又接入了联网搜索。用户问「阿司匹林有什么副作用」------ 该查知识库，还是该搜网页？这个问题在之前的RAG里根本不存在，今天却是每个多源系统的第一道必答题。 本文把业界散落在各框架教程、工程博客与学术论文里的路由方式收拢成一张全景地图： 三大流派、两个旁支、十一种指路方式，以及它们各自的速度、成本与死穴。

0. 引子：一个从不存在的问题

最早的 RAG 长这样：用户问题进来，向量化，去向量库里捞最相似的几段资料，喂给大模型生成答案。一条直线，没有岔路。

直线时代没有选择问题------检索被写死在管道里，问题来了必然走向量库，就像老式自动售货机：按下按钮，出货口是焊死的。

变化发生在系统接入第二个、第三个信息源的那一刻。知识库之外接了 SQL 数据库（统计数据它最准）、接了联网搜索（最新消息只有它知道）、接了图数据库（「张三和李四什么关系」这种关系链只有它能走）。四个源各有所长，同一个问题就有了四条可能的路------

「阿司匹林有什么副作用」：知识库里也许存着你的医药笔记，公网上也有海量科普------查谁？ 「2024年销售多少」：向量库里只有报表的散文描述，精确数字在 SQL 里------查谁？ 「最近这个公司有什么新闻」：知识库是静态快照，天生答不了------查谁？

在检索发生之前，先决定「去哪找」------这个决策环节，就叫查询路由（Query Routing）。 它是多源 RAG 与 Agentic 系统的地基问题：路由做对了，后面全对；路由做错了，检索再精也南辕北辙。

本文回答三个问题：路由到底是什么；业界有哪些指路方式（比大多数教程讲的「两种」多得多）；以及怎么给自己的系统选一种。

1. 路由是什么：从管道到岔路口

先把两代架构摆在一起看，路由的位置就清楚了：

第一代是管道式 ：检索写死在流程里。第二代是路由式 ：检索变成了若干条可选路径，入口处多了一个做选择的组件。这个选择不是随便做的------路由器要读题：分析这个问题的特征，判断哪条路最可能给出好答案。

读题读的是什么？业界实践总结下来是四个维度：

维度	低端特征 → 走哪	高端特征 → 走哪
上下文依赖	事实型问题 → 向量检索直接捞	多跳推理 → 图数据库或 Agent 协调
推理跳数	单跳 → 一次检索搞定	多跳 → 迭代检索
数据类型	非结构化文档 → 向量库	结构化表格 → SQL
时效性	静态知识 → 本地知识库	实时信息 → 联网搜索

「2024 年华东区销售多少」是单跳、结构化、静态------SQL 最快；「供应商罢工对股价有什么影响」要串起供应商→事件→合同→股价四环------图数据库更合适。路由的判断素材，就是这四个维度在问题里的投影。

但还有个隐含前提值得说破：路由之所以值得做，是因为每次全查一遍不划算。四路齐发，延迟加数百毫秒、成本翻几倍------「都查」看似稳妥，实则是用钱和延迟买确定性。所以路由真正寻找的，是准确、效率、成本三者的平衡点。

2. 全景地图：谁来指路

教程里常说「路由就两种：逻辑路由和语义路由」。这是入门的窄门------业界实际形态远不止此。把散落在框架文档、工程博客、学术论文里的做法全摊开，按**「谁来决策」**分族，是三大流派加两个旁支：

• 规则派：代码写死的 if-else 规则做决策------关键词路由、决策树路由
• 相似度派：轻量模型算向量相似度，毫秒级------语义路由、交叉编码器路由、学习式路由
• 大模型派：让 LLM 推理着选------逻辑路由、多路由、复杂度路由、Agentic 路由
• 旁支一（全都要派）：干脆不选，全查后融合------多路并联 + RRF
• 旁支二（见机行事派）：先走一条，不行再换------级联降级

下面逐个拆开讲。你会发现它们的排列不是并列关系，而是速度、成本、理解深度三根轴上的不同落点------从 0 毫秒零成本的硬规则，到每轮烧 token 的大模型循环。

3. 规则派：确定性的第一道闸

3.1 关键词路由：最古老的 if-else

如果 问题包含「最新 / 今天 / 实时」 → 联网搜索
如果 问题包含「统计 / 汇总 / 对比」 → SQL 数据库
否则                              → 向量知识库

这就是路由的暴力解法：正则或关键词匹配，写死在代码里。它的优点在今天依然值钱------快（0 毫秒）、免费、完全确定、可以写单元测试。高风险行业偏爱确定性，这类路由在生产系统里活得很好。

死穴也众所周知：规则枚举不完，语义歧义无能为力。「苹果昨天发布了什么」一个时效词都没有，却强时效；「我笔记里怎么记的阿司匹林副作用」满屏「阿司匹林」「副作用」，规则会把它甩给公网------但公网搜不到你的私人笔记。关键词是词表特征，时效性、私有性是语义特征，两者隔着一道鸿沟。

3.2 决策树路由：规则的「路由形态」

把一组 if-else 组织成多级判断的树，就得到决策树路由------规则派里最像「路由器」的形态：

问题进来先问「带时效词吗」，带了去 Web 搜索；没带再问「要结构化统计吗」，要去 SQL；再问「是概念原理类吗」，是去向量库；全不是------剩给混合检索策略兜底。左边配四个决策因素（时效分析、类型识别、语义相似度、复杂度评估）作为判断素材。

决策树的定位要说清楚：它是第一道快筛，不是全部。真实系统里它处理最典型、最规律的那部分流量，筛剩下的疑难杂症交给后面的语义或 LLM 路由------规则快筛 + 模型细判的分工，是工程上的常见搭配。

4. 相似度派：毫秒级的模糊匹配

规则派跨不过语义鸿沟，相似度派来接棒------思路是把「判断问题像哪类」变成「计算问题与哪组示例最像」。

4.1 语义路由：示例问句的模糊匹配

LangChain 官方教程把路由二分为「逻辑路由与语义路由」，语义路由是其中之一。它的机制像一张模糊匹配表：给每个意图预先写 4~10 条示例问句（术语叫 utterances）------

意图「金融查询」的示例：
  「查一下销售额」「财报数据怎么样」「营收如何」「利润分析」

意图「技术支持」的示例：
  「产品怎么用」「技术文档在哪」「故障怎么排查」

用户问题进来，向量化；每条示例问句也向量化；算相似度，超过阈值（常见默认 0.85）即触发对应路由 。整个过程不碰大模型，纯向量计算------约 50 毫秒，用本地 embedding 模型甚至完全免费。

代价有两条：一是要维护示例问句库 ------意图多了，每路 4~10 条例句的维护成本线性上涨，实战建议意图数不超过 20 个；二是做不了复合逻辑判断------「涉及金融数据且强时效则优先实时库」这种带「且/或/优先级」的规则，相似度表达不了，还得请大模型。

4.2 交叉编码器路由：拼对打分的更准一档

语义路由用的是双塔结构（query 和示例各自编码再算距离），交叉编码器路由更进一步：把 query 和数据源描述拼成一个对，一起送进 cross-encoder 模型打分。因为两段文本在模型内部充分交互，判断精度更高------代价是每对都要跑一次模型，慢一档。它适合源描述比较微妙的场景：几条路的「说明书」长得很像、双塔分不清的时候，交叉编码器来仲裁。

4.3 学习式路由：训练一个专职路由器

学术前沿的做法。2025 年的 RAGRouter 论文提出了一个此前被忽视的现象------检索本身会改变「谁能答对」：同一个问题，某模型检索前答不出、检索后答得出；另一个模型恰恰相反，检索引入的噪声反而把它带崩了。所以「按模型固有知识给问题选模型」的老路由方法，在 RAG 场景会系统性失准。

RAGRouter 的解法是用对比学习训练一个专职路由器，把「检索引发的知识位移」显式建模进路由决策，路由准确率超过最强单模型与既有路由方法 1.67%~9.33%。这类方法的定位：面向多模型、多源、高流量的场景，前期训练投入换后期路由的准确与便宜------流量不大的系统用不着。

5. 大模型派：让 LLM 读菜单点菜

相似度派够快，但最难的判断------复合条件、长尾语义、没见过的问题形态------只有大模型的推理能力兜得住。大模型派的路由方式，全部围绕「怎么用好这一次推理调用」展开。

5.1 逻辑路由：菜单式选择

LangChain 官方二分法的另一半，也是工程上最常用的 LLM 路由形态：给大模型一份「数据源菜单」，让它读题后从枚举值里选一个。

菜单大致长这样：

你是查询路由专家，把问题路由到合适的数据源：
- 涉及财务或销售数据      → finance_db（关系数据库）
- 涉及技术文档、产品手册  → tech_docs（向量库）
- 涉及人员或组织关系      → knowledge_graph（图数据库）
- 需要最新实时信息        → web_search
- 无法明确判断            → general_search
只返回数据源名称，不要返回其他内容。

生产实践踩出来的三个讲究：

1. 结构化输出 + 枚举值。早期让模型自由返回字符串，会收到「我觉得可以查金融库或者通用检索」这种模糊答案，下游没法解析。用结构化输出把返回值锁死成枚举，干净利落。
2. 温度调低（如 0.1）。路由需要稳定不需要创意------温度 0.7 时同一个问题一会儿路由到知识图谱、一会儿路由到 Web 的翻车实录，是很多人交过的学费。
3. 数据源 ≤5 个最稳。菜单太长，模型开始犯迷糊------超过 5 个源建议改用语义路由或分层路由（先粗分大类再细分）。

响应速度约 500~800 毫秒（一次 LLM 调用），每次路由有 token 成本------比语义路由慢十倍、贵一截，换来的是真正的意图理解：复合条件、口语化表达、没见过的问题形态都能处理。

术语辨析 ：不少中文教程把「逻辑路由」解释为「基于规则和查询结构分析」------严格说这是把规则路由（if-else）也笼统装进了这个词。LangChain 官方口径里，逻辑路由特指LLM 按菜单规则做推理选择；纯代码规则的那种，叫关键词路由或规则路由更准确。读教程时留意这个歧义。

5.2 多路由：不做单选题

单选不是唯一解。多路由让 LLM 一次选出若干条相关路径，并行执行后合并结果。「分析公司 2024 年销售数据并对比行业趋势」天然是两路------销售数据走 SQL、行业趋势走 Web------多路由直接把两路都派出去。它牺牲了延迟与成本（几路并发），换来复合问题的完整覆盖。

5.3 复杂度路由：按问题难度分档

Adaptive RAG（2024）提出的思路：路由器不选「数据源」，选「处理深度」。用一个（通常是便宜的）分类器把问题按复杂度分四档：

档位	问题形态	处理策略
A	常识闲聊	不检索，直接回答
B	单跳事实	一次 RAG 检索
C	多跳推理	迭代检索 + 综合多轮
D	时效/知识库外	联网搜索

妙处是成本跟着难度走：80% 的简单问题走最便宜的档位，重火力只留给少数难题。这是「按需分配推理资源」的思想在检索层的落地。

5.4 Agentic 路由：把路由搬进循环里

前面所有方式有个共同点：路由是一次性的、发生在检索之前 。Agentic 路由打破这一点------它把检索降格为工具，摆上大模型的工具菜单，让模型在 ReAct 循环里边走边选：

典型轨迹是这样的：第一轮，模型看题后调用「知识库检索」工具 → 观察返回「无命中」→ 第二轮，思考「知识库未覆盖，改调 Web 搜索」→ 调用 Web 搜索 → 拿到材料 → 生成终答。观察结果成了下一轮决策的新输入------路由从「一次性的赌」变成了「可纠错的试」。

学术界给这条路铺了两块砖：CRAG （Corrective RAG）在每次检索后加一道质量评估闸，检索质量不合格时自动用 Web 搜索补救；Self-RAG 让模型自己反思「这道题需要检索吗？检索结果可信吗？」。两者共同点：把纠错机制内置进检索循环。

代价同样清晰：循环的每一轮都在烧大模型的 token 和延迟------Agentic 路由是理解力天花板，也是成本天花板。

6. 旁支一：全都要派------不选路，直接 RRF 融合

还有一个釜底抽薪的思路：路由那么难，那我不选了。多路并联融合：问题同时发给多个检索器，各回各的排名列表，最后用 RRF（Reciprocal Rank Fusion，排名倒数融合）合成一份总排名。

RRF 的巧妙在于以排名为共同语言：BM25 和向量检索的原始分数刻度完全不同（一个是词频统计、一个是余弦距离），没法直接比大小------但「第 1 名」「第 3 名」人人会说。文档在 BM25 排第 1、在向量检索排第 3，融合分 = 1/(60+1) + 1/(60+3)，两路都靠前的文档自然登顶（k=60 是经验平滑系数，压制单路名次的噪声）。

实测数据很有说服力：BM25 单独召回 70%，向量单独 85%，RRF 融合后 92%------而代价只是两路并行的约 50 毫秒。它是混合检索（关键词+语义）的标准答案。

边界也要说清楚：RRF 适合合并同类型检索器的结果，不解决「该走 SQL 还是 Web」的跨源路由问题------后者还是得回到前面几节的路由器。两者是互补关系：路由器在源间选路，RRF 在源内提召回。

7. 旁支二：见机行事派------级联降级

最后一派面对选择的方式是：先走主路，出状况再换道。级联降级（cascade + fallback）：

流程是纵向的兜底链：问题先走首选源（知识库检索）→ 检索结果过置信度闸门（分数够不够高）→ 够了，正常生成答案；不够，降级第二源（Web 搜索补查）→ 还不行，兜底响应（默认知识库或如实拒答）→ 最终，转人工。

这一派是企业客服系统的标准形态，它的价值观值得单独一句：可控性与可审计性压倒回答覆盖率 。置信度闸意味着「分数不够就不硬答」；终点是转人工而不是搜公网------因为在客服、医疗、金融这类场景，一个错误答案的成本远高于一次转人工。系统每一级都有退路，永不裸奔。

8. 横向对比与选型

十一种方式全部登场，拉通对比：

方式	决策者	速度	成本	理解深度	规模上限	最适用
关键词路由	代码规则	0ms	零	无	无限	特征词明确的高频流量
决策树路由	代码规则	0ms	零	无	无限	规律性强的分流快筛
语义路由	向量相似度	~50ms	低/免费	浅	≤20 意图	高流量意图分类
交叉编码器路由	cross-encoder	~100ms	低	中	中	源描述微妙的仲裁
学习式路由	训练的路由器	~10ms	前期训练	深	大	多模型多源高流量
逻辑路由	LLM 单次推理	~500ms	按 token	深	≤5 源	少量源的深理解
多路由	LLM 单次推理	~500ms+	按 token	深	≤5 源	复合问题多路并发
复杂度路由	分类器/LLM	可变	分档	中	中	按难度分配算力
Agentic 路由	LLM 循环推理	秒级	最高	最深（可纠错）	大	开放式复杂任务
RRF 并联融合	不决策（全查）	+50ms	中	无需	中	同类型检索器合并
级联降级	闸门 + 顺序	可变	低	无需	大	高合规高确定性场景

选型归结为三问：数据源有几个？延迟预算多少？错误答案的代价多高？ 三问答完，路线基本浮出水面------数据源只有一个，先别谈路由，上 BM25+向量混合检索可能就够了；要跨源路由且源少，逻辑路由；源多且流量大，语义路由打底；源多到几十上百，先对「数据源说明书」做一次检索、只把 top-N 菜单递给 LLM（大型 Copilot 的实际做法）；能容忍秒级延迟，Agentic 路由给你最强理解力；错误代价极高，级联降级把确定性焊死。

真实系统几乎都是三层混搭，而不是单选：

第一层：语义路由做日常意图分类（快而免费，扛住大部分流量）
第二层：逻辑路由兜复杂特判（时效性例外、复合条件）
第三层：每个数据源内部用 RRF 融合提召回（BM25 + 向量）

生产数据佐证这套组合的可行性：路由准确率 92.5%、路由环节平均延迟 +50ms、系统整体扛住 1000 QPS------路由作为独立服务，其准确率是被持续监控的指标，而不是玄学。

9. 生产工程化：路由自己也是个组件

路由器不是装上就完事的「一次性决策」，它自己也是一个要被工程化对待的组件。三个生产配套值得了解：

语义缓存：把常见问题的向量缓存下来，新问题相似度 >0.95 直接返回缓存答案，跳过整条检索与生成链路。生产实测命中率 30%~50%，命中时响应从 ~500ms 掉到 ~50ms------最简单、回报最高的一招。

分级模型：路由的判断结果除了选数据源，还可以选模型------简单事实题走便宜的小模型，复杂推理题走旗舰模型，两者单价差可达 100 倍。若流量里八成是简单题，总成本能降到原来的两成。这是路由思想从「选源」到「选算力」的延伸。

失败处理 ：路由器自己会出错（置信度不足、路由失败），所以它自己也需要鲁棒性设计------置信度闸门、降级到默认源、最终转人工，正是第 7 节那条兜底链。给做决策的组件配保险，和给它做决策的能力同等重要。

10. 结语：没有最好的路由，只有匹配的路由

把全文收拢成三句话：

1. 路由的本质，是把「去哪找答案」这件事从代码编译期（写死的管道）提升到运行时（看题选路）------用一点决策成本，换检索的精准与系统整体的省。
2. 三种流派不是竞争而是分工：规则派管确定性的快筛，相似度派管毫秒级的流量底盘，大模型派管最难的那部分理解；两个旁支一个消灭选择（全查融合）、一个消灭风险（级联兜底）。
3. 选型的正确姿势是先诊断再动工：看看当前系统的失败案例属于哪类（是检索不精？是源走错了？还是复合问题没人接得住？），再按数据源数量、延迟预算、错误代价三问选路线------单源先上混合检索，多源从「语义打底 + 逻辑特判」起步，验证有效再谈 Agentic。

RAG 的检索技术这两年突飞猛进，但检索的「前一刻」------那道岔路口的选择题------依然是决定系统上限的第一颗螺丝。路修得再好，指错了方向也到不了终点。

参考资料

• LangChain 官方教程《RAG from Scratch: Part 10 (Routing)》------逻辑路由与语义路由的原始出处
• LangChain 官方文档《Router pattern》与 multi-agent routing 指南
• Easton《RAG Query Routing: Logic, Semantic, and Hybrid Retrieval》（2026）------三种方式的生产实测对比与成本优化
• Sami Maameri《Routing in RAG-Driven Applications》------路由器类型学（keyword/LLM/multi-route/embedding/cross-encoder）
• 论文《Adaptive-RAG》（2024）------按查询复杂度分档路由
• 论文《Corrective RAG (CRAG)》《Self-RAG》------检索后纠错与自我反思
• 论文《RAGRouter: Learning to Route Queries to Multiple Retrieval-Augmented LLMs》（2025）------RAG 场景下的学习式路由
• LlamaIndex 官方文档《Routers》------LLM selector / Pydantic selector / multi-selector 实现
• Microsoft Learn《How the M365 Copilot Orchestrator Chooses Actions》------大规模生产系统的工具候选检索机制