意图识别技术拆解：从需求分析到算法落地

前言

#

最近在研究智能客服相关的技术方案，深入梳理之后发现，意图识别这件事远比想象中复杂。它不是一个简单的分类问题，而是一整套从单条 Case 分析到全局体系构建的工程方法论。这篇文章把我的思考整理出来，希望对同样在做对话式产品的朋友有帮助。

意图识别到底是什么

#

先说一个核心观点：意图是目的，不是表达。

举个生活中的例子。朋友约你吃饭，你不想去，说了句"改天吧"。你说的是"改天"，但你的目的是拒绝。如果对方追问"那改到哪天？"，你会觉得这人怎么这么不懂事。你明明是在拒绝，对方却在字面意思上较真。

AI 产品的核心能力，就是根据用户的各种行为数据来推测意图。用户不会按你设计的模板说话，真实的表达往往极度口语化、随意、甚至充满情绪。一条用户消息，可能有四种甚至更多的解读方向，你需要有能力精准判断到底哪一个是正确的。

我把意图分析浓缩成一个公式：

意图分析 = 目的 + 承接动作

这个公式有两层含义。第一，分析意图不是分析用户那句话本身，而是搞清楚两件事：用户有什么目的？用什么动作去承接更合适？第二，意图识别的最终目标是承接。每一类意图都应该对应一组具体的承接动作，如果识别了一个意图却没有任何动作可以接住它，那这个识别就毫无意义¹。

理解了这个公式，我们来看一个经典案例。

“贷款审批怎么还没通过”：一个 Case 讲透意图分析

#

这是一个银行客服场景。用户发来一条消息：

“我贷款审批怎么还没通过，都提交好几天了”

拿到这条消息，用户的意图是什么？别急，先列出四种可能的解读。

解读一：进度咨询。 用户只是在问审批进度，想知道还要等多久。如果系统识别为"进度咨询"，承接动作就是告知当前审批状态和预计完成时间。但结果呢？客服回复"您的贷款正在审批中，请耐心等待"，用户可能更焦虑了。我都等了好几天了，你就让我继续等？

解读二：情绪宣泄。 用户明显有些焦虑和不耐烦，提交了好几天还没结果，心里不踏实。如果系统判断为情绪宣泄，走安抚路线。但光说"理解您的心情"有什么用？用户的核心诉求不是被安慰，而是想知道到底什么时候能批下来。

解读三：紧急催办。 用户可能急需这笔贷款，等着用钱。走催办流程，联系审批部门加急处理。但问题来了，第一，有些贷款本身审批周期就长，催办也不一定能加速；第二，用户可能只是随口一问，并不真的急，盲目催办反而打乱审批节奏。

解读四：贷款方案调整。 用户等了很久没通过，可能是因为当前贷款产品审批严格或额度受限。与其被动等待，不如主动帮用户评估是否可以更换贷款产品、调整贷款金额或期限。走贷款方案调整流程，用户要么获得更合适的方案，要么明确知道当前审批卡在哪里、还需要多久，同时客服可以给出具体的下一步建议。

只有第四种解读，用户才会满意。

对比一下四种解读的承接效果：

这个案例说明了一个关键点：意图分析的核心不是分析文字表面，而是倒推。用什么承接动作能满足用户的需求，就去定义什么意图。 贷款方案调整流程能完美承接，因为它既解决了用户的实际需求（获得更合适的方案或明确进度），又能倒查审批卡点，安抚也更加具体、有依据。

这就是意图分析公式的威力：根据承接动作倒推意图²。

再来看两个练习场景：

理财产品咨询： 用户问"你们那个年化 4% 的理财产品现在还能买吗？“如果识别为简单问答，查产品状态返回结果。如果产品确实在售，那还行。但如果已经售罄了呢？用户可能接下来就要把钱转到别的银行了。有没有更好的承接方式？比如识别为"理财需求咨询”，提前给用户推荐收益相近的替代产品。

信用卡账单查询： 用户说"我这个月账单怎么这么多"，查账意图。查询流程怎么接更合适？是直接报总金额？还是先列明细再标注异常交易？不同承接方式，用户体验天差地别。

意图标注：从单条 Case 到全局视图

#

单个 Case 会分析了，但现实是：算法同学不会只拿一条 Case 来找你。他们会问：这种意图在业务里占比多少？优化这个意图能解决多大的业务价值？

