意图识别
NLU核心技术：将用户自然语言输入映射到预定义意图类别，让机器理解”用户想做什么”
简介
意图识别（Intent Recognition/Classification）是自然语言理解（NLU）的核心任务之一，目标是将用户的自然语言输入分类到预定义的意图类别中。在对话系统/客服系统中，意图识别是对话流程的起点——系统先理解用户想做什么（查订单？退款？咨询？），才能决定下一步动作。在智能客服MVP实践中，意图识别通常与槽位填充（Slot Filling）配合使用，大模型被用作”翻译器”，将用户自然语言转换为包含意图和槽位的结构化JSON。
关键信息
- 类型：技术 / NLP子任务
- 领域：自然语言理解 / 对话系统 / 智能客服
- 核心输入：用户自然语言文本 + 预定义意图列表
- 核心输出：结构化JSON（intent + slots）
- 相关概念：智能客服、通义千问、槽位填充、对话管理器
核心特性
意图识别在对话系统中的角色
用户输入："薯片碎了，订单号12345，我要退款"
↓
意图识别 + 槽位填充（大模型NLU层）
↓
{
"intent": "apply_refund",
"slots": {
"product": "薯片",
"issue": "破损",
"order_id": "12345"
}
}
↓
对话管理器（状态机）→ 调用退款API / 追问信息为什么不用大模型直接生成回复
在智能客服场景中，普遍选择让大模型只做NLU（意图识别+槽位填充）而非生成最终回复的三个理由：
- 可控制性：生成式回复不可控——模型可能输出错误信息、承诺不该承诺的事情、或遗漏关键步骤。结构化JSON输出后由确定性代码执行，每一步都可预期。
- 延迟：NLU输出JSON延迟约200ms，而生成完整回复延迟可能达800ms+——客服场景的实时性要求使得4倍延迟差异不可接受。
- 成本：NLU输出几十个token的JSON远低于生成几百token的回复，在每万次调用量级下成本差异达8倍以上。
模型选型对意图识别的影响
来自零食品牌智能客服的实测对比：
| 模型 | 意图识别准确率 | 推理延迟 | 每万次成本 | 适用场景 |
|---|---|---|---|---|
| 通义千问 | 92% | 200ms | 1.5元 | 中文NLU MVP首选 |
| GPT-4 | 97% | 800ms | 12元 | 高精度要求但预算充裕 |
对于意图识别这类结构化分类任务，准确率从92%到97%的提升在客服场景的实际体验差异不大，但延迟和成本差异显著。MVP阶段应优先选择”够用、快、便宜”的模型。
当前局限
- 单意图限制：一次用户输入只能识别一个意图。用户说”薯片碎了，顺便查一下巧克力物流”时只能识别第一个意图（退款），第二个（查物流）会被忽略。
- 覆盖范围依赖预定义：只能识别预定义意图列表内的意图，超出范围的输入会被错误分类。
- 上下文缺失：单独一句话的意图识别不考虑对话历史，用户聊了10轮才说需求时准确率下降。
后续迭代方向：多意图识别、未知意图检测、结合对话历史的上下文意图识别。
不同素材中的观点
- 2026-05-26-智能客服MVP三件事：嘻嘻李在零食品牌智能客服项目中，将大模型（通义千问）定位为NLU层——只做意图识别+槽位填充，将用户自然语言翻译为结构化JSON指令，而非生成对话回复。方案的效果是延迟200ms、每万次1.5元，三个月将三个核心场景自助解决率从50%提升至80%。核心洞察是”大模型在对话系统中的最佳角色不是说话的人，而是翻译官”。
实用信息
Prompt设计要点
进行意图识别+槽位填充时，prompt应包含：
- 用户原始输入
- 预定义的意图列表（含每个意图的描述和示例）
- 槽位定义（含每个槽位的名称、类型、是否必填）
- 输出格式要求（JSON schema）
适用场景
- 客服系统（查订单、退款、咨询等标准化场景）
- 语音助手（播放音乐、设置闹钟、查询天气等指令类场景）
- 工单路由（自动判断用户问题类型并分派到对应处理队列）
- 搜索意图解析（区分导航型、信息型、交易型搜索）
不适用场景
- 开放式闲聊（无预定义意图可分类）
- 需要复杂推理的多步骤任务（意图识别只做第一跳）
- 高度依赖上下文理解的场景（如连续追问）