先评再选：用 EvalScope 产出选型报告

作者先讲了一个惨痛教训：给业务部门做模型训练时，误以为"通用榜单更强的模型，业务场景必然更出色"，信誓旦旦承诺新模型微调后会更好——结果翻车。每个模型的预训练数据构成不同：有的恰好见过大量与你业务相似的数据，微调事半功倍；有的通用能力虽强，却和你的领域"八字不合"，怎么调都差一口气。

结论只有一句话：通用指标只能做初筛，最终选择必须看业务数据上的表现。

一、为什么"问几个问题"选不出模型

常见选型动作——看排行榜、看下载量、准备几个问题手动试试——都有一致缺陷：测试集不固定、评判标准不统一，结果不可比。两个模型看起来都答得不错，放到几百上千条数据上测，准确率和稳定性可能差距明显。

评测的价值就是把不规范的判断变成统一方法：准备 500 道固定测试题，让 Qwen、DeepSeek 等候选模型分别回答，用相同规则算分。既可比整体，也能定位各自的强弱项。

二、两级评测：公开 Benchmark 初筛 + 业务数据复测

公开 Benchmark 各测什么：

Benchmark 分数高 ≠ 业务好用：公开数据集没有你的专业术语和内部规则。正确姿势是用它做初筛圈出 2-3 个候选，再用业务数据复测——智能客服就用真实咨询记录，知识库就用员工日常检索问答，工业运维就用设备故障日志。

业务测试集的准备误区是"越多越好"。代表性和覆盖面比数量关键：一份合格的测试集要有梯度——日常高频基础题 + 一定比例的复杂长难题 + 边界异常题。全是简单重复题测出的高分没有参考价值。

三、EvalScope：一次装好，三件事都能干

EvalScope 是 ModelScope 社区的评测框架，覆盖大语言模型、多模态模型和检索用的 Embedding/Reranker。四个能力点：

1. 通用 + 自定义都支持：预置 MMLU/GSM8K 等，也支持自定义评测集（业务分类、问答、抽取数据直接进流程）；
2. 接入形态全：本地离线模型、vLLM/SGLang 部署的 OpenAI 格式服务都能测；
3. 性能压测：模拟多并发，测吞吐量、首 Token 延迟（TTFT）、单 Token 耗时（TPOT）、P50/P99；
4. 报告可视化：自动生成统计报表与对比图表。

动手最快路径（Notebook 内）：

pip install evalscope
# 公开题库初筛：Qwen3-0.6B 跑 math_500 前 10 条
evalscope eval --model Qwen/Qwen3-0.6B --datasets math_500 --limit 10

检索效果评测（RAG 选 Embedding 模型时）：准备三个文件——corpus.jsonl（文档库）、queries.jsonl（查询）、qrels.jsonl（查询-正确文档对应关系），走 RAGEval + MTEB 后端跑 Recall/Precision。

性能压测：先 vllm serve 起一个 OpenAI 兼容服务，再用 EvalScope 分别以 1/10/50/100 并发打过去，观察吞吐量、首 Token 延迟和成功率随并发的变化——这一步测出的是客户生产环境的承载能力。

四、FDE 视角：选型报告是售前阶段的硬通货

• 给客户的选型结论不要写"我们调研后推荐 X"，要写：初筛方法（Benchmark 选了哪几个、为什么）→ 业务测试集构成（多少条、什么梯度、怎么标注）→ 候选模型对比表（效果分 + 压测数据）→ 结论与风险；
• 压测数据（并发-延迟曲线）是方案里最防杠的部分：客户 IT 一句"我们 200 人同时用会不会卡"，用 P99 数据回答；
• 业务测试集本身就是交付资产——后续微调验收、版本升级回归都能复用（呼应交付工程线的"评测体系从零建"）。

本课自测

1. 为什么榜单高分不能直接推出业务好用？两级评测各解决什么问题？
2. 一份合格的业务测试集要有什么梯度？为什么纯简单题的高分没有参考价值？
3. EvalScope 的检索评测需要准备哪三个文件？各放什么内容？
4. TTFT 和 TPOT 分别衡量什么？客户问"会不会卡"该用哪个数据回答？