ms-swift评测功能：用OpenCompass评估模型真实水平-育师

ms-swift评测功能：用OpenCompass评估模型真实水平

1. 为什么模型评测不能只看“感觉”？

你有没有遇到过这样的情况：微调完一个模型，自己试了几个问题，觉得效果不错，信心满满地部署上线，结果用户反馈“回答不靠谱”“逻辑混乱”“经常胡说八道”？
这不是你的错——而是缺少一套客观、全面、可复现的评测体系。

很多开发者习惯用“人工抽查+主观打分”的方式判断模型好坏。这种方式效率低、覆盖窄、易受情绪影响，更关键的是：它无法发现模型在特定能力维度上的系统性缺陷。比如，一个模型可能在常识问答上表现优异，但在数学推理或中文长文本理解上严重失能；又或者在单轮对话中流畅自然，却在多轮上下文保持中频繁遗忘前序信息。

ms-swift 没有把评测当作一个“附加功能”，而是将其设计为训练闭环中不可绕过的质量守门员。它深度集成 OpenCompass 作为评测后端，不是简单调个接口，而是打通了从模型加载、数据预处理、推理调度、指标计算到报告生成的全链路。这意味着：你不需要额外配置评测环境，不用手动拼接提示词模板，也不用为不同数据集写重复代码——一条命令，就能跑出一份专业级的模型能力画像。

本文将带你实操 ms-swift 的评测模块，聚焦 OpenCompass 集成能力，手把手演示如何用真实数据集量化评估一个微调后的 Qwen2.5-7B-Instruct 模型。不讲抽象概念，只讲你能立刻用上的方法、踩过的坑和看得见的效果。

2. 评测前必知：ms-swift 与 OpenCompass 是怎么协作的？

2.1 评测不是“跑个分”，而是一套标准化流水线

ms-swift 的swift eval命令背后，是一整套被工程化封装的评测流程：

模型接入层：自动识别模型类型（Qwen、Llama、GLM 等），加载对应 tokenizer 和 template，处理 system prompt、role 格式等细节；
推理引擎层：支持pt（PyTorch 原生）、vllm、lmdeploy三种后端，可按需选择速度与显存的平衡点；
OpenCompass 对接层：将 ms-swift 的模型输出无缝转换为 OpenCompass 要求的 JSONL 格式，自动映射数据集字段（如question→input，answer→label）；
指标计算层：调用 OpenCompass 内置的各类评估器（accuracy、bleu、rouge、math_equivalence 等），对每个子任务独立打分；
报告生成层：输出结构化 Markdown 报告 + CSV 详情表，支持横向对比多个模型版本。

这个设计让评测真正脱离“手工劳动”，变成和训练、推理一样可脚本化、可版本化、可自动化触发的关键环节。

2.2 为什么选 OpenCompass？它解决了什么实际问题？

OpenCompass 是上海人工智能实验室推出的开源大模型评测框架，其核心价值在于权威性、广度与可解释性：

权威数据集全覆盖：内置 100+ 经典评测集，涵盖语言理解（MMLU、CMMLU）、推理（GSM8K、Math）、代码（HumanEval、MBPP）、中文专项（C-Eval、Gaokao-Bench）、多模态（MMBench、OCRBench）等，所有数据集均经过严格清洗与格式统一；
细粒度能力拆解：不只给一个总分，而是按学科、难度、题型、知识点维度逐层展开。例如 C-Eval 不仅给出总准确率，还细分“数学”“物理”“法律”“历史”等 52 个子领域得分；
公平可比的基准线：提供官方发布的各主流模型（Qwen、Llama、InternLM 等）在相同硬件、相同设置下的参考分数，让你一眼看清自己的模型处于什么梯队；
开放透明的实现：所有评测脚本、prompt 模板、评分逻辑全部开源，你可以随时查看、修改、复现，杜绝“黑箱评测”。

ms-swift 选择 OpenCompass，正是因为它不是“玩具级评测”，而是工业级模型交付前必须通过的“能力体检报告”。

3. 实战：用一条命令跑通 Qwen2.5-7B-Instruct 的完整评测

我们以一个真实场景为例：你刚用 ms-swift 完成对 Qwen2.5-7B-Instruct 的 LoRA 微调，现在需要快速验证它在通用能力上的提升效果。我们将使用 OpenCompass 的经典组合——C-Eval（中文综合能力） + GSM8K（数学推理） + ARC（常识推理）进行三维度评估。

3.1 环境准备：轻量起步，无需重装

确保你已安装 ms-swift（推荐pip install 'ms-swift[all]' -U），并准备好微调后的模型路径（例如output/qwen2.5-7b-instruct-lora/checkpoint-500）。OpenCompass 依赖会随ms-swift[all]自动安装，无需单独配置。

注意：OpenCompass 默认使用 CPU 运行评估器（非模型推理），因此对 GPU 显存无额外要求。模型推理部分由--infer_backend控制，可灵活选择。

3.2 核心命令：一条指令，三套数据集并行评测

