前言前段时间有个粉丝去面京东,岗位是大模型应用开发。一面聊得还不错,二面面试官深挖项目细节。他简历上写了做过一个企业知识库问答系统,用的 RAG 架构,面试官就顺着问了一句: 你的 RAG 系统有几种检索路径?你怎么决定一条 query 该走哪条路?他愣了一下,说系统里有向量搜索和 BM25 两种,面试官追问什么情况下用哪种,他想了想说都走一遍看哪个效果好。面试官笑了笑,没继续追问,但表情有点意味深长。他回来复盘才意识到,自己对query 路由这件事几乎没认真想过——系统里确实有两种检索方式,但什么 query 走哪条路,完全是拍脑袋决定的,没有逻辑主线。读完这篇文章,你能搞明白:为什么都走一遍是零分答案——不同 query 本就该走不同路路由器实现的三层演进——规则→分类器→学习型路由四层请求分层框架——跳过检索/精确查询/语义查询/混合查询RRF 怎么融合多路结果——只看排名不看分数RRF 之后为什么还要 Rerank——融合排名不解决排序精度面试话术三层模板——60 分答法和 90 分答法的差距在哪不管你是做 RAG 应用开发的工程师,还是需要在面试里讲清检索架构的开发者,这道题都值得提前想清楚。开拆!一、为什么都走一遍是零分答案先搞清楚面试官问这道题的意图。他不是在问你系统里有几种检索方式,而是在看你有没有想过query 本身该怎么分流。很多人做 RAG 的时候,精力都花在怎么调 embedding、怎么切 chunk、怎么改 prompt 上,但很少有人认真想过:在检索之前,query 本身应该怎么分流?假设你的 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 通常取 60,rank_i 是某篇文档在第 i 个检索结果中的名次。名次越靠前,贡献的分数越高,最后按总分重新排序。这个方法最早是 Cormack 等人在 2009 年 SIGIR 论文里提出的,被证明能超过 Condorcet Fuse、CombMNZ 等多种融合方法。如今 Elasticsearch、OpenSearch、Weaviate、Qdrant 都把它内置成了标准组件,不需要额外训练就能直接用。六、RRF 之后为什么还要 RerankRRF 不是万能解药。有研究做过对比,在同等条件下用凸组合(把两种分数按权重线性相加)反而跑出了比 RRF(k60)更高的召回率。而且把 k 调小到 10 左右,RRF 自身的表现还能进一步提升。RRF 的默认参数值得按自己的数据集重新调一调,而不是照抄 k60。更关键的是:RRF 只是融合排名,它解决的是两份结果怎么合并的问题,并不解决排序本身够不够准的问题。很多生产系统会在 RRF 之后再加一层 Cross-Encoder 重排,用更贵但更精细的模型对融合后的候选再筛一遍。这也是为什么你会经常看到BM25 向量 RRF Rerank这种四段式流水线,而不是单用 RRF 就收尾。七、两派路由实现与选型业界现在能看到的路由实现,大致分两派:Embedding 派:像 Semantic Router 这样基于 embedding 相似度做分类的轻量方案。优点是只需要一个 embedding 模型、延迟低、资源占用小。LLM 派:直接调用 LLM 做零样本意图判断。判断更灵活,但每做一次路由就得额外掏一次 LLM 调用的开销和延迟,高并发场景下并不划算。如果团队已经在用 LangChain 或 LlamaIndex,两者都内置了现成的路由组件,不需要从零开始搭。但如果 query 分布比较特殊(比如编号类查询很多),自己写一层规则路由做前置过滤,往往比直接上语义路由更省心。多数团队真正需要的不是路由器有多智能,而是先踏踏实实把线上 query 日志跑一遍分布统计。看看精确匹配、语义查询、数值查询各占多少比例,这个数字会直接告诉你该从哪层框架开始搭。八、从架构师视角看 Query 路由的几个工程取舍从架构师视角看几个 Query 路由的工程取舍。取舍一:规则路由 vs 学习型路由——什么时候该升级。规则路由覆盖 80% 场景时就够用,只有当规则数量超过 20 条且仍然有 10% 的 query 被误路由时,才值得上学习型路由。判断标准:误路由率 10% → 升级; 5% → 规则够用。取舍二:RRF 的 k 值——照抄 60 还是自己调。k60 是论文默认值,但不同数据集的最优 k 不同。工程上建议:用标注数据跑 k10/20/40/60/100 五组对比,取召回率最高的。不要照抄默认值。取舍三:混合检索的触发条件——什么时候该走双路。不是所有 query 都需要 BM25向量双路检索。工程上建议:只有当 query 同时包含精确标识符语义描述(如WO-8827391 的处理流程)时才触发混合检索,纯精确或纯语义的走单路就行。双路检索的成本是单路的 2-3 倍,不要滥用。取舍四:路由层的延迟预算。路由本身也消耗时间(规则路由1ms,分类器 5-10ms,LLM 路由 100-300ms)。工程上建议:路由层延迟预算不超过总检索延迟的 10%。如果路由比检索还慢,说明路由方式选错了。取舍五:路由结果的缓存。同一个 query 多次查询时,路由结果可以缓存(query→路由决策)。但缓存的有效期要注意:知识库更新后,某些 query 的最优路由可能变了。工程上建议按知识库版本号做缓存 key。取舍六:路由的可观测性。路由出问题时你需要知道:是规则写错了?是分类器准确率不够?还是 LLM 路由判断失误?工程上建议给每次路由打标签(路由方式路由结果后续检索命中率),定期统计各路径的命中率分布,发现异常分布时及时调整路由策略。九、面试话术考官想听的是什么回到面试场景。这道题考的不是你系统里有几种检索方式,而是你有没有想过 query 该怎么分流。常见错误回答一:“都走一遍看效果”。这是零分——把路由降维成了多跑几次检索。常见错误回答二:“用向量搜索就行”。这是没考虑到精确匹配场景——工单号/订单号在向量空间里分不清。高分答题模板:三层结构。第一层(抛本质):“不同类型的 query 本就该走不同路。不存在一种检索方式通吃所有场景,需要的不是更强的单一检索器,而是懂得分流的路由层。”第二层(讲四层框架RRF):“我用四层框架:简单问题跳过检索,精确查询走 BM25/数据库,语义查询走向量,混合查询双路跑RRF 融合。RRF 只看排名不看分数,绕开了量纲不一致的问题。RRF 之后加 Cross-Encoder Rerank 做精排。”第三层(升华):“路由器实现有三层演进:规则路由→轻量分类器→学习型模型。多数团队先用规则顶着,等积累 query 日志再升级。核心是先统计 query 分布,再决定从哪层开始搭。”60 分 vs 90 分对比:追问点60 分回答90 分回答“RRF 怎么融合结果?”“按排名合并”“RRF(score)Σ 1/(krank_i),k通常取60;只看排名不看分数绕开量纲问题;但k值要按自己数据调,不照抄60”“什么时候该走混合检索?”“都走”“query同时含精确标识符语义描述时才走双路;纯精确或纯语义走单路;双路成本2-3倍不滥用”“路由器怎么实现?”“写规则”“三层演进:规则路由(零成本)→轻量分类器(需标注)→学习型模型(RAGRouter);先用规则顶着等日志再升级”“RRF 够用吗?”“够用”“RRF只解决融合不解决排序精度;之后要加Cross-Encoder Rerank;四段式流水线BM25向量RRFRerank”加分项提示:如果你能主动提到先统计线上 query 分布,看精确/语义/数值各占多少比例,这个数字直接告诉你该从哪层开始搭,面试官会认为你有工程优先级意识。总结回到开头那道面试题。“你的 RAG 有几种检索路径?怎么决定走哪条”——这道题考察的是你对 query 路由的系统理解。都走一遍是零分答案:不同 query 本就该走不同路,不是多跑几次检索。四层框架:跳过检索(简单问题)→精确查询(BM25/DB)→语义查询(向量)→混合查询(BM25向量RRF)。路由器三层演进:规则路由→轻量分类器→学习型模型,成本分批摊销。RRF 融合:只看排名不看分数,k 值要按数据集调不照抄 60。RRF 之后要 Rerank:融合排名不解决排序精度,四段式流水线 BM25向量RRFRerank。两派路由:Embedding 派(轻量低延迟)vs LLM 派(灵活但贵)。路由的核心价值从来不是用了多复杂的技术,而是让每一条 query 都走上适合它的那条路。先统计 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%免费】