公司里最近要做大模型选型我们干脆做了一个大模型选型评估器。不是简单的 benchmark 套壳而是围绕真实业务场景把“效果、速度、成本、可控性”拆开打分最后输出一张可以直接拍板的对比报告。这篇文章把整个设计和落地过程捋一遍包括评估维度怎么拆、测试集怎么构造、自动化打分怎么避免不准、以及本地部署模型怎么测才客观。1. 选型评估器应该解决什么而不是又造一个榜单1.1 为什么选型经常变成拍脑袋先聊一个很现实的问题市面上开源模型和闭源模型几十个跑分都高得离谱为什么真正接到业务里还是各种翻车很多团队的做法是拿几个热门模型跑一遍公开榜单或者抄两篇对比文章然后凭感觉选。结果上线之后发现模型在通用理解上确实不错但在你们特定的文档抽取、复杂工具调用、长文本逻辑推理这些场景里表现完全不是那么回事。还有更隐蔽的问题——推理速度跟不上、Token 成本爆了、私有化部署的显存放不下模型。这些情况本质上不是模型不行而是选型时没有一套能对应实际需求的评估体系。所以做这个大模型选型评估器目标不是做一个新榜单去给模型排名而是把“选模型”变成一件有依据、可重复、能被团队审阅的事。1.2 评估器的定位从单点测试变成完整决策链路我当时在设计的时候反复确认了一个原则评估器不是要跑尽量多的模型而是要在一个可控的成本内快速回答三个问题。这个模型在我要做的任务上效果到底行不行它的响应速度、并发能力、资源占用能不能扛住业务流量综合 Token 价格、部署成本、维护成本值不值得长期用顺着这三个问题我把评估器拆成了四个核心模块场景定义、测试集管理、自动化评测、决策报告。后面所有内容都是围绕这四个模块展开的。你可以把它理解成一个漏勺——筛的不是模型榜单上的分数而是“你的具体业务需求”。2. 评估体系设计把业务场景拆到模型能力2.1 场景拆解从老板的一句话到可执行的评估任务最容易犯的错就是直接拿一个泛泛的“智能问答”场景去做评估。真实业务里的场景一定是具体的比如从保险理赔单 PDF 里抽取关键字段并输出结构化 JSON给售后工单做标签分类同时判断用户情绪和紧急程度把零散的会议纪要改写成标准周报面对用户的连续提问准确从企业知识库里检索并回答。每个具体场景背后对模型的能力要求完全不同。第一个测试的是 OCR 协同下的信息抽取和格式遵循能力第二个测试的是文本分类和细粒度情感判断第四个测试的是检索增强生成RAG链路下的指令跟随和抗干扰能力。所以在评估器里我第一个模块就是让用户描述场景然后评估器自动把它映射到若干能力项上。能力项我分了六大类语义理解、知识问答、逻辑推理、信息抽取、工具调用、内容生成。每个场景可以有多个能力项但必须给定权重。2.2 指标分层效果、性能、成本、可控性四维指标看起来简单但里面每个维度再往下拆才是真正可测的东西。效果指标我不建议只看一个准确率。不同任务要用不同指标抽取类任务看字段级准确率和召回率分类任务看 F1生成类任务看答案完整性和忠实度。对于没有标准答案的内容还得分人工评审维度比如相关性、流畅度、格式合规度。性能指标包括首 Token 延迟、完整响应时间、每秒请求数QPS和并发承载能力。这些指标直接影响用户体验和系统架构设计。一个小知识很多模型跑 benchmark 时看起来快但并发一上来吞吐量掉得非常厉害这是选型时必须实测的。成本指标不光看 API 单价还要算上输入输出 Token 的比例。比如文档分析任务输入 Token 往往是输出的几十倍这时按 Token 单价选择和按固定价格选择结果完全不同。如果私有化部署还要把 GPU 采购成本、电力成本、运维成本摊到每个月。可控性指标这个最容易被忽略。主要包括输出格式稳定率、敏感内容拦截率、幻觉出现频率、以及微调后的性能变化趋势。格式不稳定是生产环境里最头疼的问题因为下游程序解析不了就全白搭。我给这套指标体系设定了一个默认评分公式综合得分 效果分 × 40% 性能分 × 25% 成本分 × 20% 可控性分 × 15%不过权重永远是活的业务不一样权重就得调。聊天机器人性能权重应该更高法律文书生成场景效果和可控性权重要压上去。评估器允许每个场景单独保存一套权重配置。3. 自动化评估链路构造测试集、批量执行、打分去噪3.1 测试集构造宁可少不能脏这是整个评估器里最需要耐心的一步。公开测试集当然可以直接用但我发现它们和真实业务数据的分布差距太大。你拿 MMLU 这类通用题去测一个垂直行业模型根本测不出它在你业务里的真实水平。我推荐的做法是从真实业务数据里抽样本然后做脱敏和标注。流程分三步。第一收集原始数据。从系统日志、人工处理记录、真实用户反馈里捞一批样本覆盖典型情况和边界情况。第二清洗和标注。定义好每道题的标准答案同时标注难度和考察点。第三分批与版本管理。测试集要分基础集和扩展集基础集稳定不变用来做模型版本回归扩展集跟随业务变化持续更新防止模型过拟合到测试集。数量上单场景至少 100 条核心场景建议 300 条以上。少于 50 条的结果基本没有统计意义模型多回答一轮波动就掩盖了真实差距。3.2 自动打分规则优先模型评审辅助评估器在执行批量测试的时候一次会跑几十个用例逐个人工看根本来不及所以必须自动化打分。我尝试过三种方式。规则打分适合有明确答案的任务。比如信息抽取直接比对模型输出 JSON 里的字段值和标准答案全对得满分部分对按字段给分。这种方式稳定、可解释、没有额外成本是我最推荐的主力方式。模型评审适合开放式的生成任务。用一个更强的模型当裁判LLM-as-a-Judge对比候选模型的输出和参考答案从相关性、完整性、格式三个角度打分。这里要注意裁判模型也会有偏见所以同一个测试集要跑两轮打乱顺序后再跑一轮取平均。人工抽检作为最后一道保险。自动打分全部跑完后按比例抽 10%-20% 的结果人工复核尤其是分数异常高和异常低的样本。人工抽检除了确认机器打分对不对还有一个作用发现测试集本身的问题比如某个题描述有歧义或者标准答案写错了。3.3 测评时常见的数据污染与顺序偏差数据污染这个坑一定要提。如果你的模型是拿网上数据训练的而你的测试集又跟网上某个公开数据集高度重合那测出来的分数会非常虚高。避免的办法是测试集里的样本一定要经过改写不能直接复制网上的原题核心业务数据优先用自己的脱敏数据。顺序偏差是另一个容易被忽略的问题。同一个模型跑同一个测试集先跑后跑结果可能有差异。我碰到过离谱的情况某个模型同样的题隔一天跑分数差了 15%。排查下来有的是因为在线模型的版本偷偷更新了有的是因为并发高导致响应被截断。所以评估器里每次测试都要记录模型版本号、温度参数、请求时间、并发数保证结果可追溯。脱敏操作的覆盖程度也要写进测试报告便于别人审阅数据是否合规。4. 本地部署模型的评估显存、推理速度、量化精度4.1 先算显存账别等部署完才发现装不下很多开源的模型看着参数不大一部署才发现显存爆炸。这里有一个简单的估算公式模型权重占用 ≈ 参数量 × 每个参数的字节数。FP32 是 4 字节FP16/BF16 是 2 字节INT8 是 1 字节INT4 约 0.5 字节。以 7B 模型为例BF16 需要约 14GB 显存INT4 量化后约 3.5GB。但别忘了一件事推理时的 KV Cache 也要占显存长上下文场景下 KV Cache 可能比权重还大。所以更保险的做法是把模型大小、批次大小、输入长度三个参数代入推理框架自己提供的显存估算工具里去算。我在评估器里做了一个简单表格录入模型参数、精度、并发数、上下文长度后会按照每个 Token 的缓存开销大致估算出显存占用区间至少能筛掉一批明显跑不动的方案。4.2 本地推理性能到底怎么测本地部署的模型API 测试那套并发探测方式照样用但核心指标变成了三个单请求延迟、吞吐量、并发劣化曲线。单请求延迟就是用户发出一个请求到收到完整回复的时间。吞吐量是单位时间内能处理的请求数或生成的 Token 数。并发劣化曲线是指逐渐增加并发观察延迟和吞叶怎么变化。有的模型单请求只要 0.5 秒但并发一过 10延迟直接涨到 8 秒这种就不适合做在线服务。我在评估器里会控制输入 Token 长度一致设置不同的并发档位比如 1、4、8、16、32每个档位持续跑 3 分钟记录 TP95 延迟和吞吐量。这里特别强调用 TP95 而不是平均值因为长尾请求才真正影响用户体验。4.3 量化带来的效果损失不能只看显存省了多少量化是把 FP16 权重压成 INT8 或 INT4显存小了速度也快了但效果多多少少会掉。有的模型量化后只掉 0.5% 的分数有的直接掉 5%。这跟模型架构、训练时的量化感知程度都有关系。评估器在处理量化模型时必须跑同一套测试集做两轮比对一轮用原版精度一轮用量化后模型。如果效果分掉得少于 2%性能提升又明显那把量化版本作为推荐方案并在报告里标注量化参数和评测差异。如果分数掉得厉害就宁可用原版接受更高的显存成本。这件事一定要自己测。5. 评估结果怎么落到选型决策上5.1 分场景权重与前后置筛选同一个模型在不同场景里表现可能天差地别。一个通用对话很强的模型做字段抽取不一定比一个小参数模型强。评估器输出的不是一份静态排行榜而是每个场景一份独立报告。我习惯做两个阶段的筛选。第一轮是硬性条件筛选比如必须在私有化环境部署、必须是开源的、上下文窗口必须大于 32K、单次推理成本不能超过某个阈值。这些条件不满足就直接淘汰不用浪费测试时间。第二轮进入完整评测跑效果、性能、成本、可控性四维数据按场景权重计算综合分。5.2 报告里要有结论也要有证据报告如果只给一个综合分别人没法信服。评估器生成报告时我会强制它包含以下内容基础信息模型名称、版本、量化精度、部署方式、测试时间原始数据每个测试用例的输入、标准答案、模型输出、得分四维指标汇总效果分、性能指标、成本测算、可控性表现场景加权后的排名以及推荐理由风险提示比如哪些场景分数波动大、哪些用例反复失败、模型在当前业务上的明显的短板。这样老板看结论团队看证据运维看指标一份报告能满足所有角色。报告我会另外导出一份 CSV方便后续手动分析。5.3 微调后的模型必须重新评估才算数这是很多人都踩过的一个坑拿基座模型测试了一遍微调之后凭感觉觉得应该更好了就直接上线。不做复测你根本分不清微调带来的提升是真的还是因为测试用例对训练数据过拟合。评估器支持同一个模型的不同版本生成对比曲线微调前和微调后跑同一套基础测试集看哪些能力项提升、哪些能力项倒退。尤其是指令遵循和通用知识微调之后反而下降这是很常见的。我在实际使用中见过专门做代码补全的模型微调后代码 F1 提升了 12%但普通对话能力掉得没法用。这种信息不对比测试是发现不了的。6. 评估器在实测中的坑与对策6.1 评测结果的随机波动大模型本身有随机性就算把温度调到 0不同批次跑出来的结果也可能有小幅波动。加上在线模型服务端可能动态调整负载网络波动还得再叠加一层。对策是同一个测试用例至少跑 2 到 3 次取平均。如果两次差距超过 5%就要提高测试次数并且留意服务端的版本和负载情况。6.2 测试集被背下来的伪高分如果你的测试集被用在了模型的训练数据里那评估结果就会虚高。特别是现在很多模型收集了巨量数据很容易出现这种问题。我处理的办法是定期替换测试集里的边界用例保留核心题目不变外环题目每季度换掉 30%。测试集本身也要纳入 git 管理和模型版本、评估结果绑定在一起方便回溯。6.3 长上下文评估的特殊性评价长文本能力时如果只是把一篇长文档放到输入里跑一次问答得分基本是随机的。长文本评测更接近抽检需要在文档的不同位置埋设关键信息分别考察前段、中段、后段信息提取看模型是否真的把整段上下文都读进去了。我见过不少模型输入 64K 以上的文档之后开头信息记得结尾信息也记得中间一大段全忘了。这种问题必须在不同位置埋题才能测出来。评估器还应该记录确实的实际输入 Token 数免得框架自动截断后你误以为模型真读完了。6.4 人工评审一致性用人工评审打分的时候两个评审员给同一份答案打出的分数可能差得很多。我在评估器里加入了双人评审交叉校验并且定义了明确的分值锚点4 分表示完全正确且格式完美3 分表示核心内容正确但有细节遗漏2 分表示方向对但关键信息有误1 分表示完全偏离。分值锚点挂在工作台上评审员一直看得到能显著提高一致性。6.5 评测脚本自身要存版本最后说一个血泪教训评估逻辑本身也是一个软件会改 bug会升级。如果你改了打分逻辑但没记录版本跑出来的两次结果根本没法对比。我从一开始就要求评估器每次运行都要记录核心代码版本和依赖库版本将来复现任何一份历史报告都有据可查。项目做到后面这种“评测评测器本身”的意识会越来越重要。我现在每次给团队出评估报告都会附上完整的运行参数和环境信息。这样即使过两三个月有人质疑某个结论我们还能一键重现当时的测评环境。别小看这个细节它让评估器脱离了“一次性的临时脚本”真正变成了选型决策里可信的基础设施。