CUDA_VISIBLE_DEVICES=0 swift eval \ --model Qwen/Qwen2.5-7B-Instruct \ --adapters output/qwen2.5-7b-instruct-lora/checkpoint-500 \ --infer_backend vllm \ --eval_backend OpenCompass \ --eval_dataset C-Eval \ --eval_dataset GSM8K \ --eval_dataset ARC_c \ --max_new_tokens 1024 \ --temperature 0.0 \ --num_gpus_per_model 1 \ --limit 100 \ --work_dir ./eval_results/qwen25_lora_v1

参数详解（用人话解释）：

--model：指定基础模型 ID，ms-swift 会自动从 ModelScope 下载或加载本地路径；
--adapters：指向 LoRA 权重目录，ms-swift 会自动加载并注入模型；
--infer_backend vllm：启用 vLLM 加速推理，大幅提升评测吞吐（尤其对长上下文）；
--eval_backend OpenCompass：明确指定评测后端为 OpenCompass；
--eval_dataset：可多次使用，添加多个数据集。C-Eval是中文综合能力标杆，GSM8K测数学解题，ARC_c（ARC-Chinese）测常识推理；
--limit 100：每个数据集只评测前 100 题，用于快速验证。正式评测时可移除此参数；
--work_dir：指定结果保存目录，便于后续归档与对比。

3.3 执行过程：看到的不只是日志，更是能力图谱

运行后，你会看到清晰的分阶段输出：

[INFO:swift] Loading model and adapters... [INFO:swift] Initializing OpenCompass evaluator... [INFO:swift] Running evaluation on C-Eval (100 samples)... [INFO:swift] Running evaluation on GSM8K (100 samples)... [INFO:swift] Running evaluation on ARC_c (100 samples)... [INFO:swift] Aggregating results... [INFO:swift] Generating report to ./eval_results/qwen25_lora_v1/...

约 15–20 分钟后（取决于 GPU 性能），评测完成。结果将生成在./eval_results/qwen25_lora_v1/目录下，包含：

summary.md：主报告，含各数据集总分与关键子项；
details/：每个数据集的详细结果（JSONL 格式，含每题输入、模型输出、是否正确）；
configs/：本次评测使用的完整配置文件，确保可复现。

3.4 结果解读：从数字读懂模型“会什么、不会什么”

打开summary.md，你会看到类似这样的结构化报告：

## 评测总览 | 数据集 | 子集数量 | 样本数 | 准确率 | 参考基线（Qwen2.5-7B-Instruct 原版） | |--------|----------|--------|--------|-----------------------------------| | C-Eval | 52 | 100 | 62.3% | 58.1% | | GSM8K | 1 | 100 | 41.7% | 35.2% | | ARC_c | 1 | 100 | 78.9% | 76.5% | ## C-Eval 详细能力分布（Top 5 提升领域） | 领域 | 得分 | 提升幅度 | 说明 | |----------|------|----------|--------------------------| | 法律 | 72.1%| +8.3% | 合同条款理解更精准 | | 计算机 | 68.5%| +6.1% | 编程概念解释更清晰 | | 历史 | 65.2%| +5.7% | 时间线梳理更连贯 | | 数学 | 59.8%| +4.2% | 基础运算正确率提升 | | 物理 | 53.6%| +3.9% | 公式应用更合理 | ## ❗ GSM8K 典型错误分析（抽样10例） - 错误类型1（占比40%）：步骤跳步，直接给出答案未展示推导； - 错误类型2（占比30%）：单位换算错误（如 km/h 误作 m/s）； - 错误类型3（占比20%）：题目条件遗漏（忽略“匀速”“静止”等关键词）； - 错误类型4（占比10%）：四则运算笔误。

这份报告的价值远超一个总分：
你知道模型在法律、计算机等专业领域提升显著，可优先用于相关场景；
你发现数学推理仍是短板，且问题集中在“步骤缺失”和“单位混淆”，下一步微调可针对性加入带步骤的数学数据；
你确认常识推理稳定可靠，可放心用于客服、知识问答等泛化任务。

这才是评测该有的样子——不是“及格/不及格”，而是“哪里强、哪里弱、怎么补”。

4. 进阶技巧：让评测更贴合你的业务需求

4.1 自定义数据集：评测你最关心的“真问题”

OpenCompass 支持自定义 JSONL 格式数据集。假设你的业务场景是电商客服，最怕模型答非所问或编造商品参数。你可以构造一个ecommerce_qa.jsonl：

{"question": "这款手机支持5G吗？", "label": "支持，搭载高通骁龙8 Gen2处理器，支持Sub-6GHz和毫米波5G网络。", "category": "5G"} {"question": "退货地址在哪里？", "label": "请寄回：上海市浦东新区张江路123号XX科技仓库，邮编201203。", "category": "售后"}

然后用以下命令评测：

swift eval \ --model Qwen/Qwen2.5-7B-Instruct \ --adapters output/checkpoint-500 \ --eval_backend OpenCompass \ --custom_eval_dataset ./data/ecommerce_qa.jsonl \ --eval_config ./configs/ecommerce_eval.py

