上一篇我们聊了 LLM 语义路由，用模型本身做意图分类，告别了关键词硬匹配的三种陷阱。不少同学问：那到底什么时候用关键词、什么时候上 LLM？只用 LLM 不是更香吗？

其实我在真实项目里踩过这个坑——把所有意图判断都扔给 LLM，上线三天客服系统崩了：日均 10 万次意图识别请求，光这一个环节的 API 费用每月烧了 8 万元，延迟还高达 800ms。后来换了分层方案，费用降到 3000 元，延迟压到 60ms。

意图识别不是"选最强的技术"，而是"在对的位置用对的方案"。

这篇我把生产环境里用过的五种设计全部拆开讲，每种给你代码 + 决策口诀，最后一张决策树帮你直接对号入座。

---

01 关键词匹配：最快的那把刀，但只能切直线

关键词匹配是意图识别里最古老的方案，也是很多人最先放弃的方案。放弃得太早了。

它的本质就是一张"触发词 → 意图"的映射表：

// keyword-intent-matcher.tsconstintentKeywordsRecordstringstringorder_query"订单""物流""快递""发货""到货""运单"refund_request"退款""退货""退钱""申请退""要退"complaint"投诉""不满意""太差了""骗人""垃圾"product_inquiry"价格""多少钱""有没有""规格""参数"functionmatchKeywordIntenttext: stringstringnullforconstofObjectentriesifsome(kw) =>includesreturnreturnnull// 没有命中，交给下游处理consolelogmatchKeywordIntent"我的订单还没发货啊"// order_query ✅consolelogmatchKeywordIntent"这个多少钱"// product_inquiry ✅consolelogmatchKeywordIntent"我想买个东西"// null — 关键词方案的天花板

延迟：< 1ms。准确率：高频确定意图 > 95%。

问题也很明显：用户说"帮我看看这个东西多久能到"，没有"订单""快递"这些词就会漏掉。它处理不了任何口语变体。

什么时候用： 高频确定意图（退款、查单），作为第一层过滤，先把 30% 的明确请求快速处理掉，不要单独使用。

决策口诀：词汇映射清晰 + 对速度极端敏感 → 关键词先上

---

02 正则 + 规则引擎：给关键词装上"上下文"

很多同学觉得关键词不够用，就直接跳到 ML 模型。其实中间有一层被低估了——正则加规则引擎。

它比关键词多了两个能力：位置感知和组合逻辑。

// rule-engine-intent.tsconstintent"order_status_query"patterns/我的(订单|包裹).*(到了|在哪|多久)//(查|看看).*(物流|快递)/combinator"any"asconstintent"complaint_hardware"patterns/(不能用|用不了|坏了)//(产品|设备|手机)/combinator"all"asconstnegativePatterns/怎么用/// 排除教程问题functionmatchRuletext: stringstringnullforconstofconstpatternsfilter(p) =>testconstnegativePatternsfilter(p) =>testiflength0continueconstcombinator"any"length0lengthpatternslengthifreturnintentreturnnullconsolelogmatchRule"我的快递到哪了"// order_status_query ✅consolelogmatchRule"手机用不了了"// complaint_hardware ✅consolelogmatchRule"手机怎么用"// null（负样本过滤） ✅

比关键词覆盖了更多口语表达，延迟仍然在 1~5ms 之内。

但规则会膨胀。 意图从 10 个增长到 50 个后，规则文件膨胀到 2000 行，相互冲突，维护成本直线上升。我见过一个团队维护了 1 万行规则，最后谁也不敢动了。

决策口诀：意图 < 20 个 + 表达有规律可循 → 规则引擎

---

03 Embedding 分类器：从"字面"升级到"语义"

当意图数量超过 20 个、口语表达差异大，规则就撑不住了。上向量分类器。

核心思路：把每个意图的示例句子 Embedding 成向量，用户输入也 Embedding，找最近邻。每个意图只需 5~10 条示例，就能处理大量口语变体。

