能力不是单一分数
模型能力指模型在特定任务、语言与输入分布下的表现分布，而不是一个可以横比的综合分。同一次发布里，「会写代码」和「严格按 JSON 输出」是两种独立能力：前者依赖知识与推理，后者依赖指令遵循与格式约束，训练数据与后训练策略不同，强弱没有必然关联。拆解维度的目的，是让选型、验收和上线回归都落到可复现的具体项目上，而不是停在「感觉更聪明」。
基本信息
| 评估对象 | 闭源 API 模型 / 开源自托管权重 / 微调后的自有模型 |
|---|---|
| 维度来源 | 公开榜单做初筛，业务自建集做定论 |
| 最小可行集 | 20~50 条高频真实请求，覆盖主场景与边界 |
| 记录口径 | 通过率、人工偏好、格式合法率、稳定性分开记 |
| 复核时机 | 模型版本变更、业务分布变化、集中投诉出现 |
| 统计单位 | 按场景统计，不按模型整体统计 |
典型使用场景
- 选型初筛：先用公开榜单缩小候选范围，再用自建集做淘汰赛
- 上线验收：新模型接入前逐维度过一遍，避免整体替换后局部退化
- 版本回归：厂商更新后跑同一套题，确认核心能力没有回退
- 立项评估：判断现有模型能否支撑目标功能，不承诺无法交付的效果
- 投诉归因：定位「变笨」是能力、提示词、检索还是解析环节的问题
- 档位分配：把贵模型留给真正需要的维度，其余走低成本档位
维度与观察点
| 维度 | 怎么看 | 容易误判 |
|---|---|---|
| 知识与事实 | 领域问答、术语解释、单位与口径是否一致 | 把检索缺失误判成知识缺口 |
| 多步推理 | 逻辑与计算题的正确率、中间步骤能否核查 | 只看最终答案不看过程 |
| 指令遵循 | 格式、字段、字数、拒答边界是否遵守 | 把下游解析失败算成能力弱 |
| 长上下文 | 长文档定位、跨段引用、末尾信息保持 | 只看标称窗口不测有效长度 |
| 工具调用 | 意图识别、参数拼装、错误重试是否规范 | 把工具侧报错算成模型错误 |
| 多模态 | 图文对应、表格与截图读数、版面理解 | 把预处理 OCR 误差算成理解错误 |
| 稳定性 | 同一输入多次运行的结论一致率 | 用单次最好结果代表整体水平 |
可复用的评测记录
可复用的评测记录
# 每条记录只描述一个可复现的最小评测单元
id: case-013 # 稳定编号，便于跨版本对比
scene: 合同金额抽取 # 写业务场景，不要写模型能力名
lang: zh # 输入语言，中英文分开统计
input_hash: 3f9c2a... # 输入指纹，避免题目被悄悄改动
expect: 字段齐全且口径为含税 # 期望必须可判定
metric: pass_or_fail # 优先通过率，主观打分单独一列
run: 3 # 重复次数，用来看抖动
seed: 20261017 # 支持固定随机性的通道要固定
prompt_ver: v7 # 提示词版本必须与结果一起归档公开榜单的维度划分偏学术：更看重孤立题目上的知识与推理，对中文长尾表达、行业术语、格式约束与工具链协作覆盖不足。自建集的价值不在规模，而在于它复刻了你的真实输入分布与失败代价。
不要用单一综合分做决策。更稳的做法是按维度加权：把每个维度和一次失败的修复成本挂钩，格式错误可以重试，事实错误会直接伤害用户信任，两者的权重不该相同。
温度、采样上限、工具调用字段名等具体参数，各厂商口径与默认值并不一致，务必以对应厂商官方文档为准；评测结论要连同当时的参数一起归档，否则无法复现。