企业官网建设流程全解析

在 lm-evaluation-harness 中评估时间常识推理：MC-TACO 任务详解

【免费下载链接】lm-evaluation-harnessA framework for few-shot evaluation of language models.项目地址: https://gitcode.com/GitHub_Trending/lm/lm-evaluation-harness

MC-TACO（Multiple Choice Temporal Commonsense）是 EleutherAI 的lm-evaluation-harness中内置的一项**时间常识理解（Temporal Commonsense Understanding）**评测任务，对应仓库内的任务配置位于 lm_eval/tasks/mc_taco/default.yaml，任务说明文档位于 lm_eval/tasks/mc_taco/README.md。本文将以该任务为线索，介绍 MC-TACO 数据集的核心设计、五种时间属性、在 harness 中的 YAML 配置实现，以及使用--limit参数时的关键注意事项，帮助读者正确复现该基准并理解其评测结果的语义。

一、MC-TACO 是什么：面向时间常识的 13k 问答数据集

MC-TACO 全称 Multiple Choice Temporal Commonsense，源自论文《"Going on a vacation" takes longer than "Going for a walk": A Study of Temporal Commonsense Understanding》（论文摘要见 arXiv:1909.03065）。它是一组包含13k 个问答对的数据集，专门用于考察模型对**时间常识（temporal commonsense）**的掌握程度——即人类在无须显式计算的情况下，对事件时长、先后顺序、发生时刻等时间关系的直觉判断。

根据任务 README 的描述，MC-TACO 将时间常识拆解为五类时间属性（five temporal properties）：

1. duration（时长）：一个事件需要多长时间，例如"去度假"比"去散步"花的时间更长；
2. temporal ordering（时序）：事件的典型先后顺序；
3. typical time（典型时间）：事件通常发生在什么时间；
4. frequency（频率）：事件多久发生一次；
5. stationarity（稳定性）：某个状态是否会长时间甚至无限期地保持。

数据集主页为 AllenAI 的公共排行榜（leaderboard.allenai.org/mctaco），该基准是社区衡量模型时间常识推理能力的事实标准之一。

二、仓库中的任务实现：逐字段解析 default.yaml

在lm-evaluation-harness中，所有任务均以 YAML 配置为核心（框架层面详见 docs/task_guide.md）。MC-TACO 的完整任务配置位于 lm_eval/tasks/mc_taco/default.yaml，全文如下：

task: mc_taco dataset_path: CogComp/mc_taco output_type: multiple_choice validation_split: validation test_split: test doc_to_text: "{{sentence}}\nQuestion: {{question}}\nAnswer: {{answer}}\nPlausible:" doc_to_target: label doc_to_choice: ["no", "yes"] should_decontaminate: true doc_to_decontamination_query: "{{question}} {{sentence}}" metric_list: - metric: acc - metric: f1 metadata: version: 1.0

下面对照框架的TaskConfig字段（见 docs/task_guide.md 的 "Configurations" 一节）逐项解读：

• task: mc_taco：任务注册名，即命令行中传入--tasks的名称。README 的 "Tasks" 一节确认仓库仅提供mc_taco这一个变体，且当前不属于任何任务组（Not part of a group yet）。

• dataset_path: CogComp/mc_taco：Hugging Facedatasets库中的数据集标识（对应load_dataset的第一个参数），由 CogComp 团队维护。

• output_type: multiple_choice：指定模型输出类型为多项选择。框架支持generate_until、loglikelihood、loglikelihood_rolling与multiple_choice四种输出类型，此处选择multiple_choice意味着模型对每个候选项计算对数似然并选取得分最高者。

• validation_split: validation/test_split: test：分别指定验证集与测试集。原论文的官方设置以验证集为评测基准，因此该配置将validation与test两个 split 都显式声明出来。

• doc_to_text：Jinja2 模板，负责把一条数据渲染成喂给模型的输入文本。MC-TACO 的模板为：

  {{sentence}} Question: {{question}} Answer: {{answer}} Plausible:

  它把原始事件句（sentence）、问题（question）和候选答案（answer）拼接在一起，并让模型预测末尾 "Plausible:" 之后的内容，即该候选答案在时间常识上是否"说得通"。

• doc_to_target: label：取数据集中的label字段作为目标答案。对multiple_choice任务而言，它返回的是正确答案在doc_to_choice列表中的下标。

• doc_to_choice: ["no", "yes"]：两个候选答案，"no" 表示"不合理"、"yes" 表示"合理"。这正是 MC-TACO 的判定式任务形态：对每个 "事件句 + 问题 + 候选答案" 组合判断其合理性。

