AI 意图识别与智能路由，让自动化从按按钮变成说需求
客服群里的消息从来不按流程走。有人写订单号，有人甩截图，有人一句话里夹着时间。这篇讲意图驱动的自动化难在哪，从固定流程切过来要改哪三样东西，意图分类为什么不是越多越好，参数抽取里时间表达和数字口径最容易翻车，置信度为什么不能直接当阈值，以及三层兜底该怎么划。最后写了准确率怎么分层估、失败样本怎么回流，还有哪几种场景不建议上。
早上九点，客服群里堆着三种写法
早上一上班，客服群里就开始进消息。
「麻烦查一下 1024 号订单到哪了。」
「昨天那批货什么时候能发，客户催得厉害。」
「多的那 300 退我。」
同一件事，三个人三种说法。有的人连订单号都懒得打，直接甩一张截图过来。
做自动化的团队看到这儿，通常第一反应是想要个机器人，让它把这些消息分好类，然后自己去系统里查、自己去回。这个想法方向没错，难的地方比想象中靠后。
从按按钮到说需求，中间隔着一道翻译
固定流程的自动化里，人是流程的设计者。每一步点哪里、填什么值，流程里都写死了。人做错了，界面会拦一下，人能看见。
意图驱动换了个位置。人只说一句需求，剩下的交给系统去判断该走哪条分支。判断这件事没有对错标准，它完全由人说的话决定。这道翻译就是 AI 识别用户意图真正要干的活。
大模型意图分类本身并不难。难的是从固定流程切到意图驱动之后，有三样东西要跟着改。
一是流程的组织方式。从一条主干变成一棵分叉树，每条枝上必须有明确的落点，落点说不清的分叉最后都会长成人工。
二是参数的来源。固定流程里参数来自界面输入框，意图驱动里参数要从那句话里抽出来。
三是失败的处理。固定流程做不下去，人会停在原地看提示；意图驱动做不下去，人可能根本不知道系统已经做不下去了。
意图分类不是越多越好
这件事最容易走的方向，就是不断增加类别。看到一句没归过的话就想加一个类，加到后来三四十个。
这时候问题来了，人能分清的和模型分的不是一回事。
有两类词看着不一样，业务上其实是同一件事。「查订单」和「物流到哪了」，最后都要去同一个接口拿数据。分成两个类，参数抽取和流程分支就得写两遍，改一处漏一处。
反过来，两个类看着像，处理路径却完全不同，混在一起才是真麻烦。「退款」和「退货退款」只差两个字，前者只调接口，后者要走质检和仓库。
定类的时候有几个能上手的判断。
先看处理动作。处理动作一样，多半可以合成一个类，后面再在类内区分。处理动作不同，硬合成一个类，类里就要写一堆判断分支，模型也更容易分错。
再看出现频次。一年出现两三次的意图，写进分类表里只会稀释其他类的表现，不如直接让它落到兜底。
还有一条更省事的做法。有些意图干脆不做分类，让它落到默认分支，由人接手。这条分支看着像失败路径，实际用起来往往比硬做一个分类更稳。
参数抽取才是真难点
意图分对了，后面的活才算开始。
用户那句话里能带的信息，往往不够。
「查一下 1024 号订单」有单号，直接用。「昨天那批货什么时候能发」没有单号，得先知道是哪个客户、哪个平台、哪一批。这时候只能反问。
所以意图驱动里面，反问是一等公民，不是失败兜底。设计的时候要明确一个问题最多问几轮，问到第几轮还补不齐就转人工。问三轮还在原地转圈，体验比第一轮就转人工更差。
参数还有几个地方容易翻车。
一是时间的相对表达。「昨天」「上周」「月底」这类，抽取的时候要落到具体日期，不能原样传给下游。跨零点的任务在这里出的错最多。
二是数字的口径。「多的那 300 退我」，这 300 是实付金额还是应退金额，得问清楚，不然退款接口会算错，而且错得很安静。
三是别把敏感信息塞进参数日志。手机号、身份证、银行卡这些，抽出来是为了调用，不是为了留档。
置信度和兜底，三条线要一起画
智能路由怎么做，难点几乎全在兜底上。
模型给每个意图都带一个置信度，这个数不能当真理。它在不同类别上的分布很不均匀，有些类天生就容易被判高。所以别急着定阈值，先攒一批真实数据，看每个类别各自的分布。
兜底通常分三层。
第一层是转人工。用户明确说找不到、说不清楚、要投诉的，立刻转。这一层靠规则，不靠模型。
第二层是转相似流程。模型不确定，但前几名意图接近的，走最近的那条流程，结果要让用户确认一次。这一层能消化掉相当一部分模糊请求。
第三层才是硬转人工。前两层都不成立的时候才走。
还有一种情况比模型判错更麻烦，就是意图判对了但流程跑失败。这时候回给用户的应该是流程出的错，不能说成没听懂。用户点进来是为了办事，不是在做测试。
准确率怎么估，别只看一个总数
评估这一步最容易糊弄过去。
一个总的准确率看着挺好看，拆开全是问题。某一类准确率极低，被其他大类平均掉了，总数上根本看不出来。线上真正影响体验的，恰恰就是那几类。
所以评估至少分三层看。
第一层看分类，按类别分开算，而且要看错去了哪一类。混进相邻类往往比直接判错更难处理，因为流程会拿着错的参数去干活。
第二层看参数抽取，重点看必填参数的填充率。意图对了但订单号没抽出来，用户还是得转人工，前面那一层做得再准也没意义。
第三层看端到端，从收到那句话到业务系统返回结果，有多少是走完的。这个数最能说明问题，也最难看。
评估集要来自真实的线上流量，不要用自己编的句子。口语里的省略、错别字、拿截图代替文字，这些在编出来的测试集里通常不会出现。
失败样本回流，决定这套东西能撑多久
转人工的时候顺手记一笔，成本很低。
用户原话、模型判成了什么、最终人工怎么处理、最终对不对。这四个字段记下来，一个月后就是一份很有价值的样本。
这份样本比重新标注一批语料有用，因为它天然带着后果信息。人工改判的那些，说明模型的判断确实错了；人工只是补了缺的参数，说明分类可能没错，要改的是参数抽取。这两类混在一起，只看准确率是分辨不出来的。
回流之后要做的是把高频失败样本定期并进评估集，并进意图表或者补进规则。这个动作不复杂，但很多团队做着做着就停了，因为没人负责看。停掉的几个月之后，输入分布变了，分类表还是老的，错的还是那几类。
什么情况下别上意图驱动
这套东西有代价，说清楚什么时候不值得付比较好。
流程本来就短，两三步就完了。固定流程配一下半天的事，上了意图驱动反而要养分类、评估、兜底三套东西。
用户量小，一天才来几条消息。样本攒不够，置信度分布看不准，阈值怎么定都是拍的。
请求高度结构化。多数请求本来就带着明确字段，从系统里直接触发的，压根没有自然语言这一层。
错误代价高而且不可回滚。直接动账务、直接改权限的流程，意图判错一次就是一次事故。这种场景先做只读和建议，把动作留给人工确认。
团队里没人愿意维护分类表。意图驱动的准确率全靠这张表养着，没人管的话，它会比固定流程烂得更快。
先跑通一条再说
要做，就别一次铺开。
挑一个请求量大、后果轻、参数清楚的场景，比如查订单或者查物流。这类不涉及资金和权限，做错了也没有不可逆后果。先把分类、抽取、兜底这三块在这一个场景里跑顺。
跑顺的标志不是准确率好看，而是三件事成立。转人工这条路是通的，人工接手时能看到用户原话和模型的判断，接手成本是几秒钟而不是几分钟。失败的样本能回流。兜底规则有人维护。
这三条稳了，再往下一个场景扩。顺序反过来做，先铺十个场景再回头补兜底，通常是十个场景一起烂。
相关的场景落地和选型，前面几篇可以看看。
延伸阅读