LongProc 长程过程生成基准评测任务在 lm-evaluation-harness 中使用与指标解析【免费下载链接】lm-evaluation-harnessA framework for few-shot evaluation of language models.项目地址: https://gitcode.com/GitHub_Trending/lm/lm-evaluation-harnessLongProcLong Procedural Generation是一个针对长上下文语言模型的基准测试其核心思路是通过长过程生成long procedural generation来检验模型模型必须严格遵循给定的过程性指令并产出结构化的长输出。本文以 lm-evaluation-harness 仓库中lm_eval/tasks/longproc/的 README 与配套 YAML/源码为依据完整讲解该基准的 6 类任务、16 个子任务、长度分级、评测指标与命令行运行方式并结合metrics.py、utils.py与任务配置深入剖析每类任务的打分原理与底层实现帮助你直接上手评测长上下文模型的过程遵循与长程生成能力。LongProc 基准概览LongProc 由 Princeton PLI 团队提出Ye, Xi et al., LongProc: Benchmarking Long-Context Language Models on Long Procedural GenerationConference on Language Modeling, 2025目标是评测长上下文 LLM 的过程性生成能力模型需要按照指定的过程procedure一步步执行并生成结构化输出输出长度横跨 500 到 8K tokens。这意味着它不仅考验能否读懂长上下文更考验能否在长输出中始终如一地遵循规则、不中途出错。在 lm-evaluation-harness 中LongProc 通过 lm_eval/tasks/longproc/ 目录下的 YAML 任务配置接入评测框架其完整引用信息标题、摘要、Homepage 与 BibTeX记录在 lm_eval/tasks/longproc/README.md 中。仓库内提供原文的 BibTeX 引用条目inproceedings{ye25longproc, title{LongProc: Benchmarking Long-Context Language Models on Long Procedural Generation}, author{Ye, Xi and Yin, Fangcong and He, Yinghui and Zhang, Joie and Yen, Howard and Gao, Tianyu and Durrett, Greg and Chen, Danqi}, journal{Conference on Language Modeling}, year{2025} }6 类任务与 16 个子任务LongProc 覆盖 6 种任务类型每种类型内部再按目标输出长度细分为多个子任务总计16 个可评测任务。README 中的 Groups/Tags/Tasks 结构如下任务类型子任务按长度任务内容Countdown0.5k / 2k / 8k通过算术运算搜索组合数字达到目标数Path Traversal0.5k / 2k / 8k在图中遍历连接两座城市的路径Theory-of-Mind Tracking0.5k / 2k / 8k在物体放置故事中跟踪位置与信念HTML-to-TSV0.5k / 2k / 8k从 HTML 页面抽取信息并转为 TSV 格式Pseudocode-to-Code0.5k / 2k将逐行伪代码翻译为 C 代码Travel Planning2k / 8k依据时长与航班约束制定旅行计划每个子任务的命名规则为longproc_task_type_length例如longproc_countdown_0.5k。各任务入口配置位于 lm_eval/tasks/longproc/ 目录如 countdown_0.5k.yaml、path_traversal_0.5k.yaml、travel_planning_2k.yaml 等并通过include机制共享三份按长度划分的默认配置。Group 层次结构与指标聚合任务按三层 Group 组织全部在longproc根 Group 下聚合根 Grouplongproc包含全部 16 个任务定义于 lm_eval/tasks/longproc/_longproc.yaml类型 Group如longproc_countdown0.5k/2k/8k、longproc_path_traversal、longproc_tom_tracking、longproc_html_to_tsv、longproc_pseudo_to_code0.5k/2k、longproc_travel_planning2k/8k每个类型一个 YAML例如 lm_eval/tasks/longproc/_longproc_countdown.yaml叶子任务每个子任务一个 YAML 文件。聚合时lm_eval/tasks/longproc/_longproc.yaml 通过aggregate_metric_list将各任务score取均值weight_by_size: false从而得到整个基准的综合分group: longproc task: - longproc_countdown - longproc_path_traversal - longproc_tom_tracking - longproc_html_to_tsv - longproc_pseudo_to_code - longproc_travel_planning aggregate_metric_list: - metric: score aggregation: mean weight_by_size: false metadata: version: 1.0任务配置的继承关系与长度分级所有任务共享三份按输出长度的默认配置通过include指令引用默认配置适用任务max_gen_toks_default_yaml_0.5k各 0.5k 任务含longproc_travel_planning_0.5k之外的 0.5k 任务1024_default_yaml_2k各 2k 任务3072_default_yaml_8k各 8k 任务92160.5k 默认配置_default_yaml_0.5k的完整内容dataset_path: PrincetonPli/LongProc unsafe_code: true output_type: generate_until test_split: test process_docs: !function utils.process_docs doc_to_text: {{input_prompt}} doc_to_target: {{reference_output}} num_fewshot: 0 generation_kwargs: temperature: 0 do_sample: false until: [] max_gen_toks: 1024 metadata: version: 1.0关键配置项说明dataset_path: PrincetonPli/LongProc评测数据来自 Hugging Face 上的PrincetonPli/LongProc数据集test_split: test指定使用 test 划分output_type: generate_until任务属于自由生成型非 loglikelihood 型模型需要完整生成答案文本process_docs: !function utils.process_docs调用 utils.py 中定义的process_docs对原始数据做预处理doc_to_text/doc_to_targetinput_prompt作为模型输入reference_output作为标准答案也是打分时的 ground truthgeneration_kwargstemperature: 0、do_sample: false保证贪婪解码、结果可复现max_gen_toks依长度分级放宽1024 → 3072 → 9216保证足够空间生成长输出unsafe_code: true标记该任务涉及执行模型生成的代码。在 lm_eval/api/task.py 中unsafe_code is not False会令任务设置UNSAFE_CODE True提示评测环境存在安全风险伪代码转 C 任务需要本地编译运行模型输出。数据预处理utils.process_docsutils.py 中process_docs的唯一职责是解析metadata列数据集中每行样本的metadata字段是 JSON 字符串这里将其反序列化为 Python dict 存回metadata_parsed供模板渲染和打分函数直接使用例如 countdown 任务的数字与目标值、travel planning 的行程真值、pseudo_to_code 的测试用例都在其中。def process_docs(dataset): def _parse(doc): doc[metadata_parsed] json.loads(doc[metadata]) return doc return dataset.map(_parse)子任务 YAML 的构成每个子任务 YAML 通过include继承对应长度的默认配置并声明自身任务名、数据集子集名dataset_name、打分函数process_results与指标列表。以 countdown_0.5k.yaml 为例include: _default_yaml_0.5k task: longproc_countdown_0.5k dataset_name: countdown_0.5k process_results: !function metrics.process_results_countdown metric_list: - metric: score aggregation: mean higher_is_better: true - metric: accuracy aggregation: mean higher_is_better: true - metric: partial_accuracy aggregation: mean higher_is_better: true - metric: extraction_rate aggregation: mean higher_is_better: true大部分任务上报score / accuracy / partial_accuracy / extraction_rate四类指标HTML-to-TSV任务例外上报score / f1 / precision / recall / extraction_rate见 html_to_tsv_0.5k.yaml。四类通用指标的含义贯穿全文score该任务的主指标也是 Group 聚合时使用的指标accuracy严格正确率输出与标准答案完全匹配partial_accuracy部分正确率按行/按步的渐进式评分反映做到第几步才出错extraction_rate答案抽取率模型输出中是否包含可解析的答案块如Solution、Route等标签。六类任务的评测指标与源码解析所有打分逻辑集中在 lm_eval/tasks/longproc/metrics.py 中。各process_results_*函数接收单个样本docdict与results列表首个元素为模型生成文本返回指标名到标量值的映射。以下是逐类任务的解析。Countdown数字搜索与最终解校验模型需用给定数字、通过加减乘除组合出目标数输出必须包含最终解Solution标签且生成过程# Search Procedure段要与标准搜索过程逐行比对。打分逻辑process_results_countdown分为三层最终解校验先抽取Solution.../Solution内容调用_evaluate_countdown_final_solution校验——要求解恰好 3 行等式每行lhs rhs的算术结果成立且左右操作数必须来自当前可用数字池用过即移除、结果放回最后剩余数字等于目标值。通过则score accuracy partial_accuracy 1.0搜索过程比对若最终解不通过则截取# Search Procedure之后、Now we have found the target之前的内容与标准搜索过程逐行比对_evaluate_countdown_search_procedure返回第几步开始出错换算的partial_accuracyidx / len(gt_lines)抽取率pred_solution存在则extraction_rate 1.0否则为 0。注意该函数内部使用eval解析等式左端metrics.py中注明 trusted data且对搜索过程的比对相当严格Pick two numbers、|- Try等式、drop this branch分支标记都必须逐字匹配。Path Traversal路径输出的行级前缀比对模型需在图中找出连接两座城市的完整路径答案放在Route标签内。打分process_results_path_traversal步骤用_extract_with_tag抽取Route内容抽不到则四项指标全为 0与标准路径gt精确相等 →score accuracy partial_accuracy extraction_rate 1.0否则按行前缀比对从第一行开始逐行比较遇到第一个不匹配行即停止partial_accuracy (match_count 1) / len(gt_lines)即把出错那一步之前的行数计入extraction_rate 1.0。这种前缀逐步加分机制正是 LongProc 强调过程正确性的体现只要模型在路径开头走对若干步即便后半段出错也能获得部分分数。Theory-of-Mind Tracking信念列表的归一化比对模型需在物体放置类故事中跟踪各角色的位置信念输出形如- 角色 believes 位置的行。打分process_results_tom_tracking流程只保留预测与标准答案中以-开头的行抽取信念内容通过_normalize_tom做归一化转小写、去标点、去停用词_TOM_STOPWORDS_RE覆盖a/an/the/step/thinks/believes/is/are/of/location/know/belief等、压缩空白归一化后的信念列表与标准列表逐元素比对完全一致则accuracy 1.0否则从第一个不一致的信念位置计算partial_accuracy first_diff / len(gt_beliefs)列表长度不足时按最短匹配比例计算。与 Path Traversal 类似Tom Tracking 也采用顺序敏感的逐步评分且归一化规则对冠词/停用词做了容错避免因措辞差异误伤正确推理。HTML-to-TSV表格级精确率 / 召回率 / F1模型需从 HTML 页面中抽取信息输出为 TSV 表格通常包裹在tsv ... 代码块中。打分process_results_html_to_tsv是唯一使用 F1 的任务用正则tsv([\s\S]*)抽取 TSV 块抽取失败则score f1 precision recall extraction_rate 0_string_to_pd将 TSV 文本解析为 pandas DataFrame首行作表头行长度不足时补N/A每个单元格经_normalize_answer_html归一化小写、去标点、去冠词、去所有空白_compute_html_to_tsv_metrics计算行级精确率预测的每一行是否在真值表中存在与召回率真值的每一行是否在预测表中存在进而得 F1score直接取 F1extraction_rate依据解析是否出错m[error] is None判定。注意该指标需要pandas源码中明确提示缺失时需pip install pandas。行级集合匹配 单元格归一化使它对内容正确但顺序略有不同的表格输出相对宽容。Pseudocode-to-Code真实编译执行g模型需将逐行伪代码翻译为 C 代码这是 LongProc 中唯一涉及真实代码执行的任务也是unsafe_code: true的由来。打分process_results_pseudo_to_code流程用正则cpp([\s\S]*)抽取代码块兼容c写法将代码拼接到_SPOC_IMPORT_HEADER#include cstdio、vector、algorithm、using namespace std;等标准头之后得到完整 C 程序_evaluate_spoc_code在临时目录中调用g -stdc11 -O编译编译失败返回compilation error编译成功后用metadata[testcases]中的前 10 个测试用例逐一执行Popen管道喂入输入、3 秒超时比较程序输出与期望输出全部一致才判对任一步失败即score 0但extraction_rate 1.0代码块可抽取。运行此任务的环境必须具备gC11否则打分函数会记录g not found警告并判失败。临时目录与文件在打分结束后会被清理finally块保证评测过程相对隔离、不留垃圾文件。Travel Planning行程结构解析 搜索过程比对模型需根据总天数与航班约束制定欧洲多城市旅行计划最终行程放在Plan标签内。打分process_results_travel_planning包含两层行程正确性_parse_travel_response用正则解析输出中的Day N from A to B航班行与M-N停留区间行还原成(city, stay_days)序列随后_evaluate_travel_plan_solution将解析结果与metadata[ground_truth_cities]、metadata[ground_truth_durations]以**分隔的字符串逐项比对要求城市与停留天数全部一致才accuracy 1.0搜索过程比对行程不完美时截取Solving Procedure段与标准过程比对经_normalize_travel_line小写、去标点、去a/an/the、压缩空白归一化后逐行检查标准行是否包含于预测行得到partial_accuracy idx / len(gt_lines)。extraction_rate由是否成功抽取Plan块决定score直接取行程正确性accuracy。在 lm-evaluation-harness 中运行 LongProcLongProc 已通过 lm-evaluation-harness 的任务自动发现机制注册目录级任务文件被 TaskManager 的索引机制收集见 lm_eval/tasks/manager.py 与 lm_eval/tasks/init.py。安装依赖后即可通过lm_evalCLI 运行。运行单个子任务例如 0.5k 的 Countdownlm_eval --model hf \ --model_args pretrainedyour/model \ --tasks longproc_countdown_0.5k \ --device cuda运行整个 LongProc 基准16 个任务一次性评测并聚合lm_eval --model hf \ --model_args pretrainedyour/model \ --tasks longproc \ --device cuda运行某一任务类型如 3 个长度的 Path Traversallm_eval --model hf \ --model_args pretrainedyour/model \ --tasks longproc_path_traversal \ --device cuda运行要点数据源为 Hugging Face 数据集PrincetonPli/LongProc首次运行会自动下载评测使用test划分默认num_fewshot: 0零样本这是由任务配置写死的解码参数已在配置中固定为贪婪解码temperature: 0, do_sample: false无需也无法在命令行覆盖8k 任务的max_gen_toks高达 9216请为模型预留足够长的上下文窗口与输出预算运行longproc_pseudo_to_code_*前请确认评测机器装有gC11与pandasHTML-to-TSV 任务需要否则对应任务会因环境缺失而计 0 分或告警。小结LongProc 在 lm-evaluation-harness 中的实现完整继承了原基准的评测语义以generate_until自由生成为主6 类任务分别用严格匹配 / 行级前缀 / 归一化列表 / 表格 F1 / 真实编译执行 / 行程结构解析等差异化指标衡量长上下文模型在 500 至 8K token 长输出场景下的过程遵循能力。score / accuracy / partial_accuracy / extraction_rate四件套构成了统一的评测语言partial_accuracy尤其值得关注它能量化模型在长过程中第几步开始崩溃这正是长上下文评测区别于短任务评测的关键维度。通过 lm_eval/tasks/longproc/README.md 可获取基准的完整引用信息与任务清单lm_eval/tasks/longproc/metrics.py 与 lm_eval/tasks/longproc/utils.py 承载全部打分与预处理实现lm_eval/tasks/longproc/ 目录下的各 YAML 文件则是可直接复用的任务定义。若你的模型宣称具备长上下文能力不妨先用--tasks longproc跑一轮观察它在不同长度下的partial_accuracy曲线——它能直观暴露模型读得进长文但写不出长过程的短板。【免费下载链接】lm-evaluation-harnessA framework for few-shot evaluation of language models.项目地址: https://gitcode.com/GitHub_Trending/lm/lm-evaluation-harness创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考