AI 团队通常背负核心业务指标，压力很大。你拿出一个意图优化方案，但如果占比只有 0.5%，算法和业务团队根本不会配合你做。你必须找出占比最大的意图，优先优化，才能撬动资源。

怎么知道各意图的占比？靠的就是意图标注，通过大规模评估画出意图的全景图。

不夸张地说，做 AI 产品的人 30% 到 40% 的时间，其实都花在分析用户意图和各类评估上。评估涉及随机抽样、数据选取、标准制定等一系列方法论，一个环节出错，结论就全偏了。

怎么做一次靠谱的评估

#

第一步：确定评估集。

评估集就是用来做标注的数据集，这一步决定了整个评估的根基。几个关键点：

规模要够，最少 1000 条。如果在大型商业银行、股份制银行这种量级的业务，最少 10000 条。达不到规模，随机数据可能缺失，占比就不能反映真实情况。

时间要选对，一定要尽量模拟真实环境。去除大促、节假日等特殊时期的数据。大促期间用户需求量大但相对特殊，节假日咨询量可能极少。这些数据混进来，占比就会失真。不能模拟真实环境是非常致命的³。

抽法有讲究。随机不去重、随机去重、分层随机，各有适用场景。在比较正常的环境下，随机不去重最能代表真实情况。为什么？因为真实环境中高频问题本来就会出现多次，去重反而歪曲了占比。

对话条数要够。银行客服场景一般抽 3 到 5 条对话，保证有上下文。只抽一条可能没有上下文，根本看不懂用户在说什么。

第二步：输出评估文档。

评估文档不是摆设，它的目的是让所有参与评估的人知道"什么 Case 标什么意图，什么 Case 不标什么意图"。

每种意图需要包含三部分：

• 意图介绍： 用文字说清楚这个意图是什么。比如"贷款方案调整是用户因审批延迟、额度不满足等原因申请更换贷款产品或调整贷款条件的意图"。
• 代表问： 最能代表该意图的 3 到 5 种问法，包括 query 的方式。
• 相似问： 与代表问相关但不那么典型的问法，符合条件也归为该意图。

假设有 10 种意图，就把每种意图的这三部分都列出来。文档初期不完善是正常的，随着评估越来越多，不断补充和修正，文档会越来越完善。

第三步：执行评估。

参与人员方面，最少 2 到 3 人交叉评估。意图评估是主观判断的过程，不同人理解不同，所以必须交叉。更重要的是，算法同学和业务运营至少各有一人参与，这是拉齐 AI 项目中不同角色对意图认知的好机会⁴。

计算方式上，每个独立 Case 评完意图后，每类 Case 的数量除以评估总数，就是该意图的占比。比如评估 1000 条，其中 100 条是贷款方案调整，那贷款方案调整占比 10%。

最终产出就是一张意图全景图。这张图会让你心里有底，你到底在为什么样的用户做产品。

评估中的三个大坑

#

做了很多次评估之后，总结了最容易踩的三个坑：

坑一：随机取数逻辑有误。 这是最隐蔽的坑。每个人对"随机"的理解不一样，加上各种限定条件之后，取出来的数据可能完全不能代表真实分布。1000 条都评完了，结果占比是错的，白干。务必在取数之前确认随机逻辑。

坑二：评估人不用心，质量低。 把评估任务分发下去，大家各自评各自的，拖到最后一天赶工，质量惨不忍睹。怎么解决？找一个下午，定一个会议室，所有人坐在一起评。有问题当场讨论，有分歧当场解决。这个投入绝对值得。

坑三：评估标准不一致。 算法觉得应该标 A，业务觉得应该标 B，产品觉得应该标 C，三方争论不休。怎么办？个例先跳过。但当多个 Case 出现分歧时，必须有人站出来拍板给出方案。这是 AI 产品经理的责任，作为那个最理解用户的人，也是要为最终效果负责的人。

建立意图体系：从混沌到结构

#

做完一轮标注，会面对一个现实问题：意图太多了。

中等复杂度的智能客服业务，最少也有 200 到 300 个意图。大型复杂业务，比如大型商业银行、股份制银行这种级别，意图数量轻松过千。这么多的意图，如果不做组织和管理，后续的维护、迭代、模型训练都会非常痛苦。

