别只盯着榜单：大模型上线前的评测体系，到底要评什么

模型榜单分数越来越高，但真正把大模型放进生产环境的团队都知道：榜单成绩和线上表现之间，隔着一整个工程化鸿沟。一个在通用基准上名列前茅的模型，可能在你的业务场景里把 JSON 输出得支离破碎，或者对长上下文的指令遵从一塌糊涂。本文结合近期多个项目的落地经验，梳理一套大模型上线前值得认真搭建的评测体系，重点回答"到底要评什么"。

一、先评任务适配度，而不是通用能力

通用榜单衡量的是模型的"平均智商"，而业务关心的是"在你的任务上的成功率"。上线前评测的第一层，应该是从真实业务中抽取的代表性任务集：把过去一段时间内的真实请求脱敏后抽样，覆盖高频场景、边界场景和已知易错场景，标注出期望输出。这个私有任务集哪怕只有两三百条，对上线决策的价值也远超任何公开基准。关键是样本要"脏"一点——包含口语化表达、错别字、多轮上下文残缺等真实噪声，而不是干净利落的测试用例。

二、评结构化输出的稳定性

如果下游系统依赖模型输出 JSON、SQL 或特定格式，稳定性必须单独评测。做法很简单：让模型对同一批输入重复生成多次（比如每条跑 5 遍），统计格式合法率、字段完整率和值一致性。实践中最常翻车的不是"完全不会"，而是"偶尔错"——90% 的合法率意味着每天上万次调用中有上千次需要兜底重试，这个成本必须在上线前算清楚。对这类场景，评测还应覆盖不同温度参数下的表现，而不是只测默认配置。

三、评指令遵从的边界

大模型最常见的线上事故，是模型"热心地做了没让它做的事"：要求只做分类，它输出了大段解释；要求引用给定材料，它补充了训练语料里的知识。指令遵从评测要设计对抗性用例：系统提示词与用户输入冲突时听谁的、要求"不知道就说不知道"时是否硬编、多约束条件叠加时是否丢约束。这类问题在通用榜单位置上几乎测不出来，但对幻觉率敏感的业务是致命的。

四、评长上下文的衰减

模型标称支持 128K 上下文，不代表在 100K 处还有可靠的召回能力。"大海捞针"式测试应该成为标配：在长文档的不同深度埋入关键信息，检验模型能否准确提取。实践中发现，很多模型的检索能力随上下文长度增加明显衰减，且"中间内容"比"开头结尾"更容易被忽略。如果业务依赖 RAG 拼接的长上下文，评测时就应该用真实拼接后的形态去测，而不是干净的独立长文。

五、评成本与延迟曲线，而不只是单次均值

评测体系里最容易缺的是工程指标。单次调用的均值延迟没有意义，要看 P95/P99 延迟分布、并发压力下的吞吐衰减，以及不同输入长度下的 token 消耗。特别是推理类模型，思考链长度不可控，可能出现个别请求消耗上万思考 token 的情况，直接冲击成本预算和超时策略。上线前应基于评测数据设定明确的熔断和降级预案。

结语：评测是持续资产，不是上线门槛

很多团队把评测当成上线前的一次性考试，通过后就束之高阁。真正有价值的做法是把评测集变成持续资产：每次线上发现坏例，经过确认后回流进评测集；每次更换模型或升级版本，全量回归一遍，用同一把尺子量化收益与退化。评测体系建的早、养的勤，模型迭代才能从"凭感觉换"变成"看数据换"——这才是大模型工程化真正的护城河。