Interview AiBoxInterview AiBox 实时 AI 助手，让你自信应答每一场面试
面试官追问：为什么你的 RAG 把所有 Query 都丢进向量库？Query 理解与路由怎么讲
很多人能讲召回和重排，却讲不清为什么不同 Query 要走不同链路。本文从 Interview AiBox 的面试场景出发，拆解 Query 理解、实体提取、路由与回退机制。
- sellTechnical Deep Dive
- sell产品更新
很多候选人讲 RAG，最容易露馅的地方不是向量库，也不是模型名字，而是这句太顺口的话：
用户提问之后，我们先做向量检索，再把召回内容交给大模型生成答案。
这句话听起来没错，但只要面试官继续追两步，问题就出来了。
如果用户问的是：
- “帮我算一下 A 款保险的理赔金额”
- “昨天那个案例现在到哪个节点了”
- “最新版本的理赔流程和上个月有什么区别”
这些问题真的都应该直接去知识库里搜吗？
答案显然不是。
所以这篇文章，我想专门把一个很多人忽略、但在真实系统里非常关键的模块讲清楚：
Query 理解与路由。
它解决的不是“让检索更聪明”这么简单，而是先判断：
- 这个问题到底是什么类型
- 该不该检索
- 该检索哪些索引
- 要不要带时间、来源、角色等过滤条件
- 如果当前链路失败，系统怎么回退
对 Interview AiBox 这类面试场景来说，这一步尤其重要。因为用户问的不是纯知识问答，而是项目追问、行为面、系统设计、计算型问题、结构化信息查询混在一起的真实面试流。
先看主链路：Query 进来之后，我们先判断“走哪条路”
一、为什么“所有 Query 都走同一条检索链路”会翻车
这个问题之所以高频，不是因为大家不会做检索，而是因为很多人默认把 RAG 当成了一个统一入口。
但真实产品里的问题类型非常杂。
同样是用户输入一句话，背后的处理需求可能完全不同：
- 事实型查询：问定义、问流程、问政策，适合走知识检索
- 计算型查询：问金额、问配额、问损益，应该优先走计算或工具模块
- 结构化查询：问某条记录、某个进度、某个指标，更适合走数据库或 API
- 带过滤条件的查询：比如“昨天”“最新”“某个来源”，需要先提取约束再检索
- 闲聊或越界问题：可能应该礼貌拒答，而不是硬进 RAG
如果不做这一步，系统就会出现两个典型问题：
该算的不算
用户要的是数值推导，系统却回了一段制度说明。
该过滤的不过滤
用户问的是“最新版本”，系统却把旧材料和新材料混着召回，最后答案表面流畅，实际上过期。
这也是为什么真正做过系统的人，通常不会把链路讲成：
query 进来，先 embedding，再向量检索。
更完整的说法应该是：
query 进来后，先判断它属于哪类任务，再决定是否进入检索链路，以及该带什么约束进入检索链路。
二、意图识别不是花活，而是第一层调度能力
很多面试官一问 Query 理解，真正想听的是：你有没有把系统看成一个多能力入口，而不是一个“只有检索”的单能力管道。
规则层适合处理高频明确表达
在很多业务场景里，一部分 Query 的模式非常稳定。
比如出现：
- “算一下”
- “金额”
- “平均”
- “占比”
- “最新”
- “昨天”
这些词本身就可以提供很强的路由信号。
规则层的优势是：
- 快
- 可解释
- 没有额外模型成本
它很适合先吃掉一批明显样本。
分类模型适合提升鲁棒性
问题在于，用户不会永远用你预期里的那种表达。
有人说“帮我估一下这笔理赔能拿多少”，没有出现“计算”两个字，但意图依然是计算求解。
这时候，轻量分类模型的价值就出来了。它能根据语义而不是关键词做判断，减少规则层的漏判。
大模型更适合处理疑难样本，而不是全量分类
很多团队会直接让大模型做意图分类，这在 Demo 里很方便，但在线上系统里不一定是最优解。
更务实的方式通常是：
- 规则优先
- 分类模型兜底
- 只有低置信度样本才交给大模型补判
这样兼顾了：
- 延迟
- 成本
- 稳定性
对 Interview AiBox 这种实时面试产品来说，这种分层特别重要。因为用户不会接受每个问题都先多等一轮模型判断。
三、实体提取决定你能不能真的“理解约束”
意图识别解决的是“走哪条路”，但还不够。
很多 Query 里还藏着真正决定结果质量的约束条件。
比如：
“昨天《独家新闻》里那条关于化学制品行业的排名是什么？”
这句话里至少有几类信息：
- 时间：昨天
- 来源：独家新闻
- 主题：化学制品行业
- 查询目标：排名
如果系统不把这些实体单独提出来，直接用整句话去搜，检索很可能只命中“化学制品行业”的泛话题内容，而不是用户真正想找的那条记录。
所以 Query 理解里非常关键的一层，是把这类约束结构化出来。
常见会提的实体包括：
- 时间
- 来源
- 项目名
- 公司名
- 技术栈
- 数值参数
- 角色或岗位方向
这些信息一旦被提出来，就能直接影响后续路由和过滤。
四、真正的路由决策，核心不是“聪明”，而是“少走错路”
很多人讲路由的时候喜欢说得很复杂，但从工程角度看，最关键的其实只有一句话：
把问题送到最不容易犯大错的那条链路。
一个更稳的路由思路，通常会像这样：
不确定时，保守默认而不是激进跳路
这是最容易被忽略的工程判断。
如果分类器信心不够高，宁可先走默认检索或多路并行，也不要硬把问题送到可能完全不适配的链路。
因为错路由的代价，往往比“走了一条稍慢但还算可用的默认路径”更大。
五、在面试场景里，我们为什么更重视 Query 路由
通用知识库问答更像“找答案”。但面试场景更复杂，它还要解决：
- 当前是项目追问还是行为面
- 用户想要事实支撑还是表达模板
- 这一轮应该拉项目材料，还是拉 STAR 结构、系统设计提纲
- 这一句是要解释方案，还是要把结果先讲清楚
所以在 Interview AiBox 里，我们更愿意把 Query 理解看成一个“场景识别层”。
它不是只为了技术准确率，也是为了回答风格和上下文选择更像真人面试。
例如：
- 如果判断是项目追问，系统会更偏向拉项目事实、结果指标、技术权衡
- 如果判断是行为面，系统会更偏向拉 STAR 素材、协作冲突、影响力表达
- 如果判断是系统设计，系统会更偏向拉架构提纲、容量估算、trade-off 模板
这也是为什么我们会反复强调：面试场景里的 RAG，不只是“更会搜”，而是“更知道当前该怎么答”。
六、回退机制往往比分类准确率更能体现工程成熟度
很多人在面试里会花很多时间讲识别准确率，但真正在线上决定体验的，往往是回退策略。
你很难保证每个 Query 都被一次性路由正确。
真正成熟的系统通常会准备几层兜底：
低置信度回退到默认检索
当意图不够明确时，至少保证系统还能给出保守可用的回答，而不是直接把用户送进错误链路。
工具失败再回检索
如果计算模块、数据库查询模块或工具链返回异常，系统应该有机会退回到保守解释路径，而不是把错误结果直接吐给用户。
这类设计不会让 Demo 看起来更炫，但会让产品更能扛真实流量和复杂输入。
七、面试里怎么把 Query 理解讲得像真做过
如果面试官问你：
“不同类型的 Query，你们怎么处理？”
你可以按这个顺序展开：
先讲为什么不能一股脑都走检索
不同 Query 的目标不同。事实型问题适合检索，计算型问题要走工具，结构化查询要走数据库，带时间和来源约束的问题需要先做实体提取再过滤。
再讲你们怎么分层识别
规则先吃掉高频明确 Query，分类模型提升鲁棒性，大模型只在低置信度场景下做补判。
然后讲实体提取怎么影响后续链路
时间、来源、项目名、岗位方向这些实体会参与过滤、索引选择和上下文组装。
最后讲回退机制
分类不确定时保守回默认链路，工具失败时自动兜底，避免误判直接把答案质量打穿。
如果你再补一句：
在 Interview AiBox 这种面试产品里，我们更关心当前问题属于项目追问、行为面还是系统设计，因为这会直接影响后面拉取什么证据和什么表达模板。
这套回答就会明显比“我们先检索再生成”更像做过产品的人讲出来的。
FAQ
Query 理解是不是一定要上大模型？
不一定。很多高频问题用规则和轻量分类就能解决，大模型更适合用在低置信度和复杂表达场景里。
为什么不直接让检索层自己处理时间和来源这类约束？
因为纯语义检索不擅长处理这类显式过滤条件。先提取实体，再做元数据过滤，通常更稳也更可解释。
Query 路由做得太复杂，会不会反而拖慢系统？
会，所以重点不是堆能力，而是分层。高频样本走低成本路径，疑难样本再升级处理，这样才能兼顾速度和准确率。
下一步
- 想看整条链路怎么串起来，可以继续读面试场景下，我们的 RAG 方案
- 想看知识底座和召回质量如何影响路由后的效果，可以继续读知识库召回质量提升93%
- 想看模型选型和精排怎么讲得更像真做过，可以继续读RAG 面试怎么讲 Embedding 选型
- 想从系统设计视角回答 RAG 架构题，可以继续读RAG 系统设计面试全攻略
Interview AiBoxInterview AiBox — 面试搭档
不只是准备，更是实时陪练
Interview AiBox 在面试过程中提供实时屏幕提示、AI 模拟面试和智能复盘，让你每一次回答都更有信心。
AI 助读
一键发送到常用 AI
智能总结
深度解读
考点定位
思路启发
分享文章
复制链接，或一键分享到常用平台
