从"全量检索"到"按需调度"：深度解析 LLM 应用的 Intent Routing 架构与工程实践
在 LLM 应用开发的早期，我们习惯于"一力降十会"：无论用户问什么，通通丢给最强的模型，或者一股脑塞进 RAG（检索增强生成）流水线。但随着应用进入生产环境，开发者们很快撞上了三堵墙：居高不下的 Token 成本 、难以忍受的响应延迟 ，以及在复杂任务面前捉襟见肘的确定性。
解决这些问题的钥匙，不在于模型参数的大小，而在于系统架构的进化------意图路由（Intent Routing）。
一、 什么是 Intent Routing？
它是 LLM 应用的**"中枢神经系统"**。它的任务不是直接回答问题，而是作为流量调度器，在毫秒级内"看清"请求的本质，并决定将其分发给最合适的执行单元：是一个昂贵的高参数模型、一个极速的本地模型、一个专业的检索系统，还是一个预定义的 Python 函数。
二、 工程价值：从"省钱"到"提效"
- 模型分流与成本治理 (Model Tiering)：
企业应用中，80% 的请求往往是简单的。通过路由将简单任务导向轻量模型（如 GPT-4o-mini），仅让 20% 的硬核逻辑占用高成本模型，综合成本可降低 70% 以上。 - 能力边界的解耦 (Capability Routing)：
大模型并非万能。路由能让模型在擅长的领域发挥，在不擅长的领域求助：计算任务交给代数引擎，时效性任务交给搜索插件。 - RAG 的精准控制：
并非所有问题都需要检索。路由能有效识别"闲聊"，避免强行插入无关的检索片段（Context Contamination），显著降低首字延迟（TTFT）。
三、 核心：四种意图类型的路由策略
构建路由系统的第一步，是建立清晰的"意图-路径"映射表：
| 问题类型 | 核心特点 | 路由终点 | 核心工程手段 | 示例 Query |
|---|---|---|---|---|
| Factual (事实) | 考查私有知识、最新资讯 | RAG 链路 | 向量数据库 + 重排 | "公司去年的报销政策是什么？" |
| Reasoning (推理) | 考查逻辑、规划、运算 | 高级模型 / Agent | 思维链 (CoT) + 递归规划 | "对比两份报告分析 A 和 B 的优劣。" |
| Procedural (过程) | 考查指令执行、API 调用 | Tool Use | Function Calling | "帮我预定明天下午三点的会议室。" |
| Chit-chat (闲聊) | 情感交流、简单礼貌 | 轻量级模型 | 语义缓存 (Semantic Cache) | "你好，你今天心情怎么样？" |
四、 核心算法：意图置信度（Confidence Score）怎么算？
置信度（Confidence Score）是路由系统的"定海神针"。它决定了系统是该"自作主张"地执行指令，还是"卑微"地向用户求证。根据系统复杂度的不同，计算方式分为基础算法与混合权衡。
1. 基础场景：单一维度的量化
如果你仅使用一种路由手段，置信度的计算相对纯粹：
- 语义路由（Embedding-based）：
计算用户 Query 向量与预设意图向量簇的余弦相似度。
工程标准： 通常相似度 被视为高置信度。
- 模型路由（LLM-based）：
- Logprobs（对数概率）： 提取模型生成"意图分类标签"时该 Token 的概率值。
- Self-Reflection： 在 Prompt 中要求模型以 JSON 格式输出
score（1-10）。
工程标准： 分数 视为确信。
2. 进阶场景：混合架构下的"决策漏斗"
在"正则 + 向量 + 大模型"的混合架构中，不同路由器的输出维度不同（苹果和橘子无法直比）。此时，置信度演变为一套优先级漏斗逻辑：
A. 优先级链条（Priority Chain）
混合架构不采用简单的加权平均，而是按确定性由高到低进行逻辑截断：
- L1 静态层（正则/关键词）： 命中即 。一旦匹配（如"退出"、"重来"），立即拦截，不再触发后续计算。
- L2 语义层（向量匹配）： 若 L1 未命中，计算向量相似度。
- L3 模型层（LLM 仲裁）： 若 L2 的分数处于"灰色地带"（如 ），则激活小参数模型进行最终语义裁决。
B. 异构分数归一化（Score Normalization）
为了在控制台中监控整体表现，我们需要将不同维度的信号映射到同一个坐标系 ：
| 路由源 | 原始信号 | 归一化逻辑 |
|---|---|---|
| 正则/静态 | Boolean | Match = 1.0; Non-match = 0 |
| 向量相似度 | 区间拉伸：根据实验阈值 映射。例如 | |
| LLM 自评 | 1-10 整数 | Score / 10.0 |
3. 动态修正：引入上下文权重（Context Bias）
在生产环境，置信度计算还需加入"时空变量"。例如，用户输入"怎么弄？"，这在任何维度下置信度都很低。
但如果前序对话是在讨论"发票申请"，我们可以给"财务类意图"增加一个 **先验权重 **：
通过这种方式，系统能更好地处理模糊表达，减少反问次数。
4. 决策水位线（Thresholding）
最终，系统根据计算出的综合分 做出动作：
- 执行区（）： 自动分流。
- 澄清区（）： 触发 Clarification Loop。系统询问："您是指查询订单，还是申请售后？"
- 降级区（）： 路由失效。转发给全量高级模型或人工处理。
五、 实现范式：漏斗式混合架构
为了平衡精度与延迟，成熟的系统通常采用**"三级过滤"**：
- 静态路由 (Static)： 利用正则匹配或关键词（如"查一下"、"预定"）。延迟几乎为 0。
- 语义路由 (Semantic)： 利用向量相似度匹配预设意图。速度极快（< 50ms），具备模糊处理能力。
- 模型路由 (LLM-based)： 使用小参数模型执行 N-Class 分类任务。虽然增加了几十毫秒延迟，但对语境理解最准。
六、 工程边界情况：那些"坑"在哪里？
-
模糊意图 (Ambiguity)： 当用户输入"那个东西怎么弄"时，强行路由会导致灾难。
-
对策： 引入 Clarification Loop（反问机制）。当置信度低于阈值（如 0.6）时，触发反问 Prompt 而非强行分流。
-
路由递归 (Router Loop)： 在 Agent 架构中，Router 可能导致逻辑死循环。
-
对策： 设置 Max Iterations（硬性步数限制），一旦超过 3 次未出结果，强制降级到高级模型。
-
性能开销 (Overhead)： 路由本身不能成为瓶颈。
-
对策： 对分类结果进行 Semantic Cache（语义缓存），相同语义的请求直接复用路由结果。
七、 实战案例：从输入到结果的路由全过程
案例 1：知识问答型（Factual / RAG）
- 用户输入： "公司最新的居家办公补贴申请流程是什么？"
- 路由决策： 识别"申请流程"，意图置信度
Factual: 0.95。 - 分发路径： 触发 RAG 链路 -> 检索 Wiki -> 提取文本 -> 小模型摘要。
- 效果： 确保了 100% 准确性，避免了"AI 瞎编"补贴金额。
案例 2：复杂任务型（Reasoning / Tool Use）
- 用户输入： "对比上季度报表，分析华东区利润下滑原因，并生成邮件。"
- 路由决策： 识别"对比"、"分析"，意图置信度
Reasoning: 0.88。 - 分发路径： 路由至 高级模型 (GPT-4o) + SQL 插件。
- 效果： 充分利用大模型的逻辑规划能力，虽延迟稍高，但解决了核心业务痛点。
案例 3：低价值冗余型（Chit-chat / Cache）
- 用户输入： "太棒了，谢谢你！"
- 路由决策： 命中 语义缓存 (Semantic Cache)。
- 分发路径： 路由至 本地轻量化模型 (Qwen-1.8B) 或返回预设话术。
- 效果： TTFT（首字延迟）降至毫秒级，且无需支付高昂的 API 费用。