前言
前段时间有个粉丝去面京东,岗位是大模型应用开发。一面聊得还不错,二面面试官深挖项目细节。他简历上写了做过一个企业知识库问答系统,用的 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 之后为什么还要 Rerank
RRF 不是万能解药。有研究做过对比,在同等条件下用凸组合(把两种分数按权重线性相加)反而跑出了比 RRF(k=60)更高的召回率。而且把 k 调小到 10 左右,RRF 自身的表现还能进一步提升。
RRF 的默认参数值得按自己的数据集重新调一调,而不是照抄 k=60。
更关键的是: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 还是自己调。 k=60 是论文默认值,但不同数据集的最优 k 不同。工程上建议:用标注数据跑 k=10/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/(k+rank_i),k通常取60;只看排名不看分数绕开量纲问题;但k值要按自己数据调,不照抄60" |
| "什么时候该走混合检索?" | "都走" | "query同时含精确标识符+语义描述时才走双路;纯精确或纯语义走单路;双路成本2-3倍不滥用" |
| "路由器怎么实现?" | "写规则" | "三层演进:规则路由(零成本)→轻量分类器(需标注)→学习型模型(RAGRouter);先用规则顶着等日志再升级" |
| "RRF 够用吗?" | "够用" | "RRF只解决融合不解决排序精度;之后要加Cross-Encoder Rerank;四段式流水线BM25+向量+RRF+Rerank" |
加分项提示: 如果你能主动提到"先统计线上 query 分布,看精确/语义/数值各占多少比例,这个数字直接告诉你该从哪层开始搭",面试官会认为你有工程优先级意识。
总结
回到开头那道面试题。"你的 RAG 有几种检索路径?怎么决定走哪条"------这道题考察的是你对 query 路由的系统理解。
- "都走一遍"是零分答案:不同 query 本就该走不同路,不是多跑几次检索。
- 四层框架:跳过检索(简单问题)→精确查询(BM25/DB)→语义查询(向量)→混合查询(BM25+向量+RRF)。
- 路由器三层演进:规则路由→轻量分类器→学习型模型,成本分批摊销。
- RRF 融合:只看排名不看分数,k 值要按数据集调不照抄 60。
- RRF 之后要 Rerank:融合排名不解决排序精度,四段式流水线 BM25+向量+RRF+Rerank。
- 两派路由:Embedding 派(轻量低延迟)vs LLM 派(灵活但贵)。
路由的核心价值从来不是用了多复杂的技术,而是让每一条 query 都走上适合它的那条路。 先统计 query 分布,再决定从哪层开始搭------这才是工程上正确的做法。
你的 RAG 系统里 query 路由是怎么做的?踩过"工单号被向量搜索分不清"的坑吗?欢迎评论区交流。