意图识别与槽位提取架构方案 (Hierarchical NLU)

1. 架构设计理念

为了实现业务模块的高内聚、低耦合，我们采用 分层式 (Hierarchical) 的 NLU 架构，而非单节点全能型架构。

核心优势

• 封装性：设备控制的参数定义（如 target_device, action）仅封装在 IoT 子模块中，主流程无需感知。
• 可维护性：新增业务（如“订餐”）只需在主路由增加一个枚举值，无需干扰现有的提取逻辑。
• 准确性：领域专家 Agent 可以加载该领域特有的 Knowledge（如设备同义词表），上下文更专注，提取更精准。

---

2. 流程架构图

---

3. L1 主意图路由 (Main Router)

职责：仅做分类，不做提取。快速分发。

System Prompt

# Role
你是一个智能中控路由。你的唯一任务是判断用户输入的意图类别。

# Intent Categories
1. **MEETING**: 涉及会议室预定、查询会议、修改日程等。
   - 示例: "定个明天的会", "查一下305有人吗", "取消下周的例会"
2. **IOT**: 涉及物理环境控制、设备操作、环境调节。
   - 示例: "太热了", "把灯关一下", "开启演示模式", "三楼那个大屏打开"
3. **DATA**: 涉及能耗、人流、设备状态等数据的查询与报表。
   - 示例: "上个月电费多少", "昨天人流量大吗"
4. **QA**: 其他闲聊、知识问答或无法明确归类的指令。
   - 示例: "你好", "什么是碳中和", "打开天窗说亮话(俗语)"

# Output Format
只返回 JSON，包含 intent 和 confidence。
{
  "intent": "MEETING" | "IOT" | "DATA" | "QA",
  "confidence": float // 0.0 ~ 1.0
}

---

4. L2 领域专家 (Domain Specialists) 接入标准

职责：Master 仅负责通过 L1 Router 判定意图所属领域。具体的槽位提取、意图细化及业务逻辑由各领域专家 Agent (Specialists) 自行负责。

4.1 接入契约 (L1 -> L2 Protocol)

当 L1 判定意图后，主流程将按以下标准向 L2 容器分发：

传递字段	类型	说明
query	String	原始用户输入文本。
context	JSON	包含当前时间、用户信息、当前空间状态等全局上下文。
intent_l1	String	L1 判定的顶层意图（如 IOT, MEETING）。

4.2 L2 回传逻辑 (Handback)

专家 Agent 处理完毕后，必须向主流程反馈其执行状态或澄清需求：

{
  "status": "COMPLETED" | "CLARIFY" | "REJECTED",
  "payload": {
    "text": "回复给用户的文本",
    "action": "ACTION_TYPE", 
    "params": { ... }        
  }
}

---

5. 各领域专家详细设计

具体 Agent 的 Slot Filling 逻辑与工作流，请参考各业务模块的专项设计文档：

• 设备控制 (IoT)：参见 SA_设备控制_Agent设计
• 会议预约 (Meeting)：参见 SA_空间预约_Agent设计

---

6. 总结：为什么选这个方案？

1. 工程解耦：当您开发“设备控制”子流程时，您只需要关注 IoT Specialist 的 Prompt 和 JSON 结构。无论主流程如何变化，只要进来的意图是 IOT，您的子流程就能稳健运行。
2. 错误隔离：如果会议参数提取做得不好，完全不会影响设备控制的逻辑。
3. Token 成本与延迟：虽然多了一跳（Router -> Specialist），但由于每个 Prompt 都变短了（Token 数减少），整体延迟增加有限，且换来了巨大的架构灵活性。对于企业级应用，这是值得的交换。

---

附录：AI NLU 架构科普与对比分析

1. 专业术语定义

• 联合式方案 (Joint Intent & Slot Filling):
  • 术语: Joint Model 或 Monolithic NLU (单体 NLU)。
  • 定义: 在单个模型调用（Single-pass）中同时完成意图分类（Classification）和槽位提取（Extraction）。
• 流水线式方案 (Router-Expert Pattern):
  • 术语: Hierarchical NLU (分层 NLU) 或 Cascade Architecture (级联架构)。
  • 定义: 采用“先分诊，后专诊”的逻辑，第一层（Router）决定方向，第二层（Expert）处理具体业务逻辑。

2. 核心架构对比 (Pros & Cons)

维度	联合式 (Monolithic)	流水线式 (Hierarchical)
设计隐喻	全能型员工 (一人包办)	前台导诊 + 专科医生
封装性	差：所有业务参数都在一个 Prompt 里，模块间严重耦合。	优：各专家 Agent 相互独立，业务逻辑严格隔离。
可维护性	低：改动 IoT 的参数可能影响会议的分类效果。	高：新增业务模块只需在 Router 增加一个枚举值。
准确率	中：LLM 需同时关注多个任务，注意力易分散。	高：LLM 在子流程中上下文专注，提取精度更高。
响应延迟	低：仅需一次大模型调用（1 Round-trip）。	中：需两次调用，延迟约为联合式的 1.5 - 2 倍。
Token 成本	较低 (总 Token 数较少)	较高 (Router + Specialist 多次消耗)

3. 适用场景建议

• 建议使用联合式 (Monolithic):

  • 业务逻辑简单（只有 1-2 个固定意图）。
  • 对响应时间要求极其苛刻（毫秒级）。
  • 成本预算非常受限。

• 建议使用流水线式 (Hierarchical) [本项目选择]:

  • 企业级复杂系统：意图多（会议、设备、能耗、QA等）。
  • 多人协作开发：不同人负责不同子流程，需要明确的工程边界。
  • 高可靠性需求：需要精细处理每个业务领域的边界情况（Edge Cases）。