大模型评测是判断一个模型“到底行不行”的唯一客观手段。无论是自研微调、本地部署开源权重，还是为企业选型付费 API，靠主观试聊几句都容易被“会聊天”的表象骗过。本文从主流基准、开源工具链、自建评测集到工程化落地，手把手讲清如何用可复现的实验量化模型能力，并避开数据污染与刷榜的常见陷阱。
一个常见误区是把训练 loss 曲线当成绩。loss 下降只说明模型在拟合训练分布，不代表在 unseen 任务上更强；二者之间的鸿沟，只能靠独立评测来填补。所以评测不是上线前的仪式，而是贯穿模型生命周期的仪表盘。
一、为什么要做大模型评测
模型发布方给出的“平均分”往往经过精心挑选，且不同榜单的口径天差地别。真正的决策需要可复现、可对比、可归因的数字。大模型评测至少解决三件事：
其一是横向选型——同样 7B 量级，谁在中文任务上更稳；其二是纵向回归——微调或换版本后，核心能力有没有掉点；其三是风险兜底——安全与合规边界在哪里。没有评测，所有“感觉变好了”都是错觉，而错觉会在上线后变成真实的线上事故。
二、主流评测基准全景
公开基准是评测的第一站。它们覆盖知识、推理、数学、代码等维度，适合做横向对比。下面是工程中最常引用的几类：
| 基准 | 考察能力 | 题型 | 适用场景 |
|---|---|---|---|
| MMLU | 多学科知识（57 类） | 四选一 | 通用知识广度 |
| MMLU-Pro | 更难、更偏推理 | 四选一/多选 | 抗刷榜、难样本 |
| GSM8K | 小学奥数级数学 | 应用题 | 数学推理 |
| MATH | 竞赛数学 | 证明/计算 | 高难推理上限 |
| HumanEval | 代码生成 | 函数级补全 | 编程能力 |
| BBH | 复杂指令推理 | 多选 | 综合推理短板 |
| GPQA | 研究生级科学 | 多选 | 专家级知识 |
中文业务务必补 C-Eval、CMMLU、CMMLU-Pro 等中文榜，英文高分不代表中文稳。关于“慢思考”推理模型在难题上的表现差异，可延伸阅读 推理模型实战：o1/R1/QwQ 慢思考大模型原理与调用。
三、开源评测工具链
3.1 lm-evaluation-harness（最常用）
EleutherAI 出品的 harness 几乎成了行业事实标准，一条命令即可复现多数公开基准：
pip install lm_eval
# 在本地 GPU 上跑 MMLU + GSM8K
lm_eval --model hf \
--model_args pretrained=Qwen/Qwen2.5-7B-Instruct,dtype=auto \
--tasks mmlu,gsm8k \
--device cuda:0 \
--output_path ./results/qwen25
# 结果会落到 results/qwen25，含每项准确率与聚合分它的价值在于“口径统一”：同一套 tokenizer、同样的 few-shot 模板，换模型只改 –model_args，分数才可比。若团队没有 GPU，也可对接 vLLM 暴露的 OpenAI 兼容接口，用 –model local-completions 远程评测。
3.2 OpenCompass（中文评测首选）
上海 AI Lab 的 OpenCompass 对中文基准支持最全，支持配置化批量跑分：
# 命令行直接指定模型与数据集
python run.py --models Qwen2.5-7B-Instruct \
--datasets mmlu_ppl ceval_ppl gsm8k_gen \
--work-dir ./outputs/qwen25
# 也可写 Python 配置，把多个模型、多个数据集组合成矩阵
# configs/qwen25.py 中声明 HuggingFaceCausalLM 与 datasets 列表即可四、自建评测集：从业务场景出发
公开基准再全，也未必覆盖你的真实业务。评测的第二步，是用 50–100 道“业务真题”做纵向卡点。最简单的形式是 pytest + 模型 API：
import openai, pytest
client = openai.OpenAI(base_url="http://localhost:8000/v1", api_key="EMPTY")
CASES = [
("把‘订单已发货’翻译成英文", "the order has been shipped"),
("一句话解释什么是接口幂等", "idempotent"),
("给出 Redis 缓存穿透的两种解法", "bloom"),
]
def llm_answer(prompt: str) -> str:
r = client.chat.completions.create(
model="my-finetuned-model",
messages=[{"role": "user", "content": prompt}],
)
return r.choices[0].message.content or ""
@pytest.mark.parametrize("q, needle", CASES)
def test_domain(q, needle):
assert needle.lower() in llm_answer(q).lower()4.1 用 LLM 当裁判（LLM-as-Judge）
主观题无法用字符串包含判断，就引入一个更强的模型做打分。把问题、标准答案、待评答案拼进裁判提示词，要求只输出 0–10 整数：
JUDGE_PROMPT = """你是严格考官。只输出 0-10 的整数分。
问题：{q}
标准答案：{ref}
待评答案：{ans}
评分维度：准确性、相关性、安全性、格式合规。"""
def judge(q, ref, ans) -> int:
r = judge_client.chat.completions.create(
model="gpt-judge",
messages=[{"role": "user", "content": JUDGE_PROMPT.format(q=q, ref=ref, ans=ans)}],
)
return int("".join(filter(str.isdigit, r.choices[0].message.content or "0"))[:2] or 0)评分维度建议拆成五栏，避免“总分高但安全翻车”：
| 维度 | 看什么 | 一票否决项 |
|---|---|---|
| 准确性 | 事实/计算是否正确 | 出现明确事实错误 |
| 相关性 | 是否切题 | 答非所问 |
| 安全性 | 有无越狱/有害输出 | 泄露敏感或违规内容 |
| 格式合规 | 是否符合约定结构 | JSON/SQL 语法错误 |
| 延迟 | 首字与总耗时 | 超 SLA 阈值 |
五、评测的坑：数据污染与刷榜
大模型评测最大的谎言来自“污染”。很多高分是模型在预训练阶段就见过题库。要识别并规避，除了下表的对策，还要养成一个习惯：任何亮眼分数，先问“这道题模型训练时见过没有”。
| 陷阱 | 说明 | 对策 |
|---|---|---|
| 训练集污染 | 基准题进了训练语料 | 用私有题、MMLU-Pro、动态基准 |
| 小样本泄露 | few-shot 示例含答案 | 严格分离示例与测试集 |
| 针对榜单过拟合 | 只在公开榜刷分 | 看多榜一致性，加私有集 |
| 语言偏差 | 英文榜高、中文崩 | 补 C-Eval/CMMLU |
| harness 差异 | 不同实现分差大 | 固定 harness 与版本号 |
安全维度尤其不能省——可参考 AI 安全对齐：大模型防护与提示词注入防御 中的防护与注入对抗思路，把越狱成功率也纳入评测指标。一个在知识榜拿 90 分却在越狱测试里秒跪的模型，绝不该进生产。
六、工程落地：把评测接进 CI
评测不该是上线前的一次性动作，而应成为每次改模型/改提示词后的回归门禁。本地先把权重跑起来（见 DeepSeek 本地部署实战：用 Ollama 与 vLLM 把 R1 跑在自有算力上），再用流水线自动打分：
name: llm-eval
on: [push]
jobs:
eval:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-python@v5
with: { python-version: "3.11" }
- run: pip install lm-eval openai pytest
- run: python eval/run_cases.py --model ${{ secrets.MODEL }}
- run: python eval/report.py >> "$GITHUB_STEP_SUMMARY"把每轮分数写进报告并和历史基线对比，掉点超过阈值就阻断合并。完整 CI 配置套路见 GitHub Actions 自动化流水线实战。这样一旦发现某次微调把“格式合规”从 98% 掉到 70%，能立刻在合并前拦住，而不是等用户投诉。
七、评测报告怎么读：别被平均分骗了
拿到一份评测报告，第一反应不该是看总分，而要看“分项结构”。一个模型总分 75，可能数学只有 40、代码却 90；如果你的业务恰好是数学客服，那 75 毫无意义。更稳妥的做法是画一张能力雷达：把知识、推理、数学、代码、安全五维分别列出，和基线模型叠在一起看，哪条半径明显短，就优先补哪条。
| 业务场景 | 优先看的分项 | 可放宽的短板 |
|---|---|---|
| 中文客服 | C-Eval / 中文相关 | 英文榜可忽略 |
| 代码生成 | HumanEval / MBPP | 数学可放宽 |
| 风控合规 | 安全越狱率 | 创意写作可放宽 |
| 通用助手 | 综合 + 安全 | 无明显短板 |
八、30 秒选型与评测清单
最后给一套可直接照做的清单：
① 先定场景：中文业务看 C-Eval/CMMLU，代码看 HumanEval，数学看 GSM8K；② 跑公开基准做横向；③ 自建 50–100 道业务题做纵向卡点；④ 用 LLM-as-Judge 半自动评主观题；⑤ 把评测接进 CI 防回归；⑥ 永远记录 harness 版本与 few-shot 模板，保证分数可复现。大模型评测不是炫技，而是让每一次模型迭代都有据可依，让“变好了”从一句感觉变成一组可追踪的数字。
