背景与目标
定义意图分类系统的核心问题、技术约束与验收标准
问题陈述 (Problem Statement)
意图分类的核心挑战
在现代 AI 应用架构中,意图分类(Intent Classification)承担着”智能路由”的关键角色。当用户发送一条消息时,系统需要准确判断用户想要做什么,并将请求路由到正确的处理器。这个看似简单的问题,在实际生产环境中面临多重挑战:
语义多样性问题:用户表达同一意图的方式千差万别。例如,“我要订机票”和”帮我查下北京到上海的航班”可能都指向”航班预订”意图,但字面上几乎没有重叠。传统的关键词匹配在这里完全失效。
边界模糊问题:很多意图之间存在语义重叠。“查天气”和”旅游攻略”可能都包含地点信息,但处理逻辑完全不同。当用户说”北京明天怎么样”,系统需要判断这是询问天气还是旅游建议。
新意图识别问题:用户的请求可能完全超出预定义的意图范围。一个健壮的系统需要识别”未知意图”,而不是强行归类到某个现有类别。
规模化问题:随着意图数量增长(从 10 个到 100 个再到 1000 个),分类准确率会显著下降。如何在保持精度的同时支持大规模意图集,是架构设计的核心难点。
当前主流解决方案的局限
传统 NLU 方案(如 Rasa NLU、Dialogflow)依赖监督学习模型,需要大量标注数据。这种方法的主要问题在于:
- 数据依赖性强:每个新意图都需要收集标注样本,冷启动成本高
- 泛化能力有限:对于训练数据之外的表述变体,表现不稳定
- 维护成本高:意图变更需要重新训练模型,迭代周期长
基于 LLM 的方案虽然解决了数据依赖问题,但带来了新的挑战:延迟高、成本高、输出不可控。如何设计一个既准确又高效的 LLM 意图分类系统,是本研究的核心问题。
约束条件 (Constraints)
性能约束
延迟要求:用户交互场景中,意图分类通常需要在 100-500ms 内完成,以保持流畅的对话体验。直接使用大型 LLM(如 GPT-4)进行分类,单次调用延迟可能达到 1-3 秒,无法满足实时性要求。
成本约束:假设日活用户 10 万,平均每人发起 5 次对话,使用 GPT-4 进行意图分类的月成本可能高达数千美元。对于商业化产品,这是一个不可忽视的成本项。
准确率基线:根据行业经验,意图分类准确率低于 85% 会显著影响用户体验。高于 95% 则需要更复杂的架构设计。
技术约束
意图数量:小型系统通常有 10-50 个意图,中型系统 50-200 个,大型系统可能超过 500 个。不同规模需要不同的架构策略。
意图粒度:意图定义的粗细程度直接影响分类难度。过粗的意图难以路由到具体处理逻辑,过细的意图则增加歧义风险。
动态性需求:部分系统需要支持动态添加/修改意图,不重启服务即可生效。这对架构设计提出了额外要求。
业务约束
多语言支持:全球化产品需要支持多语言意图分类,且不同语言的分类质量应保持一致。
可解释性:某些场景(如金融、医疗)需要解释为什么将用户请求分类到特定意图,这对黑盒模型提出了挑战。
合规要求:用户数据可能需要本地处理,限制了对云端 LLM API 的使用。
成功指标 (Success Metrics)
核心指标
| 指标 | 定义 | 目标值 | 测量方法 |
|---|---|---|---|
| 准确率 (Accuracy) | 正确分类的请求比例 | > 90% | 标注测试集评估 |
| 召回率 (Recall) | 各意图被正确识别的比例 | > 85% | 分意图统计 |
| F1 分数 | 准确率和召回率的调和平均 | > 88% | 综合评估 |
| 延迟 (P95) | 95% 请求的响应时间 | < 300ms | 线上监控 |
| 成本效率 | 每千次分类的 API 费用 | < $0.05 | 成本分析 |
次要指标
None 意图识别率:系统应正确识别不属于任何预定义意图的请求,误判率应低于 10%。
意图置信度校准:输出的置信度分数应与实际准确率匹配,避免过度自信或过度保守。
冷启动性能:新增意图后,系统应在无需重新训练的情况下正确分类相关请求。
验收标准
一个合格的意图分类系统应满足以下条件:
- 基准测试通过:在标准数据集(如 HWU64、CLINC150)上达到或超过基准模型表现
- 生产环境验证:在实际流量中稳定运行至少 2 周,无重大故障
- A/B 测试提升:与现有方案对比,至少一项核心指标有统计显著提升
- 成本可控:总成本(API 调用 + 计算 + 存储)在预算范围内