模型评测榜怎么看
榜单要拆开看：人工盲测偏好类榜单反映的是人类主观选择，适合判断整体体验；真实仓库缺陷修复类基准靠自动测试判定，更贴近工程任务；知识类选择题基准容易被数据污染，分数高不等于好用。最关键的判断依据是自己那套贴合业务的评测集——公开榜单决定候选范围，自建评测决定最终选择。
基本信息
| 榜单类型 | 人工偏好、真实任务自动判定、知识问答、专项能力 |
|---|---|
| 人工偏好类 | 盲测投票产生排名，反映整体可用性 |
| 真实任务类 | 在真实代码库或任务上自动判定，贴近工程场景 |
| 知识类 | 选择题准确率，易受训练数据污染影响 |
| 自建评测 | 用业务真实问题加标准答案，参考价值最高 |
| 使用建议 | 榜单筛候选，自建评测定最终选择 |
常见榜单怎么读
| 榜单类型 | 测什么 | 读法 |
|---|---|---|
| 人工偏好类 | 人类更倾向哪个回答 | 看排名区间与题目分布，别只盯名次 |
| 缺陷修复类 | 能否在真实仓库修好问题 | 看通过率与任务难度构成 |
| 知识问答类 | 知识覆盖与推理水平 | 警惕训练数据污染带来的虚高 |
| 专项能力类 | 代码、数学、长文等单点能力 | 按自己的任务类型挑选对照 |
| 企业自建类 | 贴合业务任务的实际表现 | 最应该投入精力建设的一类 |
自建评测怎么做
- 从线上真实请求里取样，覆盖高频与困难两类任务
- 给每条样本写标准答案或可自动判定的验收条件
- 把评测脚本固化下来，每次换模型或改提示词都跑一遍
- 按功能维度拆分指标，避免总分掩盖局部回退
- 人工抽查一部分结果，防止自动指标与体感脱节
评测集的最小结构
评测集的最小结构
{"id": "case-001", "task": "extract", "input": "……一段真实工单文本……",
"expected": {"类别": "前端异常", "是否紧急": true},
"check": "字段级比对"}
# 一条样本包含：输入、期望输出、判定方式
# 判定方式尽量自动化：字段比对、关键词命中、脚本校验
# 主观类任务另附评分标准，由人工或模型按标准打分
# 评测集要版本化，样本增删都要留记录常见陷阱
| 陷阱 | 后果 | 规避 |
|---|---|---|
| 只看总分 | 局部能力回退被掩盖 | 按功能维度分别统计 |
| 样本与训练数据重叠 | 分数虚高，上线后落差大 | 用业务私有数据做评测 |
| 样本量太小 | 结论不稳定，波动被当成提升 | 扩充到足以区分差异的规模 |
| 判定标准模糊 | 同一结果不同人给出不同分 | 把判定条件写成可执行的规则 |
评测集是资产：随着业务变化持续补充困难样本，它的价值会随时间增长，比任何一次性的选型结论更持久。
把公开榜单名次写进采购或验收标准风险很大：榜单考察的任务与自家业务相差越远，名次与实际体验的落差就越大。