工业级Agent意图识别分层漏斗上个月我把公司那条线上意图识别服务拆了重做原因很简单直接用大模型做意图识别Demo里效果惊艳一上生产就原形毕露——延迟不稳定、token成本按天翻倍、半夜还会来几个莫名其妙的误判。后来我在内部把整个方案换成了分层漏斗这套思路把Agent的意图识别从一个黑盒大模型调用拆成了规则缓存、召回匹配、模型判别、兜底回流四个层级线上稳定性和成本效率都有了质的改善。这篇把整个设计思路、实现细节和踩过的坑完整记录下来希望给正在做Agent意图识别、或者准备把LLM能力往生产环境推的朋友一些参考。这套方案的核心价值在于意图识别不是选一个最强模型把活全干了而是让每一层只做自己最擅长的事模糊地带逐级下放最后再用低成本兜底把漏网之鱼收回来。听起来像是架构层面的老生常谈但真正落地时你会发现每一层的边界划分、阈值设定、数据回流都藏着大量细节。下面我从为什么必须拆分开始逐层拆解漏斗的设计。1. 为什么单一的意图识别方案撑不住生产环境1.1 一次真实的线上事故模型漂移与成本失控我们的业务是一个ToB的Agent服务用户通过自然语言向Agent发指令Agent需要判断指令的意图再决定调用哪个工具、走哪条流程。第一版方案很简单粗暴把用户输入拼上历史会话直接丢给GPT-4级别的通用大模型让它在预设的二十多个意图枚举值里选一个同时输出对应的置信度。联调和内测期间效果确实能到95%以上的准确率但一上生产问题接踵而至。首先是延迟波动。大模型推理存在排队效应高峰期P99延迟能从800毫秒飙到3.5秒。对Agent来说用户发完消息后如果三秒没反应后续的交互节奏就全乱了。其次是成本我们每天的请求量在百万级一个基于图片的token计费方案算下来每个月仅意图识别这一项就是六位数起步。最要命的是漂移问题——用户表达习惯随时间变化运营又不断往Agent里加新功能意图列表其实是动态的但模型是静态的于是总有一部分请求被硬生生归到最相似的错误类别里还自信地给出98%的置信度。当时我的结论是单一大模型不适合承载工业级意图识别这个高频、低延迟、强稳定性的场景。这个判断和模型效果无关纯粹是工程问题——你不能用一门重炮解决所有战术任务该用手枪的时候用手枪该用狙击枪的时候用狙击枪该让观察员先判断敌情的时候就别急着开火。1.2 单模型方案的三个死穴我把自己踩过的坑归纳成三个维度的死穴这也是后来设计分层漏斗时反复对照的原始问题清单。成本不可控。如果每个请求都走大模型哪怕只是PassThrough一次路由判断也要付首token和输出token的全额。更隐蔽的是大模型输出不稳定导致结果重试率很高一次判断失败你的客户系统可能会自动重发成本直接翻倍。我们在高峰期统计过带重试逻辑的意图判断请求占总请求的17%光重试费用就占了意图识别总成本的近三成。可观测性和可调试性太差。大模型给出的意图判断往往缺乏可解释的推理链路出了问题你没法像看代码一样逐步定位。曾经有个客户反馈你们的Agent把我今天要做的事理解成另一个部门的任务了我翻日志查了半小时只能看到Prompt里有用户的整段描述和模型返回的结果中间到底哪句话权重更高、哪个上下文信息被忽略了完全是黑盒。黑盒问题不解决你就永远只能靠运气调Prompt。置信度失真。即便你在Prompt里要求模型输出confidence这个置信度也是校准不准确的。大型模型在自身知识边界内给出高置信度的概率本来就高真正遇到OODOut-of-Distribution输入时它的高置信度恰恰是最危险的——因为它会用最熟悉的知识来强行适配陌生输入。生产系统如果只凭模型自信程度做护栏必然崩溃。1.3 工业级意图识别的真实约束条件前面那三个死穴本质上揭示了一个现实工业级意图识别要同时满足四个互相矛盾的约束——准确率要够高、延迟要够低、成本要可控、决策要可解释。这四个目标在单模型架构下几乎不可能同时达成。你上大模型就牺牲成本和延迟上小模型就牺牲准确率上规则系统就牺牲覆盖率。所以我们必须换一个思路把目标拆解到不同粒度的处理层让每一层只优化一部分约束最后通过漏斗结构把整体指标拉回可接受范围。我的经验是做这个决策时要敢于打破技术洁癖。很多算法同学会觉得意图识别就该是一个端到端模型分层了就不先进了。但生产系统要的是组合收益不是单一模型指标。分层漏斗本质上是用架构手段做算力分层分治这在传统服务端架构里非常常见只是到了LLM时代被很多团队忽略了。2. 意图识别分层漏斗的整体设计与核心逻辑2.1 先理解漏斗的运作机制层层放行而非层层拦截我见过很多文章把漏斗理解成多级过滤器每一层都用严格的方式拒绝一批请求最后剩下最难的就交给大模型。这个理解是错的。工业级漏斗的正确语义是层层放行模糊下放每一层只拦截自己明确能解决的部分自己不确定的部分直接放给下一层而不是在每层设置一个拒绝动作。举个例子第一层规则引擎是精确匹配查余额转账支付账单这类高频意图它只输出两种结果命中或跳过。命中就直接返回跳过则往下一层送。到了召回层同样如此它会对用户输入算相似度、做候选排序对Top1候选的相似度超过0.92的请求直接给结果低于这个阈值的全部放行给大模型层。这样每一层都在把明确的东西提前消化模糊的、复杂的、边界的情况最终汇聚到大模型层做综合判断而不是每一层都砍一刀。这种设计的核心收益在于响应分布80%的常见请求在两层内结束延迟在50毫秒以内成本几乎为零剩下20%才需要模型或大模型兜底。真正落到大模型层的其实只有约5%-10%的流量但这个比例可控、可预算成本曲线就变得平滑了。2.2 四层漏斗的总体架构与数据流转我实现的这套漏斗一共四层层级名称核心手段适用场景预期延迟预期调用成本L1规则与缓存层精确匹配、正则表达式、历史意图缓存高频固定表达、重复请求、模板化指令 10ms内存/Redis开销L2召回匹配层向量相似度、轻量文本分类模型常见表达变体、近义改写20-60ms小模型推理/向量检索成本L3大模型理解层通用LLM或领域微调模型复杂上下文、跨领域歧义、OOD输入500-3000ms大模型Token成本L4兜底与回流层默认策略、人工标注、Badcase挖掘新意图发现、未知输入、低置信度歧义异步处理人工定时任务数据在层与层之间流转时每一层必须明确输出三类信息命中或未命中、置信度或相似度分数、供下一层使用的上下文摘要。这个上下文摘要很关键——因为到了L3大模型层你不能再丢整段原始输入而是要把对话历史、候选意图、用户的近期操作路径压缩成一份精炼的上下文让大模型做仲裁者而不是做第一判断人。整个漏斗还有一个配套的决策横向旁路就是每层都会写入统一的Trace日志包含输入、命中结果、分数、跳转到下一层的原因、下一层的最终决策。这样任何一个请求的意图识别链路都是可以回放、可以审计的这更是后面做评测集和Badcase回流的基础。2.3 为什么要用大模型后置而不是大模型前置有些人会觉得既然大模型效果最好那就先让大模型判断判断不了再降级到规则。我强烈反对这种顺序原因有三个。第一是成本和质量的性价比错位。大模型判断大多数高频简单请求是一种浪费如果你先调大模型再走规则那么你为那80%的简单请求付了大模型的费用这完全没有任何工程美感。第二是错误传染路径。大模型如果在前置阶段产生错误判断后续规则和查询阶段往往会沿着错误方向做搜寻导致最终结果的错误被包装得更加自信。第三是可回退性。当大模型服务出现故障时比如上游限流、超时前置方案会直接导致整个系统崩溃但后置方案只是让L3层暂时断开L1和L2依然能覆盖大部分请求。有一次我们上游模型供应商机房故障大模型服务整体不可用。因为漏斗设计的顺序L1规则层和L2匹配层照常工作系统瞬间自动把大模型层降级为一个基于历史会话缓存的最近意图猜测逻辑。那一段时间线上整体功能可用率只下降了3个百分点而不是崩溃。这就是后置架构的实际价值。2.4 漏斗精神与Agent记忆、Agent安全的关系分层漏斗不应该孤立存在它天然要和Agent系统里的两个模块耦合记忆模块和安全模块。记忆模块可以给漏斗提供用户级意图热点。比如某个用户连续五次都在查订单物流那么L1缓存层应该针对这个用户动态增加一个高优先级意图记录直接把查物流的常用表述模板热加载进去让第六次请求直接命中。这一层记忆我不建议做得太重简单的LRU热点意图缓存就够了不需要把记忆向量化塞进大模型上下文——那会让简单问题复杂化。安全模块放在L3和L4之间尤为重要。当大模型判断出一个意图后在执行之前需要对照权限策略做一次强制校验。比如删除用户数据这个意图在模型层识别出来后不能直接放行给工具执行需要经过安全策略引擎查询该用户权限、操作范围、是否二次确认。安全策略必须是独立于意图识别之外的旁路否则一旦意图识别被提示词注入绕过Agent的安全防线就跟着失效了。3. 分层漏斗各层的实现细节与工程化要点3.1 第一层L1先别急着上模型把确定性的活先干完L1层的目标就是快、省、稳。具体的实现我拆成三个子模块。高频意图规则库。从线上历史日志里拉起过去30天内的意图分布数据找到每天调用量超过1000次的意图模板。对查天气查余额打开日程这类意图直接由模板匹配完成。这里有个关键细节写规则时不要把正则写得过死要考虑用户的自然语言变体。比如帮我看看明天的天气和明天穿什么衣服合适在语义上都是查天气但正则很难覆盖后者。所以我这个层只锁死动词名词明确对象的强规则比如查|看|查询|显示天气凡是规则匹配不了但高频的请求宁可放到下一层也不要强行用宽松正则去磕。用户级短时缓存。同一用户短时间内重复发相同/相似指令是常态。我们做了一个意图缓存key是用户ID语义Hash对输入做归一化后的字符串的Hashvalue是意图ID、缓存时间戳和上下文摘要。用户三次内重复同一请求直接命中缓存过期时间设成5分钟。这里要特别小心时效性如果用户第一次问今天天气第二次问明天天气二者的归一化文本不同不会误中缓存但如果用户第一次说帮我订明天早上9点的会议室5分钟内又说改成10点这时候你不能直接命中缓存返回订会议室因为你丢失了改成这个修正意图。所以缓存必须带一个意图变体识别的防御逻辑当新输入与缓存输入相似但不完全相同且其中包含意图关键词订、改、删、取消时强制让缓存失效并下沉到下一层。完全未知意图的快路径拒绝。对于一些明显超出Agent能力的请求例如帮我写一首诗在纯工具型Agent里就没法处理规则层直接返回意图不支持不进后面的模型层省掉所有后续开销。但快路径拒绝的目标要设置得非常保守宁可不拒绝也不能错杀。3.2 第二层L2用轻量模型做候选召回把大模型的负担降到最低L2层是整个漏斗的性能核心设计得好能让大模型层的流量占比降到个位数。这一层包含两个并行的技术向量召回和轻量文本分类。向量召回。我们把全部的意图描述、意图示例句、工具function文档切块后做成embeddings存进向量数据库。用户请求进来后先做query embedding然后去向量库里检索Top5候选意图。这里有一个我认为最重要的调参技巧余弦相似度的阈值不能设一个统一的全局值而应该按意图类型分别标定。比如查询类意图的表达方式相对固定相似度0.88就可以命中而操作类意图删除、取消、修改因为用户会带入很多具体参数整体相似度天然偏低它的阈值要放到0.82。全局阈值要么导致大量漏判整体偏高要么导致大量误判整体偏低几乎不可能同时满足两类意图的特点。轻量分类模型。向量召回的一个问题是它只看语义相似不抓全局判别信息偶尔会把帮我把日历上的会议移到明天召回到创建会议。所以我在向量召回之上还部署了一个轻量级BERT分类器蒸馏版参数量约10M它把用户输入召回到的Top5候选意图做二分类判别输出该候选意图是否正确。这个模型的训练数据来自线上日志回流的人工标注样本框架用fasttext或者轻量transformers都行推理速度在CPU上不到30ms。这里的好处是模型不是从零开始识别意图而是给候选排序做置信度校准任务简单所以小模型就能胜任。L2层在判断时必须输出候选意图列表、每个候选的召回相似度和分类器打分。如果Top1候选的最终分数大于阈值这个阈值是全局的但每个意图类型可以有调整就直接返回结果否则拼接候选信息和用户原始输入传给L3大模型层。这种召回重排的结构很多人熟悉但从搜索领域搬到意图识别场景时大家容易忽略一点候选意图的数量和顺序要参考上下文而不只是当前输入。比如用户上一轮已经在转账流程中这轮说改5000那么候选列表里修改转账金额应该排在所有其他候选之前。所以L2层的向量检索我维护的是一个全局通用意图索引流程会话态意图索引双索引后者只在会话内生效优先级更高。3.3 第三层L3大模型在漏斗里的定位是仲裁者不是猜测者到达L3层的请求已经满足两个条件L1没命中说明不是高频规则场景、L2的Top1置信度不够说明确实存在语义歧义或者表达不够典型。这时候你再让LLM去识别它面对的是真正的难题但同时它的输入也已经被L2层的召回结果做过锚定不再是无边界自由发挥了。我的L3 Prompt结构会明确规定四部分内容候选意图列表及其对应的置信度、对话历史中的关键上下文由L2提取的意图状态流转而不是原始聊天全文、用户当前输入、以及输出约束只能从候选意图中选择如果认为候选都不对直接输出Unknown并给出原因。这样设计后大模型的幻觉空间被极大压缩——它不再有机会凭空创造意图枚举值只能在我们给出的候选池里选择或弃权。L3层还负责处理一个L2处理不了的场景多意图混合。比如用户说帮我查一下明天的行程顺便订个餐厅这是两个意图。L2召回只能锁一个。L3通过预设的多意图解析模式会把这类请求拆成两个有序意图并标记执行顺序。这个场景的处理逻辑我放在L3而不是L1/L2是因为它天然依赖语义综合理解强行在前两层做只会带来一堆边界case。还有一个不能省的事L3层必须做标定校准。大模型给出的置信度不能直接当真实概率用我们需要做一个经验校准。我们统计了模型输出的置信度区间分布和历史准确率的关系发现0.7-0.8区间的实际准确率只有0.550.8-0.9区间的实际准确率约0.85所以我们在工程上会对模型置信度做一个重映射低于0.8的请求视为低置信度不给最终结果送到L4做兜底或人工。重映射的系数是从两周的线上数据里统计出来的每隔一周重新统计一次保证校准曲线跟得上模型行为漂移。3.4 第四层L4兜底回流不是设计的终点而是数据的起点L4兜底层承担三个职责很多团队把这个层只当成认怂层 这是极大的浪费。第一是合理的默认策略。对于L3识别不出的请求我们不能简单返回无法识别。我建议配备一个基于模板和人工打包匹配的意图需求询问流程——当意图置信度过低时让Agent主动向用户提问缩小范围再回到L2重新召回。例如用户说帮我搞定那个事系统不知道是哪个事就自动追问您说的是删除日程、还是修改会议这个追问模板由L4层生成它不在三个主层里循环判断而是直接引导用户澄清。这样体验比直接报错好了很多实测可以把LowConfidence请求的意图识别成功率提升约25%。第二个职责是新意图挖掘。把L4层接收到的请求和被触发的追问结果定期汇总做聚类分析看是否存在反复出现的新意图表达。比如有这么一批请求用户反复说帮我归档项目但我们的意图枚举值里没有归档项目这个选项。聚类分析会把这条请求聚成一个独立的簇。然后我们每周人工审核一次确认是真实需求就给新意图补充示例句并加入L1规则库或者L2索引。这就是一个让漏斗可持续进化的闭环。第三是Badcase回流入训练集。L3输出错误、L2阈值设置不当、L1规则误命中的case都要自动打标后进入一个待校正数据集。这个数据集定期由标注同学或半自动规则整理成标准格式一部分补充到L2小分类模型的训练样本里一部分更新到L1规则库还有一部分作为L3评测集的负样本。4. 阈值标定、成本核算与整套系统实测效果4.1 置信度阈值背后的统计逻辑和标定方法阈值的设定是整个漏斗里最容易被低估的事情。我见过有人拿拍脑袋的0.9当默认值结果L2层漏掉一半请求L3层流量占比冲上40%成本和延迟全部飙升。阈值不是一个静态值它应该来自一份置信度-准确率-覆盖率的三方联调曲线。我们在两周内随机采集了十万条请求让每一层都对请求打分不截断然后把打分记录下来最后人工标注每条请求的真实意图得到一张分布表。从中就能画出这样一条曲线当L2的分数阈值从0.8调到0.9通过率从35%降到22%但准确率从96%升到98.5%。你要做的就是在准确率和覆盖率之间找平衡点。对于意图识别来说我的经验是宁可多放一点模糊请求到下一步也不要在当前层硬切所以L2我的阈值标在0.85附近对应的单层准确率是97%、通过率是29%。这个数值不是最优解是在成本和准确率之间性价比最高的解。L3的阈值标定更讲究因为大模型的错误代价比小模型要高——它错了之后整个流程会往错误方向执行比不执行还糟糕。所以我们用重映射后的置信度做判定低于0.75直接走L4。这个经验数值在不同模型上会有差异但思路一致大模型层的低置信度结果必须触发人工确认或追问流程不能硬着头皮下发工具调用。4.2 成本与延迟预算的工程测算做工业级系统预算必须建立在可计算的模型之上。拿我们的量级日均约220万次意图识别请求举例L1 规则缓存单请求成本几乎为零延迟中位数5msL2 召回分类单请求成本约0.0005元主要是向量检索和CPU推理延迟中位数约35msL3 大模型层单请求成本约0.03-0.06元取决于输入长度和模型档位延迟中位数约800ms兜底层以上传日志和定时任务为主单独核算。流量占比大概是这样L1命中约48%L2命中约32%L3约占15%L4约5%。综合成本 0.48×0 0.32×0.0005 0.15×(0.03~0.06) 兜底成本。算下来日均意图识别成本大约在几百元人民币量级。如果单一方案全程用大模型日均成本至少是3500元以上。这中间差了近7倍而且大模型的延迟还在高峰期成倍恶化。分层漏斗在这个维度上的收益是决定性的。4.3 线上A/B实验与上线后的指标对比我们上线分层漏斗时做了两周的A/B实验对照组留在旧的单一大模型方案实验组跑漏斗方案。样本为随机分流各覆盖50%的生产流量。最终核心指标如下表所示指标旧方案单一大模型新方案分层漏斗意图识别准确率94.6%96.2%平均首响应延迟1.2s180msP99延迟3.4s620ms日均成本约3600元约600元极端故障降级能力无有L3断开可降级运行准确率提升有一个关键原因分层后L3大模型处理的是L2召回过锚定候选的场景输入更清晰输出限制更严反而比自由枚举的旧方案更少犯错。这说明漏斗不是用一个模型替代另一个模型而是合力提升了每层各自擅长的子任务的能力。4.4 评测集构建与回归防退化任何一个新的分层方案上线后都要防止一个幽灵随着规则层不断加规则、模型层不断精调系统在新数据上越学越偏旧能力反而退化。所以我们在做评测集时定了三条硬规矩。第一评测集必须是分层切片的。单独一套测试集上跑整体准确率没有任何意义出了问题你根本定位不到是哪一层退化。我的做法是给数据集打上标签这些case本来应该由L1命中、这些应该走到L2、这些应该交给L3、这些应该进兜底。每天跑回归时每层只看自己该管的那一批样本任何一层退化都能被迅速发现。第二评测集要包含扰动样本。模型和规则有一个共性问题——对输入顺序和吞吐敏感。把帮我查一下明天的天气改成明天天气帮我查一下在端到端模型上准确率可能会下降几个点。所以评测集里特别要加入这类词序打乱、无语义停顿、口语插词、错别字变体这些都是线上真实环境里每天都在发生的事。很多团队测了标准样本就觉得自己很优秀上线后被口语打回原形问题就出在这。第三新意图加入必须触发全量回归。每当我们要加一个新的意图不是简单往L2向量库里插几条向量就完事。我会专门生成新意图的标准评测样本跑一遍全量回归观察它和现有30多个意图类别之间的混淆度矩阵。比如新增归档项目意图后如果发现它和删除项目的混淆度超过5%那就说明向量库的embedding信息不足以区分这两个语义需要补充意图描述、增加差异化的正负样本到分类器里重新训练。5. 落地过程中最容易踩的坑和最重要的经验5.1 坑一把漏斗做成了多级串行堆叠这是我见过最多人走偏的方向。他们拿着分层漏斗的PPT出去讲但实现的时候就是把规则、小模型、大模型串起来每层做一次全量判断都要自信才放行。这导致的问题是每一层都要精确每一层都会漏漏下去之后下一层又要在没有足够信息的情况下重启判断彻底丢失了前面层的概率特征。漏斗的放行不是拒绝后传递给下一层而是本层处理到它该处理的完整程度把处理过程和置信度一起传给下一层。下一层看到的不应该是未命中三个字而是这个请求和意图X的余弦相似度是0.81分类器得分是0.63候选意图列表中还有Y和Z。信息传递的质量决定了漏斗能不能形成递进放大的效果而不是层层衰减。5.2 坑二只看准确率不评估错误成本的分布意图识别里的错误不是等价的——把删除误判成归档的代价比把查询误判成统计的代价可能高一百倍。单纯拿准确率做调优指标会诱导模型为了刷分而把一些高风险操作意图往安全的低风险意图靠。我们在实际工程里给每个错误样本配了一个损害权重高权重错误包括删除、修改、转账类误判低权重错误包括查询、打开类误判。在评测和阈值调整时我们用的指标是加权错误率而不是平权准确率。L2阈值往高调或者往低调查看的是加权错误率怎么变化这才能真实反映生产环境的风险暴露。而且有一类误差特别容易被忽略意图识别太准导致的体验下降。当一个用户的指令里带点模糊词系统为了准确率强行追问澄清追问次数多了用户就会烦躁。我们用了一个很朴素的平衡方案对高风险的意图删除、修改、支付必须高置信度才执行宁可多问一次对低风险意图查询、翻页、打开哪怕置信度偏低也直接执行。这本质上是把风险成本纳入了意图识别的决策函数里。5.3 坑三忘记给整条漏斗留下逃生通道即使分层漏斗已经做得比较稳生产系统还是要留出两条逃生通道。第一条是面向Agent执行器的逃生通道当L3意图识别和下游工具执行的返回值产生明显冲突时比如识别出查询天气但工具返回的是该技能未开通执行器要反向通知意图识别模块做二轮纠偏而不是认死理。第二条是面向用户的明示逃生通道漏斗无法识别的请求除了追问澄清还应该提供转人工客服或新建工单的出口。不要试图让意图识别系统对100%的输入都有答案真实世界里永远有超出枚举值的需求。留下逃逸出口反而能在体验上把系统做不到的事变成系统诚实但不完美的正面印象。5.4 最有价值的一件事把漏斗对齐到Agent系统规划的高度最后我说说分层漏斗设计和整体Agent架构之间的关系。很多人做Agent的时候意图识别是作为一个一次性判断模块存在的——用户输入进来判别完就转给工具调用完事。但在我做完这套漏斗后最大的体会是漏斗不应该只被理解为意图分类器它其实是Agent系统里一个交互预算分配器和风险分发器。什么意思呢它本质上是把一个模糊的、开放的意图识别问题拆成了四个不同粒度的子问题然后按照成本、延迟、风险三个维度分配处理资源。这和你设计Agent的记忆模块时要决定什么信息放短期记忆、什么放长期记忆、什么向量化、什么结构化是同一个思路。所以当你把意图识别做成漏斗再去设计Agent的记忆、Agent的工具编排、Agent的安全护栏时会发现它们是天然对齐的——都是在不确定信息环境中做多级决策、按资源代价分层处理的模式。如果你正在做一个中大型Agent系统我的建议是别把意图识别当做一个点来优化把它当成一个基础设施来架构。先从规则层和缓存层开始搭哪怕一开始只有两层也要把漏斗的放行信息传递语义定义清楚。然后逐步加入小模型召回、大模型仲裁、兜底回流。每一层的加入都应该带着明确的数据回流计划而不是模型效果不好就加一层的堆叠。这样你的系统会越跑越顺而不是越跑越乱。这套分层漏斗我做完之后回头复盘最想分享的一句话其实是在LLM时代做工程别把所有希望寄托在最强模型上要学着把模型当成一种可以被调度的服务资源该用多少用多少该在哪里用在里用。今天我们做的意图识别是这样明天做Agent编排、Agent安全、Agent记忆进化底层逻辑也还是这样。