smol-course 自动基准评测指南：用 LightEval 跑通 MMLU 等标准 Benchmark 并构建你自己的评测策略

• 教程
• 人工智能
• 大模型
• NLP
• 微调

自动基准（Automatic Benchmarks）是评估语言模型能力的标准化工具，也是本仓库 Evaluation 模块（v1/4_evaluation/README.md）中第一条评测路径。本篇指南将带你理解 MMLU、TruthfulQA、GSM8K 等主流基准各自的评估对象与固有局限，掌握 LightEval 中{suite}|{task}|{num_few_shot}|{auto_reduce}的任务定义格式与完整评测管线写法，并在此基础上构建一套"标准基准打底 + 自定义领域评测兜底"的多层评测策略，最终能为你的 smol 模型产出一份可复现、可横向对比的评测结果。

理解自动基准评测：标准化带来的价值与边界

自动基准通常由一组精心整理的带标签数据集和预定义评测指标构成，目的是从"基础语言理解"到"复杂推理"等多个维度刻画模型能力。它们的核心优势在于标准化：

• 可横向对比：不同模型在相同任务、相同指标下可以直接比较分数；
• 结果可复现：固定 prompt 模板、固定 few-shot 示例数量与固定采样种子，评测结论可以稳定复现。

但也必须清醒认识到：基准分数并不总是等价于真实世界的有效性。一个在学术基准上表现优异的模型，可能依然无法胜任特定领域的业务应用——这正是本仓库在标准基准之外又开辟了 自定义领域评测 与完整领域评测项目 的原因。

主流基准与其各自局限

通用知识类基准

• MMLU（Massive Multitask Language Understanding）：横跨从科学到人文学科的 57 个学科子任务，覆盖面广、信息量大。但正因为"广"，它未必能反映某个专业领域所需的深度专业能力——你在仓库的 评测 notebook 中可以看到，实践中常从 MMLU 中抽取anatomy、professional_medicine、high_school_biology、high_school_chemistry等子任务拼出一个"医疗领域"评测集，这正是对 MMLU 的一种领域化裁剪用法。
• TruthfulQA：评测模型"复述常见误解"的倾向，用于衡量事实性与诚实性。但它只能覆盖已知的误解类型，无法捕获所有形式的错误信息。

推理类基准

• BBH（Big-Bench Hard）：聚焦逻辑思维与规划类复杂任务，考察模型的分析能力。
• GSM8K：小学数学应用题集，专门测试数学问题求解能力。

这两类基准能很好地暴露模型在"多步推理"上的短板，但现实场景中的推理往往需要结合上下文、领域知识甚至工具调用，这类"细粒度推理"很难被标准题集完整覆盖。

语言理解类基准

• HELM：提供一个整体性（holistic）的评测框架，覆盖多种能力与场景。
• WinoGrande：通过代词消歧任务测试常识推理。

它们能给出语言处理能力的快照，却不足以代表真实对话的复杂性，也未必覆盖领域专属术语的用法。

替代评测方法：弥补标准基准的盲区

针对标准基准的上述局限，业界普遍发展出三类替代方法：

1. LLM-as-Judge（以大模型评大模型）：用一个大模型评价另一个模型的输出。相比传统指标能给出更细腻的反馈，但它自带模型偏见，需要谨慎设计裁判 prompt 并做偏差校验。
2. 评测竞技场（Evaluation Arenas）：例如 Anthropic 的 Constitutional AI Arena，让模型在受控环境中互相交互与评估，能暴露出传统基准中不易显现的相对强弱。
3. 自定义基准套件（Custom Benchmark Suites）：组织内部按自身业务定制评测集，可能包含领域知识测试，或模拟真实部署场景的评测用例。

这三类方法与标准基准并非互斥，而是互补——仓库的领域评测项目正是"自定义套件"的完整落地示范（项目 README）。

构建你自己的评测策略

核心原则一句话：LightEval 让跑标准基准变得很容易，但你不应止步于此。标准基准提供基线，自定义评测决定上线。建议按以下四步展开：

1. 先用相关标准基准打底：建立基线，并支持与其他模型做公平对比。
2. 明确你的用例需求：你的模型实际要完成哪些任务？哪类错误最致命？先回答这两个问题再设计评测。
3. 开发贴合真实用例的自定义数据集，可以包括：
   • 来自你业务领域的真实用户查询；
   • 你实际遇到过的常见边界情况（edge cases）；
   • 特别有挑战性的场景样例。
4. 实现多层评测策略：
   • 自动化指标用于快速反馈；
   • 人工评估用于捕捉细腻的语义差异；
   • 领域专家评审用于专业应用场景；
   • 受控环境下的 A/B 测试用于最终决策。

用 LightEval 运行自动基准

任务定义格式

LightEval 中的每个任务都是一个特定格式的字符串：

{suite}|{task}|{num_few_shot}|{auto_reduce}

例如"mmlu|abstract_algebra|0|0"表示：在 MMLU 的 abstract_algebra 子任务上以 zero-shot 方式评测。

