模型怎么选才不是拍脑袋：一套自建评测集方法

公开榜单选不出你能用的模型

打开任何一个模型排行榜，前面几名往往只差一两个百分点。但这些分数来自选择题、数学题、标准问答，和你让模型干的活——从一张模糊的送货单里抠出品类和数量、把客户一段带情绪的语音整理成工单、按公司模板写一段投标响应——中间隔着一整个业务现场。

榜单失真通常有三个来源：题目分布跟你无关；公开题库可能已经被训进模型里；榜单也不测工程指标——输出 JSON 稳不稳定、长文档读到第三万字会不会开始编、并发上来以后延迟抖不抖。这些恰恰是上线后天天出问题的地方。

所以我们内部有个说法：用你自己的任务测，别用别人的榜单选。下面这套方法分四步，一个懂业务的运营配一个懂技术的同事，两三天能跑完第一轮。

评测集常见的错，是让懂 AI 的人凭想象写 50 条 prompt。写出来的题又干净又短，而真实工单里全是错别字、口语、截图和上下文缺失。

做法是回到系统里捞：客服记录里挑 20 条没处理好的；销售合同里挑 10 条条款解释请求；生产日报、会议纪要、产品手册问答各挑几条。凑够 30–50 条，按「出现频率 × 出错代价」分层——高频低成本的写文案、改邮件占大头；低频高风险的合同条款比对、数据核对虽然少，但必须有。

每条任务除了输入，还要写下「什么样的输出算合格」。这句话写不出来，说明这个场景还没想清楚，先别急着选模型。

不打分的评测，最后都会变成一句「感觉 B 好一点」。合格的评分表每条任务配 3–5 个维度，每个维度 1–5 分，或者干脆用通过/不通过。字段抽取这类任务用二值判定更省事：字段全对算过，错一个算不过。

两个细节决定这张表靠不靠谱。一是找两个人各打一遍同样 10 条，分差超过 2 分，说明标准写得含糊，回去改标准而不是改分数。二是把「可用度 4 分以上」当成上线门槛，别只看平均分——平均 3.8 分可能意味着一半任务很好、一半完全不能用。

模型名一露出来，人就会偏向自己听说过的那家。做法很土但有效：候选模型编号成 A、B、C，顺序随机打乱，用同一套 prompt、同一组参数（temperature 固定，能设 0 就设 0），输出并排贴进表格，只看输出不看名字。

要记录的元信息比分数本身更重要：模型名和版本号、调用日期、prompt 全文、参数、token 消耗、响应时间。各家模型三个月一换代，半年后回头看「当时 B 更好」这个结论，没有版本号和日期就是一句空话。

跑的过程中顺手记两类问题：一类是模型能力问题，一类是你的 prompt 问题。经验上后者更多——很多「模型不行」的结论，其实是没给示例、没约束输出格式、没把背景资料放进去。

单价表只算了裸调用，真实成本还要乘上重试率和人工复核率。举个我们见过的对比：

人工复核的时薪比 token 贵得多，这笔账一定要算进去。反过来，如果某个场景输出只是给人看的草稿、错了也能重来，那便宜模型的低单价就是实打实的优势。所以成本结论必须绑定场景，不能全公司一刀切一个模型。

更省事的做法是分级：简单分类、摘要走小模型；要多步推理、要卡死 JSON 结构的走大模型；数据敏感的走私有化部署的小参数模型。这套路由和额度控制，属于模型 API 与成本管理的范畴，落到工具上就是网关加计费看板。

用官方 demo 的 prompt 直接测。Demo prompt 是针对榜单调过的，换到你的数据上表现会掉一截。要么用你自己的 prompt，要么两边都用同一套。
只测一轮就定结论。同一模型跑两次差异能到一个档位，尤其温度没固定的时候。
忽略上下文长度和并发。文档一长就开始丢中间内容，这是长文档场景常见的失效点；并发一上来延迟飙升，体验直接崩，这些榜单都不测。
评测集建完就锁进抽屉。业务变了、模型换代了，题要跟着加，我们一般一个季度补 5–10 条新任务。

20 条任务、3 个候选模型、一张两列评分表，一个下午能跑完。结论不用写成报告，三句话就够：哪个模型在这类任务上够用、大概什么成本、什么条件下会失效。这三句话比任何榜单都更能支撑决策。

流程跑顺了再往深处走——把评测集接进企业知识库的召回测试里，或者在 AI 智能体私有化部署之前先拿它做一轮准入，能省下不少返工。

如果你手上正有几个候选模型拿不定主意，先按上面的方法攒 20 条真实任务自己跑一轮，跑完再谈部署和价格也不迟。想找人复核这份评测集，或者需要把它固化成一个可复用的表单和脚本，可以打 400-873-2750，或者联系我们约个时间，把任务清单带过来一起看。