模型路由不是负载均衡：把成本写进路由策略

去年我们给一家零售客户做客服智能体，上线第一个月账单超预算 3.4 倍。查下来不是模型贵，而是所有请求——包括“订单到哪了”这种一句话能答的问题——都走了同一个最强模型。

一、先把请求分层，而不是先挑模型

很多团队的做法是先选一个“效果最好”的模型，再考虑成本。顺序反了。正确的顺序是先回答：这个请求答错的代价有多大？

我们通常把请求分成三层：

• 事实层：查状态、查参数、查政策。答案唯一，错了立刻被发现。适合小模型 + 严格检索，检索不到就直接说不知道。
• 解释层：把结果讲清楚，处理多轮上下文。需要中等模型，重点是稳定性与格式约束。
• 决策层：涉及建议、方案、风险判断。使用强模型，并且必须有人工确认节点。

分层之后你会发现，事实层通常占调用量的 60% 以上。把这一层压下来，整体成本结构才会变。

二、路由的三个输入：质量下限、预算上限、时延上限

路由不是一个开关，而是一次带约束的选择。我们在路由请求里显式传入三个参数：

• 质量下限：该场景允许的最低评测通过率，例如 92%。低于下限的模型直接不进入候选。
• 预算上限：单次调用可接受的最大成本，用业务可理解的单位表达，而不是 token 数。
• 时延上限：用户可等待的时间，例如在线客服 2.5 秒，后台批处理可以不设。

三个约束共同筛出候选集，再按“成本最低优先”排序。这样选出来的模型未必最强，但一定是这个场景里够用的。

三、降级链要预先设计，而不是出事再想

生产环境一定会遇到超时、限流与内容拦截。降级链建议遵循“同质量降级”原则：

1. 首选模型超时 → 切换到同级别备用模型，提示词不变。
2. 备用也失败 → 降低生成长度要求，只输出结构化结论。
3. 仍失败 → 返回明确失败，转人工，绝不用低质量模型硬答。

第三条最容易被忽略。我们在某个项目里见过“降级到最后仍强行生成”，结果把政策条款答错，人工返工的成本远高于一次转人工。

四、记录什么，才能解释为什么这么选

每条路由记录我们至少保留六个字段：场景标识、候选集、被选模型、命中约束、实际成本、最终质量结果（人工反馈或自动评分）。

有这六个字段，才能回答三个问题：为什么这次贵了？为什么这次慢了？为什么这个模型被淘汰？没有这些记录，路由就是黑盒，调优全靠猜。

五、三个常见反模式

• 按 token 价格排序：便宜的模型往往需要更多轮次与更长提示，实际总成本更高。
• 全站统一策略：客服与后台批处理的约束完全不同，统一策略必然有一边浪费。
• 没有回滚：路由策略本身也是配置，必须有版本与一键回滚，否则调参就是赌博。

六、结果与边界

上面那家零售客户在完成分层与预算约束后，第二个月总成本回到预算内，人工处理量下降 34%，平均首响时间 11 秒。代价是事实层约 4% 的请求会明确回复“未收录”，需要人工补录知识——我们认为这个交换是值得的。

路由解决的是“用对模型”，解决不了“知识不对”。如果检索质量本身不过关，再精细的路由也只是把错误答案算得更便宜。