跳到主要内容

不是所有请求都要走最强模型

· 阅读需 5 分钟
一介布衣
一介布衣
全栈开发者 / 技术写作者

补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-05-16 14:30。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。

如果只选一个真实场景来解释这篇文章，我会选“客服混合链路”。

这个链路里同时存在三类请求：

  1. 很简单的分类，例如“这是退款还是咨询”。
  2. 中等复杂度问答，例如“这张券为什么不能用”。
  3. 少量高难样本，例如“多个订单、多个活动规则叠加后的争议场景”。

项目最初为了省事，几乎所有请求都默认走最强模型。早期流量小，大家只觉得“效果不错，就是稍微贵一点”。但一旦请求量上来，问题很快暴露：

  • 成本并不是“稍微贵”，而是被大量简单请求一起抬上去了。
  • 用户等待时间变长，前端体验开始变差。
  • 团队失去了判断“哪些任务其实根本不需要强模型”的机会。

这也是我后来越来越笃定的一点：不是所有请求都要走最强模型。模型分层不是为了抠预算，而是为了让系统真正进入可运营状态。

这个链路后来是怎么拆分的​

我们后来把请求粗暴但有效地拆成三层：

第一层：稳定结构化任务​

例如：

  • 意图分类
  • 字段抽取
  • 标签判断

这些任务的共同特点是：

  • 输出格式固定
  • 错误容易被规则兜底
  • 本来就不需要太强的开放式推理

它们如果还全量走最强模型，基本就是在用旗舰卡跑表格函数。

第二层：通用问答和常规生成​

例如：

  • 常规知识问答
  • 普通客服草稿
  • 常见改写任务

这类任务需要语言能力，但很多时候不需要最强模型的推理深度。

第三层：复杂样本和高价值节点​

例如：

  • 多规则冲突场景
  • 多文档综合判断
  • 高风险人工辅助决策

这类请求才最值得交给更强模型。

一个真实的路由对比​

最开始的代码其实几乎是这样：

async function handleRequest(task) {
  return strongestModel.run(task)
}

简单、直接、看起来不容易错。

后来我们改成了更像下面这样：

async function handleRequest(task) {
  if (task.kind === 'classification' || task.kind === 'extract') {
    return smallModel.run(task)
  }

  if (task.kind === 'qa' && task.risk === 'low' && task.contextSize < 4) {
    return mediumModel.run(task)
  }

  return strongModel.run(task)
}

这段代码真正重要的不是 if/else，而是背后的治理逻辑：

  • 模型强度是按任务分配的
  • 高成本能力只给高价值节点
  • 系统终于可以被测量，而不是一刀切

为什么“全量强模型”其实会让系统变笨​

听起来有点反直觉，但这是真的。

因为一旦所有请求默认都走最强模型，团队会很快失去两种能力：

1. 失去任务分层能力​

没人再会认真区分哪些问题本质是规则、哪些是检索、哪些才是复杂推理。

2. 失去优化压力​

缓存、路由、降级、规则补位这些设计都会被推迟，因为团队总会觉得“先用最强模型扛一下”。

最后系统当然还能跑，但会越来越贵、越来越慢，也越来越难解释。

我现在怎么看“最强模型”的实际位置​

在我看来，最强模型更适合扮演三个角色：

1. 难例兜底​

主路径先交给便宜模型，少量复杂样本再升级。

2. 高价值节点​

比如最终总结、复杂决策辅助、多文档综合分析，这些地方模型质量的边际收益更高。

3. 评测基线​

强模型有时非常适合当成“理想上限”，让团队拿它去和小模型、规则链路做对比，帮助判断哪些地方真的值得花钱。

我会怎么判断某类请求能不能下沉​

现在如果让我决定一类请求是不是应该脱离最强模型默认路径，我会先问：

  1. 输出是不是高度结构化？
  2. 错误是否容易被规则兜住？
  3. 请求是否高频、重复、可缓存？
  4. 是否真正需要复杂推理？
  5. 成本和延迟会不会直接影响用户体验？

只要这几个问题里有三个以上偏向“是”，我基本就会优先考虑下沉。

一个更现实的团队共识​

后来我们内部有一句很有用的话：

强模型不是默认路径，而是预算更高的能力插槽。

这句话的好处在于，它会逼着大家从“模型崇拜”回到“系统设计”。

最后给一张可执行清单​

当团队又想把所有请求都交给最强模型时，我现在会先过这张表：

  1. 这类请求是不是其实可以走规则、查库或缓存？
  2. 这类请求真的需要复杂推理吗？
  3. 这类请求量一上来，账单是否还能接受？
  4. 这类请求的延迟增加，会不会立刻伤害体验？
  5. 如果下沉到中小模型，错误是否可以被检测和兜底？

总结​

不是所有请求都要走最强模型，因为系统的目标从来不只是把单次结果做到最好，而是让能力、成本、延迟和治理一起达到可持续状态。

最强模型很重要，但它更像高价值节点和难例兜底的资源，而不是整个系统的默认底座。谁越早接受这一点，谁的 AI 系统越容易长期跑得稳。