选模型先看榜单排名，是很多团队的第一反应。但把学术榜单分数直接等同于业务效果，落地时往往会踩坑。下面聊聊榜单的局限，以及自建业务评估集的实战方法。

## 学术榜单的三处硬伤

**第一，数据污染。**测试集里的题目可能已经混进模型的训练语料，公开的技术讨论中多次指出过这类现象。一旦污染存在，高分反映的可能是记忆能力而非泛化能力，而污染与否从外部很难验证。

**第二，与业务脱节。**MMLU 考的是学科知识问答，HumanEval 考的是独立函数编写，但真实业务可能是客服多轮对话、老代码修 bug、领域文档问答。榜单任务分布和业务任务分布不一致，排名靠前的模型未必是业务上最好用的。

**第三，刷榜导致过拟合。**当整个行业都盯着同一套榜单优化时，分数上涨可能来自对榜单分布的针对性调优，而非能力的真实提升。

众包竞技榜单如 Chatbot Arena（现 LMArena）是另一个参照系，但它反映的是普通用户的即时偏好：回答更长、语气更好往往占优，这和任务正确性是两回事。

## 自建评估集的四步法

**1. 任务采样。**从真实业务日志里按意图分布采样，覆盖高频场景和长尾难例。采样要分层，避免被头部意图淹没。

**2. 黄金答案。**简单任务由专家撰写标准答案并交叉校对；主观任务不设唯一答案，而是制定评分细则（rubric），明确几档得分的判定标准。

**3. 人工 + LLM-as-judge 双轨。**全量用 judge 模型规模化打分，定期抽样做人工复核，校准两者的一致率。要注意 judge 模型的系统性偏见：偏好更长的回答、对先出现的选项更宽容等，prompt 里要显式约束，必要时交换选项顺序做二次判定。

**4. 版本基线与回归流程。**锁定一个基线版本，每次模型或 prompt 迭代都跑全量评估集，做版本间差分分析；把历史上翻车的坏案例沉淀为回归库，防止修好一个坏一个。

榜单适合做初步筛选，自有评估集才是上线决策的依据。你在做模型选型时，是更信榜单还是更信自己的评估集？欢迎分享你的评测实践。