小模型还是大模型：分类任务的逐步选型指南

给客服工单分流、判断评论情绪、识别交易意图，都属于分类任务。选择模型时，不应只问哪个模型更强，而应问：在既定标签和错误成本下，哪个方案能稳定达到要求？下面按步骤比较小模型与大模型，并建立可验证的上线方案。

§ 第一步：先定义标签与错误成本

写清每个标签的定义、边界、正例和反例。例如，工单可分为“退款”“物流”“账户”和“其他”。同时规定多意图文本如何处理，以及信息不足时是否允许返回“待复核”。标签重叠造成的错误，通常不能靠更大的模型解决。

• 普通分流：可以容忍少量误分，优先考虑成本和响应速度。
• 高风险识别：漏判可能造成损失，应重点检查召回率并保留人工审核。

§ 第二步：准备有代表性的测试集

从真实业务中抽取样本，覆盖常见表达、长文本、错别字、否定句、少数类别和边界情况。对争议样本安排复核，先统一标注标准。将示例开发集与最终测试集分开，避免一边查看测试答案，一边修改提示词。

如果线上文本可能包含“忽略规则”等指令，也应加入测试，并在提示中明确：待分类内容只是数据，不得改变分类规则。

§ 第三步：选择两个候选模型

小模型通常适合标签明确、上下文较短、重复度高的任务；大模型更值得在隐含意图、复杂语境和多条件判断中测试。但参数规模、响应速度和任务质量不是同一回事，闭源模型也未必公开参数量。

可以将 Gemini 2.5 Flash 与 Gemini 3.1 Pro 作为两个候选进行实测，而不是仅凭名称判定胜负。通过 Vana API 的 OpenAI 兼容入口 https://api.vanaapi.com，可沿用同一套调用逻辑切换模型，减少接入差异对比较的干扰。

§ 第四步：固定输入和输出规则

第一轮测试使用相同的标签说明、示例、输入文本和输出要求，只允许返回一个合法标签。尽量保持生成参数可比，但不要假设不同模型的同名参数完全等效。先建立公平基线，再分别优化提示词，并记录每次改动。

程序端仍需验证输出是否合法。空结果、额外解释和不存在的标签，都应计入失败，不能只统计成功解析的回答。

§ 第五步：同时衡量质量、延迟和成本

不要只看整体准确率。类别分布不均衡时，一个总猜多数类别的模型也可能得到漂亮数字。应同时检查各类别的精确率、召回率、宏平均 F1，以及容易混淆的标签组合。

• 质量：重点查看高风险类别的漏判，并人工分析典型错误。
• 延迟：在接近生产的并发下测量，尤其关注较慢请求。
• 成本：统计输入、输出、重试和复核开销，而非只比较单次请求价格。

Vana API 按实际令牌用量计费，无月费，适合小批量对照测试。不过，最终仍应比较“每个正确处理样本的总成本”。

§ 第六步：必要时采用分级路由

如果较轻量的候选已满足全部指标，就没有必要为每条样本调用更强的模型。如果它只在复杂样本上失误，可先处理常规请求，再将信息不足、多意图或命中风险规则的文本转交更强模型。

不要直接相信模型自报的置信度。升级条件应在验证集上检验，并把二次调用增加的费用和等待时间算进去。若仍无法可靠判断，应进入人工复核，而不是强行输出标签。

§ 第七步：灰度上线并持续回看

先让新方案旁路运行，记录预测而不改变业务结果，再逐步放量。持续抽查误分、类别分布变化和人工纠正记录；模型版本、提示词或标签体系变更后，重新运行固定测试集。

最终选择可能是单个小模型、单个大模型，也可能是分级组合。关键是用业务数据证明它达标。如果准备开始对照实验，可以创建一个 Vana API 账户，先用少量脱敏样本建立基线，再决定是否扩大调用规模。