意图识别

1. 分层设计：意图识别通常作为路由层

核心理念：把“理解用户意图”和“执行动作”拆开。 在工程中，一般做法是：

用户消息 → 意图识别 → 参数提取 → 具体处理（工具调用/查询/记忆）

这样有几个好处：

• 清晰职责：意图识别只关心“用户想做什么”，不管具体怎么执行。
• 可复用性：不同的执行模块（工具、RAG、数据库）可共享同一套意图识别。
• 可测试性：意图识别模块可以单独做精度评估和优化。

可借鉴点：

• 将意图分类和实体抽取分成两个子模块：
  • Intent Classifier → 输出 intent
  • Entity Extractor → 输出 entities（如订单号、商品名、地址等）
• 对多意图消息可以先拆分，再按优先级处理。

---

2. 意图分类方法

a. 基于规则 + ML 的混合模式

• 规则：正则、关键词匹配、模板匹配
  • 优点：快速、确定性高
  • 缺点：覆盖面有限，难以扩展
• 机器学习 / LLM：
  • 使用文本分类模型或 LLM 来识别意图
  • 优点：泛化能力强、可理解自然语言变体
  • 常见做法：
    • 小型模型训练意图分类器（BERT / DistilBERT）
    • 或使用 LLM prompt + schema 输出 JSON

工程实践借鉴：

• 对常见、高频意图可以用规则匹配做初筛，低频/模糊意图交给 LLM 或 ML 分类器
• 输出结构化 JSON（intent + confidence + entities）方便后续处理

---

b. 置信度 & 异常处理

• 置信度 threshold：低于阈值时，不盲目执行动作，而是：
  • 向用户询问澄清
  • 或 fallback 到人工客服
• 日志 & 可观察性：
  • 记录意图分类结果和实体提取结果
  • 便于评估模型准确率和排查误判

借鉴点：工业系统中，几乎都会有“意图置信度 + fallback”机制，保证用户体验和安全。

---

3. 多意图和多轮对话

• 多意图拆分：如“取消订单并退款”，可先识别多个意图，再按优先级或顺序执行
• 上下文关联：通过对话历史或记忆增强意图识别
  • 实践中常用 滑动窗口 + 历史状态 或 对话状态机 来辅助分类
  • 典型场景：用户说“还有其他问题”，需要把之前的意图和当前消息关联

---

4. 工程上可借鉴的模式

模式	应用场景	优势
Routing Layer	消息 → 意图识别 → 工具/RAG/记忆	职责清晰，便于维护
Chain of Responsibility	多个意图检测器按顺序处理	可以灵活扩展意图、规则与模型
Schema-guided LLM	让 LLM 返回固定 JSON schema	直接可用结构化输出，减少解析错误
Hybrid Rule+ML	高频意图用规则，低频意图用 ML/LLM	高效且覆盖广
Confidence-based Fallback	低置信度→人工/澄清	保证安全和用户体验

---

5. 工程实践总结

1. 意图识别是路由，而不是决策：它只告诉系统“做什么”，具体怎么做由后端工具决定
2. 结构化输出 + 置信度：JSON 输出 intent/entities + confidence
3. 混合模式：规则覆盖高频意图，ML/LLM 覆盖复杂/模糊意图
4. 可观测 & 可评估：日志、统计误分类率、定期回训
5. 支持多意图和上下文：多轮对话或组合意图的处理逻辑必须明确