路由即产品：为什么你的低成本分类器比旗舰模型决定了更多行为

我上个季度接触的一个团队上线了一个他们称之为“路由项目”的东西：在他们的旗舰模型前端放了一个微型 BERT 分类器，用来判断查询是否足够简单，以便分流给更便宜、更快速的备选方案。这个项目在三周内就回本了。成本仪表盘上绿光一片。旗舰模型的评估套件——包含三百个对抗性案例、每周的评分运行等等——依然在每个周五稳稳通过。

上线六周后，某个特定产品界面的留存率下降了四个百分点，没人能找到原因。旗舰模型表现正常。延迟也正常。结果发现，路由竟然将 71% 的查询发送到了廉价模型。这种情况从第二周就开始了。对于大多数用户来说，这个廉价模型才是真正的产品，而这个廉价模型根本没有任何评估套件。

这是我在 2026 年看到的采用 LLM 路由进行成本控制的团队中最常见的失败模式：评估规范被绑定在系统的昂贵长尾部分，而廉价的头部部分——即承载大部分请求量、定义了产品体验的部分——却处于盲跑状态。

路由不是优化手段，它就是产品界面

路由被当作一种成本杠杆来推销。这种说法很耳熟：顶级前沿模型每百万 token 的价格为 30 到 60 美元，中端模型为 10 到 15 美元，而小型开源权重模型低至 0.10 到 0.50 美元。在前端放一个小型分类器，将简单的查询发送到廉价层级，你的账单就能减少 30% 到 85%，且“质量影响极小”。

推广这种方法的框架 RouteLLM 证明了在 MT Bench 上，仅向 GPT-4 发起 26% 的调用即可达到其 95% 的质量。这个数字是真实的。但如果你不盯着它的反面看，它也是危险的：这意味着 74% 的查询流向了廉价模型。如果廉价模型处理了 74% 的请求，那么它就对你 74% 的产品行为负责——而且大约 74% 的新用户在判断你的产品是否好用时，看到的是它的表现。

团队把路由当作负载均衡。他们像评估产品一样评估旗舰模型。但你的用户并不直接面对旗舰模型；他们面对的是路由决策的输出。如果路由校准哪怕只是稍微向廉价方向倾斜一点，典型的用户体验就不再是你的旗舰模型，而是一个在紧张的延迟预算下解读模糊提示词的小型模型。那才是产品。旗舰模型只是在少数流量下触发的备选方案。

架构上的认知既简单又令人不安。你的评估投入应该与每条路径处理的流量份额成正比。如果 70% 以上的查询命中了廉价路径，那么你 70% 以上的评估工程应该针对那里。大多数团队的做法恰恰相反：90% 的评估都指向了只处理 30% 负载的模型。

当路由未经评估时，会产生叠加的失败模式

当你不单独评估路由层时，四种失败会悄然堆积。

路由假阴性。 路由看到一个确实需要旗舰模型的查询，却判定它“简单”，并将其分发给廉价模型。廉价模型不知道自己无法胜任，所以它不会上报——它直接回答。基于自一致性的升级机制只有在廉价模型在样本间产生明显不一致的输出时才会触发；而那些需要旗舰模型处理细微差别而非原始正确性的查询，则会悄无声息地溜走。用户得到了一个自信、看似合理但错误的回答。没有异常抛出。没有告警触发。点睬率上升了 0.5%。

语言或主题偏差。 你的路由是在昨天的流量上训练的，而昨天的流量偏向英语、西方产品名称和特定的边缘案例词汇。对于分类器来说，西班牙语或普通话的新查询看起来比实际“更简单”，因为分类器在训练中很少正确处理这些语言，从而学会了默认处理。因此，你上线了一个没人设计、也没人监控的语言质量差异——因为评估集也主要是英语。更糟的是：你的业务 KPI 也会反映出这一点，“非英语用户参与度较低”会被归结为本地化差距，而不是路由校准失误。

新查询类型的漂移。 基于历史流量训练的路由会系统性地误路由那些在训练集冻结时还不存在的查询。新功能上线后，用户开始询问一种新的问题，路由从未见过这种分布，于是它回退到它的先验值——这通常意味着廉价路径，因为训练优化奖励了在主流历史分布下的廉价路径选择。新产品界面得到的路由最差，恰恰是因为它们是新的。关于“路由崩溃时”发生什么的最新研究描述了路由会收敛到退化行为，无论输入是什么都默认使用一个模型——这是一种特别糟糕的漂移形式，分类器无声地停止了分类。

对抗性重路由。 “重路由 LLM 路由 (Rerouting LLM Routers)”系列研究表明，对输入的微小扰动可以翻转路由决策，攻击者可以故意设计查询措辞，以强迫升级到昂贵层级（成本放大攻击）或分发到廉价层级（质量攻击）。如果你的路由只是一个没有经过对抗性训练的微调分类器，你就为经济型和质量型拒绝服务攻击提供了一个侧信道。

这些都不是理论上的假设。每一个都是团队最终去查看时会发现的真实现象。他们没有早点发现的原因是，他们从前路由时代带过来的评估规范是运行在模型上的，而不是运行在路由决策上的。

难度校准：将路由决策与回答质量分开评估

修复方案并非“将廉价模型添加到你现有的评估套件中”，尽管你也应该这样做。真正的修复方案是意识到现在有两个产品需要评估：

1. 给定路由决策后，模型的回答质量。
2. 路由决策本身。

