你的模型路由是基于评估集训练的，而不是你的真实流量

我上个季度交流过的一个团队发布了一个模型路由（model router），在离线基准测试中获得了 96% 的路由准确率，并使平均推理成本降低了 58%。但在运行三周后，支持工单开始集中在特定的用户群体中——即那些通过 API 运行脚本化批量查询的企业管理员。低成本路径向这些用户发送了大量垃圾回复。路由完全按照设计运行，但设计本身错了。

这个故事代表了常态，而非特例。“能用小模型就用小模型，必须用大模型时才用大模型”的架构是生产环境下 LLM 系统中最可靠的成本杠杆之一，在标准基准测试中记录的成本降幅在 45% 到 85% 之间。但每个路由演示中引用的节省数字都假设了基准测试的分布。生产流量并不具备这种形态，而两者之间的差距正是质量回退（quality regressions）存在的地方——这些回退集中在你的离线评估（eval）从未设计覆盖的细分领域。

这里的深层失败并不是某个特定路由的 bug，而是一个范畴错误（category error）。我们一直把这些东西当成分类器来构建——训练、验证、发布、监控准确率。但它们不是分类器，它们是控制系统。而在控制理论中，一个没有被控对象反馈的控制系统是“开环”的，这在控制理论中是“坏掉”的委婉说法。

基准测试设定了分布，且分布是“干净”的

看看典型的生产路由是如何构建的。团队选择一个基准测试——MT-Bench、MMLU、GSM8K，或者是一个为了涵盖其用例而生成的合成查询集。他们同时针对这些测试运行低成本模型和昂贵模型，标注哪些查询是低成本模型可以正确处理的，然后训练一个分类器，通过查询特征来预测“低成本模型是否可以处理此项”。

路由得分很高。这理所当然。基准测试是由理解任务的人构建的。查询是格式规范的句子。每个查询表达一个意图。输入是干净的，且在模型的上下文窗口内。边缘案例的比例也是某人认为合理的。

但生产环境完全不是这样。生产环境是以下情况的长尾集合：

• 格式错误的输入。 带有复制粘贴痕迹、清理不彻底的 HTML、末尾带有三个问号的查询，或者某人本想粘贴一个句子却意外转储的文件内容。
• 多意图查询。 用户在同一轮对话中先问一个问题，接着问另一个问题，然后又进行补充说明。基准测试是按主要意图标注查询的，但生产环境没有主要意图。
• 分布外领域。 新产品发布后，用户发送了关于基准测试编写时还不存在的功能的查询。路由将其视为熟悉的形状，因为表面特征看起来很普通。
• 对抗性异常。 用户以没人预料到的方式进行提示，脚本客户端提交格式错误的 JSON 作为查询，以及在单条消息中混合多种语言。

路由无法分辨其中的区别。它的特征是针对一个几乎不存在这些输入的世界进行校准的。因此，它自信地将它们路由到低成本模型——得到的回复很差，而且在任何仪表盘上都不会显示为路由错误，因为路由完全按照其训练数据的要求执行。

错误是成簇的，而这种聚集性才是核心

这是团队在报告聚合路由准确率时经常忽略的部分。基于基准测试训练的路由在生产中的失败并非均匀分布在用户中，而是呈严重的聚集状态。

这种聚集几乎每次都遵循相同的模式：

• 一小部分具有异常使用模式的用户——高级用户、API 客户、自动化脚本、企业脚本。
• 特定功能面上的输入形态与自然聊天不同——批量处理、程序化客户端、集成插件。
• 基准测试覆盖率较低的特定区域或语言。
• 工作流中的某个阶段，此时上下文已经累积，提示词在结构上与新鲜对话大不相同。

你的整体 P99 路由质量看起来不错，因为这些细分领域仅占总流量的 3%。但对于这 3% 的用户来说，路由正在静默地将本需要大模型的查询分配给小模型，导致这些用户看到的是你产品最差的版本。而且，这些用户往往也是那些会大声抱怨、提交工单、写差评并告诉同事的人，他们的流失率极高。

这就是为什么当团队询问是否要发布路由功能时，我开始使用这个框架：“长尾路径中的质量损失往往超过了热路径上的成本节省”。节省是真实的，但其代价是由一小部分无法容忍劣质回复的用户支付的。这种账目核算方式很少被采用。

路由是控制系统，而非分类器

解决方案不是更聪明的分类器，而是不同的心智模型。分类器将输入映射到标签，并通过留存准确率来评判。控制系统则引导过程走向目标输出，观察结果，并根据目标与观察值之间的差距进行调整。两者的成功标准截然不同。

如果你的路由是一个分类器，你会发布它一次，针对静态评估集监控准确率，并在准确率下降时重新训练。评估集定义了真理，漂移意味着模型针对该真理的表现正在变差。

如果你的路由是一个控制系统，评估集只是一个校准工具，而不是真理的源头。真理的源头是生产中路由决策的结果：低成本路径是否产生了用户接受的答案？向昂贵路径的升级（escalation）是否发生得太晚，以至于用户已经放弃了？同一类查询是否系统性地以重试、重新生成或点睬评价告终？

从认真对待这一框架出发，会有三个转变。

