前天有个读者私信我，说他在字节面大模型应用岗，二面被一个问题搞得彻底没话说。

事情是这样的。他一路介绍完自己的 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%免费】