拿榜单当结论
公开评测反映通用能力，与合同审阅、工单分类这类任务的相关性有限。正确做法是从业务日志抽两三百条真实样本，人工标注期望输出，形成小而专的评测集，再让候选模型同台跑，结论才站得住，也便于复现。
默认最大参数
大模型在复杂推理上占优，但抽取、分类、格式转换这类任务，中等模型往往够用且延迟更低。按任务分层选型，把大模型留给真正需要的环节，比全线统一更省，也更容易控制响应时间与排队长度，用户体验更稳定。
忽略输出稳定性
需要写入系统的场景要求字段齐全、类型正确、可解析。若模型偶发漏字段或自造枚举值，工程侧就要写大量兜底逻辑，维护成本被低估。选型时必须把解析成功率单列成指标，并按周统计波动，才能发现隐性退化。
只比单价
单价低的模型可能上下文更短、需要更多轮次或更高重试率。应比较完成同一任务的总消耗与人工介入次数，而不是每千 token 的标价，否则容易选到看似便宜、实际更贵的方案，年底复盘时也很难解释。
选完不再回归
供应商升级或下线模型会改变输出风格，提示词随之失效。缺少版本登记与回归评测，问题往往在上线数周后才暴露，定位困难。建议每次变更都跑同一套用例并留档，形成可追溯的记录，也便于和供应商沟通。
适用与不适用
适合谁
- 正在做模型对比测试、具备样本标注能力的技术团队
- 被供应商演示打动、准备直接采购的决策者
- 需要向管理层解释选型依据的负责人
不适合谁
- 尚无业务样本、只能凭演示判断的团队
- 不接受上线后持续评测的项目，也拿不出样本。
典型场景
某物流企业最初按公开榜单选了最大参数模型，上线后单据抽取的字段缺失率偏高，人工补录量大。团队改用三百条历史单据建评测集，把抽取任务交给中等模型并加校验规则，复杂异常解释才路由到大模型，返工量随之下降，选型依据也留存成文档。
可执行步骤
- 从业务日志抽取真实样本，覆盖常见情况与边界情况，去掉重复与明显无效的样本
- 人工标注期望输出，明确可接受的差异范围、判定规则与出现分歧时的仲裁人
- 让候选模型跑同一评测集，记录成功率、解析失败数与延迟分布并保留原始输出
- 按任务分层确定主模型与备用模型，写明切换条件、阈值与具体责任人，并约定责任人
- 登记模型版本，约定升级后的回归流程、样本更新周期与记录留档方式，并留存对比结论
常见坑
- 评测集只用顺利样本，边界情况缺失，上线后错误集中爆发且难以快速归因到某一类输入，返工窗口很小。
- 只测单轮问答，忽略多轮与长上下文下的表现衰减，真实场景的体验落差会很大，投诉集中在复杂问题
- 用一次测试结果定论，未考虑随机性与参数设置带来的波动，结论既不可复现也难以复核，结论也无法复核。
- 没有备用模型，主模型下线或限流时业务直接中断，恢复时间与影响范围都不受自己控制，也无从补救。
- 选型记录只写结论不写依据，人员变动后无法复盘，也无法回答评审与审计的追问，评审时也缺依据。
自检与验收清单
- 评测集是否来自真实业务样本并覆盖边界情况
- 是否单列结构化输出解析成功率与失败明细，是否留档
- 是否比较单位任务总消耗，而不是单次调用单价
- 是否设定主备模型、切换条件与对应责任人，是否有签字
- 模型版本与回归记录是否留存并按周期归档，是否归档
常见问题
公开榜单还有参考价值吗？
有，但只用于初筛，判断哪几家进入候选。最终结论要来自自有任务集上的对比，因为榜单任务与你的业务分布、术语和格式要求往往差别很大，分数高不代表在场景里更好。
几个模型分数接近时怎么定？
看工程侧指标：解析成功率、延迟分布、上下文长度、限流策略与价格结构。分数接近时，稳定性和可维护性通常比再高一点点的准确率更影响总成本，也更容易向评审说明依据。
需要几个模型同时上线吗？
常见做法是一个主模型加一个备用，复杂任务再路由到更强模型。模型过多会增加评测与运维负担，除非业务差异明显、或不同任务对延迟要求差异很大，否则不必铺开，先把主备切换跑顺更实际。