因为我最近在一个在线协作平台做了个 AI 助手让团队用自然语言管项目。比如帮张三建个任务、这个迭代进度怎么样、哪些需求延期了系统听懂后就自动执行。做到现在57 个意图7 个业务域准确率从 86% 干到了 97%。这篇文章是我从头到尾踩过的坑和改过的方案。第一阶段把所有希望寄托在一个 prompt 上最初的方案很直接。把所有意图的名称和描述塞进一个 prompt让 LLM 返回匹配结果。一个 prompt 同时做三件事识别意图、提取参数、输出置信度。实际跑起来两个问题立刻暴露。慢。50 多个意图的完整描述塞进 prompt大概 5000 tokenLLM 每次调用 3 到 4 秒。对话系统的用户期望秒级响应等不了。不准。选项太多LLM 经常在语义相近的意图之间漂移用户说任务情况它可能匹配到客户查询、工作记录、数据统计中的任何一个。我把 50 多个意图按用户心智模型划成 7 个语义域项目、任务、资源、迭代、团队、通知、数据每个域配一组关键词。用户输入先过关键词匹配确定落在哪一两个域只把该域的 5 到 10 个意图送进 LLM。同时把 prompt 格式从多行描述改成单行紧凑格式每个意图从大概 100 token 压到 40 token。再把意图识别模型从通用推理模型换成速度更快的轻量模型。效果立竿见影。延迟从 3 到 4 秒降到 0.5 到 1.2 秒准确率也涨了候选少了LLM 更容易选对。但这带了新问题。第二阶段域预筛选从 3s 降到 0.5s但漏词是无底洞域预筛选靠关键词而关键词永远不够全。每次联调都能发现新漏词。进度这个高频词我没放进任何域的词库任务情况、工作记录全部匹配失败。今天团队进度怎么样没命中数据域也没命中任何任务锚点走了闲聊。完成率在数据域的词库里但不在任务型意图的锚点里经营报告任务没被注入候选。除了漏词还有误伤。我设了怎么操作、怎么做这些关键词匹配操作指南类意图。结果下个迭代怎么提效率被怎么做三个字命中路由到了操作指南检索但这明明是个经营策略问题不是系统操作教学。我搞了三层防御。负向排除给容易误伤的关键词加排除模式怎么做命中操作指南但怎么做能、怎么做才能这种模式排除掉。多域叠加一个关键词可以命中多个域取并集进度同时指向迭代域和数据域。全量兜底如果没有任何域命中不拒绝用全量意图压缩格式做一次识别宁可慢一点也不漏掉。但说实话这只是在打补丁。关键词方案的上限就在那里能解决 70% 的路由问题剩下 30% 需要语义理解。这个认知为后面的 embedding 通道埋下了种子。回头看这个阶段最重要的收获不是关键词怎么配而是意识到基于规则的召回和基于语义的理解是两种根本不同的能力。后来的双通道架构起点就在这里。第三阶段架构分层让 LLM 只做理解代码做决策做了域预筛选之后准确率提升了但一类问题始终解决不好LLM 同时做理解和决策两者逻辑互相打架。具体来说我的 prompt 要求 LLM 做三件事识别涉及哪些意图做 NLU给出置信度低于 0.6 就走闲聊做路由决策判断是单意图还是多意图需要编排做编排决策。结果很糟糕。置信度是个坑。LLM 对任务型意图利润分析、热销排行经常给 0.4 到 0.5 的置信度不是没识别到是对自己不确定。但我的阈值 0.6 把它们全拦掉了一个阈值干掉了一半的任务路由。多意图检测不稳定用户说建个项目再拉个群聊LLM 应该识别出两个意图但它经常直接匹配第一个把第二个吃掉。业务判例越堆越多。为了修单个 case我往 prompt 里加规则任务情况转数据、创建活动不匹配查询、入库和出库不要混淆。prompt 从 10 行规则膨胀到 40 行每修一个 case 可能引入两个 regression。就是在用自然语言写 if-else。核心改法很简单LLM 只做语言理解路由决策交给代码。旧流程是 LLM 直接输出路由结果和编排判断。新流程里 LLM 只输出这句话涉及哪些意图代码根据 len(intents) 做编排根据结构化评分做路由。具体改了三件事。Prompt 瘦身删掉全部业务判例规则从 40 行砍到 5 行。LLM 只需要输出这句话涉及哪些意图不需要做任何路由判断。结构校验层在 LLM 输出之后路由之前加一层确定性校验。每个意图预先声明它的动词类型query、write、report、analyze和参数语义模式人名、手机号、金额、日期。代码根据声明做评分排序score 必填覆盖乘以 0.50 加 参数模式匹配乘以 0.30 加 动词匹配乘以 0.15 加 LLM 置信度乘以 0.05。注意 LLM 置信度只占 5%。主决策靠结构化信号LLM 置信度降到微调级别。四态裁决CLEAR唯一候选或分差明显直接执行AMBIGUOUS多候选分差小追问用户或编排INSUFFICIENT候选确定但缺参数槽位追问REJECTED全部淘汰域引导拒绝或闲聊。这一步改完之后prompt 里的业务判例全清了但识别准确率反而提升了因为原来那些规则本来就互相打架。我后来把这阶段总结成一条原则系统中规则的唯一合法形式是结构化规则基于 schema、类型、模式的判断。在 prompt 里用自然语言写的业务判例说到底就是不可维护的 if-else。如果你正在准备简历或面试需要简历优化、面试辅导或者求职陪跑可以在置顶动态找我。前端、后端、AI 全栈、AI Agent 应用开发这几个方向都可以。第四阶段问题分流不是所有输入都该进意图匹配架构分层之后意图匹配链路本身稳定了很多但一类问题暴露了有些用户输入压根不该进入意图匹配。三个典型 case。建项目怎么操作被匹配到了建任务意图缺参数开始追问任务ID和金额但用户想问的是怎么操作系统不是要执行建任务。下个迭代怎么提效率被匹配到了利润分析任务或操作指南但这是个经营策略问题。分析一下被匹配到了经营策略建议但用户刚查了某个客户的详情说的是分析这个客户。这三个问题的共同点是它们需要在意图匹配之前先回答一个更基本的问题这是不是一个技能问题。在意图识别之前加一层 Problem Type 预分类把用户输入先分成五类。ACTION明确执行动作如帮张三建个项目QUERY明确查数据如查一下这个迭代进度GUIDE问系统怎么操作如建项目怎么操作STRATEGY问经营建议如下个迭代怎么提效率CHAT闲聊如你好。分类器两步走先用规则关键词加模式匹配规则不确定时才调一次轻量 LLM不注入意图列表只判断问题类型。这样操作教学和经营策略在入口就被分流了不再和业务意图竞争。这一步揭示了一个容易被忽视的前提不是所有用户输入都适合走意图路由。强结构任务如建任务发货适合弱结构查询如分析数据适合但需要更强的推理开放问题如经营策略操作教学根本不该进入意图竞争。先判断这是不是一个意图问题比匹配哪个意图更重要。但 case 3 分析一下还没解决。单看这四个字Problem Type 判定为 STRATEGY 完全合理。问题在于它不感知对话上下文。所以又加了一层上下文拼装在分类之前先检查对话中是否有刚解析的实体比如刚查了某个项目。如果有把实体信息拼入分类输入分析一下变成分析一下某个项目Problem Type 就能正确判定为 QUERY。第五阶段三模型对比发现单模型天花板做了上面所有优化之后我决定用数据说话。写了 104 条标注路由 case覆盖正向匹配、边界表达、混淆干扰三类跑了三个不同能力等级的 LLM。轻量快速模型准确率 80.8%平均延迟 2.2 秒。中等均衡模型准确率 82.7%延迟 6.0 秒。强力推理模型准确率 86.5%延迟 15.1 秒。三个关键发现。中等模型性价比极低。比轻量模型只提高 1.9%延迟翻了 2.7 倍。意图识别不需要强推理能力用贵模型是浪费。数据分析域是最大的失败点。轻量模型在分析域只有 47% 的准确率强力模型有 87%。利润分析、热销排行、延期预警这类任务型意图需要 LLM 做语义归纳推理简单的关键词匹配和模式识别不够用。没有一个模型突破 87%。27 条不同的失败 case 中只有 4 条是三模型共同失败的也就是说 73% 的失败是模型特异的。每个模型有自己擅长和不擅长的场景。也就是说如果能让不同能力互补准确率应该能显著提升。把失败 case 按根因分类发现了五种模式。任务型意图被误判为闲聊占大约六成LLM 给低置信度被阈值拦掉。短词命令被误判为操作指南占大约一成五规则层过早拦截LLM 没机会处理。跨域语义歧义占大约一成。口语化表达不识别调个期、人够不够占大约一成。歧义误判为多意图占大约半成查一下这个任务被当成 8 步编排。占比最大的前两类说到底也是同一个问题单通道方案的天花板到了。纯 LLM 方案语义推理强但置信度不稳定对短词和口语表达识别弱。如果换成纯 embedding 方案关键词匹配好但间接表达不行这个任务取消掉匹配不到取消订单。这直接指向了最终方案。第六阶段双通道融合突破天花板我把最终方案总结为三层Intent Resolution Recall 召回加 Reasoning 推理加 Ranking 排序。Recall 从候选池中快速找出可能相关的意图用 embedding 向量检索。Reasoning 对候选做语义推理和消歧LLM 在意图树上推理遍历。Ranking 多信号融合评分输出最终判决alpha 加权排序加三态决策。这个结构不只适用于意图识别。RAG 里的文档选择、Agent 里的工具选择、推荐系统里的候选排序说到底都是同一个问题多信号转统一评分再排序决策。只是每个场景的 Recall 和 Reasoning 实现不同。在意图识别这个具体场景下Embedding 做 Recall 和 LLM 做 Reasoning 各有优劣互补性极强。用户说取消订单纯 Embedding 能命中 cancel_task纯 LLM 也能命中。用户说这个任务取消掉纯 Embedding 匹配不到纯 LLM 能命中 cancel_task。用户说今天团队进度怎么样纯 Embedding 走到 query_revenue纯 LLM 走到 daily_report。用户说什么卖得最好纯 Embedding 走到 query_product纯 LLM 走到 hot_selling。两个通道并行执行结果融合为三态判决。Embedding 通道 5 到 15 毫秒跑完意图树推理通道走 LLM 调用两个并行。融合评分 final alpha 乘以 embedding_score 加 (1 减 alpha) 乘以 tree_score。通道一用 sentence-transformer 模型bge-small 系列大概 95MB将用户消息和每个意图的描述编码为向量cosine similarity 排序取 top-K。速度极快关键词匹配好但间接表达不行。通道二受 VectifyAI 的 PageIndex 框架启发将意图识别建模为 LLM 在层级树上的推理遍历。不是把 50 个意图平铺给 LLM而是构建一棵按语义域分组的树。项目管理下面挂 check_task、create_task、task_analysis经营分析下面挂 daily_report、profit_analysis、hot_selling。LLM 用 CoT 推理先判断属于哪个域再在域内精确匹配。语义推理强但依赖 LLM 可用性和响应速度。这棵意图树就是一个轻量的语义知识图谱domain 是上层语义聚类intent 是节点tree_text 定义的不只是这个意图是什么更关键的是它不是什么通过描述与相邻意图的边界给 LLM 提供了推理路径。这和传统的 flat list 分类有区别。生产中最核心的一个 insight一段描述不可能同时对 embedding 和 LLM 都最优。一个意图需要配两段文本。embed_text 面向 embedding关键词密集同义词丰富喂给 embedding 模型用户实际会说的话热销排行, 做得最多, 高频任务, 什么任务多, 爆款, 经常做。tree_text 面向 LLM描述性强含消歧提示告诉 LLM 这个意图是什么以及不是什么用户想看任务完成排行区分查完成率走 daily_report查成员效率走 staff_commission。在 104 条标注 case 上做网格搜索找最优参数。alpha 最优值 0.10embedding 权重极低意图树推理主导。delta 最优值 0.10Top1 和 Top2 差距阈值低于此值判定为歧义。alpha 为什么是 0.10在我当前的数据集上 57 个意图LLM 推理能 cover 大多数场景embedding 更多是召回安全网的角色。但这个比例不是普适的如果意图数量增长到 200 加或者扩展到多行业、多语言场景LLM 会逐渐力不从心embedding 作为语义空间召回的主力价值会显现。alpha 应该随着系统规模动态调整所以我把标定工具做成了开源库的一部分。三态判决不做二选一的强制路由承认不确定性。CLEARTop1 领先明显直接路由。AMBIGUOUSTop1 和 Top2 接近执行 Top1暗示 Top2不烦用户追问在结果末尾附一句如果想看某某也可以告诉我。LOW全部得分低降级到闲聊或引导搜索。单通道降级LLM 挂了 embedding 仍然工作embedding 出错 LLM 仍然能推理两个都挂走 LOW。融合和参数提取并行进行不增加额外延迟。生产环境的成本控制这里需要专门说一下成本。双通道融合建好之后我很快意识到一个问题ToB 场景里用户表达高度重复。帮张三建个项目、查一下这个迭代进度、哪些任务延期了这类表达每天出现几十上百次每次都走一遍 embedding 加 LLM 推理纯属浪费。加了三级缓存。第一级完全匹配缓存。用户输入跟历史请求完全一致0 毫秒返回命中率大概 15 到 20 个点。第二级embedding 近似缓存。用 cosine similarity 找最近的已解析请求相似度 0.95 以上直接复用命中率大概 30 到 35 个点。第三级才是 LLM 推理。前两级都 miss 了才走 LLM而且 LLM 返回的结果也会写回缓存。加上这套缓存之后实际走 LLM 的请求占比降到了不到 40%。还有一个容易被忽略的点域预筛选用的关键词匹配就是传统 NLP正则、模式、高频词。问题分流那步的规则分类器也是。这些技术在整个链路里承担了前置过滤和快速路由的工作高频表达走规则秒回低频长尾才上 LLM。不是什么先搭好 LLM 舞台再挂传统 NLP 装饰而是从一开始就是 waterfall 结构便宜的规则和 embedding 先跑不确定的才上贵的 LLM。最终成绩与剩余问题逐阶段演进单模型基线 104 条准确率 80.8%双通道融合初版 104 条准确率 87.5%加了 6.7 个点意图树补上了任务型识别双通道融合加口语优化扩展到 140 条准确率 97.1%加了 9.6 个点embed_text 覆盖口语加编排检测修复。数据分析域变化最大从单模型最差的 47% 干到了满分。单模型轻量 47%7 对 15单模型强力 87%13 对 15双通道融合扩展集 100%21 对 21。140 条扩展回归中剩 4 条失败全部是含指代词的短句那个任务排多久需要上下文才知道指什么把这个任务调个期需要上下文这个任务不做了先归档需要上下文那个需求评审了没需要上下文。结论剩余失败全部属于对话上下文层的职责范围意图识别层本身已无系统性短板。为什么这是一个通用结构写完这个系统之后我试着从更抽象的角度理解为什么双通道融合有效。核心原因是用户输入是不完整、不确定的信息。而不同方法的区别在于如何利用这些信息。纯规则信息利用率低但确定性高。纯 embedding利用表层语义但缺乏推理能力。纯 LLM推理能力强但稳定性差。单一方法都是对输入信息的单视角解释因此一定存在盲区。而 Recall 加 Reasoning 加 Ranking 的结构我理解成Recall 从不同视角尽可能保留信息不遗漏可能性Reasoning 对候选进行语义推理补全隐含信息Ranking 在多信号下做一致性决策选择最优解释。这个结构的关键不是具体实现embedding 还是 BM25LLM 还是规则引擎而是通过多信号融合最大化信息利用率同时控制不确定性。所以它不只适用于意图识别也适用于其他需要在不完整信息下选最优解释的场景。RAG 文档选择Recall 候选文档转 Reasoning 判断相关性转 Ranking 排序。Agent 工具选择Recall 可用工具转 Reasoning 判断可行性转 Ranking 决策。推荐系统Recall 候选集转 Reasoning 用户意图转 Ranking 精排。沉淀的设计原则最后把踩坑过程中最值得带走的几条总结一下。LLM 只做理解代码做决策。让 LLM 告诉你用户消息涉及哪些意图代码决定路由策略。不要让 LLM 同时做 NLU 加路由加编排判断。不要把 LLM 的 confidence 当硬开关。LLM 置信度是不稳定的主观信号。用它做弱参考5% 权重不要用它做路由阈值。用结构化信号必填参数覆盖率、动词匹配、参数模式做主决策。一段描述不可能同时对两个通道最优。embedding 需要关键词密集的同义词集合LLM 需要描述性强且含消歧提示的自然语言。独立维护 embed_text 和 tree_text。先判断问题类型再挑具体意图。操作教学、经营策略、数据查询、执行动作这些是不同类型的问题不应该在同一条链路里竞争。不要低估短句和口语的破坏力。用户不会按你的意图描述说话。调个期、人够不够、最近啥项目赶这些口语化表达必须在 embed_text 中显式覆盖。歧义和多意图是两件事。查一下这个任务是歧义同实体多种查询方式不是多意图如建项目加拉群。歧义选最优多意图走编排。很多识别错误不是识别层的错。可能是缺上下文分析一下不知道分析谁可能是缺对话状态管理好的不知道是接受提议还是新话题。归因到意图识别之前先检查上下游。缓存不是锦上添花是第一天就该设计的东西。ToB 场景里用户表达高度重复完全匹配缓存的命中率比你想象的高。我后悔没在第一阶段就加上。单一信号一定有盲区多信号融合才是出路。embedding 和 LLM 各有擅长和不擅长的场景没有一个能覆盖全部 case。与其追求单一方案的完美不如让多个不完美的信号互相补位。第七阶段扔掉意图这个词写完上面这些之后我遇到了一条让我重新审视整个方案的评论。原话是意图是个过时的概念了不要在 LLM 上用 BERT 时代的东西。我当时回了一段关于阶段选择的解释但那几天脑子里一直在转这件事。后来想明白了他说得对。我做的这套系统从第一天起就叫意图识别但实际上做的事情从头到尾都是工具路由。用户说帮张三建个项目系统不是要把它分到取消任务这个类别里而是要决定调哪个 API、传什么参数。这个区别不是咬文嚼字。意图分类和工具路由在 BERT 时代可以是同一件事因为在那个范式下你能做的就是把文本映射到预定义标签。但在 LLM 时代这两个是不同的问题。所以我把整个系统重新审视了一遍发现其实不需要改什么架构。双通道融合里的 embedding 通道原来召回的是意图候选现在召回的是工具候选。意图树推理通道原来 LLM 在意图树上遍历现在在工具树上遍历。融合评分、三态判决、缓存、waterfall全部复用。变的只有一件事定义方式。原来定义意图IntentEntry(namecreate_task,domain项目管理,embed_text建任务, 排期, 分配, 创建任务, 帮我建,tree_text用户想给某个客户创建任务。区分查任务→check_task取消任务→cancel_task,)现在定义工具ToolEntry(namecreate_task,description给指定成员创建任务需要成员信息和排期,parameters{customer_name:{type:string,description:客户名称},timeline:{type:string,description:排期时间},},embed_text建任务, 排期, 分配, 创建任务, 帮我建,tree_text用户想给某个客户创建任务。区分查任务→check_task取消任务→cancel_task,)多了参数 schemaLLM 不仅能选工具还能直接填参数。参数提取那一步不用单独跑一次 LLM 了工具选择的时候顺手把参数带出来。这个改动的实际收益比想象的大。第一加新能力变简单了。原来加一个意图要纠结放哪个域、跟哪些意图语义冲突、embed_text 够不够全。现在加一个工具就是写一段描述加参数 schemaLLM 自己判断适用范围。第二长尾表达覆盖更好。原来总有口语化表达匹配不到对应意图因为你怎么定义都定义不全。现在 LLM 看了工具描述自己推理这个工具能不能处理这句话。不需要你预判所有说法。第三跨域问题自然解决。原来的架构里一个意图只能属于一个域但现实中有很多跨域表达。比如帮我分析一下这个项目的进度然后给出建议涉及项目查询、进度分析、任务推荐三个域三个工具。用工具路由的话 LLM 直接返回三个 tool_call编排层串起来执行不需要在意图层纠结分类。关键洞察是这六个阶段搭起来的架构双通道融合、三态判决、缓存 waterfall、结构化校验这些不是意图识别专用架构。它们是通用的选择加路由架构。把被选择的对象从意图换成工具整个系统零改动就能跑。所以我在 intent-fusion 里加了一个 ToolRouter 模式。用法几乎一样from intent_fusion import ToolRouter,ToolEntry tools[ToolEntry(namecreate_task,description给指定成员创建任务,parameters{...},embed_text建任务, 排期, 分配, 帮我建,tree_text创建任务。区分查任务→check_task取消任务→cancel_task,),]routerToolRouter(tools)resultawait router.fuse(帮张三建个项目,your_llm)#result.selected_tool →cancel_task#result.parameters →{order_id:xxx}回头看这个演进路径其实是必然的。意图识别是 BERT 时代留下的思维惯性先分类再执行。LLM 时代应该直接映射到执行。但搭建这套映射系统需要的工程能力召回、推理、排序、缓存、降级跟我前面六个阶段积累的东西完全重合。所以如果你现在从零开始做类似的事我建议直接上工具路由跳过意图识别这一步。但如果你已经有一套意图识别系统在跑迁移成本很低把意图定义改成工具定义加参数 schema其他不动。学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%免费】