信心级联（Confidence-cascading）而非信心承诺（Confidence-committing）。 基准测试训练的路由中最大的设计错误是将低成本模型的决策视为终结性的。低成本模型生成答案，系统返回答案，循环结束。控制系统路由则将低成本模型的输出视为候选方案，对其置信度进行评分（使用 Token 级别的确定性、输出结构验证、针对 Schema 的确定性检查、针对高风险路径的 LLM 裁判），并在置信度较低时升级而非直接承诺。级联模式处理长尾问题的方式不是预先预测哪些输入是困难的，而是事后检测低成本回复何时表现不佳。

文献报告显示，结合质量、成本和不确定性信号可以达到尖端模型约 97% 的准确率，而成本仅为尖端模型的 24%——但这只有在级联系统真正接入反馈时才能实现。一个只在发布时设置了一次置信度阈值且从未重新校准的级联系统，只是一个披着级联外衣的分类器。

生产流量回放作为主要评分信号。 基准测试不再是唯一真理，而变成了健康检查。真正的路由评分是针对生产流量的分层样本计算的，并按用户群、查询类型和功能面进行切片。你不是在问“平均准确率是多少”，而是在问“表现最差的集群准确率是多少，该集群的用户是否可以容忍”。这是唯一能捕获长尾失败模式的指标，因为聚合准确率在结构上对此是盲目的。

一个实际的实现：将每个集群的一小部分流量影子测试（shadow）到昂贵模型，离线比较答案，并由裁判评分。成本是有限的（你只是在抽样，不是全部复制），而评分会为你提供该集群而非全局平均值的“成本 vs 质量”曲线。做到这一点的团队最终会为每个集群设置不同的阈值，一旦你意识到用户群体并非同质，这就是正确的答案。

检测输入分布的漂移，而不只是模型漂移。 大多数 LLM 监控栈跟踪输出漂移——拒绝率、回复长度、情感、随时间变化的裁判评分。这些很有用，但对于捕捉静默失效的路由来说，它们不是合适的工具。对于路由来说，你真正关心的漂移是输入漂移：实时流量分布是否偏离了路由校准时的分布？

这是可以衡量的。对输入的查询进行向量化（Embedding），对其进行聚类，并将随时间变化的集群权重与校准基准进行比较。如果出现了一个占流量 5% 的新集群？那就是路由重新校准的触发信号。现有集群规模翻倍？同样需要。Fiddler 式和 Evidently 式的工具都有这种基础功能；工作在于将其真正接入你的路由层，而不是将其视为一个通用的监控挂件。

导致这种 Bug 上线的组织失效模式

上述技术模式只是简单的部分。难点在于，这种 Bug 协议反复出现是因为团队架构的组织方式，而不是因为工程师不知道级联故障和漂移检测。

这种模式通常是这样的：ML 团队负责路由器。产品团队负责评估套件。平台团队负责可观测性。按各自的指标来看，每个团队都在正确地履行职责。ML 团队针对给定的评估套件进行训练。产品团队根据他们认为具有代表性的用法来策划评估套件，而这些用法往往偏向于他们最初构思的使用场景。平台团队则监控他们被要求监控的指标。

没有人去关注“评估套件是否仍能代表生产环境的流量？”这个问题——因为这个问题存在于三个部门之间的缝隙中。六个月后，流量发生了变化，路由器在某个基准测试上仍然能拿到 96% 的分数，但该基准测试已不再符合现实，而且错误的答案都集中在评估套件编写时并未被列为优先级的某个用户群体中。

组织层面的解决方案是将“评估代表性”作为一项一等指标，并明确负责人。有些团队将其归于 ML 侧（“路由器团队负责针对当前流量进行校准”）。有些则将其归于平台侧（“可观测性团队负责漂移信号”）。两种方式都行得通。行不通的是让它处于无人负责的状态，因为在用户开始投诉之前，这种失效是隐形的。

在季度评审中有一个很有用的诊断问题：评估集最后一次从新的生产样本中重建是什么时候？如果答案是“自发布以来从未有过”或“我不知道”，那么你的路由器目前正运行在过时的真实标签（ground truth）之上，而长尾 Bug 已经存在于生产环境中。你只是还没测量到它而已。

闭环反馈

路由的全部意义在于，某些查询不需要昂贵的模型。这没错。实施中的问题在于，你如何发现哪些查询不需要，以及随着世界的变化，你的发现过程是否依然有效。

一个仅针对基准测试构建一次并部署到生产环境的路由器是开环（open-loop）的。它在对一个它从未观察其行为的系统进行预测。只要假设成立，这种设置就有效——但关于用户查询分布的假设不会维持太久，尤其是在大多数团队部署这些系统的高增长阶段。

我所见过的那些能从路由中获得持续节省的团队，并不是因为他们拥有更智能的分类器。他们拥有一套贯穿整个路径的反馈闭环：生产流量流经路由器，结果流回校准集，当分布发生偏移时漂移检测会发出警报，并且有人专门负责将重新校准周期作为其工作的一部分。路由器在基准测试上的表现可能会变得没那么惊艳，但在实践中却更加可靠。这种权衡正是关键所在。

如果你能从这篇文章中记住一点，那就是：停止询问“我们的路由器有多准确？”，开始询问“当路由器出错时会发生什么，以及我们如何察觉？”第一个问题的答案无法告诉你系统是否正常工作。第二个问题的答案才可以。