面试官一句「意图识别你们是怎么做的」要是你张口就来「丢给大模型让它判断不就行了」——这话一出口面试官基本已经在心里给你画叉了。不是故意为难你。真实项目里如果每一句话都走大模型延迟、成本、稳定性三样会一起崩。我有个做智能客服的朋友第一版就是「全交给大模型」结果大促当天 P95 延迟飙到 8 秒调用账单当月翻了三倍。他痛定思痛才把架构改成了三层漏斗。这道题表面问「怎么判断用户需求」实际考的是工程分层取舍——你怎么在准确率、响应延迟、服务成本之间找平衡。一、两个极端都不可取先说两种会翻车的做法理解了这俩中间那条路才立得住极端做法后果全写死规则意图全靠关键词、if-else 硬编码用户换个说法就识别失效维护成本爆炸全依赖大模型每句话都丢给对话模型判断延迟高、开销大、易超时量一上来就崩核心思路就一句话搭一个三层漏斗简单请求上层快速处理常规需求中层承接只有复杂模糊的语句才交给底层大模型兜底。层级越靠下识别能力越强但速度越慢、成本越高。设计目标很明确——绝大多数流量要在上两层消化掉。图两个极端都不可取二、三层漏斗总览层处理对象技术手段特点第一层·规则拦截高频、句式固定的指令关键词、正则、状态机毫秒级、零算力、稳定第二层·上下文小模型九成常规对话轻量微调小模型 / 语义向量匹配 对话状态快、成本低、灵活第三层·大模型兜底边缘、模糊、跨领域需求大模型 函数调用 / MCP能力强但慢且贵把三层串成路由逻辑骨架是这样的图三层漏斗架构def route(user_msg, history):# 第一层规则快速拦截if match_rule(user_msg): # 关键词/正则/状态机return rule_handler(user_msg)# 第二层小模型 上下文intent, conf small_model(user_msg, history)if conf THRESHOLD: # 九成流量在这消化return handle(intent)# 第三层大模型兜底return llm_with_tools(user_msg, history)图路由逻辑对应 route 伪代码三、第一层规则快速拦截层处理意图清晰、表达固定的高频指令靠关键词、正则、状态机实现。用户说「打开设置」「查余额」「转人工」这类句式没有歧义完全不需要调用模型毫秒级就能路由分发。优势短板与边界速度快、零算力开销、服务稳定不能堆大量规则否则维护成本爆炸、容易误判误伤所以这一层只收纳高频、固定不变的简单指令。它存在的意义是把最确定的流量用最便宜的方式消化掉替下层省算力。四、第二层上下文小模型层这一层承接项目九成常规对话流量。绝大多数用户问题都必须依赖上下文才能读懂——用户只说「就这个」「还是不行」单独一句话根本判断不了意图必须读取完整对话历史。技术上用轻量化微调小模型或语义向量匹配结合对话状态做识别。速度远快于大模型成本极低灵活性又比纯规则高很多。工程关键就一句话做好对话状态持久化。上下文一旦错乱意图判断直接跑偏——前面识别得再准丢了历史就全废。五、第三层大模型工具兜底层只有前两层置信度不足、无法识别的边缘语句才走到这一层。它不单单做意图分类还会搭配函数调用、MCP 协议让大模型理解跨领域、模糊复杂的需求直接匹配对应工具、填充执行参数一步完成「意图识别 业务调用」。缺点是调用成本高、推理延迟高只能作为少量复杂请求的最后防线绝对不能承载主流流量。用户量一上来这一层占比稍微涨一点成本就会失控。图三层技术对比六、面试标准回答模板可直接背第一句亮方案做意图识别不会全部交给大模型采用三层漏斗分层架构。规则层关键词、正则、状态机处理固定高频指令毫秒响应低成本拦截简单请求。上下文层轻量化小模型结合对话历史识别常规需求平衡速度与灵活度承接九成流量。工具兜底层大模型搭配工具调用处理模糊复杂需求作为最终防线。总结就是——简单需求低成本快速处理复杂需求才消耗大模型算力兼顾准确率、延迟与成本。意图识别这道题拼的不是会不会调用大模型而是懂不懂分层架构与工程取舍。能说清「哪层处理什么、为什么这么分」面试官就知道你有线上落地的真经验。七、收尾留个思考题第二层小模型的置信度阈值设太高或太低分别会带来什么问题提示它直接决定流量往大模型层漏多少——漏多了成本和延迟崩漏少了又退化成「几乎全靠大模型」。欢迎在评论区聊聊你的判断。