• should_decontaminate: true：开启去污染（decontamination）检查。对应的框架实现位于 lm_eval/api/task.py：当should_decontaminate为真时，若doc_to_decontamination_query为 None 则回退到doc_to_text，否则按配置中的模板渲染查询串。

• doc_to_decontamination_query: "{{question}} {{sentence}}"：以"问题 + 事件句"作为去污染查询文本，用于检测评测语料是否与模型训练语料重叠（详见 docs/decontamination.md）。

• metric_list：评测指标为acc（准确率）与f1（F1 分数）。这两个指标均为框架原生支持（见 lm_eval/api/metrics.py），f1对每个样本计算 gold 与 pred 后按宏平均聚合。

• metadata: version 1.0：配置版本号，用于追踪任务配置的迭代（框架约定任务应在metadata中携带version键）。

三、为什么对 MC-TACO 使用--limit会得到误导性结果

这是本任务 README 中最重要的警示，务必在复现前理解：

WARNING: Running this task with a--limitarg will give misleading results!

其根因在于 MC-TACO 数据集的构造方式。作者把每道多选题拆解为若干"问题-选项对"（question-option pairs），例如一道包含 4 个候选答案的选择题会被拆成 4 条独立样本，每条样本交由模型单独做合理性判断（plausibility testing）。在 harness 中，这些拆解后的样本被"隔离"进**独立的文档（document）**参与评测。

由于评测执行前会对文档进行打乱（shuffle），一旦使用--limit N截取前 N 条文档，就很可能**"截断"掉某道题的部分候选答案**：有的选项进了被评测的子集，有的选项被丢弃。而本任务的指标（尤其是准确率与 F1）要求穷尽式地评估一道题的全部选项——例如准确率的计算需要在同一道题的全部候选项都被模型打分之后才能判定模型选对了哪个。只评估部分选项会系统性扭曲分数，使结果无法与官方排行榜或论文中的设置对齐。

这一点在原论文的 Section 4 中有详细论述（README 中亦指明参见论文第 4 节）。因此：

• 评测 MC-TACO 时应评测完整数据集（validation 或 test 全量），不要加--limit；
• 如果确实需要快速冒烟测试管线是否跑通，请把--limit的结果仅当作"流程验证"而非"模型得分"来解读；
• 框架层面，--limit对应EvalConfig中的limit字段（见 docs/config_files.md 的 Config Schema 表），它会按文档数截断每个任务的输入，对绝大多数独立样本任务无影响，但对这种"选项被拆分、指标需跨文档聚合"的任务是致命的。

四、实际运行方式

在仓库根目录下，可以直接用命令行运行该任务（模型侧以 Hugging Face 模型为例）：

# 用验证集评测（论文官方基准设置） lm-eval run \ --model hf \ --model_args pretrained=gpt2,dtype=float32 \ --tasks mc_taco \ --device cuda:0 # 也可以同时验证任务配置是否合法 lm-eval validate --tasks mc_taco

需要注意两点：

1. 不要加--limit（理由见上一节）；如需限制，仅用于验证管线连通性。
2. 任务的 prompt 设计是"事件句 + 问题 + 候选答案 + Plausible:" 的判定式模板，最终指标为acc与f1。若要与其他实现对比，务必保持相同的 prompt 与指标配置——这正是 README Checklist 中所要求的"记录发布评测设置是否被复现"的意义。

此外，任务 README 中的 Citation 部分目前仅保留了占位符（"BibTeX-formatted citation goes here"），实际引用时应采用论文《"Going on a vacation" takes longer than "Going for a walk": A Study of Temporal Commonsense Understanding》（arXiv:1909.03065）的 BibTeX。

五、小结与延伸阅读

MC-TACO 任务在lm-evaluation-harness中以极简的 YAML 配置实现：multiple_choice输出类型 + 判定式模板 +acc/f1双指标 + 去污染查询，是理解"选项拆分型"数据集如何在评测框架中落地的典型案例，同时也是一面重要的警示牌——不是所有任务都适合用--limit抽样评测。

延伸阅读路径：

• 任务配置：lm_eval/tasks/mc_taco/default.yaml
• 任务说明：lm_eval/tasks/mc_taco/README.md
• 任务配置字段详解：docs/task_guide.md
• 运行参数与配置文件：docs/config_files.md
• 去污染机制：docs/decontamination.md
• 指标与聚合函数实现：lm_eval/api/metrics.py

【免费下载链接】lm-evaluation-harnessA framework for few-shot evaluation of language models.项目地址: https://gitcode.com/GitHub_Trending/lm/lm-evaluation-harness