第六章 · 意图理解与智能路由
本章定位：前五章讲了「怎么检索得更准」。但有个问题一直没碰——用户的问题真的都该走知识库吗？ 用户说「你好」「讲个笑话」，你也去检索一遍知识库、跑一遍向量召回？用户的问题该查哪个知识库（公司有产品库、人事库、财务库），全查一遍还是精准定位？问题模糊时（「我想弄一下那个」），是硬答还是反问澄清？意图理解就是检索之前的那道「分诊台」，把不该走知识库的问题前置分流，把该走的精准路由到正确的库。
本章分两部分：
- 上篇 · 概念与原理（科普）：为什么需要意图识别？有哪几种意图类型？意图识别的三种方案（规则/大模型/混合）？意图树是什么，为什么扁平四分类撑不住？路由架构怎么设计？
- 下篇 · SparkX 源码落地（实践）：SparkX 的多级拦截链（样例命中→规则快路径→LLM 分类→歧义澄清）、意图节点三类型（KB/SYSTEM/MCP）、澄清引导的双策略、意图如何约束检索、评测体系。
上篇 · 概念与原理
一、为什么需要意图识别
1. 一根筋的 RAG 系统会出什么问题
假设你做了一个企业智能客服，接了产品、人事、财务三个知识库。如果没有意图识别，会发生什么？
- 用户说「你好」→ 系统拿「你好」去检索知识库 → 召回一堆无关内容 → 模型基于垃圾上下文回一句奇怪的「你好」；
- 用户问「报销流程」→ 系统在三个库里全查一遍 → 人事库命中、财务库也命中一堆 → 召回结果互相干扰；
- 用户说「帮我看看那个」→ 系统不知道「那个」是什么，硬去检索 → 答非所问。
问题本质：不是所有问题都需要检索，也不是所有问题都要全库检索。不加区分地「问题→检索→回答」，既浪费资源又降低体验。
2. 医院分诊台的类比
意图识别就像医院的分诊台：
| 用户问题 | 分诊结果 | 去哪 |
|---|---|---|
| 「你好」 | 问候 | 不用看病，直接回应 |
| 「报销流程」 | 业务问题·人事 | 去人事科（人事库）精准查 |
| 「今天天气怎样」 | 闲聊/超纲 | 自由聊，不看病 |
| 「帮我看看那个」 | 模糊 | 反问「您指的是哪个？」先澄清 |
意图识别的价值：在昂贵的检索/生成之前，先用极低成本判断「这个问题该怎么处理」，把不该走知识库的问题前置拦截，把该走的精准路由。既省钱又提质。
二、四种意图类型
参考业界惯例，一个 RAG 系统通常要识别四类意图：
1. 知识检索（Knowledge Retrieval）
最常见的业务问题，需要去知识库找答案。如「退货政策是什么」「报销流程怎么走」。这是唯一需要走完整检索链路的意图。
2. 工具调用（Tool Invocation）
用户的问题不是查文档，而是要执行某个动作。如「帮我查一下订单 20240315 的状态」「今天北京天气怎样」——这些要调外部接口/工具（订单系统、天气 API），而不是检索知识库。
3. 闲聊对话（Chitchat）
问候、寒暄、情绪表达、能力询问。如「你好」「你是谁」「讲个笑话」「今天好烦」。不需要检索，直接让大模型自由回答即可。
4. 引导澄清（Clarification）
问题太模糊或多义，无法确定意图。如「帮我弄一下那个」「我要查东西」。不直接回答，而是反问引导用户明确意图。
5. 四种意图对比
| 意图 | 是否检索 | 是否调工具 | 典型处理 |
|---|---|---|---|
| 知识检索 | ✅ | ❌ | 走 RAG 全链路 |
| 工具调用 | ❌ | ✅ | 调用对应工具/接口 |
| 闲聊 | ❌ | ❌ | 大模型直接回答 |
| 引导澄清 | ❌ | ❌ | 反问澄清，不走后续 |
💡 核心收益：闲聊和澄清完全跳过检索，省掉向量召回、重排、生成的全部开销。对于客服场景，闲聊和已收录的标准问题可能占 30%~50% 的流量——零成本拦截它们，能省下巨大成本。
三、意图识别的三种方案
1. 规则匹配方案
用关键词/正则表达式判断意图：
🔒 以上为本章部分预览（约 10%）
本章剩余 90% 内容包含：关键源码逐行拆解、设计细节与工程权衡、代码示例与生产实践要点。
💡 本次展示的仅为部分预览内容（约 10%）。完整的源码深度解析包含每一个技术点的完整实现细节。点击上方按钮扫码加入知识星球，解锁全部内容。