这是两个不同的产品，有着不同的指标。模型评估问的是：“既然这个查询分配到了这个模型，其响应是否正确？”而路由评估问的是：“给定这个查询，将其发送到这个层级是否是正确的决定？”

为了评估路由决策，你需要为每个查询打上难度标签。获取难度的方法可以参考 RouteLLM：向旗舰模型和廉价模型发送相同的查询并分别打分，将分数差距作为判断是否需要升级调用的基准真相（ground-truth）信号。如果廉价模型的分数与旗舰模型的分数差距在 ε 范围内，那么走廉价路径就是正确的选择。如果差距很大，则说明需要旗舰模型，路由器本应该进行升级调用。

有了难度标签，路由层就有了自己的混淆矩阵——误报升级（False-positive escalation，发送到了旗舰模型但其实不需要：纯粹的成本浪费）和漏报升级（False-negative escalation，留在廉价路径但其实需要旗舰模型：纯粹的质量损失）。这些才是路由器的实际 SLI。延迟和成本只是它们的下游产物。

最具参考价值的衍生指标是升级率（escalation rate），并按查询细分进行切片。如果总升级率漂移上升同时成本增加，那是分类器漂移（classifier drift）——路由器正在失去信心并过度转向旗舰模型。如果升级率漂移下降同时质量下降，那是分类器崩塌（classifier collapse）——路由器正越来越多地将所有内容都交给廉价路径处理。无论哪种模式都是路由事故，独立于任何模型事故。

影子路由：保持路由器诚实的最廉价方式

如果事后再计算，大规模获取难度标签的成本非常高。影子路由（Shadow routing）是一种让成本降低的运维实践：在生产环境中每隔 N 个查询取样，同时运行两条路径，记录廉价路径的响应和旗舰路径的响应，并由评审员（LLM 即评审或少量的人工审核队列）对不一致的地方进行评分。

影子路由具有三个重要的特性：

• 它运行在真实的生产流量上，因此它能自动代表当前的分布情况——包括你离线评估集尚未覆盖的新查询类型。
• 它是观察性的，而非实验性的。用户只能看到生产环境的路由决策；影子路径的输出会被记录并丢弃。因此，影子路由对用户没有影响，不需要像 A/B 测试那样经过产品端的批准。
• 不一致信号比任何离线评估都更密集。即使 N=100，一个中等流量的产品每天也能获得数千个难度样本，并按语言、主题和用户群进行细分。

影子路由与差异分检队列配合使用。当廉价回答与旗舰回答的偏离程度超过设定的阈值时，该查询、两个响应以及路由决策会被归档到一个队列中，由值班 AI 工程师每周进行审查。该队列也是下一批路由器重新训练的来源——路由器从它判断错误的查询中学习最多，而它本身无法识别这些错误。

在发布路由器（或修复已发布的路由器）之前需要进行的插桩

如果你只从中记住一件事：每个路由决策都必须是一个一等可观测性维度，而不是一个隐藏的内部状态。

• 每个 Trace 的路由标签。 每个请求日志都应包含路由决策（选择了哪个层级）、路由原因（驱动决策的规则或分数）、路由模型版本以及路由置信度分数。你的成本仪表盘、质量仪表盘、延迟仪表盘、留存切片——所有这些都应该在这个维度上进行切片。如果出现回归，你可以在几秒钟内回答“这是路由问题还是模型问题？”
• 将升级率作为 SLI。 为升级率设定一个目标区间（例如 18-24%）。对超出该范围的任何波动进行报警。你可能会倾向于抑制上限警报，因为“更多的升级意味着我们更安全”——请抵制这种冲动。升级率向任何方向的偏移都是分布偏移的信号，意味着路由器已经无法跟上现状。
• 按细分的质量切片。 质量指标应按路由决策以及用户细分（语言、地理位置、客户等级、查询主题）进行切片。你不去衡量的差异，就是你交付出去的差异。
• 影子路由队列。 建立一个常态化的后台采样，即使采样率很小，也要配合差异分检流程。没有这个，你就没有关于难度的基准真相来源，每一次重新训练都将是凭感觉驱动的。
• CI 中的对抗性探测。 一组精心设计的查询——例如不应改变层级的同义改写，或必须升级的边缘案例——在每次路由器发布时运行，就像类型检查（typecheck）在每次构建时运行一样。路由器会以旗舰模型不会发生的方式静默回归，因为它们更小，且对输入分布更加脆弱。

你的工程副总裁需要听到的产品定位重构

团队在路由评估（router eval）上投入不足的原因是组织架构问题，而非技术问题。路由由平台/基础架构团队负责，因为它看起来像是一个基础架构组件。评估则由 AI/应用团队负责，因为它们看起来像是一个模型质量问题。没有人获得资金支持去评估路由层的产品影响，因为没有人将“廉价路径”视为一个产品交付面。

能够获得支持的重构思路是：廉价路径才是最常被使用的产品。如果 70% 的用户在 70% 的查询中都能看到它，那么它就值得你投入与旗舰界面同等的产品管理规范。这意味着需要一个负责路由产品用户侧质量的产品经理（PM），一个其仪表盘权重根据流量占比而非模型重要性来计算的评估负责人，以及在事故管理分类中设立一个独立于模型事故的路由事故类别。

成本感知路由是 2026 年 LLM 系统中杠杆率最高的模式之一。它也是那个“无人关注的小细节”决定用户实际体验的地方。旗舰模型是你的工程师们引以为傲的资本。而路由才是真正交付给用户的东西。