// embedding-intent-classifier.tsimportOpenAIEmbeddingsfrom"@langchain/openai"classEmbeddingIntentClassifierprivatenewOpenAIEmbeddingsmodel"text-embedding-3-small"privateintentsArrayintentstringembeddingsnumberasyncbuildexamples: Array<{ intent: string; texts: string[] }>forconstofconstawaitthisembedderembedDocumentsthisintentspushasyncclassifytext: string, threshold = 0.75constawaitthisembedderembedQueryletintentnullasstringnullscore0forconstofthisintentsforconstofconstcosineSimilarityifscorereturnscoreintentnullscorescoreconstnewEmbeddingIntentClassifierawaitbuildintent"order_query"texts"我的快递到哪了""订单什么时候发货""帮我查一下物流"intent"refund"texts"我要退款""这个不想要了怎么退""申请七天无理由"// 没有"订单"词，照样命中 ✅consolelogawaitclassify"包裹现在在哪个城市"// { intent: "order_query", score: 0.87 }consolelogawaitclassify"我想取消这笔购买"// { intent: "refund", score: 0.81 }

五种方案对比：

方案	延迟	准确率	意图数上限	冷启动样本
关键词	< 1ms	高（确定意图）	无上限	0
正则规则	1~5ms	中高	~20 个	0
Embedding 分类	30~80ms	高（语义泛化）	~200 个	每意图 5~10 条
小模型 Fine-tune	10~30ms	中高	~500 个	每意图 > 100 条
LLM 自路由	400~1200ms	最高（zero-shot）	无上限	0

决策口诀：意图 20~200 个 + 口语差异大 + 有少量示例 → Embedding 分类器

---

04 小模型 Fine-tune：数据够了，这才是生产主力

当每个意图积累了 200+ 条标注样本，小模型 fine-tune 是性价比最高的方案。

算一笔账：日均 10 万次意图识别，GPT-4o-mini 约 90 美元/月、延迟 200600ms；自托管 BERT 约 40 美元/月、延迟 1030ms。成本省 55%，速度快 10 倍+。

在 LangGraph 里，把小模型封装成 Runnable，直接插进路由节点：

// small-model-in-langgraph.tsimportRunnablefrom"@langchain/core/runnables"importStateGraphAnnotationfrom"@langchain/langgraph"importHfInferencefrom"@huggingface/inference"classSmallModelClassifierextendsRunnablestringintentstringconfidencenumber"custom""intent"privatenewHfInferenceenvHF_TOKENconstructorprivate modelId: stringsuperasyncinvoketext: stringconstawaitthishftextClassificationmodelthismodelIdinputsreturnintentlabelconfidencescoreconstStateAnnotationAnnotationRootuserInputAnnotationstringdetectedIntentAnnotationstringconfidenceAnnotationnumberconstnewSmallModelClassifier"your-org/intent-bert"constnewStateGraphStateAnnotationaddNode"intentRouter"asyncconstawaitinvokeuserInput// confidence < 0.8 → 标记为 uncertain，触发 LLM 兜底returndetectedIntent0.8"uncertain"addNode"orderHandler"addNode"refundHandler"addNode"llmFallback"addEdge"__start__""intentRouter"addConditionalEdges"intentRouter"(s) =>order_query"orderHandler"refund_request"refundHandler"detectedIntent"llmFallback"compile

决策口诀：数据量 > 200 条/意图 + 高并发 + 成本敏感 → 小模型 Fine-tune

---

05 LLM 自路由：zero-shot，解锁"无标注"和"模糊意图"

LLM 自路由最大的优势是 zero-shot——不需要标注数据，一段描述即可定义新意图，上线成本极低。

// llm-intent-router.tsimportChatOpenAIfrom"@langchain/openai"importfrom"zod"constorder_query"用户询问订单状态、物流进度；【不包括】修改地址"refund_request"用户要求退款、退货、取消订单"complaint"用户明确表达不满；【不包括】产品使用疑问"product_faq"用户询问产品规格、功能、使用方法"other"以上均不符合"constIntentSchemaobjectintentenum"order_query""refund_request""complaint""product_faq""other"confidencenumberreasoningstringasyncfunctionllmRouteinput: stringconstnewChatOpenAImodel"gpt-4o-mini"temperature0withStructuredOutputIntentSchemaconstObjectentriesmap([k, v]) =>`- ${k}: ${v}`join"\n"returninvokerole"system"content`你是意图分类器，判断用户输入属于哪个意图：\n${list}`role"user"content// 模糊表达也能识别 ✅constawaitllmRoute"我那个东西好久没消息了"// { intent: "order_query", confidence: 0.85, reasoning: "暗指购买物品的追踪" }

