京东面试官问：“你的RAG系统有几种检索路径？怎么决定走哪条？“ 我支支支吾吾地说了句“都走一遍看效果最好的“。

前段时间有个粉丝去面京东岗位是大模型应用开发一面聊得还不错到二面的时候面试官开始深挖项目细节。他简历上写了做过一个企业知识库问答系统用的RAG架构面试官就顺着问了一句“你的RAG系统有几种检索路径你怎么决定一条query该走哪条路”他愣了一下说系统里有向量搜索和BM25两种然后面试官追问那什么情况下用哪种他想了想说都走一遍看哪个效果好。面试官笑了笑没继续追问但表情有点意味深长。他回来复盘的时候才意识到自己对query路由这件事几乎没认真想过——系统里确实有两种检索方式但什么query走哪条路完全是拍脑袋决定的没有逻辑主线。这个问题其实挺典型的。很多人做RAG的时候精力都花在怎么调embedding、怎么切chunk、怎么改prompt上但很少有人认真想过在检索之前query本身应该怎么分流不同类型的query本来就该走不同的路而不是一股脑全丢给同一个检索器。今天就把这件事讲清楚从最简单的规则路由到四层框架再到混合检索的结果怎么融合争取把query路由这件事从头到尾捋一遍。RAG中怎么搞多路查询路由这件事假设一下哈你的 RAG 系统一直靠向量搜索撑着运行得也还算正常。直到有一天呢有人突然问了一句“工单号 WO-8827391 现在处理到哪一步了”然后呢向量检索器就很认真地转了一圈翻出来的结果全是关于工单流程啊、处理规范啊这类泛泛的文档没有一条真正命中这个编号。问题出在哪呢其实不在于检索器不努力而是它天生就不是干精确匹配这个活的。向量搜索的强项是语义相近弱项恰恰就是字符级别的精确对齐。你想想看嘛WO-8827391和WO-8827392这两串字符在语义向量空间里几乎是重合的邻居。毕竟从意思上来看它们确实没什么差别对吧。京东面试官问的那个问题其实就是在探这个你的系统里有几种检索路径你有没有想过不同类型query该走哪条路如果你的回答是都走一遍看效果那说明你对这件事还没想明白。不同类型的 query本来就该走不同的路咱们把几种常见问法摆在一起看就更清楚了。比如说怎么报销差旅费这种问法语义比较模糊、也没有什么硬指标交给向量搜索去理解意图反而比较合适。但是呢WO-8827391 的进度这种它不是一个需要去理解的问题它是一个需要精确匹配的字符串。用 BM25 或者直接查数据库会快得多、也准得多。再往下看去年12月的库存周转率这类问题本质上是一次数值计算或者数据库聚合向量搜索在这里基本就使不上什么力气了。还有就是公司年假政策这种关键词很清楚、说法也比较固定的问题BM25 靠字面匹配往往比语义检索要更稳一些。所以结论其实很朴素不存在一种检索方式能够通吃所有场景。你需要的不是更强的单一检索器而是一个懂得进行分流的路由层让每条 query 各自去走它该走的路。路由器可以做到多简单也可以做到多复杂最省事的做法呢就是写死几条规则。比如说 query 里出现了数字或者编号就转去查数据库query 很短的话就走 BM25出现了怎么如何这类词就走向量搜索。这套方案的好处是零成本、立刻就能上线。但坏处也很直接就是规则会越写越多像打地鼠一样总有新的 query 形态从缝隙里漏出去逼着你不断地去打补丁。往上一层呢就是训练一个轻量分类器。哪怕只是逻辑回归把 query 分成精确匹配、语义查询、数值查询、混合查询这几类。相比手写规则它能学到一些人工写不出来的模式。只是代价是你得先攒出几百条标注数据这对很多小团队来说本身就是一道门槛。再往上呢路由本身也可以做成一个持续训练、持续迭代的模型。这正是 RAGRouter、RouteRAG 这一类方案想要去解决的问题效果通常是最好的。但问题是需要一整套训练 pipeline对大部分项目而言更像是有更好没有也不影响上线的一个加分项而不是必需品。值得补充一句哈这三种做法不是互斥的替代关系更像是一条演进路径。很多团队一开始用规则路由顶着等积累了真实的用户 query 日志再拿这批数据去训练分类器。成本是分批摊销的不需要一开始就 all in 到复杂方案上。面试官问你怎么决定走哪条路的时候如果你能说出这三种实现方式的区别和演进路径至少说明你对这件事有系统的思考而不是拍脑袋决定。一个够用的四层框架与其纠结路由器该多智能不如先想清楚请求的分层。第一层呢就是问题足够简单、模型自己就能答的那种直接跳过检索就好了。这一层的意义经常被低估它省下来的是真金白银的检索和推理成本。第二层是精确查询比如工单号、订单号这类的直接走 BM25 或者数据库就行。第三层是语义查询就是那些模糊描述、意图不太明确的那类问题交给向量搜索去处理。第四层呢也是最少见但最贵的一层query 里精确和语义两种诉求都有的情况。这时候 BM25 和向量搜索就一起跑然后再用 RRF 把两份结果融合成一份。这个框架的价值在于分布本身嘛。大多数真实流量会落在第一、二层就被消化掉了只有少数复杂问题才需要去触发最贵的混合检索路径。这样一来整体成本曲线就被拉得很平了。混合检索的结果怎么合并RRF 为什么好用BM25 给出的分数和向量搜索给出的余弦相似度根本不在同一个量纲上。前者可能是十几分后者被压缩在 0 到 1 之间。直接相加或者简单归一化去凑都容易出问题。RRF也就是 Reciprocal Rank Fusion它绕开了这个麻烦。它压根不看原始分数只看每份结果里的排名。公式是这样的RRF(score) Σ 1 / (k rank_i)k 通常取 60rank_i 是某篇文档在第 i 个检索结果中的名次。名次越靠前呢贡献的分数就越高最后按总分重新排一次序就好了。这个方法其实不年轻了最早是 Cormack 等人在 2009 年的 SIGIR 论文里提出来的被证明能超过 Condorcet Fuse、CombMNZ 等多种融合方法。如今 Elasticsearch、OpenSearch、Weaviate、Qdrant 这些主流检索引擎都把它内置成了标准组件不需要额外训练就能直接用。不过呢RRF 也不是万能解药。有研究做过对比在同等条件下用凸组合就是把两种分数按权重线性相加反而跑出了比 RRFk60更高的召回率。而且同一份对比里还发现把 k 调小到 10 左右RRF 自身的表现还能进一步提升。也就是说呢RRF 的默认参数值得按自己的数据集重新调一调而不是照抄 k60 就完事了。另外可以补充的一点是RRF 只是融合排名它解决的是两份结果怎么合并的问题并不解决排序本身够不够准的问题。很多生产系统会在 RRF 之后再加一层 Cross-Encoder 重排用更贵但更精细的模型对融合后的候选再筛一遍。这也是为什么你会经常看到BM25 向量 RRF Rerank这种四段式流水线而不是单用 RRF 就收尾了。路由不只是技术选型也是一种工程分工哲学跳出 RAG 这个具体场景来看的话query 路由其实和很多系统设计里的分层缓存灰度分流是同一种思路。就是把便宜、确定性强的请求尽早拦下来只让真正复杂、模糊的请求去走最贵的那条链路。业界现在能看到的路由实现呢大致分两派。一派是像 Semantic Router 这样基于 embedding 相似度做分类的轻量方案优点是只需要一个 embedding 模型、延迟低、资源占用小。另一派呢是直接调用 LLM 做零样本意图判断判断更灵活但每次路由都要多付一次 LLM 调用的成本和延迟对高并发场景不算友好。如果你的团队已经在用 LangChain 或者 LlamaIndex两者都内置了现成的路由组件不需要从零开始搭。但如果 query 分布比较特殊比如说本文开头这种编号类查询很多自己写一层规则路由做前置过滤往往比直接上语义路由更省心一些。我个人的判断是多数团队真正需要的不是路由器有多智能而是先老老实实把线上 query 日志跑一遍分布统计。看看精确匹配、语义查询、数值查询各占多少比例这个数字会直接告诉你该从哪一层框架开始搭而不是一上来就奔着 RAGRouter 那种学习型方案去。说到底呢路由这件事的核心价值从来不是用了多复杂的技术而是让每一条 query 都走上适合它的那条路。而不是拿一种检索方式去覆盖所有场景。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】