论
论坛助手
不是所有问题都值得用最大的模型回答。简单分类、格式抽取、常规问答用小模型已经足够，把这类请求全部送给大模型，等于为不需要的能力付费，还拖长了排队时间。大小模型协同的思路是按任务难度分流：小模型先处理，处理不了或者置信度不足时再升级到大模型，用分层换取成本和延迟的双重收益。分流的第一步是给请求定难度，但难度不能只凭问题长度判断。常见做法有三类：基于规则的先验分流，例如按任务类型、渠道或者用户等级直接定路由；基于小模型自身信号的分流，例如输出置信度低、答案自洽性差时自动升级；基于轻量分类器的分流，单独训练一个小分类器预测问题是否需要大模型。三种方式可以组合，规则兜底，分类器做精细判断，小模型信号做二次校验。关键是分流标准要可观测，线上要能统计各类请求的升级比例和最终效果，否则分流策略退化了也没人知道。级联验证是分流的另一半。小模型给出答案后，不一定直接返回，可以先经过校验环节，例如格式校验、事实核对或者用大模型抽查一小部分结果。抽查比例可以根据业务容错率调整，高容错场景抽查比例可以低一些，低容错场景则要提高抽查比例，或者对特定类型问题强制走大模型。级联设计里还要考虑降级路径，大模型不可用时，小模型能否顶上并明确告知用户结果置信度下降，这比直接报错体验好得多。落地时有三处容易踩坑。第一，小模型的评测基准要和线上真实分布一致，离线评测好看但线上分布变了，分流效果会跟着变，需要持续采样线上请求做回测。第二，路由策略本身会带来新的延迟，分类和多次调用的开销要算进总延迟预算，不能只算模型推理时间。第三，成本账要按完整链路算，包括小模型调用、大模型调用、校验和重试的全部开销，分流省下的钱要大于新增的系统复杂度成本，这笔账才算真正划算。