搭对话助手绕不开一步：意图识别。用户说一句话，你得先搞清他想干啥——查物流？要退款？还是纯闲聊？分清了才能把他引到对的处理流程上。

这步有两条路，老派的规则分类，和现在流行的大模型。我两条都用过，掉过坑，这篇把区别讲明白。

规则分类：靠关键词和模式

最朴素的办法。提前列好一堆规则：

包含"快递"/"物流"/"到哪了" → 物流查询意图
包含"退"/"不想要了"/"退款" → 退款意图
包含"发票"/"开票" → 开发票意图
其它 → 兜底

匹配上哪条就归到哪类。

好处：快，几乎零延迟，一次匹配的事；准，命中关键词就是它，不会飘；便宜，不花模型调用的钱；可解释，错了你一眼看出是哪条规则的锅。

坏处：脆。用户不按你列的词说话就抓瞎。我见过最离谱的，用户说"那个东西我用不上了，怎么弄回去"——明明是退款,一个退款关键词没踩中,直接掉兜底。规则这东西,你永远列不全人类说话的花样。

大模型：靠语义理解

把用户的话连同候选意图列表一起丢给大模型，让它判断属于哪类。

好处：懂人话。上面那句"用不上了怎么弄回去"，大模型一下就懂是退款，不依赖具体词。换着花样说、有错别字、绕着弯说，它都能扛。

坏处：慢，多一次模型调用，几百毫秒到几秒；要花钱，每次都是调用；偶尔会飘，同一句话今天判A明天判B，稳定性不如规则；还可能"自作多情"，把简单的归类问题想复杂。

我拿一句话直接对比

测试句:"昨天买的那个,颜色不太对,这事咋整"

• 规则分类:没踩中任何明确关键词,掉兜底。挂。

• 大模型:识别出"可能涉及商品问题/换货",引导到售后流程。对。

再来一句:"查物流"

• 规则分类:秒中"物流",0延迟,完美。

• 大模型:也对,但慢了一秒还花了次调用。这种送分题,大模型纯属高射炮打蚊子。

看出门道了吧:简单明确的,规则更香;模糊绕弯的,大模型才顶得住。

我现在的做法:两层兜底

不二选一,串起来用:

1. 先过规则。能被关键词秒中的,直接出结果,又快又省。日常七八成的"查物流""退款"这种直球都在这层解决了。

2. 规则没中的,再交给大模型。剩下那两三成绕弯的疑难杂句,让大模型用语义去兜。

这么搭,大部分请求走便宜的规则层,只有少数难句才惊动大模型。延迟、成本、覆盖率,三个一起照顾到了。在能编排流程的平台上,这就是一个"规则节点 + 模型节点"串起来的事,不用写分类器代码。

一个容易忽略的坑

两层之间的"分界线"得调。规则太宽,会把本该大模型处理的绕弯句强行错判;规则太严,又起不到分流作用,啥都漏给大模型,省不下钱。我那个助手的规则,前后改了三四版才找到平衡——这没有标准答案,得看你自己的用户到底怎么说话,拿真实对话喂出来。

意图识别这步看着小,搭歪了后面全乱。规则和大模型不是谁取代谁,是各管一段。

（大模型那层我接的是讯飞 MaaS，现成API直接调，不用自己训分类模型也不用部署，省心。）