但为什么要建意图体系，很多人给出的理由其实只说对了一半：

• “分层之后增删改查更方便”，对，但不够本质。
• “有一级大类、二级大类，新人更容易理解”，对，但也不够本质。
• “能查漏补缺，发现缺失的意图”，对，还是不够本质。

真正的根本原因：提升识别准确率的容错能力

#

用一个例子说清楚。假设你在搜索一个精准地址：XX 城市 XX 区 XX 街道 XX 门牌号。

方案 A： 搜索系统只认门牌号这一层。搜不到门牌号？返回空结果。用户得到的是一片空白。

方案 B： 搜索系统有层级结构，城市、区、街道、门牌号。搜不到门牌号？返回街道级别的结果。用户到了街道，可以自己找、可以问路人、可以继续缩小范围。

两种方案都没有完美满足"精准到门牌号"的需求，但方案 B 明显更好。因为它有容错能力。

意图体系也是同一个道理：

• 当意图能精准识别时，有没有体系、有没有父子结构，差别不大，模型直接命中，皆大欢喜。
• 但当意图不能精准识别时（这才是常态），有体系和无体系的差别巨大。没有体系，模型只能给出一个完全不相关的结果，也就是"答非所问"。有体系，模型至少能识别到父类意图，给出的结果虽然不精准，但方向是对的。

所以，建立意图体系的根本原因是提升识别准确率的容错能力。 凡是跟识别准确率有关系的事情，一定要做。

另外，意图体系对后续做启发式对话（引导对话）也非常有用。有了层级结构，就能在识别不准时引导用户缩小范围，而不是直接给出一个不靠谱的答案⁵。

搭建意图体系的三个原则

#

原则一：每个意图用代表问和相似问圈定范围。 在意图分析阶段，已经为每个意图梳理了代表问和相似问。在搭建体系时，这些代表问和相似问就是每个意图的"边界线"。范围的概念非常关键，代表问和相似问定义得越清晰，这个意图的边界就越明确。

原则二：每个意图的边界要清晰。 当意图超过 100 个时，会明显感到某些意图之间非常相似、重叠部分很高。人都会搞混的情况下，模型识别时更容易把 A 误判为 B。一旦误判，B 对应的承接动作满足不了用户的需求，就会造成答非所问。在客服场景中，这是非常严重的事故。所以必须明确：这个意图就是管这一圈事情，那个意图就是管另外一圈事情，边界要划得清清楚楚。

原则三：同类问题的不同情况归为同一层级。 比如：贷款提前还款、利率变更还款、逾期补缴，这三个看起来是三个不同的意图，但本质上是"还款异常处理"这个问题的三种不同情况。判断标准很简单：它们是不是同一个问题的不同种情况？如果是，归为同一层级。

补充一点：意图层级越少越好。层级越多，管理和维护成本就越大。能两层解决的事情，不要搞三层。

意图体系是长出来的，不是画出来的

#

一套意图体系不是坐在会议室里画个脑图就能定下来的。通常需要半年到一年的时间才能逐渐稳定。

迭代过程中会不断遇到这些问题：标注标准不统一，同一类 Case 上周标 A 这周标 B；意图重复冗余，发现两个意图其实是一回事；意图遗漏，用户问了新问题，现有意图覆盖不了。

这些都非常正常。意图体系本身就是一个极度复杂、需要持续迭代的过程。心态不要是"我要一次性设计完美"，而是"我先搭个框架，然后在实战中不断修正"。

一条完整路径

#

把三个步骤串起来：

用户那样问，TA 有什么目的，用什么动作去满足。 这是意图分析，解决单个 Case 的问题。

现在有多少种意图，每种意图占比多少。 这是意图标注，解决全局认知的问题。

哪些意图应该归在一起，层级结构长什么样。 这是意图体系，解决结构化管理的问题。

三者串联起来，得到的就是一张完整的意图体系，也就是用户需求全景图。

有了这张全景图之后，不管用传统方式建 QA 库做匹配，还是用生成式模型做 RAG，都有了坚实的地基。识别需求、满足需求、迭代优化，雪球就能滚起来。

意图识别不是一个纯粹的技术问题，而是一个"你到底有多懂用户"的问题。你对用户的理解有多深，意图体系就有多靠谱，AI 产品就有多好用。