模型评测

小模型能接住哪些任务:一个任务适配性判断框架

关于小模型(Claude Haiku、GPT-5 mini、Gemini Flash 这一档)该不该用,讨论经常停在”哪个更便宜""哪个中文更好”这类横评层面。但真正决定要不要换小模型的问题其实更前置:这个任务本身是不是小模型能接住的类型。横评之前先做这道判断题,能省掉大量”换了模型又切回来”的折腾。这篇不比具体模型(那部分可看 Claude Haiku 4.5 vs GPT-5 mini 横评),只讲判断框架。

一、先明确一个前提:小模型的能力边界在哪

小模型和大模型的差距,不是均匀分布在所有能力维度上的。实测里差距最大的几个维度:

  • 多步推理链:需要在头脑里维持 5 步以上推导、每步依赖上一步结论的任务,小模型容易在中间步骤”走神”,得出看似合理但实际错误的结论。
  • 长上下文里的精确定位:几万字文档里找一处细节并准确引用,小模型的”大海捞针”能力明显弱于大模型。
  • 模糊指令的意图猜测:用户表达不清楚、需要模型自己补全隐含要求的场景,小模型更容易”照字面执行”而漏掉隐含意图。
  • 对抗性或边界场景的判断:需要综合考虑多个冲突规则、做价值权衡的场景(比如复杂的内容审核边界判断),小模型的判断一致性较差。

而在这几个维度上,小模型和大模型的差距很小甚至可以忽略:

  • 格式转换和结构化提取:给定明确 schema,从文本里提取字段
  • 短文本分类:情感分析、意图识别、垃圾内容识别
  • 模板化生成:按固定格式生成短文本(邮件回复、commit message、SEO 摘要)
  • 简单事实性问答:答案就在给定上下文里,不需要跨段落推理

二、任务适配性判断框架:四个问题

拿到一个具体任务,按顺序问这四个问题,能快速判断是否适合小模型。

问题 1:任务的输出是否可以用规则或简单校验验证正确性?

如果输出格式固定(JSON、枚举值、固定长度),可以写代码校验结果是否合法,那即使小模型偶尔出错,也能通过重试或者规则兜底纠正。这类任务对模型能力的容错空间大,适合小模型。反过来,如果输出是自由文本、正确性只能靠人工判断(比如”这段分析写得对不对”),小模型出错不容易被自动发现,风险更高。

问题 2:任务需要的推理步数有多少?

单步或两步以内的推理(“这句话是正面还是负面”、“从这段文字提取公司名”)小模型基本没问题。三步以上、且步骤间强依赖的推理(“先判断这个合同条款属于哪一类,再结合另外三个条款判断整体风险等级,再给出修改建议”),建议直接上大模型,省下的钱不足以覆盖出错后人工复核的成本。

问题 3:错误的代价是什么?

同样是分类任务,“给内部工单打标签方便统计”和”判断这笔交易是否欺诈”的错误代价完全不同。错误代价低、可以事后修正的场景,小模型的偶发错误可以接受;错误代价高(涉及金钱、合规、安全)的场景,即使小模型准确率只比大模型低 3-5 个百分点,也不建议为了省成本冒这个险。

问题 4:任务的输入分布是否稳定?

小模型在训练分布内的任务上表现接近大模型,但遇到分布外的输入(罕见格式、多语言混杂、异常长度)时性能下降幅度比大模型更明显。如果任务的输入来源杂、格式不受控(比如用户自由输入的客服问题),要么先用规则/小模型做预分类过滤掉异常输入,异常部分转大模型处理,要么直接接受小模型在长尾场景的失败率会更高。

三、按任务类型给出参考结论

任务类型小模型是否适合说明
意图分类/路由适合经典的小模型场景,本身也是很多路由方案的第一层,参考 多模型成本智能路由方案
结构化信息提取适合给定 schema,输出可校验
内容审核(明显违规)适合明确规则、边界清晰的部分
内容审核(边界模糊)不适合价值权衡类判断,建议大模型或人工复核
短文本摘要(<2000字)适合单段落摘要小模型质量可接受
长文档综合摘要(跨多章节)不适合需要跨段落整合,小模型容易遗漏
代码补全(局部)适合局部上下文足够
代码架构设计/多文件重构不适合需要维持大范围一致性的推理
客服 FAQ 应答适合答案通常就在知识库里,检索+小模型足够
多轮谈判/销售对话不适合需要持续追踪对方意图变化,策略性强

四、一个常见的错误用法:用小模型做”降级兜底”

有些团队的做法是:默认用大模型,大模型超时或报错时自动降级到小模型重试。这个思路本身没问题,但容易忽略一点——如果任务本身就属于”不适合小模型”那一类,降级重试拿到的结果质量会明显更差,用户可能收到一个语气正常但内容有问题的回答,比直接报错体验更糟。降级兜底应该只用在问题 1-4 判断下来”适合小模型”的任务上,不适合的任务降级应该是”排队重试大模型”或者”提示用户稍后再试”,而不是静默换成小模型给出一个凑合的答案。

五、混合架构:多数团队的实际选择

真正的生产系统很少是”全大模型”或”全小模型”,而是按上面的框架把任务拆开分流。典型架构是先用小模型做意图分类/复杂度打分,简单任务小模型直接处理完,复杂任务转发给大模型。这类分级路由的配额管理和降级触发条件设计可以参考 模型分级的成本策略。

需要注意的是,分流本身也是一个判断任务——用小模型判断”这个任务该不该用小模型”,这个判断步骤本身要足够简单可靠(问题 1-4 里的低复杂度类型),否则分流环节自己就会成为新的错误来源。

六、相关阅读