评测体系搭建：基准选择、内部 Eval Suite¶

更新日期：2026-04-17

一、评测的三个层次¶

flowchart LR
    capability["1. 能力评测<br/>知识/推理/代码"]
    behavior["2. 行为评测<br/>对话/指令遵循/Arena"]
    safety["3. 安全评测<br/>红队/偏见/越狱"]

    capability --> behavior --> safety

    classDef stage fill:#fff,stroke:#cc785c,color:#1a1a1a;
    class capability,behavior,safety stage

层次	关注点	典型基准	评测方式
能力	是否能解决问题	MMLU, GSM8K, HumanEval, AIME	自动验证（多选/单元测试）
行为	是否好用	Chatbot Arena, MT-Bench, IF-Eval	人类盲评 / LLM-as-Judge
安全	是否会出事	HarmBench, ToxiGen, JailbreakBench	红队 + 自动判定

二、通用基准速查¶

2.1 2026 主流基准¶

2.2 数学基准¶

2.3 代码基准¶

2.4 Agent 基准¶

三、评测框架¶

3.1 主流评测框架对比¶

3.2 lm-evaluation-harness 使用¶

# 运行一组基准测试
lm_eval --model hf \
    --model_args pretrained=meta-llama/Llama-3.1-70B-Instruct \
    --tasks mmlu,gsm8k,humaneval,hellaswag,arc_challenge \
    --device cuda \
    --batch_size 8 \
    --output_path results.json

# 自定义任务
# 添加 YAML 配置文件:
task: my_custom_task
dataset_path: my_dataset
metric: accuracy

四、人类评估¶

4.1 Chatbot Arena (LMSYS)¶

最被信任的综合评测。原因：人类盲评 + 大规模 + 无法 game。参考 Chatbot Arena。机制: 1. 用户提交 prompt 2. 系统随机选 2 个匿名模型回答 3. 用户选哪个更好 (或平局) 4. Bradley-Terry 模型计算 ELO

2026 前沿: - Claude Opus 4.6: ~1380 ELO - GPT-5: ~1375 ELO - Gemini 3.1 Pro: ~1370 ELO - DeepSeek-V3: ~1340 ELO (最强开源) - Qwen3-72B: ~1300 ELO

4.2 为什么 Arena 可信¶

五、内部 Eval Suite 搭建¶

企业/研究团队应当建立自己的 eval suite，不能只依赖公开基准。

5.1 Eval Suite 组成¶

flowchart LR
    smoke["冒烟测试<br/>~20 例核心能力"]
    regression["回归测试<br/>~200 例不退步"]
    domain["领域评测<br/>~1k 例业务任务"]
    adversarial["对抗 / 红队<br/>~100 例越狱与边界"]
    online["线上反馈<br/>真实用户 + thumbs"]

    smoke --> regression --> domain --> adversarial --> online

    classDef stage fill:#fff,stroke:#cc785c,color:#1a1a1a;
    class smoke,regression,domain,adversarial,online stage

模块	规模	频率	用途
冒烟	20-50	每次 commit	拦截严重退化
回归	200-1000	每次 release	确保新版本不退步
领域	1k-10k	每次重要训练	验证业务效果
对抗	100-500	每次重要 release	安全 / 红队
线上	持续	实时	真实分布反馈

5.2 自建 Eval 数据¶

# 好的内部 eval 数据有这些特征:
eval_example = {
    'task': '从客服对话中提取客户问题',
    'instruction': '...',
    'input': '<真实用户对话>',

    # 关键: 可自动验证的 output
    'expected_output_format': 'JSON with keys [problem, category, urgency]',
    'verification': {
        'format_check': lambda out: is_valid_json(out),
        'category_in_list': lambda out: out['category'] in VALID_CATEGORIES,
        'semantic_match': lambda out, gt: llm_judge_similarity(out, gt) > 0.8,
    },

    # 金标准答案 (用于对比)
    'ground_truth': {...},

    # 难度标注
    'difficulty': 'medium',

    # 所属模块
    'tags': ['customer_service', 'extraction', 'chinese'],
}

5.3 Eval 流程自动化¶

class InternalEvalRunner:
    def __init__(self, eval_suite):
        self.suite = eval_suite

    def run(self, model, baseline_model=None):
        results = {}
        for task in self.suite:
            # 运行当前模型
            predictions = [model.generate(x) for x in task.inputs]
            scores = [task.verify(p, gt) for p, gt in zip(predictions, task.ground_truth)]
            results[task.name] = {
                'accuracy': mean(scores),
                'failures': [(x, p) for x, p, s in zip(task.inputs, predictions, scores) if s < 1],
            }

            # 对比 baseline
            if baseline_model:
                baseline_preds = [baseline_model.generate(x) for x in task.inputs]
                baseline_scores = [task.verify(p, gt) for p, gt in zip(baseline_preds, task.ground_truth)]
                results[task.name]['baseline'] = mean(baseline_scores)
                results[task.name]['delta'] = mean(scores) - mean(baseline_scores)

        return results

六、评测的陷阱¶

6.1 数据污染 (Data Contamination)¶

