跳转到主要内容

模型路由首先是评估问题,其次才是优化问题

只有在固定的评估集下,以任务级结果而非单纯的每 token 成本来评判路由器时,模型间的路由才能带来回报。

Detailed view of a microchip, showcasing intricate electronic components on a dark textured surface.

为什么路由看起来像成本杠杆

模型路由通常作为支出控制手段被引入。其卖点很直接:大型前沿模型处理困难案例,较小的开放权重模型处理常规案例,分类器在请求看起来简单时将其发送到更便宜的层级。由于开放权重模型在广泛的常规工作范围内不断改进,总账单下降,演示仍然通过。可见的收益是支出。不可见的成本是长尾上的任务失败。

失败模式是结构性的,而非偶然的。路由器是一种将请求映射到模型的策略。如果策略针对诸如每 token 成本之类的代理指标进行优化,它就会学会将更多流量发送到更便宜的模型。这对代理指标而言是正确行为,但对产品而言是错误行为——只要便宜模型在代理指标无法区分的某个任务类别上只是近似正确。聚合基准会掩盖这一点,因为它们对任务类别取平均。一个只报告单一分数的路由基准可能有所提升,而某一特定任务类别却退化到低于对用户至关重要的阈值。

路由器必须依据什么来评估

路由器是关键路径中的一个组件,它需要与任何其他可能悄然改变行为的组件相同的评估纪律。在路由策略被允许上线之前,需要三样东西。

一个冻结的任务套件,带有逐任务通过标准。 套件是一组代表性任务,每个任务都有明确的通过条件。通过条件必须是逐任务的,而非逐套件的。只报告一个数字的套件会诱使路由器以许多任务上的小损失换取少数任务上的大收益。逐任务标准使这种权衡变得可见。套件像代码一样进行版本管理:当任务被添加、移除或其标准发生变化时,版本随之改变,路由变更与同一版本进行比较。

Close-up image showing JavaScript code on a computer screen, reflecting modern programming work.

一个包含重试、升级和人工审核的成本模型。 推理成本只是路由决策真实成本中最小的一部分。一个经常失败的便宜模型会触发重试、升级到更大的模型或人工审核。每一项都有成本,每一项都是路由决策的后果。只计算推理的成本模型会系统性地偏好便宜模型,即使端到端成本更高。该模型应将重试和升级归因于导致它们的路由决策,从而在完整路径上评判策略。

一个回归门禁,当任何任务类别低于阈值时阻止路由变更。 门禁是执行机制。它在冻结套件上将候选策略与现行策略进行比较,如果任何任务类别低于其阈值,即使聚合指标有所改善,也拒绝提升候选策略。门禁将路由从成本实验转变为具有回滚方案的工程变更。

门禁的一个具体机制是配对比较。对于套件中的每个任务,同时运行现行策略和候选策略,记录结果,并计算逐类通过率。只有当每个类别都达到或高于其阈值且聚合指标不更差时,候选策略才被提升。这比单次聚合运行更昂贵,但这是捕捉隐藏在平均值中的回归的唯一方法。

设计说明

基于任务特征路由,而非仅基于提示长度。 提示长度是难度的弱代理。短提示可能是困难的推理任务;长提示可能是常规提取。更好的特征包括任务类型、是否存在结构化输出要求、轨迹可能需要的工具调用数量,以及模型自身的置信度信号。特征集是路由器接口的一部分,应随其一起进行版本管理。

当置信度信号退化时,允许路由器在轨迹中途升级。 在轨迹开始时做出单一决策是脆弱的。模型可能自信地开始,然后产生低置信度的 token、反复的自我纠正或返回错误的工具调用。当这些信号越过阈值时,路由器应能够在轨迹中途升级到更强的模型。这就是静态分类器与控制回路之间的区别。控制回路每次请求的成本更高,但能恢复静态策略会失败的任务。

Detailed view of a video editing software interface showing multi-track timeline and colorful design.

将路由决策与结果一起记录。 每个请求都应记录选择了哪个模型、哪些特征驱动了该选择、是否发生了升级

权衡

更细的路由粒度会带来延迟和复杂性。 一个检查许多特征并能在轨迹中途升级的路由器会为每个请求增加延迟,并为系统增加复杂性。更粗的路由更快、更简单,但准确性更低。正确的粒度取决于错误路由决策的成本相对于延迟成本的大小。

升级路径需要自己的预算,否则它就会成为默认选项。 如果升级是免费的,路由器会升级一切,更便宜的层级就变得形同虚设。升级路径需要预算和阈值,并且这些必须针对同一冻结套件进行调优。否则路由器会坍缩到最强模型,路由层就成了纯粹的开销。

没有评估工具的路由器是关键路径中一个未被测量的依赖项。 这是本文核心的诚实权衡。路由可以降低成本并改善结果,但前提是它依据结果被测量。一个针对每 token 成本优化而未逐任务评估的路由器,是一个可能悄然失败的依赖项,而关键路径中的悄然失败比更高的账单更糟。评估工具不是可选的开销;它是使优化变得安全的东西。

实际的结论是,路由应以评估为先来构建。在调优策略之前,先定义任务套件、逐任务通过标准、完整成本模型和回归门禁。然后再优化。顺序很重要,因为目标函数决定了路由器学到什么。先优化成本,路由器就学会变得便宜。在成本约束下优化结果,路由器就学会变得有用。

封面照片:Jakub Pabis / Pexels。

分享XLinkedIn永久链接5 分钟阅读

相关阅读

这能回答的问题

Why is cost per token a bad objective for a model router?

Cost per token is a proxy that does not distinguish task classes. A router optimised for it will send more traffic to cheaper models, which is correct for the proxy and wrong for the product whenever the cheap model is only approximately correct on a class the proxy does not separate. The result is aggregate improvement with per-task regression.

What should a routing evaluation suite contain?

A frozen set of representative tasks, each with an explicit pass condition, versioned like code. Per-task criteria are required so that a small loss on many tasks cannot be traded for a large gain on a few. The suite is compared against the same version for every routing change.

How does a regression gate work for routing changes?

A paired comparison runs the incumbent and candidate policies on the frozen suite, records per-class pass rates, and promotes the candidate only if every class is at or above its threshold and the aggregate is not worse. This catches regressions that hide inside an average.

When should a router escalate to a stronger model?

Escalation should be allowed mid-trajectory when confidence signals degrade, such as repeated self-corrections or tool calls that return errors. A static decision at the start of a trajectory is brittle. The escalation path needs its own budget, or it becomes the default and the cheaper tier becomes decorative.