前天有个读者私信我说他在字节面大模型应用岗二面被一个问题搞得彻底没话说。事情是这样的。他一路介绍完自己的 RAG 项目面试官听完点了点头.‍然后开始出场景题“假设用户输入’帮我算一下重疾险保额 50 万、免赔额 1 万住院花了 8 万能赔多少’——你的系统会怎么处理”‍♂️他说“先把这个问题向量化去知识库检索相关文档找到理赔规则之后拼进 Prompt让大模型基于文档回答。”‍面试官表情微妙地变了一下“所以你打算让系统先搜一堆理赔文档然后指望大模型自己从里面把计算逻辑捋清楚、再算出具体数字”‍♂️他说是的。‍面试官直接说“你这个 query 里有明确的数值参数——保额 50 万、免赔额 1 万、花费 8 万。这是一个计算题不是一个知识检索题。它需要的是一个计算模块而不是去知识库里碰运气找一段能匹配上的文本。你连意图识别都没做所有 query 一律走向量检索这不叫 RAG 系统这叫搜索引擎套了个大模型的壳。”‍♂️他当场就知道这题凉了。这个场景太典型了。我跟很多做 RAG 项目的读者聊过绝大多数人的系统都是一条直线用户问题进来 → 向量化 → 检索 → 拼 Prompt → 生成回答。所有 query 走同一条路不管用户问的是知识查询、数据计算、信息分析还是随便闲聊。结果就是该查知识的去算数了该算数的去查知识了该查数据库的去搜文档了。什么都做什么都做不好。今天把 RAG 系统的 Query 理解模块——意图识别、实体提取、路由分发——彻底讲清楚。简要回答RAG 系统在接收到用户问题后不应该无差别地全部扔给向量检索。正确的做法是在检索之前加一个 Query 理解层先搞清楚用户的意图是什么再决定走哪条处理链路。最基本的意图分类至少要区分四种知识问答类走向量检索、计算求解类走计算模块、数据查询类走 NL2SQL 或结构化查询、闲聊类直接让 LLM 回答或礼貌引导。意图判断之后还要做实体提取把用户问题里的关键约束条件时间、数值、来源抽出来辅助后续的检索过滤或计算参数注入。这件事的工程实现不复杂但它决定了 RAG 系统的天花板。没有意图识别的 RAG 就像一个不看路标的导航——偶尔能走对但大部分时候在绕路。面试里如果被问到你的 RAG 系统怎么处理不同类型的 query只说全部走向量检索基本等于告诉面试官你没做过真正的生产系统。详细解析为什么 RAG 不能一条路走到黑先想一个最简单的问题用户在一个保险问答系统里可能问什么第一种知识查询型重疾险的等待期是多少天这种问题在知识库里有现成答案向量检索 LLM 生成是最佳路径。第二种计算求解型我买了 50 万保额的重疾险免赔额 1 万住院花了 8 万能赔多少这里面有三个明确的数值参数需要套公式计算不是从文档里能搜出来的。第三种数据查询型我上个月提交的理赔申请现在到哪一步了这需要去业务数据库里按用户 ID 查记录跟知识库半毛钱关系都没有。第四种闲聊型“你好”“谢谢”“今天天气不错”。这些跟业务无关的对话根本不应该触发任何检索直接让 LLM 回复就行。如果你的系统不分青红皂白所有问题都往向量检索这条路上送会发生什么计算型的 query 去搜知识库可能搜到一堆讲理赔规则的文档LLM 拿着这些文档试图推理出赔偿金额——但大模型的数学能力你也知道稍微复杂一点的算术它就可能算错。明明一个确定性的计算用 Python 一行代码就能搞定非要让概率模型来碰运气。数据查询型的 query 去搜知识库搜出来的可能是理赔流程一般需要 5-15 个工作日这种通用信息根本不是用户想知道的我的那笔具体进展。这就是没有意图识别的代价该精确的变成了模糊的该确定的变成了概率的。意图识别怎么做三级方案知道了为什么要做接下来看怎么做。意图识别的实现方案有三种按复杂度递增排列。第一种规则匹配。最朴素但最快。维护一张关键词映射表query 里出现了多少钱“怎么算”“赔付金额这些词就分到计算类出现了进度”“状态”我的申请就分到数据查询类。实现零延迟可控性强但覆盖面有限——用户换个说法你就匹配不上了。第二种ML 分类模型。用 BERT 或者轻量级文本分类模型在标注数据上训练一个四分类器。它能识别同义表达用户说帮我看看能拿到多少补偿也能分到计算类比关键词鲁棒得多。但需要几百条标注数据来训练。第三种LLM 零样本分类。直接在 Prompt 里告诉大模型请判断以下问题属于哪个类别不需要任何训练数据上手最快。但每次调用要消耗一次 LLM 推理有延迟也有成本。而且 LLM 偶尔会判断失误稳定性不如训练好的专用模型。实际工程中最靠谱的方案是三级组合规则先行 → ML 兜底 → LLM 处理疑难。具体的流程是这样的query 进来先走规则匹配能命中就直接分类零延迟规则匹配不上的走 ML 分类器几十毫秒出结果ML 分类器信心度低的比如 softmax 最大概率只有 0.4说明模型自己也不太确定才调 LLM 做最终判断。这套组合的好处是绝大部分 query 在规则层就被处理了速度极快少量边界 case 由 ML 模型处理准确率有保障极少数的疑难 query 才动用 LLM成本可控。# 伪代码三级意图识别def classify_intent(query: str) - str: # 第一级规则匹配零延迟 if has_calculation_keywords(query): # 多少钱算一下赔付 return calculation if has_data_query_keywords(query): # 我的进度状态 return data_query if is_greeting(query): # 你好谢谢 return chitchat # 第二级ML 分类器~30ms prediction, confidence ml_classifier.predict(query) if confidence 0.7: return prediction # 第三级LLM 兜底~500ms仅极少量 query 走到这里 return llm_classify(query)实体提取从 query 里把关键参数挖出来意图识别解决了走哪条路的问题但光知道意图还不够。很多 query 里藏着关键的约束条件不把它们提取出来后续处理就会丢失精度。举一个我实际遇到的例子。用户问“上周《经济日报》报道的半导体行业景气度排名第几”这句话里至少有四个关键实体时间“上周”、来源“经济日报”、行业“半导体”、查询目标“景气度排名”。如果你不做实体提取直接把整句话丢给向量检索它大概率会基于半导体行业景气度这几个关键语义去匹配——可能搜出一堆近期关于半导体行业的分析文章但不一定是上周经济日报那篇。用户想要的是一个特定来源、特定时间的特定内容向量检索的语义匹配做不到这种精确度。但如果你提取出了时间实体上周检索时就能在元数据层加时间过滤只搜最近一周的内容提取出来源经济日报就能限定文档来源。这样检索的精准度会大幅提升。实体提取的实现有几种方式。对于日期、数字、金额这类有固定格式的实体用正则表达式又快又准。对于人名、公司名、行业名这类开放性实体可以用 NER 模型或者直接让 LLM 做结构化抽取。工业界的常见做法是正则 NER 混合各取所长。路由分发把 query 送到对的地方意图识别和实体提取都做完了接下来就是路由——根据分析结果把 query 送到最合适的处理链路。意图是知识问答→ 走标准的向量检索 BM25 混合检索链路。如果实体提取拿到了时间约束就在检索时加上时间过滤如果拿到了文档来源约束就限定检索范围。意图是计算求解→ 跳过向量检索直接走计算模块。从 query 中抽取出数值参数保额、免赔额、花费金额等注入到预定义的计算函数或者让 LLM 编写并执行计算代码。结果是确定的不存在幻觉的风险。意图是数据查询→ 走 NL2SQL 模块。让 LLM 把自然语言转成 SQL从业务数据库里查出用户的具体数据。比如把我的理赔进度翻译成SELECT status FROM claims WHERE user_id xxx ORDER BY created_at DESC LIMIT 1。意图是闲聊→ 不走任何检索直接让 LLM 以通用对话模式回复或者礼貌地引导用户回到业务话题上来。如果你的知识库按主题分成了多个索引比如理赔制度“产品信息”投保指南各一个索引还可以在路由阶段做多索引选择——根据 query 的主题选择最相关的索引去检索而不是在全库里大海捞针。这样既提高了检索精度又减少了不必要的计算量。一个容易被忽视的问题路由错了怎么办这一层防线很多人不会想到但在生产环境里非常重要。意图分类器不是 100% 准确的。如果它把一个本该走检索的 query 错误地分到了计算链路用户就彻底拿不到想要的答案。这比不做意图识别、直接走检索还要糟——至少走检索还有概率碰上对的文档。所以有一个关键原则信心不够时宁可保守走默认检索也不要冒险走错链路。具体的实现策略有两个。第一个是设信心度阈值——ML 分类器对某个类别的预测概率低于 0.6就不走那个分支回退到默认的检索链路。第二个是多路径并行——同时走两条路比如既做向量检索也做计算最后对比两边的结果取更好的一个。代价是计算量翻倍但对于准确性要求极高的场景这个代价值得付。另外还需要有回退机制。如果计算模块返回了一个明显异常的结果比如赔付金额算出了负数或者 NL2SQL 生成的 SQL 执行报错了系统应该自动回退到检索链路重新处理而不是把错误结果直接返回给用户。# 伪代码带兜底的路由逻辑def route_query(query: str, intent: str, confidence: float): if confidence 0.6: # 信心不够保守走默认检索 return default_rag_pipeline(query) if intent calculation: result calculation_module(query) if is_abnormal(result): # 结果异常回退到检索 return default_rag_pipeline(query) return result if intent data_query: try: return nl2sql_module(query) except SQLError: # SQL 执行失败回退到检索 return default_rag_pipeline(query) if intent chitchat: return llm_chat(query) return default_rag_pipeline(query) # 兜底面试怎么答这道题面试官爱问因为它能快速看出你对 RAG 系统有没有全局设计的思维。大部分候选人谈 RAG 就是谈检索——向量检索怎么做、BM25 怎么配、Rerank 怎么排。但检索只是 RAG 系统的一个环节在检索之前的 Query 理解才决定了这个问题该不该检索、该怎么检索。第一个容易翻车的点不知道 RAG 有路由层。面试官问你的系统怎么处理不同类型的 query你说都走向量检索——这就暴露了你的系统没有分层设计。面试官会觉得你做的是一个 demo不是生产系统。第二个容易翻车的点做了意图识别但没有兜底策略。面试官追问如果你的分类器判断错了怎么办你说不上来——这说明你在工程上没有考虑过 failure case。任何分类器都有出错的时候有兜底才是成熟的工程设计。第三个容易翻车的点只讲了意图识别没讲实体提取。意图识别决定走哪条路实体提取决定路上带什么参数。两个缺一个系统都不完整。一个比较完整的面试回答框架是四层递进先讲为什么需要 Query 理解模块不同 query 需要不同处理链路不区分就是在碰运气→ 再讲三级意图识别方案规则先行、ML 兜底、LLM 处理疑难→ 然后讲实体提取和路由策略时间过滤、来源限定、多索引选择→ 最后讲安全机制信心度回退、异常兜底、多路径并行。如果你还能补一句具体数字比如我们上线意图识别之后用户的首次回答满意率从 61% 提升到了 78%主要是计算类和数据查询类的 query 不再被错误地走检索链路了面试官会更加相信你是真做过这件事的。写在最后Query 理解模块在很多 RAG 教程和开源项目里是缺失的。你看大部分教程的流程图都是画一条直线用户提问 → Embedding → 向量检索 → Top-K 拼 Prompt → LLM 生成。干净利落但在真实业务场景里根本扛不住。因为真实用户不会只问知识类的问题。他们会问计算题会问自己的业务数据会说帮我看看上次那个事儿怎样了甚至会纯粹闲聊。一个成熟的 RAG 系统不能只有一条路——它需要一个指挥中心先搞清楚用户想干什么再分配最合适的处理方式。这就是 Query 理解模块的价值。它不做检索也不做生成但它决定了检索和生成的质量上限。很多时候RAG 系统效果不好大家第一反应是去调 Embedding 模型、调分块策略、加 Rerank。这些当然都有用但如果你的 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%免费】