LLM 路由的死穴是高并发：QPS 50 时平均延迟 280ms 还行，QPS 200 时已经到 820ms，QPS 500 时超时率 > 15%。而 Embedding 分类器同等场景下 QPS 500 延迟只有 45ms。

决策口诀：新意图快速上线 + 模糊语义 + 流量 < 1k QPS → LLM 自路由

---

06 分层架构：生产环境的组合拳

五种方案不是互斥的，而是分层叠加的。生产环境永远用分层，把 80% 流量在 Layer 1/2 拦截，只放 10% 给 LLM：

// layered-intent-recognizer.ts/** * 四层漏斗： * Layer 1: 关键词    < 1ms   命中 ~35% * Layer 2: 规则引擎  1~5ms  命中 ~20% * Layer 3: Embedding 30~80ms 命中 ~35% * Layer 4: LLM 兜底  400~800ms 命中 ~10% */classLayeredIntentRecognizerasyncrecognizetextstringPromiseintentstringlayernumberconstmatchKeywordIntentifreturnintentlayer1constmatchRuleifreturnintentlayer2constawaitthisembCLFclassifyifintentscore0.75returnintentintentlayer3constawaitllmRoutereturnintentintentlayer4

分层后实测收益（客服系统，日均 10 万次请求）：

指标	纯 LLM 方案	分层方案
月均 API 费用	~8 万元	~3000 元
平均延迟	800ms	60ms
P99 延迟	2100ms	280ms
准确率	94%	93%（基本持平）

监控建议： Layer 4 命中率 > 20% 时，把热点意图下沉到 Layer 3 的示例库中。不要等到崩了再改架构。

---

07 常见坑：那些把系统搞崩的决策失误

坑 1：全量 LLM，流量一高就崩

见过最多的错误。开发时日均 1000 请求没问题，上线后流量翻 100 倍，费用和延迟双双爆炸。先建分层，再把热点意图逐步下沉。

坑 2：Embedding 示例质量比数量更重要

50 条杂乱示例 → 80% 准确率；8 条精心挑选示例 → 91% 准确率。少而精 > 多而杂，示例要覆盖边界 case，而不是重复说同一件事。

坑 3：忘记处理"意图缺失"（Out-of-Scope）

分类器强行拉到最近的意图，用户说了业务外的话，回复驴唇不对马嘴。解法：每个分类器都加置信度输出，低于阈值返回 out_of_scope，触发 fallback 到 LLM 或人工。

坑 4：LLM 路由 prompt 太宽泛

意图描述里的「不包括」比「包括」更重要。complaint: 用户不满意太泛，要写成：complaint: 用户明确表达对产品/服务的负面评价；【不包括】询问使用方法时的困惑。

坑 5：一级和二级意图用同一套方案

一级意图（查订单 vs 退款）用 Layer 1/2 就够了。二级意图（查订单 → 查物流/改地址/催发货）需要语义理解。分层架构里也要再分层——粗粒度快速分，细粒度精准分。

---

总结

这篇我们把意图识别的五种方案从头到尾拆解了一遍：

• 关键词匹配是第一道门：< 1ms，先把 30% 的高频确定意图在这里拦住，别嫌它土
• 规则引擎补口语盲区：意图 < 20 个时的最优解，组合逻辑 + 否定条件让覆盖率翻倍
• Embedding 分类器是分水岭：5 条示例就能上线，语义泛化解锁所有口语变体
• 小模型 Fine-tune 是生产主力：数据够了就上，10 倍速度、50% 成本优势，封装成 Runnable 无缝接入 LangGraph
• 分层架构才是最终答案：把 80% 流量在 Layer 1/2 拦截，LLM 只做最后 10% 的兜底，费用降 97%

学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%免费】