值得注意：仓库配套 notebook 中实际使用的是另一种常见形态"leaderboard|mmlu:anatomy|5|0"——即 suite 为leaderboard、task 用mmlu:anatomy这种"套件:子任务"写法、few-shot 为 5。两种写法都遵循同一套四字段格式，具体以你的 LightEval 版本所支持的任务注册表为准。

一个完整的评测管线示例

原文档给出了一个针对医学领域任务的完整示例（automatic_benchmarks.md）：

from lighteval.tasks import Task, Pipeline from transformers import AutoModelForCausalLM # Define tasks to evaluate domain_tasks = [ "mmlu|anatomy|0|0", "mmlu|high_school_biology|0|0", "mmlu|high_school_chemistry|0|0", "mmlu|professional_medicine|0|0" ] # Configure pipeline parameters pipeline_params = { "max_samples": 40, # Number of samples to evaluate "batch_size": 1, # Batch size for inference "num_workers": 4 # Number of worker processes } # Create evaluation tracker evaluation_tracker = EvaluationTracker( output_path="./results", save_generations=True ) # Load model and create pipeline model = AutoModelForCausalLM.from_pretrained("your-model-name") pipeline = Pipeline( tasks=domain_tasks, pipeline_parameters=pipeline_params, evaluation_tracker=evaluation_tracker, model=model ) # Run evaluation pipeline.evaluate() # Get and display results results = pipeline.get_results() pipeline.show_results()

各参数含义：max_samples控制采样的样本数量（评测子集大小），batch_size控制推理批大小，num_workers控制 worker 进程数。评测结果会以表格形式输出：

| Task |Version|Metric|Value | |Stderr| |----------------------------------------|------:|------|-----:|---|-----:| |all | |acc |0.3333|± |0.1169| |leaderboard:mmlu:_average:5 | |acc |0.3400|± |0.1121| |leaderboard:mmlu:anatomy:5 | 0|acc |0.4500|± |0.1141| |leaderboard:mmlu:high_school_biology:5 | 0|acc |0.1500|± |0.0819|

此外你还可以把结果装入 pandas DataFrame，按自己的需求做可视化和再加工。

仓库配套 notebook 中的"真实可用"版本

上面的示例更侧重教学示意；如果直接照抄运行，需要注意EvaluationTracker与Pipeline的实际导入路径。仓库配套的 评测 notebook 给出了经过实际运行的等价写法：

from datetime import timedelta from transformers import AutoModelForCausalLM from lighteval.logging.evaluation_tracker import EvaluationTracker from lighteval.models.model_config import create_model_config from lighteval.pipeline import EnvConfig, ParallelismManager, Pipeline, PipelineParameters env_config = EnvConfig(token=TOKEN, cache_dir="~/tmp") evaluation_tracker = EvaluationTracker( output_dir="~/tmp", save_details=False, push_to_hub=False, push_to_tensorboard=False, public=False, hub_results_org=False, ) pipeline_params = PipelineParameters( launcher_type=ParallelismManager.ACCELERATE, env_config=env_config, job_id=1, override_batch_size=1, num_fewshot_seeds=0, max_samples=10, use_chat_template=False, )

对比可见：notebook 用PipelineParameters对象承载批大小、max_samples、few-shot 种子数等配置，并通过EnvConfig传入 Hugging Face token 与缓存目录；EvaluationTracker则支持把结果push_to_hub或push_to_tensorboard（示例中均关闭）。评测时先AutoModelForCausalLM.from_pretrained(...)加载模型，再构造Pipeline(tasks=..., pipeline_parameters=..., evaluation_tracker=..., model=...)，调用pipeline.evaluate()后通过pipeline.get_results()取结果、pipeline.show_results()打印表格。

notebook 还示范了最有价值的用法——用同一组领域任务横向对比两个小模型：分别对Qwen/Qwen2.5-0.5B与HuggingFaceTB/SmolLM2-360M-Instruct运行同一份医疗领域任务列表（leaderboard|mmlu:anatomy|5|0等），再用 pandas 把两份results["results"]的acc列拼在一起画横向柱状图。这套流程可以直接复用到：为推理场景选模型、训练中定期评测 checkpoint、以及对外分享模型分数。

进阶：让自动基准与自定义评测协同

自动基准只是完整评测策略的第一环。本仓库建议的下一步是进入 自定义领域评测指南，学习如何用 LightEval 的LightevalTaskConfig注册自定义任务、用SampleLevelMetric/SampleLevelMetricGrouping实现自定义指标；再对照完整的领域评测项目（包含 generate_dataset.py、annotate_dataset.py、create_dataset.py、evaluation_task.py 四步脚本管线），把"标准基准 + 领域自定义评测"的组合策略真正落地。标准基准负责回答"我的模型处于什么水平"，自定义评测负责回答"我的模型能不能上线"——两者缺一不可。

• 教程
• 人工智能
• 大模型
• NLP
• 微调