基准题目可能已经泄露到训练数据中。模型在基准上表现好 ≠ 能力强。 为什么这是最严重的问题： 大模型的训练数据通常包含整个互联网的爬取，而几乎所有公开基准的题目和答案都在互联网上。这意味着模型可能"见过答案"而非"推理出答案"。最极端的案例：某些模型在 HumanEval 上 pass@1 超过 90%，但在语义相同、变量名不同的改写版上骤降 20%+，说明模型在"背答案"。

污染的三种形式：

直接污染：题目和答案原样出现在训练数据中
间接污染：题目的解析、讨论帖、博客文章出现在训练数据中
基准蒸馏：用已知答案的基准数据微调模型（某些排行榜刷分者的做法）

# 检测方法:

# 1. 完成度测试 (Completion Test)
# 给模型前一半，看能否补全后一半
# 原理：如果模型见过这道题，它能像"背课文"一样补全
for question in benchmark:
    prefix = question[:len(question)//2]
    completion = model.generate(prefix)
    if similarity(completion, question[len(question)//2:]) > 0.8:
        mark_contaminated(question)

# 2. 顺序敏感性 (Order Sensitivity)
# 污染的模型对选项顺序敏感——因为它记住的是"答案是 C"而非"答案是 xxx"
original_score = model.score(question)
shuffled_score = model.score(shuffle_options(question))
if abs(original_score - shuffled_score) > threshold:
    likely_contaminated = True

# 3. 改写鲁棒性 (Paraphrase Robustness)
# 语义不变但措辞改变，被污染的模型分数会明显下降
original_score = model.score(question)
paraphrased_score = model.score(paraphrase(question))
if original_score - paraphrased_score > threshold:
    likely_contaminated = True

应对策略：

优先使用动态更新的基准（LiveCodeBench、AIME 最新年份）
保留私有测试集，绝不公开
报告结果时同时使用多个基准，交叉验证
关注时间分割：只看训练截止日期之后的题目

6.2 基准饱和 (Benchmark Saturation)¶

当一个基准上前沿模型都 >95%，这个基准就失去了区分度。 深入理解饱和问题： 饱和不只是"分数太高"。更本质的问题是天花板效应——当所有前沿模型都在 93-96% 之间时，2% 的差异可能完全来自随机波动（prompt 格式、few-shot 选择、解码策略），而非真实能力差异。此时基准变成了噪声而非信号。 饱和的生命周期模式：

发布 → 前沿 ~50% → 社区关注 → 模型改进 → 前沿 ~80% → 核心基准阶段 → 前沿 ~95% → 饱和 → 保留为"历史参考" → 被新基准替代典型周期: 1-3 年 (且在加速)

6.3 Goodhart 定律 (Goodhart's Law)¶

"一旦指标变成目标，它就不再是好指标。" 这在 LLM 评测中的具体表现：

Prompt 工程优化：同一个模型，换一种 prompt 格式分数可以差 5-10%。某些公司会为每个基准精调 prompt 模板来刷分，这不反映真实能力。
基准特化训练：在微调阶段混入基准数据或风格相似的数据。结果：基准分数飙升，但用户体验没有对应提升。这就是为什么 Chatbot Arena 的人类盲评与基准排名经常不一致。
评估指标 gaming：例如在代码评测中，模型可能学会生成"刚好能通过给定测试用例但逻辑不正确"的代码。HumanEval+ 通过增加测试用例暴露了这一点。
选择性报告：只报告表现最好的基准，忽略表现差的。解读 benchmark 时要问："他们没报告什么？"

实际案例： 2024-2025 年间，多个开源模型在 MMLU 上超过 GPT-4，但在 Chatbot Arena 中排名远低于 GPT-4。原因：这些模型针对 MMLU 风格的多选题做了大量优化，但在自由形式对话中表现平平。

6.4 评估方式的隐性偏差¶

同一个基准，不同的评估细节可以导致截然不同的分数。 这是经常被忽视的陷阱。以下因素都会显著影响分数： 后果： 两篇论文报告同一个模型在 MMLU 上的分数可能差 5%，仅仅因为评估细节不同。比较不同来源的分数时，必须确认评估协议一致。

6.5 单一指标的误导性¶

一个数字无法概括一个模型的全部能力。 常见的错误思维："模型 A 在 MMLU 上 90%，模型 B 只有 85%，所以 A 更好。"但实际上：

模型 B 可能在代码能力上远超 A
模型 B 可能在中文任务上远超 A
模型 B 可能在长上下文任务上远超 A
模型 B 的延迟可能只有 A 的 ⅓

正确做法： 始终使用雷达图/多维度对比，而非单一排名。针对你的具体使用场景，选择最相关的 3-5 个基准加权评估。

七、最佳实践¶

全面的评测策略: - 综合使用多个独立基准 (不依赖单一指标)

保留私有测试集 (不公开, 防污染)
定期抽样人工评估 (发现自动评测的盲点)
跟踪Chatbot Arena (综合人类感受)
建立回归测试 (每次迭代不退步)
监控真实用户反馈 (最终真理)

参考文献¶

[1] lm-evaluation-harness
[2] OpenCompass
[3] HELM
[4] Chatbot Arena
[5] LLM Leaderboard (Vellum)
[6] Hendrycks et al. MMLU. 2020. 论文
[7] HLE Benchmark. 2025. 论文
[8] LiveCodeBench. 2024. 论文

↑ 上级 · I. 评测与安全