你手里那套评测脚本可能还是老思路：单轮问答打分、看个总分排名就交差。体系 2.0 把评测拆得更细，加入了多轮、工具调用、稳定性与成本这几类过去没人当回事的维度，直接照老流程跑出来的结论会站不住。这篇按维度逐条拆解升级点，并给一份从选维度到出报告的落地顺序，让你能自己判断哪些改动必须跟、哪些可以先放。
你手里那套评测脚本可能还是老思路：单轮问答打分、看个总分排名就交差。通用大模型评测体系 2.0 把评测拆得更细，加入了多轮、工具调用、稳定性与成本这几类过去没人当回事的维度，直接照老流程跑出来的结论会站不住。
这篇按维度逐条拆解升级点，并给一份从选维度到出报告的落地顺序。目标不是让你把 2.0 的每条都跟满，而是让你能自己判断：哪些改动必须跟，哪些可以先放，哪些在你当前任务下根本不适用。
2.0 相对老体系改了什么：先分清能力维度与工程维度
老体系偏重单轮问答正确率，2.0 把「多轮一致性、指令遵循、工具调用成功率、长上下文稳定性」拆成独立维度，不再揉进一个总分。这一步改动最容易被低估：揉在一起时，一个模型靠单轮刷高分就能掩盖多轮崩掉的问题。
- 能力维度
- 模型自身输出质量的维度，比如多轮一致性、指令遵循、工具调用成功率、长上下文稳定性。
- 工程维度
- 模型跑在你系统里才暴露的维度，比如单位成本下的有效产出、限流与冷启动对结果的影响、失败可复现性。
工程向维度是 2.0 新增的重头。限流会让并发下的表现和单条测试完全不同，冷启动会让首轮回答明显变差，失败可复现性则决定你排障要花多久。这些在老体系里基本不出现，但恰恰是线上事故的主要来源。
- 先定任务画像，再选维度权重：做知识库问答的和做代码补全的，权重完全不同，不能共用一套。
- 分维度不等权：不要给所有维度相同权重，否则工程维度会被能力维度稀释掉。
- 不适用情形：只在做纯离线文本分类、任务边界极窄时，多轮与工具调用维度可以直接砍掉，硬加只会浪费抽题和复测成本。
- 判断标准：一个维度如果无法定义「什么算失败」，就别放进评测表，否则打分全靠感觉。
按任务画像挑维度：一张对照清单
维度清单不能照抄别人的，得按你的任务画像挑。下面这张表给的是常见任务与优先维度的对应关系，实际权重还要结合你自己的失败案例来调。
| 任务画像 | 优先维度 | 可先放的维度 |
|---|---|---|
| 对话类产品 | 多轮一致性、拒答边界、人设稳定度 | 长文档跨段检索 |
| RAG 知识库问答 | 引用准确率、幻觉率、长文档跨段检索 | 工具选择正确率 |
| Agent / 工具调用 | 工具选择正确率、参数拼装准确率、多步任务完成率与中途纠错 | 人设稳定度 |
| 成本敏感型批处理 | 单位任务 token 消耗、并发下的延迟抬升幅度 | 多轮一致性 |
成本敏感型这一行要特别注意：单位任务 token 消耗和并发下的延迟抬升幅度，不能只看厂商页面上的标称值，得去 /usage 和 /tools/speed-test 拿你自己环境里的基线。同一模型在不同 prompt 结构下消耗差距很大，别人的数字对你没参考价值。
怎么读 2.0 出来的分数：别把总分当结论
2.0 的分维度打分很容易被误读成「总分高就选它」。实际上要先做三件事：看题目饱和、看自评分与第三方复评的差距、做交叉验证。跳过这三步，总分基本等于噪音。
- 看题目饱和多数模型都接近满分的小节，说明这节已经没有区分度，权重该降下来。把区分度低的小节标出来，汇报时不要拿它当卖点。
- 对比自评分与第三方复评差距大的维度要单独复测。可参考 /benchmarks 与 /crowd-radar 的口径说明，确认两边用的是不是同一套失败定义。
- 交叉验证同一维度至少两种题型（选择+开放生成），避免模型只是学会了答题格式。选择题得分高但开放生成掉分的维度，要按开放生成的口径来读。
- 标注适用范围小样本自测（几十条）只能看趋势，不能用来对外下结论；要对外给结论，得把样本量和题型覆盖说清楚。
总分是给汇报用的，分维度和失败样例才是给选型用的。
落地顺序：把新体系套进你现有的评测流程
把 2.0 套进现有流程，关键是冻结变量、留全量记录、把成本并进报告。顺序错了，跑出来的数据下一轮就没法复用，等于白跑。
- 冻结任务画像与维度权重先把任务画像和每个维度的权重写死，再开始抽题。中途改权重等于前面跑的全废。
- 按维度分层抽题每个维度单独抽题，不要用一套通用题跑所有维度，否则无法定位失败原因。分层抽题的样本量按维度重要度分配。
- 固定推理参数再跑温度、上下文长度、并发数固定下来再跑，避免变量混在一起。要测限流影响，就单独开一组对比跑，不要混进主评测。
- 设回退线新体系跑出的结果与老结论冲突时，先复测争议题，再决定是否改选型。模型换代迁移的思路可参照 /models/deploy 的测算逻辑。
- 留全量原始输出与打分理由每条输出的原始文本和打分理由都存下来，方便下次换代时做横向对比，也方便别人复核你的结论。
- 把成本与延迟并进报告只给能力分不给成本的评测报告在选型会上很难被采纳。成本和延迟数据去 /usage 和 /tools/speed-test 取当时的数字，别引用别处的标称值。
| 常见坑 | 后果 | 纠正动作 |
|---|---|---|
| 权重中途改 | 前面跑的数据作废 | 冻结权重后再抽题 |
| 推理参数不固定 | 分不清是模型差异还是参数差异 | 固定温度、上下文长度、并发数 |
| 只存汇总分 | 无法复测争议题 | 留全量原始输出与打分理由 |
| 报告只有能力分 | 选型会难被采纳 | 成本与延迟一并列进报告 |
如果你们团队人手有限，可以先只跟三件事：多轮一致性、工具调用成功率、成本与延迟。这三项覆盖了线上事故的主要来源，也最容易在新体系里拿到可复用的数据。等流程稳定了再补长上下文稳定性与失败可复现性。
下一步想知道当前各家模型和缓存方案在成本口径上的差异，去价格追踪页核对当时的数字，再决定你的评测报告里成本那一列该怎么算。→常见问题
通用大模型评测体系2.0 是不是必须全部维度都跑一遍？
不用。它给的是维度菜单，不是必做清单。先按你的任务画像圈出三到五个核心维度，其余标记为可选项。全跑一遍成本很高，而且很多维度对你的场景没有区分度，纯属浪费推理预算。判断标准是这个维度会不会改变你的选型结论。
按 2.0 的维度重跑，结果会不会和以前的排名差很多？
常见变化是有的，因为加入了多轮、工具调用和成本维度后，过去靠单轮问答刷分的模型优势会被摊薄。但具体差多少取决于你给的权重，不是固定值。建议保留旧结论作为对照组，先看争议题的表现再决定要不要调整清单，别一次性推翻原有选型。
自己团队评测和公开榜单结论不一致，该信哪个？
优先信自己跑的结果，前提是题目、参数和打分口径都记录清楚。公开榜单是多人多时段交叉验证的结果，适合作为参考区间，但题型和你的业务往往不重合，参考口径可以去 /benchmarks/registry 和 /about 看。两者长期冲突时，先排查是不是自己的题太窄或者打分太松。
