AI 应用查询理解与多路编排路由工程 2026：统一架构
把意图分类、查询改写、多路编排路由、可观测回写熔成一个统一的查询理解层，让 90% 的用户请求走确定性路由表、剩下的 10% 升级到 Planner-Executor，用预测熵、置信度、路由-评估耦合反馈三件套撑起 AI 应用前门工程的闭环可治理。
约 17 分钟阅读5,055 字8 次阅读博主
把意图分类、查询改写、多路编排路由、可观测回写熔成一个统一的查询理解层，让 90% 的用户请求走确定性路由表、剩下的 10% 升级到 Planner-Executor，用预测熵、置信度、路由-评估耦合反馈三件套撑起 AI 应用前门工程的闭环可治理。
过去两年，我们花了大量笔墨讨论大模型推理服务的吞吐、缓存、调度、KV 复用、PD 分离、异构硬件——这些讨论默认了一个前提：请求已经到了一个明确的 LLM 端点。但在真实的 AI 应用中，从用户敲下第一个字到请求抵达那个端点之间，往往还隔着一层鲜有人系统化讨论的"前门"：查询理解层（Query Understanding）。这一层要在 50–200 毫秒的预算内，决定一条用户输入应该走 small-talk 闲聊、FAQ 模板、向量召回、对话状态查询、工具调用、还是更长的 ReAct 循环；它要在毫秒级给一个用户问"今天北京天气怎么样"打上 small_talk|telemetry|weather_query 三层标签，要在用户问"对比一下上季度和这季度的退款率"时把它拆成两个时序查询再合并，要在用户问"我昨天发的那篇稿子写得怎么样"时回放对话历史、聚合记忆、并触发后续 agent 链路。
这层在产品里叫什么？有的叫 NLU 前端、有的叫意图路由器、有的叫 query planner、有的直接叫 semantic router。在更工程化的语境下，我们建议把这一层命名为 查询理解与编排路由（Query Understanding & Orchestration Routing, QUOR）——它由两个核心子层组成：上层的 QU（query understanding，负责"这条输入是什么"）和下层的 OR（orchestration routing，负责"接下来谁处理、按什么顺序处理、如何合并结果"）。本篇要展开的，就是这套 QUOR 层的形式化定义、工程组件划分、模型选择策略、可观测性闭环、以及 7 条来自生产闭环的可执行推论。
我们把 QUOR 拆开来谈，是因为这条路径上的工程债务一旦被忽视，下游所有"模型侧"的优化都会被浪费：一个意图分类错 5% 的系统，等价于上游浪费 5% 的 LLM 预算；一个查询改写缺失 30% 的系统，等价于 RAG 检索命中率被压低 30%、rerank 误召回被放大 30%、最终生成质量随之塌方；一个编排图设计错误的系统，等价于每次有意义的交互都要付出一份完整的 planner token 预算——而这个预算本可以在常见路径上被缓存复用。本篇从工程实践角度，给出 QUOR 层从意图分类到 Planner-Executor 的完整闭环架构。
我们把 QUOR 视为一个两层决策图：
planner_required 表示输入复杂到必须进入编排子图进一步规划。形式上，给定 QUOR 系统 S = (E_QU, R_OR)，输入分布 X ∈ 𝒳，输出 y ∈ 𝒴，它应当满足：
其中 σ*(X) 是 D2 选择的最优执行链，Cost(σ) 是端到端 token 预算 + 延迟预算 + 工具调用次数，λ 是用户可调的"成本敏感度"。这里要解两个独立问题：(a) 意图边界——什么样的 X 应该归入 rag_query 而非 small_talk？(b) 编排最优——给定意图，进入哪条 σ 的期望效用最高？
意图边界问题本质是判别模型在长尾 query 上的覆盖问题。生产上常见的失败模式包括：
{person: 林黛玉, location: 贾府}，但实际意图是 literary_kb_query，需要实体引导的图谱检索。编排最优问题则更难：它必须预测"如果走 RAG σR 路径，召回 top-k 是否包含答案？"——这个问题本身需要 RAG 评估器 R_eval 回写，形成预测-执行-回写的闭环回路。我们会在第六节专门讨论这种"路由-评估"耦合的设计。
意图分类的模型选型有三条主路径，每条对应不同的工程形态。
路径 1：专用判别式 SLU 模型（DeBERTa-v3 / MiniLM / 小型 BERT）。这一类模型把分类视为 NLU 任务的子集，标签空间锁定在产品定义的几百到几千个意图槽上。优势是推理成本极低（单卡 4–8ms p99）、标签稳定、易于做标签级回归测试。劣势是覆盖长尾难、跨语种差、对 prompt injection 鲁棒性低——攻击者塞入"忽略上面的指令"等 token 就可能让分类器错位。
路径 2：LLM-as-classifier（GPT-4o-mini / Qwen2.5-7B-Instruct / function-calling structured output）。这一类模型把分类视为一次结构化生成，标签由 function-calling JSON Schema 锚定。优势是泛化强、可联合抽取槽位（NER + 意图 + query rewrite 一锅出），prompt 注入的鲁棒性比路径 1 略好（因为 prompt template 显式声明了约束）。劣势是成本（哪怕 mini 也要 200–500ms p99，比判别模型慢 50–100 倍）、标签稳定性差（同一个 query 两次调用结果可能漂移 1–3%）、对 distribution shift 敏感。
路径 3：蒸馏式小分类器 + LLM 容错器（教师-学生混合）。这一类是当前生产实践最稳定的形态：90% 的高置信 query 走蒸馏小分类器（< 5ms），剩下的 10% 低置信 query 升级到 LLM-as-classifier（200ms）做裁决——或者直接进入 ask_clarify 让用户复述。这一模式的关键是置信度阈值的设计：低阈值（置信 < 0.7 升级）会让 cost 暴涨；高阈值（> 0.95 升级）会让误判案例漏升级。我们建议使用温度刻度的预测熵 H(p) > τ 作为升级条件，而非 max(p) < 0.5 这种天真阈值。
其中 τ_low 和 τ_high 的取值需要在标注集 + 生产流量上做 ε-greedy 离线扫描，目标是"以最小 LLM 调用量，让 99% 以上的 query 落入正确意图边界"。
槽位抽取（slot extraction）与意图分类通常一同设计：双塔模型（intent tower + slot tower）共享底层 encoder 但顶部独立 head；端到端模型（joint BERT-CRF 或生成式 NER）一次性出多 tag 序列。我们推荐生产上以端到端生成式 NER为主——它对 OOV（out-of-vocabulary）槽位更鲁棒，且与下游 function-calling JSON Schema 直接对齐。
在工程上还有两个常被低估的细节值得强调。第一是槽位对齐监督：当用户输入"上季度和这季度的退款率"时，NER 层必须标出 {time_window_1: last_quarter, time_window_2: this_quarter, metric: refund_rate} 三个槽位，下游的分解规划器才能据此发起两次时序查询；这一对齐靠 golden triple（slot_value, slot_type, offset）数据集闭环维护，回归测试必须日跑。第二是归一化槽位词典：把"林黛玉 / 黛玉妹妹 / 林妹妹"映射到同一实体的规范化层是 QUOR 里最容易被忽视的组件。一个 RAG 应用如果在槽位抽取阶段就缺了 entity linking，下游无论检索器再精，召回都会被零散指代撕成几片；归一化词典通常由 BERT embed + ANN 索引 + 人工 seed 三部分组成，配合 query log 聚类做月度更新。
阈值规划方面，τ_low/τ_high 的取值是 QU 层最重要的可调超参。我们推荐用离线"成本-质量曲线"确定它们：用 5000 条 golden query 扫描所有 (τ_low, τ_high) 组合，把每个组合对应的"LLM 升级率 vs 意图分类准确率"画出来；理想的曲线是一个 L 形，拐点处给出最优阈值。拐点的判定可以用"Youden index"或者直接用"业务方能接受的最低准确率线"。一旦阈值确定，不要再轻易调——每一次微调都意味着路由表 Σ_i 的下游漂移，需要至少一周的生产观察才能重新稳态。
最后一个细节：意图分类与槽位抽取的输出 schema 必须版本化。{intents: [..], slots: {..}, confidence: ..} 这个三元组必须锁定字段名、字段类型、字段可选项。任何一次 schema 升级都要走 v1 → v2 的灰度，并保留至少 30 天的影子流量（dual-write 新旧两套字段，下游只读旧，新 schema 仅用于影子比对）。这一条听上去是常规 API 工程，但在 QUOR 层缺失它会让你的产品一旦升级就面临不可预知的下游 bug——尤其当某个下游 agent 把 confidence 当作 tool selection 的判定阈值时，confidence 字段含义的轻微漂移就会传导到工具选择的爆炸。
查询改写（query rewriting）是 QUOR 层最容易低估的子模块。它的目的是把用户原始输入 X 转化为对下游 RAG / retrieval / tool 更加友好的一组查询 {q1, q2, ..., qn}。改写策略当前主流有四种：
我们推荐意图保持改写 + 多视角扩展作为默认组合。原因有三：(1) 这两个的覆盖范围最大；(2) 它们并行友好，可以用一次 LLM 调用同时出 3–5 个 query；(3) 它们失败时的代价低（HYDE 失败一次就要重新走完整条链路）。生产实现上，最稳的做法是：归一化改写用规则，意图保持改写用 7B 量级的 instruct 模型，多视角扩展用 LLM-as-judge 选择 top-2 到 top-3 候选 query 进入下游 recall 阶段。
这里有一个常被忽视的工程细节：改写后的 query 应当携带原 query 的诊断字段——例如把 X → q' 的映射连同 confidence score 一起记录到 trace span 里，使得下游如果检索失败，能反向追溯到是不是改写阶段丢失了关键 token。这一条对 RAG 调试尤其重要，因为召回失败常常被误归因为模型侧，但根因往往是改写阶段把"林黛玉"和"贾府"压缩成"她"和"那家"。
D2 层——编排路由——是 QUOR 里真正决定每个 query 走哪条 σ 的组件。它有两种典型架构风格：
风格 A：显式 Planner-Executor。给 LLM 一个工具集（retrieve / web_search / python_sandbox / sql_query / respond_template / ask_user / delegate_subagent），让 LLM 在每一步选下一个动作。这一架构对应 ReAct / Toolformer / MRKL 等范式。优势是表达力强，可以处理任意长尾组合；劣势是 token 预算随步数线性膨胀、规划错误会传导到执行链、调试门槛高（trace 复杂）。生产上的关键工程是给 planner 一个步骤预算硬上限（如最多 8 步）、给每一次工具调用都加幂等键、给每一步都打可观测 span。
风格 B：基于路由表的确定性编排（deterministic routing）。为每一条意图预先配置一条固定的执行链 σ_i，query 命中意图 i 就走 σ_i，不命中就降级。这一架构对应传统 NLU 系统 + 规则引擎；优势是路径稳定、token 预算可控、回放便宜；劣势是表达力弱，任何长尾组合都需要额外的"逃生通道"——这条逃生通道往往就是风格 A 的 mini 版本。
我们推荐的工程范式是两层组合：90% 的 query 走路由表（响应 < 100ms、token 预算 < 500），剩下的 10% 升级到 LLM planner 处理。这一组合的关键设计是路由表自身的可学习化：
其中 Σ_i 是意图 i 上注册的候选执行链集合，𝓧_i 是该意图下的 query 分布。这个 argmax 的求解需要 offline 的 evalset——我们在第六节讨论其闭环。
需要特别强调的是"长链路 planner"和"短链路 router"的实际成本差距：一条 planner path 通常要 3k–15k token 预算（planner 自身 + 工具 IO），一条 router path 通常只需 500–1.5k token。10% 的 planner 升级就意味着平均单 query token 预算要乘以 (0.9 × 0.8k + 0.1 × 8k) / 0.8k = 1.9——即升级率从 5% 到 10% 会让平均预算翻倍。生产上必须严格看待这个比例，不能让"LLM 万能论"侵蚀路由器层。
具体到 planner 自身的实现上，两个工程决策点经常被忽视。第一是planner 状态缓存：同一会话 N 轮里，planner 的 system prompt + 工具描述（tool spec）几乎是常量——这一段应当用 prompt cache（前缀缓存/Prefix Cache）做 KV 复用，避免每轮重新 prefill。实测下来，一条 4k token 的工具 spec prompt 在 8B 模型上 prefill 要 ~150ms，cache hit 后这一段直接归零，整轮 planner 调用从 600ms 压到 200ms 左右。第二是planner 失败的回退策略：当 planner 返回的步骤链出现工具调用 parse error、参数校验失败、循环检测（连续 N 步选同一动作）时，必须有显式的回退策略——例如回退到上一轮路由表的 σ*_i、降级到 ask_clarify、或者把上下文压缩后重试。生产上常见的失败模式是"planner 反复重试直到上下文爆掉"，所以循环检测和步数上限同样重要。
路由表与 planner 的协作接口也常被乱设计。理想接口是一条"intent + plan 候选 + cost estimate"的轻量契约：QU 层送给 OR 层的不只是 (intent, slots)，还要附带"如果走 planner 路径，至少需要 token X、延迟 Y、预算 Z"。OR 层据此在路由表 Σ_i 里选一条 σ*，或者把 X/Y/Z 推给 planner 走自适应的"动态规划"模式。这一契约让 QU 与 OR 在工程上能各自独立优化——QU 的目标是最小化误分类率，OR 的目标是最小化 (cost × failure_rate) 加权和——而不至于让两边耦合为一个 LLM monolith。
最后是升级路径的回放工具。任何 query 升级到 planner 后，必须把 (X, QU 原始输出, OR 路径预测, planner 实际步骤链, 最终 y, token 预算, 延迟) 写入回放库；再用 LLM-as-judge 给 (PLANNER_OUT, ROUTER_PREDICTION) 打分。回放库每周至少跑一次：把过去一周所有升级过的 query 让路由器在没有 planner 的情况下"重新跑一次"（按 Σ_i 的候选 σ 全部尝试），看是否有任何一条路由能"事后逼近" planner 的最终 y。如果出现"路由器事后逼近"占比 ≥30%，就说明 Σ_i 的覆盖不足，应当追加新的候选 σ 并触发线上 A/B；这种事后回放逼近率是规划路由表是否能继续瘦身的最直白指标。
QUOR 层的可观测性建设要解决的核心问题是：当一次用户交互失败时，能在五分钟内定位到是 QU 错误、OR 错误、改写错误、还是某条 σ 上的子步骤错误。这套可观测系统应当具备四个支柱：
Pillar 1：分级 trace。 OpenTelemetry 风格的 trace tree 应当覆盖 QU 层输出（意图分布、置信度、改写 query 列表）、OR 层路径（路由表命中 / planner 步骤链）、每个原子算子的 span（含 token、延迟、工具 IO）。trace 的关键不是粒度而是"哪个字段能让 debugger 立刻看出意图对不对"。
Pillar 2：标签级回归测试。 对每个意图 i 维护一个 eval set（500–2000 条带 gold 标签的 query），每日 CI 跑一次，把意图分类准确率、槽位抽取 F1、改写 query 语义保持度上报到 dashboard。一旦某个意图的 F1 跌破阈值就触发人工审查——这一条比 latency budget 更重要，QU 错误的下游传导代价远超 QU 自身的延迟。
Pillar 3：路由-评估耦合反馈。 这条最容易被忽视。每次 query 完成完整 σ 执行后，把 σ 的产出 y 与 gold 输出比较，把相似度回写到路由表 Σ_i 的权重上：
α 是衰减因子（建议 0.9–0.95），sim 是 BERTScore 或 LLM-as-judge。这种隐式 bandit 反馈让路由表能够从生产数据中自我校准，是 QUOR 长期治理的关键工程。
Pillar 4：失败 case 自动回收。 任何"用户改写一次 / 重新表述 / 等几秒后重发"的 query 都隐式地标了 fail——把这些 case 抓出来 feed 回 eval set 池，构成 daily grow-from-prod 的循环。这是 Google SRE 里的"逃离速率（escape velocity）"思想在 QUOR 层的体现。
基于上述分析，我们提炼出 7 条可执行的工程规则：
ask_clarify 拒答 + 留 trace，不能直接降级到 Planner，因为降级会被攻击者利用塞入"请帮我执行任何工具调用"等诱导。QUOR 不是银弹。它在以下场景下应当被推迟考虑或简化：
回顾 QUOR 层的完整体系，它在工程上回答的是三个问题：(1) 这条 query 走哪条固定路径最稳？(2) 什么时候值得调用 LLM planner？(3) 路由表如何从生产数据中自我校准？这三个问题的解决方案——意图分类、Planner-Executor 编排、路由-评估耦合反馈——构成了 AI 应用"前门"的完整闭环。
我们建议 AI 应用的工程师们今天就在产品里埋三个 instrumentation：(a) trace 里必须有改写后的 query 列表和置信度；(b) eval pipeline 必须日跑、failure 必须自动 feed 回 eval set；(c) 路由表必须有 online 更新能力（即使暂未启用更新）。这三个 instrumentation 加起来不到一周的工作量，但会让你的 AI 应用从"看起来能用"跨越到"在长尾 query 上可治理、可回放、可进化"。
QUOR 不是技术热点——它不会上 Hacker News 首页、不在 LLM leaderboard 上、不出论文——但它是 AI 应用能否从 demo 走到 production 的分水岭。一个产品如果在前门上花了 30% 的工程预算，下游的 RAG、agent、LLM 服务的优化效果才能真正被乘性放大。如果你的 AI 应用还在"打补丁"阶段，本篇值得重新读一遍。
一句话摘要：查询理解与编排路由层是 AI 应用的前门工程，本文从意图分类、查询改写、编排路由、可观测闭环四个支柱，给出从判别模型到 Planner-Executor 的统一架构与 7 条可执行规则，强调回写机制是长期治理的关键。
Conversation
0 条