其中ecommerce_eval.py定义评分逻辑（如：是否包含关键信息点、是否虚构地址），让评测真正服务于业务目标。

4.2 多模型横向对比：一次命令，看清升级效果

你想对比微调前、微调后、合并 LoRA 后三个版本的差异？只需一行：

swift eval \ --model Qwen/Qwen2.5-7B-Instruct \ --adapters output/before_lora \ --adapters output/after_lora \ --adapters output/merged_full \ --eval_backend OpenCompass \ --eval_dataset C-Eval \ --work_dir ./eval_results/compare_v1

ms-swift 会自动为每个--adapters生成独立结果，并在最终报告中并排对比，一目了然看出哪次迭代带来了实质性提升。

4.3 评测即服务：集成到 CI/CD 流水线

将评测嵌入自动化流程，是保障模型质量的终极手段。你可以在 GitHub Actions 或 Jenkins 中添加步骤：

- name: Run Model Evaluation run: | swift eval \ --model ${{ secrets.MODEL_ID }} \ --adapters ${{ github.workspace }}/output/latest \ --eval_backend OpenCompass \ --eval_dataset C-Eval \ --limit 50 \ --work_dir ./eval_report if: always() - name: Fail if C-Eval drops below threshold run: | score=$(grep "C-Eval.*accuracy" ./eval_report/summary.md | awk '{print $NF}' | sed 's/%//') if (( $(echo "$score < 60" | bc -l) )); then echo "❌ C-Eval score $score% < 60% threshold" exit 1 fi

当评测分数低于设定阈值（如 C-Eval < 60%），流水线自动失败，阻止低质模型上线。这才是真正的“质量左移”。

5. 常见问题与避坑指南

5.1 问题：评测卡在“Loading model...”，GPU 显存爆满

原因：--infer_backend pt（PyTorch 原生）在加载大模型时默认占用全部显存，而 OpenCompass 评估器本身也需少量显存。

解法：

优先使用--infer_backend vllm，它内存管理更高效；
若必须用pt，添加--device_map auto和--max_memory {gpu_id}:12GiB限制单卡显存；
对于 24GB 显卡，建议--per_device_eval_batch_size 1并关闭--stream。

5.2 问题：C-Eval 得分异常低（<30%），但人工测试感觉不错

原因：C-Eval 题目为选择题（A/B/C/D），模型若未按标准格式输出选项（如输出“答案是A”而非纯“A”），OpenCompass 会判错。

解法：

在swift eval命令中添加--few_shot true，启用 OpenCompass 内置的 few-shot prompt；
或自定义--eval_config，强制模型输出格式（如"请只输出一个字母：A/B/C/D"）；
检查details/c_eval/下的原始输出，确认格式是否合规。

5.3 问题：想用 OpenCompass 的最新数据集，但 ms-swift 报错“dataset not found”

原因：ms-swift 内置的 OpenCompass 版本可能滞后。OpenCompass 每月更新数据集，而 ms-swift 发布周期不同步。

解法：

手动升级 OpenCompass：pip install opencompass -U；
使用--opencompass_path /path/to/opencompass指向本地最新版；
或等待 ms-swift 下一版本发布（通常滞后 1–2 周）。

5.4 问题：评测耗时太久，想加速但又怕影响准确性

平衡策略：

--limit 50：小样本快速验证（误差 < 2%）；
--num_gpus_per_model 2：多卡并行（需--infer_backend vllm）；
--batch_size 8：增大 batch（需显存充足）；
--temperature 0.0：关闭采样，固定输出，避免因随机性重复运行。

记住：评测速度与精度的平衡点，永远在你的业务节奏里。上线前用全量，日常迭代用抽样，这才是可持续的实践。

6. 总结：评测不是终点，而是新起点

用 ms-swift + OpenCompass 做模型评测，本质上是在构建一套可信赖的能力度量衡。它帮你回答三个关键问题：

我的模型到底强在哪、弱在哪？→ 不再靠感觉，而是看 C-Eval 的 52 个领域得分；
这次微调真的有效吗？→ 不再凭印象，而是对比before和after的 GSM8K 提升幅度；
它能不能上生产？→ 不再拍脑袋，而是用ecommerce_qa这类业务真题一票否决。

评测的价值，从来不在那个漂亮的总分，而在于它暴露出的每一个细节偏差——那些“答对了但步骤错”“分类对了但置信度低”“响应快了但幻觉增多”的微妙信号，才是驱动下一轮优化的真实燃料。

当你把swift eval变成和swift sft一样日常的命令，你就已经走出了“调参炼丹”的作坊模式，迈入了“数据驱动、质量可控”的工程化正轨。

获取更多AI镜像
想探索更多AI镜像和应用场景？访问 CSDN星图镜像广场，提供丰富的预置镜像，覆盖大模型推理、图像生成、视频生成、模型微调等多个领域，支持一键部署。

ms-swift评测功能：用OpenCompass评估模型真实水平