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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

加载中…