高进阶

意图识别与任务路由#

一句话答案#

意图识别判断用户”想做什么”，任务路由决定”交给谁处理”——规则快路径优先、LLM 兜底，多轮澄清处理模糊意图。

核心要点

1. 两级意图识别架构#

用户输入
  ├── 第一级：规则快路径（正则/关键词/模板匹配）
  │     ├── 命中 → 直接路由（零延迟）
  │     └── 未命中 ↓
  └── 第二级：LLM 分类（理解语义）
        ├── 高置信度 → 路由到对应处理器
        └── 低置信度 → 多轮澄清追问用户

plaintext

2. 路由方式对比#

路由方式	优点	缺点	适用场景
规则路由	快、确定性强、零成本	覆盖面有限	高频明确意图
Embedding 相似度	简单，不需训练	语义近但意图不同时误判	工具/Skill 匹配
LLM 分类	理解力强	慢、贵	兜底，复杂/模糊意图
训练分类器	快且准（ms 级）	需标注数据、维护成本	成熟业务域

3. 意图分类体系#

知识查询：需要 RAG 检索知识库
任务执行：需要工具调用完成操作
闲聊：直接 LLM 回答
元对话：“你是谁”、“切换模式”等系统指令
越界请求：拒绝并引导回正轨

4. 多轮澄清策略#

置信度 < 阈值（如 0.7）时主动追问
追问要具体不要泛泛：“您是想查询订单状态，还是要修改订单？”
最多追问 2 轮，超过则用最高置信度意图处理

5. 并行化意图识别（字节面经高频）#

多个分类器并发执行（规则+Embedding+LLM），取最快返回的高置信度结果
多意图混合请求（“帮我查下单号123，顺便改个地址”），拆分为独立子任务并行处理

6. Query Rewriting#

指代消解：多轮对话中 “它”→“订单123”
同义词扩展：提升检索召回率

面试回答（2分钟版）

意图识别和任务路由解决的是Agent收到用户输入后”交给谁处理”的问题。我们采用两级架构：第一级是规则快路径，用正则和关键词匹配处理高频明确意图，零延迟零成本；第一级没命中才走第二级LLM分类，用语义理解处理复杂和模糊的意图。路由方式有四种：规则路由最快但覆盖有限，Embedding相似度匹配简单但语义近意图不同时会误判，LLM分类理解力最强但慢和贵，训练分类器兼顾速度和准确率但需要标注数据。意图分类通常分为知识查询走RAG、任务执行走工具调用、闲聊直接LLM回答、越界请求拒绝并引导。当意图模糊时要多轮澄清而不是瞎猜，追问要具体比如”您是要查询订单还是修改订单”，最多追问两轮超过就用最高置信度意图处理。字节面经里经常追问并行化意图识别——多个分类器并发执行取最快的高置信度结果，多意图混合请求要拆分为独立子任务并行处理。

追问与易错

追问方向：

意图分类器的准确率怎么评测？用什么指标？ → Precision/Recall/F1 按意图类别分别计算。构建标注测试集（200+ 条），关注混淆矩阵中容易误分的类别对
用户意图模糊时追问还是猜？追问几轮合适？ → 置信度 < 阈值（如 0.7）时追问，追问要具体（“您是要查询订单还是修改？”）。最多 2 轮，超过用最高置信度意图处理，避免用户烦躁
并行化意图识别怎么处理结果冲突？ → 多分类器并发（规则/Embedding/LLM），取最快返回的高置信度结果。冲突时按分类器优先级：规则（确定性最强）> 训练分类器 > LLM
正则路由覆盖率不够怎么逐步提升？ → 分析 LLM 兜底处理的 case 日志，高频模式提取为新规则。迭代式：规则覆盖率 30%→50%→70%，剩余交 LLM。定期复审规则防止过时

易错点：

❌ “正则能覆盖大部分意图” → 自然语言表达多样，正则覆盖率通常 <50%
❌ “单轮分类器就够了” → 多轮场景需要结合对话上下文判断意图变化
❌ “LLM 分类不需要专门训练” → 零-shot 分类在业务域准确率不够，Few-shot 或微调能显著提升

项目实践（DocMind）： 二级路由架构：Phase 0 正则快筛（META_CONVERSATION/CHITCHAT/KB_META/OUT_OF_SCOPE 四种短路意图，零 LLM 调用），Phase 1 LLM 分类（QueryUnderstandingService 498 行，单次 LLM 调用输出 9 维分类结果：intent/complexity/specificity/timeliness/memory 等）。比较类查询用正则强制分解（“对比”/“vs”/多个”?”），不依赖 LLM 分解的不确定性。RetrievalPlanner 规则引擎替代 LLM 做工具选择，<1ms vs ~300ms。