很多人第一次接触“意图模型”时，会觉得它和大语言模型（LLM）“打架”——既然LLM能理解人话，为啥还要单独搞意图模型？今天咱们从“什么是意图”开始，一步步拆透“从0搭建意图体系”的全流程，全程用电商、生活场景举例子，保证新手也能看懂。
第一步：先搞懂3个基础概念，不被术语绕晕
在学搭建之前，得先明白“我们到底在做什么”。这3个概念是核心，记牢了后面就顺了：
1. 什么是“意图识别”？—— 猜用户“要做什么”，不是“说什么”
比如你跟电商APP的客服说：“我的快递咋不动了？”
- LLM能理解你“在抱怨快递停滞”（这是“理解说什么”，语义层面）；
- 意图识别要做的是：判断你“想查快递为啥不动，或者催快递”（这是“要做什么”，业务层面）。
简单说：意图识别是“把用户的话，翻译成系统能执行的动作指令” ——比如识别出“催快递”，系统就会触发“优先派送”的操作；识别出“查物流”，就会调用物流接口拉数据。
2. 什么是“意图体系”？—— 给用户的“需求”建一本“字典”
你想，电商APP里用户的需求有很多：查订单、改地址、退款、问商品保质期……
意图体系就是把这些需求“分类、整理、定规则”，形成一本“系统能看懂的需求字典”。比如这本字典里会写：
- “查物流”：用户想知道已发货商品的位置、预计送达时间；
- “催发货”：用户想让没发货的订单快点发；
- 每个需求对应的“系统该做什么”（比如查物流→调用物流接口）。
没有这本“字典”，系统就会“听不懂”用户要干啥——比如你说“快递不动了”，系统可能只会回复“别着急”，而不会真的去查物流或催单。
3. 大语言模型（LLM）时代，意图识别还有用吗？—— 不仅有用，还得强化
很多人会问：LLM都能聊天了，为啥还要意图模型？咱们用2个场景说透：
| 场景类型 | LLM能做啥？ | 意图识别能补啥短板？ | 例子 |
|---|---|---|---|
| 纯闲聊/知识问答 | 独立完成（比如“天为什么蓝”） | 不需要介入 | 用户问“推荐一部喜剧电影”，LLM直接推荐即可 |
| 有业务动作的场景 | 只能“说”，不能“做” | 把“话”变成“系统动作”，降低成本 | 用户说“查我昨天买的衣服到哪了”： LLM能说“我帮你查物流”，但不能真调用物流接口； 意图识别能直接路由到“查物流接口”，拉数据回复用户 |
另外还有个关键：LLM调用成本高！比如用户只是“查订单号”，用意图识别直接对接简单接口，成本只有LLM的几分之一；如果所有需求都用LLM，企业得花更多钱。
第二步：从0搭建意图体系，6个维度一步到位
搭建意图体系的核心，是把“用户需求”转化为“系统能执行的规则”。网页里提到的6个维度，是行业通用的标准，咱们用“电商场景的‘查询物流’意图”当例子，逐个拆：
维度1：起个“好名字”—— 意图命名要“简洁无歧义”
❌ 错误例子：“售后相关”（太宽泛，系统不知道该触发退款还是查物流）；
✅ 正确例子：“查询物流”（一看就知道是“查快递状态”）。
核心原则：别人看名字就知道这个意图是干啥的，别用模糊词。比如“售后”可以拆成“退款申请”“换货申请”“售后咨询”，每个都有明确指向。
维度2：下“准定义”—— 意图描述要“说清边界”
给“查询物流”写描述时，不能只说“查物流”，要写清楚“查什么、不查什么”：
✅ 正确描述：“用户希望获取已下单且已发货的商品的物流状态（如运输中、派送中）、当前位置、预计送达时间、物流单号等信息”。
这里埋了个关键：“已发货”——如果用户的订单还没发货，就不属于“查询物流”，而是可能属于“催发货”，这为后面“划边界”做铺垫。
维度3：找“例子”—— 收集用户常说的“话”（典型提问）
要让系统识别“查询物流”，得先告诉它“用户会怎么说”。需要覆盖2类场景：
- 直接提问：用户直白说需求，比如：
-
- “我的快递到哪了？”
- “查一下订单号1234的物流”；
- 模糊表达：用户没明说，但隐含需求，比如：
-
- “快递怎么3天没动了？”（隐含“查物流停滞原因”）
- “我什么时候能收到货？”（隐含“查预计送达时间”）。
收集这些例子的目的：让模型“见多识广”，不管用户怎么说，都能认出是“查询物流”。
维度4：分“层级”—— 给意图“归大类”（复杂场景才需要）
如果APP只有10个以内的意图（比如小工具类APP），不用分层；但像电商APP有上百个意图，就得像“整理衣柜”一样分层：
以电商为例，层级可以这样分：
- 一级意图（业务大类） ：订单相关、账户相关、商品咨询（对应APP的核心模块）；
- 二级意图（细分场景） ：“订单相关”下分“查订单、改订单、取消订单”；
- 三级意图（具体操作） ：“改订单”下分“改收货地址、改配送时间”。
咱们的“查询物流”，层级就是：订单相关（一级）→ 查订单（二级）→ 查询物流（三级） 。
类比：就像淘宝买衣服，“女装（一级）→ 上衣（二级）→ 吊带（三级）”，找的时候更清晰。
维度5：划“边界”—— 别让意图“打架”（最关键的一步）
很多新手栽在这里：比如“查询物流”“查询订单”“催发货”，用户的话可能很像，系统很容易认错。这时候就要用3个原则划清边界：
原则1：互斥性—— 一个需求只能对应一个意图
比如用户说“我的订单状态是什么？”
- “查询订单”管“订单本身的状态”（如已付款、已取消、已发货）；
- “查询物流”只管“已发货后的物流状态”（如运输中、派送中）；
所以这个需求只能归“查询订单”，不能归“查询物流”。
原则2：穷尽性—— 所有需求都有“归属”，没有“没人管”的情况
比如用户说“我想投诉快递丢件了”，如果现有意图里没有“投诉物流”，就得加这个意图；实在覆盖不到的，要有“兜底意图”（比如“转人工客服”），不能让用户“喊半天没人应”。
原则3：业务导向—— 别只看“语义”，要看“系统能做什么”
比如用户说：“烦死了！我的订单怎么还没有物流信息？我急着用！”
- 从语义看，用户在“抱怨没物流”，可能会误以为是“查询物流”或“投诉”；
- 但从业务看：“没物流信息”=订单没发货，用户真正想要的是“快点收到货”，所以该归“催发货”（系统能触发“优先发货”动作），而不是让用户去投诉（解决不了“急着用”的问题）。
维度6：定“动作”—— 意图识别后，系统该“做什么”（最终目的）
意图识别不是“为了识别而识别”，最终是要“解决用户问题”。所以每个意图都要对应“承接动作”：
以“查询物流”为例，承接动作分2步：
- 找订单：系统通过上下文（比如用户登录状态）找到用户说的“那个订单”（比如最近下单的订单）；
- 调接口+回复：调用物流平台的接口，拉取物流状态、位置、预计送达时间，然后用自然语言回复用户（比如“您好，您的快递当前在深圳市南山区，预计明天上午10点送达”）。
如果没有这步，意图识别就“白干了”——用户还是没拿到想要的信息。
第三步：意图模型的“实际应用”—— 不是独立工作，是LLM的“好搭档”
现在你知道了意图体系怎么搭，那实际用的时候，它和LLM是怎么配合的？其实是个“分工合作”的流程：
- 用户说话：比如用户说“查一下我昨天买的鞋子的物流”；
- 意图识别先“过滤” ：识别出“查询物流”，判断“这个需求简单，不用LLM”；
- 路由到低成本接口：直接调用物流接口，拉数据回复用户（成本低、速度快）；
- 如果需求复杂（比如用户说“我想把昨天买的鞋子退了，再换一双大码的，还要改收货地址”）：
-
- 意图识别先拆出“退款申请”“换货申请”“改收货地址”三个意图；
- 再让LLM协助“理清顺序”（比如先退款再换货，还是直接换货），然后逐个触发对应动作。
简单说：意图模型是“指挥官”，负责“分任务”；LLM是“助手”，负责“处理复杂沟通” ——既保证效率，又降低成本。
第四步：新手避坑指南 + 后续优化方向
新手常踩的3个坑：
- 意图命名太模糊（比如用“售后问题”代替“退款”“换货”）；
- 只看语义不看业务（比如把“催发货”归为“查询物流”）；
- 没有兜底意图（用户提了没覆盖的需求，系统没反应）。
后续优化方向：
- 意图澄清：如果系统不确定用户的需求（比如用户说“我想改订单”，没说改地址还是改时间），可以让LLM问用户：“请问你想修改收货地址，还是配送时间呀？”；
- 数据迭代：收集用户被“认错意图”的案例（比如用户说A，系统认成B），补充到意图体系的“典型提问”里，让模型越来越准；
- 成本优化：把简单需求（查订单、改地址）都用意图识别处理，复杂需求（比如多意图组合）再用LLM，降低整体成本。
总结：从0到1的核心逻辑
搭建意图模型，本质是“站在用户和系统中间，当一个‘翻译官’+‘指挥官’”：
- 对用户：听懂你“要做什么”；
- 对系统：告诉它“该做什么”；
- 最终目的：让用户“少等、少操作”，让企业“少花钱、效率高”。
不管是电商、金融还是政务场景，这套逻辑都通用——先搭好“意图体系”这本字典，再和LLM配合，就能做出“懂用户、能办事”的AI产品。
