意图识别任务写法
意图识别要判断的是「用户想做什么」，而不是「用户说了什么」。同一句「这个还能退吗」可能是退款咨询，也可能是售后政策咨询，差别靠上下文与业务规则定。提示里三样东西缺一不可：意图列表（每个意图一句定义 + 真实例句）、判定依据、兜底策略。兜底尤其重要——没有 other 或转人工，模型会把不认识的表达硬塞进最相近的意图里，这类错误混在正常数据中最难发现。
要点
| 意图列表 | 每个意图写一句定义 + 2-3 个真实例句 |
|---|---|
| 兜底 | other / 转人工 必须有，避免硬塞进相近意图 |
| 输出格式 | 仅输出意图 ID，或按约定输出 ID + 关键槽位 |
| 冲突处理 | 一句话命中多个意图时写明优先规则 |
| 扩展 | 可同时输出关键槽位（订单号、时间），一次调用完成两件事 |
典型使用场景
- 客服分流：把会话路由到订单、退款、技术支持等不同队列
- 工单归类：判定诉求类型后套用对应处理流程
- 语音助手：识别指令意图并抽取参数
- 邮件处理：判定来信目的，决定自动回复还是转人工
- 质检抽样：按意图分布抽样，检查特定类别的服务质量
意图识别模板
意图识别模板
判断用户意图，仅输出意图 ID：
query_order 查询订单 / cancel 取消 / refund 退款 / human 转人工 / other 其他
示例：
「我的货到哪了」——query_order # 例句用真实用户说法，不用书面语
「别发了，退了吧」——cancel
用户消息：<message>判定与兜底设计
| 情形 | 处理方式 | 原因 |
|---|---|---|
| 一句话命中多个意图 | 按优先规则取主意图，其余写入备注 | 硬选一个而不说明，人工复核时无从判断 |
| 信息不足 | 输出 other 或追问槽位 | 硬猜意图会把工单路由到错误队列 |
| 表达口语化 | 例句覆盖真实说法 | 书面化例句导致线上长尾识别率低 |
| 新增业务 | 先扩充意图列表再上模型 | 把新诉求塞进旧意图，统计口径失真 |
意图识别的评测要看每个意图单独的召回率：整体准确率很高但某些小类几乎全错，是这种任务最常见的问题。