lm-evaluation-harness 中的 IFEval 任务基于可验证指令的指令遵循评估完整指南【免费下载链接】lm-evaluation-harnessA framework for few-shot evaluation of language models.项目地址: https://gitcode.com/GitHub_Trending/lm/lm-evaluation-harness导读IFEvalInstruction-Following Evaluation是 Google Research 提出的一个可复现、可自动评估的指令遵循基准其核心思想是用 超过 400 字、至少提到 AI 关键词 3 次 这类可被程序化验证的指令来客观衡量大语言模型的指令遵循能力从而避开人工评测的昂贵与 LLM 自评的偏差问题。本文以 lm-evaluation-harness 仓库中 IFEval 任务的 README.md 为骨架结合任务配置、指令注册表、检查器实现与多语言扩展等源码完整讲解 IFEval 的评测原理、25 类可验证指令的判定机制、strict/loose 两种评分口径、运行方法以及加泰罗尼亚语/西班牙语多语言变体。读完本文你将能够理解并独立运行ifeval任务并能够读懂其输出指标的含义。IFEval 基准背景论文与出发点IFEval 出自论文Instruction-Following Evaluation for Large Language ModelsarXiv:2311.07911作者 Jeffrey Zhou、Tianjian Lu 等其提出的动机非常直接人类评测昂贵、缓慢且难以客观复现基于 LLM 的自动评测可能存在偏差或受限于评判模型自身的能力因此需要一种简单、易于复现的评估方式。解决方案是聚焦于一组可验证指令verifiable instructions例如 写超过 400 字、至少 3 次提到关键词 AI。这类指令是否被遵循可以通过规则化的程序如字数统计、关键词计数客观判定不依赖主观打分。原论文识别出25 类可验证指令并构造了约500 条 prompt每条 prompt 包含一条或多条可验证指令。上游参考实现位于 Google Research 的 instruction_following_eval 目录本仓库的lm_eval/tasks/ifeval目录即是对该实现的移植与适配。引用信息任务 README 中给出了标准的 BibTeX 引用条目在论文或评测报告中引用 IFEval 时可直接使用article{zhou2023instructionfollowing, title{Instruction-Following Evaluation for Large Language Models}, author{Jeffrey Zhou and Tianjian Lu and Swaroop Mishra and Siddhartha Brahma and Sujoy Basu and Yi Luan and Denny Zhou and Le Hou}, journal{arXiv preprint arXiv:2311.07911}, year{2023}, }任务在仓库中的组织方式ifeval目前不属于任何 task groupREADME 中标注 Not part of a group yet注册的任务名只有一个ifeval。其相关文件全部位于 lm_eval/tasks/ifeval/ 目录下文件作用ifeval.yaml任务声明文件数据源、生成参数、指标、聚合函数utils.py结果处理strict/loose 两种指令遵循判定与四个指标的计算instructions.py25 类指令的检查器类实现check_following 判定逻辑instructions_registry.py指令 ID 到检查器类的注册表以及指令冲突关系表instructions_util.py工具库句子切分、语言代码表、nltk 资源下载等multilingual/加泰罗尼亚语ca、西班牙语es多语言变体任务配置解析ifeval.yamlifeval.yaml 是任务的声明式配置逐项拆解如下task: ifeval dataset_path: google/IFEval dataset_name: null output_type: generate_until test_split: train num_fewshot: 0 doc_to_text: prompt doc_to_target: 0 generation_kwargs: until: [] do_sample: false temperature: 0.0 max_gen_toks: 1280 process_results: !function utils.process_results metric_list: - metric: prompt_level_strict_acc aggregation: mean higher_is_better: true - metric: inst_level_strict_acc aggregation: !function utils.agg_inst_level_acc higher_is_better: true - metric: prompt_level_loose_acc aggregation: mean higher_is_better: true - metric: inst_level_loose_acc aggregation: !function utils.agg_inst_level_acc higher_is_better: true metadata: version: 4.0关键字段说明dataset_path / dataset_name数据源为 Hugging Face 上的google/IFEval数据集不指定子数据集名称null。output_type: generate_until任务属于文本生成型评测生成直到满足停止条件而非 loglikelihood 型的多项选择。这决定了任务由生成式模型接口如 HFT 类模型的generate_until执行。test_split: train官方 IFEval 数据将评测集放在train分割中这里直接指定使用train分割作为评测集。num_fewshot: 0零样本评测。这与 IFEval 的定位一致——直接考察模型理解并执行单条指令的能力不使用 few-shot 示范。doc_to_text: prompt将数据行中的prompt字段作为输入文本doc_to_target: 0表示无标准答案参与计算由程序化检查器代替。generation_kwargs生成参数中until: []表示不设置停止词do_sample: false与temperature: 0.0组合为贪心解码保证评测可复现max_gen_toks: 1280设置了较长的最大生成长度以适应字数类指令如 超过 400 字所需的较长输出。process_results: !function utils.process_results评测结果交由 utils.py 中的process_results函数处理——这是整个自动判分的入口。metric_list定义四个指标详见下文四个核心指标一节其中prompt_level_*使用内置mean聚合inst_level_*使用自定义函数utils.agg_inst_level_acc聚合。metadata.version: 4.0任务版本号用于缓存键与结果追踪。25 类可验证指令注册表与分类instructions_registry.py 定义了指令 ID 到检查器类的映射INSTRUCTION_DICT。指令 ID 采用类别前缀 指令名的命名方式共 9 个类别前缀keywords:、language:、length_constraints:、detectable_content:、detectable_format:、combination:、startend:、change_case:、punctuation:。注册表中的已启用指令如下类别前缀指令 ID检查器类判定要点keywords:existenceKeywordChecker回答中必须包含指定关键词keywords:frequencyKeywordFrequencyChecker指定关键词出现次数达到阈值keywords:forbidden_wordsForbiddenWords不得出现禁用词列表keywords:letter_frequencyLetterFrequencyChecker指定字母出现次数达到阈值language:response_languageResponseLanguageChecker整个回答必须使用指定语言length_constraints:number_sentencesNumberOfSentences句子数满足 少于/至少 阈值length_constraints:number_paragraphsParagraphChecker段落数满足阈值length_constraints:number_wordsNumberOfWords词数满足阈值length_constraints:nth_paragraph_first_wordParagraphFirstWordCheck第 N 段首词为指定词detectable_content:number_placeholdersPlaceholderChecker回答包含指定数量的占位符如 [TBD]detectable_content:postscriptPostscriptChecker回答以 P.S./P.P.S 开头detectable_format:number_bullet_listsBulletListChecker回答包含指定数量的无序列表detectable_format:constrained_responseConstrainedResponseChecker回答以给定选项如 My answer is yes.开头detectable_format:number_highlighted_sectionsHighlightSectionChecker回答包含指定数量的加粗/斜体高亮段落detectable_format:multiple_sectionsSectionChecker回答包含指定数量的 Section 分节detectable_format:json_formatJsonFormat整个回答必须是合法 JSONdetectable_format:titleTitleChecker回答以 Title: 开头combination:two_responsesTwoResponsesChecker先拒绝再给出完整回答combination:repeat_promptRepeatPromptThenAnswer先原样复述 prompt 再作答startend:end_checkerEndChecker以指定结束语结尾startend:quotationQuotationChecker以引号包裹的引文结尾change_case:capital_word_frequencyCapitalWordFrequencyChecker全大写单词数量达到阈值change_case:english_capitalCapitalLettersEnglishChecker回答全部为大写英文change_case:english_lowercaseLowercaseLettersEnglishChecker回答全部为小写英文punctuation:no_commaCommaChecker整个回答不出现逗号注意注册表中有若干注释掉的 TODO 项如keywords:key_sentences、detectable_content:rephrase_paragraph、detectable_format:rephrase、multi-turn:constrained_start对应类虽然定义在 instructions.py 中如ConstrainedStartChecker、RephraseChecker、KeySentenceChecker、RephraseParagraph但未注册、未被任何数据集行引用属于从上游 Google 代码移植时保留的 dead code文件头部的文档字符串对此有明确说明。检查器的统一接口所有检查器都继承自Instruction基类instructions.py需要实现四个方法build_description(**kwargs)根据指令参数如阈值、语言构造人类可读的指令描述文本get_instruction_args()返回已构造的指令参数get_instruction_args_keys()返回参数键名列表check_following(value)核心判定方法输入模型回答字符串返回布尔值表示该指令是否被遵循。以 NumberOfSentences 为例它接受num_sentences与relationless than/at least二选一定义于_COMPARISON_RELATION两个参数check_following内部调用instructions_util.count_sentences统计句子数后与阈值比较当参数缺省时会用random.randint(1, 20)随机生成阈值。也就是说同一指令 ID 在不同样本上会带有不同的参数化约束这正是 IFEval 每个 prompt 包含一条或多条可验证指令的实现方式——指令的具体形态由数据行kwargs字段决定。指令冲突关系表instructions_registry.py 还维护了INSTRUCTION_CONFLICTS冲突表描述哪些指令之间不能同时出现在同一条 prompt 中例如json_format与大多数指令冲突two_responses与forbidden_words等冲突。conflict_make()函数将冲突关系对称化并保证每条指令与自身冲突用于在构造 prompt 时避免组合出不可能同时满足的指令对。strict 与 loose两种判定口径的源码剖析utils.py 是判分的核心。它以InputExamplekey、instruction_id_list、prompt、kwargs为输入对模型生成结果分别跑strict与loose两套判定。strict 判定test_instruction_following_strictutils.py逐条执行 prompt 中的每个指令检查器只对原始回答原文调用check_following全部通过all(is_following_list)才认为整条 prompt 被遵循。因此 strict 是字面、严格口径任何格式瑕疵如多余的星号、换行都可能导致判定失败。loose 判定test_instruction_following_looseutils.py是 strict 的上界估计。它先构造 8 个回答变体原始回答去掉所有*星号兼容 Markdown 加粗/斜体干扰去掉第一行去掉最后一行同时去掉首尾行 6-8. 上述三个去行变体再去掉星号。然后对每个指令检查器只要这 8 个变体中任一通过check_following即判定该指令被遵循。这模拟了宽松容忍的人工判读忽略 Markdown 语法字符、忽略可能出现的首行客套话如 Sure, heres your response:)从而估计模型遵循指令能力的上界。README 中对两套口径的定义是strict 直接检验回答loose 则检验去除首尾行与星号后的变体集合。四个核心指标与聚合逻辑process_resultsutils.py对每条样本同时计算 strict 和 loose 的结果返回四个指标值指标含义单样本取值聚合方式prompt_level_strict_acc严格口径下prompt 内全部指令都被遵循0/1mean样本均值inst_level_strict_acc严格口径下单条指令被遵循的比例布尔列表agg_inst_level_accprompt_level_loose_acc宽松口径下prompt 内全部指令都被遵循0/1meaninst_level_loose_acc宽松口径下单条指令被遵循的比例布尔列表agg_inst_level_accprompt-levelprompt 级以整条 prompt 是否被完全遵循为单位OutputExample.follow_all_instructions给出逐样本 0/1最终取均值反映模型完全照做的比例。inst-level指令级以单条指令是否被遵循为单位OutputExample.follow_instruction_list给出逐条布尔值。由于每条 prompt 包含多条指令样本返回的是列表不能直接取均值因此使用自定义聚合函数agg_inst_level_accutils.py先将所有列表展平再计算整体正确率。higher_is_better: true表明四个指标均为越大越好。理解这两组口径的差异是正确解读 IFEval 结果的关键prompt_level_*更严格要求指令组合整体成功inst_level_*更细粒度允许定位是哪些指令失败。依赖与运行方式环境依赖IFEval 任务在运行时需要额外依赖nltkinstructions_util.py顶部的download_nltk_resources()会校验 nltk 版本并自动下载punkt_tab分词资源。需要注意仓库明确要求nltk 3.9.1因为旧版本 nltk 的 punkt 下载存在远程代码执行漏洞对应 issue #2210版本不足会直接断言报错。langdetectlanguage:response_language、change_case:english_capital、change_case:english_lowercase等指令的判定依赖langdetect.detect()进行语言检测。检测失败LangDetectException时检查器按指令被遵循处理instructions.py这是一种宽容的降级策略。immutabledictLANGUAGE_CODES语言代码表使用不可变字典。LANGUAGE_CODESinstructions_util.py内置了 30 种语言en、es、pt、ar、hi、fr、ru、de、ja、it、bn、uk、th、ur、ta、te、bg、ko、pl、he、fa、vi、ne、sw、kn、mr、gu、pa、ml、fi语言类指令可指定其中任意一种作为目标语言。运行命令在仓库根目录下安装依赖如pip install -e .后使用 lm-evaluation-harness 的标准 CLI 运行lm_eval --model hf --model_args pretrainedmeta-llama/Llama-2-7b-hf --tasks ifeval --device cuda其中--tasks ifeval即指定本任务也可通过--limit参数限制样本数做快速验证。由于generate_until型任务与贪心解码temperature 0.0组合评测结果具有良好可复现性。结果解读示例运行结束后输出中会出现类似如下的指标表| Tasks |Version|Filter|n-shot| Metric | |Value | |Stderr| |-----------|-------|------|-----:|-----------|---|-----:|---|-----:| |ifeval | 4.0|none | 0|inst_level_loose_acc|↑| 0.523|±|0.011| | | | | |inst_level_strict_acc|↑| 0.422|±|0.011| | | | | |prompt_level_loose_acc|↑| 0.228|±|0.011| | | | | |prompt_level_strict_acc|↑| 0.111|±|0.008|以上数值仅为展示指标结构而虚构实际结果取决于被测模型。可以看到 prompt-level 普遍低于 inst-level这正是要求整条 prompt 的全部指令同时成功难度更大的体现。多语言扩展加泰罗尼亚语与西班牙语除英文原版外仓库还提供了 IFEval 的多语言变体位于 lm_eval/tasks/ifeval/multilingual/ 目录ifeval_ca.yaml加泰罗尼亚语版本数据源projecte-aina/IFEval_catest_split: test任务名ifeval_caifeval_es.yaml西班牙语版本任务名ifeval_es。两者的指标定义与英文版完全一致同样四个指标、同样的聚合函数生成参数也相同贪心解码、max_gen_toks 1280metadata 版本号为 1.0。多语言注册表 multilingual/instructions_registry.py 在英文 9 类前缀基础上为西语和加泰罗尼亚语各增加两类语言特有前缀letters:与西语/加泰语字母相关的检查器special_character:特殊字符检查器如enieñ、tildes重音符、dieresis分音符。注册表将西语字典与加泰语字典统一合并进INSTRUCTION_DICT并通过es:与ca:前缀区分同名指令例如ca:change_case:catalan_capital与es:change_case:spanish_capital。语言相关检查器同样使用langdetect检测回答语言如加泰语判定要求langdetect.detect(value) ca因此运行时同样需要langdetect依赖。从源码结构看 IFEval 的评测流程综合以上源码一条样本在 lm-evaluation-harness 中的完整评测链路可以概括为ifeval.yaml 声明数据源google/IFEval与generate_until输出类型框架按doc_to_text: prompt构造输入以贪心解码生成回答max_gen_toks: 1280每份(doc, results)进入 utils.py 的process_results通过InputExample携带instruction_id_list与kwargstest_instruction_following_strict与test_instruction_following_loose依据 instructions_registry.py 的INSTRUCTION_DICT查表实例化检查器对回答执行规则判定四个指标值返回给框架prompt_level_*用mean聚合、inst_level_*用agg_inst_level_acc展平聚合最终输出到结果表。这条链路清晰体现了 IFEval 的核心设计哲学把指令遵循转化为可编程验证的规则集合从而在零样本、零人工、可复现的前提下得到客观分数。小结IFEval 是本仓库中少数完全依赖规则检查器而非参考答案或评测 LLM 的任务其 strict/loose 双口径设计、25 类可验证指令、指令级与 prompt 级四级指标以及多语言扩展使其成为评估模型指令遵循能力的标准化工具。若需进一步了解任务配置规范或在本仓库添加类似任务可参考 docs/task_guide.md 与 docs/config_files.md如需查看本任务与其他生成型任务的实现差异可对照 lm_eval/tasks/gsm8k/gsm8k.yaml 等同类generate_until配置。【免费下载链接】lm-evaluation-harnessA framework for few-shot evaluation of language models.项目地址: https://gitcode.com/GitHub_Trending/lm/lm-evaluation-harness创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 lm-evaluation-harness 中的 IFEval 任务：基于可验证指令的指令遵循评估完整指南
lm-evaluation-harness 中的 IFEval 任务基于可验证指令的指令遵循评估完整指南【免费下载链接】lm-evaluation-harnessA framework for few-shot evaluation of language models.项目地址: https://gitcode.com/GitHub_Trending/lm/lm-evaluation-harness导读IFEvalInstruction-Following Evaluation是 Google Research 提出的一个可复现、可自动评估的指令遵循基准其核心思想是用 超过 400 字、至少提到 AI 关键词 3 次 这类可被程序化验证的指令来客观衡量大语言模型的指令遵循能力从而避开人工评测的昂贵与 LLM 自评的偏差问题。本文以 lm-evaluation-harness 仓库中 IFEval 任务的 README.md 为骨架结合任务配置、指令注册表、检查器实现与多语言扩展等源码完整讲解 IFEval 的评测原理、25 类可验证指令的判定机制、strict/loose 两种评分口径、运行方法以及加泰罗尼亚语/西班牙语多语言变体。读完本文你将能够理解并独立运行ifeval任务并能够读懂其输出指标的含义。IFEval 基准背景论文与出发点IFEval 出自论文Instruction-Following Evaluation for Large Language ModelsarXiv:2311.07911作者 Jeffrey Zhou、Tianjian Lu 等其提出的动机非常直接人类评测昂贵、缓慢且难以客观复现基于 LLM 的自动评测可能存在偏差或受限于评判模型自身的能力因此需要一种简单、易于复现的评估方式。解决方案是聚焦于一组可验证指令verifiable instructions例如 写超过 400 字、至少 3 次提到关键词 AI。这类指令是否被遵循可以通过规则化的程序如字数统计、关键词计数客观判定不依赖主观打分。原论文识别出25 类可验证指令并构造了约500 条 prompt每条 prompt 包含一条或多条可验证指令。上游参考实现位于 Google Research 的 instruction_following_eval 目录本仓库的lm_eval/tasks/ifeval目录即是对该实现的移植与适配。引用信息任务 README 中给出了标准的 BibTeX 引用条目在论文或评测报告中引用 IFEval 时可直接使用article{zhou2023instructionfollowing, title{Instruction-Following Evaluation for Large Language Models}, author{Jeffrey Zhou and Tianjian Lu and Swaroop Mishra and Siddhartha Brahma and Sujoy Basu and Yi Luan and Denny Zhou and Le Hou}, journal{arXiv preprint arXiv:2311.07911}, year{2023}, }任务在仓库中的组织方式ifeval目前不属于任何 task groupREADME 中标注 Not part of a group yet注册的任务名只有一个ifeval。其相关文件全部位于 lm_eval/tasks/ifeval/ 目录下文件作用ifeval.yaml任务声明文件数据源、生成参数、指标、聚合函数utils.py结果处理strict/loose 两种指令遵循判定与四个指标的计算instructions.py25 类指令的检查器类实现check_following 判定逻辑instructions_registry.py指令 ID 到检查器类的注册表以及指令冲突关系表instructions_util.py工具库句子切分、语言代码表、nltk 资源下载等multilingual/加泰罗尼亚语ca、西班牙语es多语言变体任务配置解析ifeval.yamlifeval.yaml 是任务的声明式配置逐项拆解如下task: ifeval dataset_path: google/IFEval dataset_name: null output_type: generate_until test_split: train num_fewshot: 0 doc_to_text: prompt doc_to_target: 0 generation_kwargs: until: [] do_sample: false temperature: 0.0 max_gen_toks: 1280 process_results: !function utils.process_results metric_list: - metric: prompt_level_strict_acc aggregation: mean higher_is_better: true - metric: inst_level_strict_acc aggregation: !function utils.agg_inst_level_acc higher_is_better: true - metric: prompt_level_loose_acc aggregation: mean higher_is_better: true - metric: inst_level_loose_acc aggregation: !function utils.agg_inst_level_acc higher_is_better: true metadata: version: 4.0关键字段说明dataset_path / dataset_name数据源为 Hugging Face 上的google/IFEval数据集不指定子数据集名称null。output_type: generate_until任务属于文本生成型评测生成直到满足停止条件而非 loglikelihood 型的多项选择。这决定了任务由生成式模型接口如 HFT 类模型的generate_until执行。test_split: train官方 IFEval 数据将评测集放在train分割中这里直接指定使用train分割作为评测集。num_fewshot: 0零样本评测。这与 IFEval 的定位一致——直接考察模型理解并执行单条指令的能力不使用 few-shot 示范。doc_to_text: prompt将数据行中的prompt字段作为输入文本doc_to_target: 0表示无标准答案参与计算由程序化检查器代替。generation_kwargs生成参数中until: []表示不设置停止词do_sample: false与temperature: 0.0组合为贪心解码保证评测可复现max_gen_toks: 1280设置了较长的最大生成长度以适应字数类指令如 超过 400 字所需的较长输出。process_results: !function utils.process_results评测结果交由 utils.py 中的process_results函数处理——这是整个自动判分的入口。metric_list定义四个指标详见下文四个核心指标一节其中prompt_level_*使用内置mean聚合inst_level_*使用自定义函数utils.agg_inst_level_acc聚合。metadata.version: 4.0任务版本号用于缓存键与结果追踪。25 类可验证指令注册表与分类instructions_registry.py 定义了指令 ID 到检查器类的映射INSTRUCTION_DICT。指令 ID 采用类别前缀 指令名的命名方式共 9 个类别前缀keywords:、language:、length_constraints:、detectable_content:、detectable_format:、combination:、startend:、change_case:、punctuation:。注册表中的已启用指令如下类别前缀指令 ID检查器类判定要点keywords:existenceKeywordChecker回答中必须包含指定关键词keywords:frequencyKeywordFrequencyChecker指定关键词出现次数达到阈值keywords:forbidden_wordsForbiddenWords不得出现禁用词列表keywords:letter_frequencyLetterFrequencyChecker指定字母出现次数达到阈值language:response_languageResponseLanguageChecker整个回答必须使用指定语言length_constraints:number_sentencesNumberOfSentences句子数满足 少于/至少 阈值length_constraints:number_paragraphsParagraphChecker段落数满足阈值length_constraints:number_wordsNumberOfWords词数满足阈值length_constraints:nth_paragraph_first_wordParagraphFirstWordCheck第 N 段首词为指定词detectable_content:number_placeholdersPlaceholderChecker回答包含指定数量的占位符如 [TBD]detectable_content:postscriptPostscriptChecker回答以 P.S./P.P.S 开头detectable_format:number_bullet_listsBulletListChecker回答包含指定数量的无序列表detectable_format:constrained_responseConstrainedResponseChecker回答以给定选项如 My answer is yes.开头detectable_format:number_highlighted_sectionsHighlightSectionChecker回答包含指定数量的加粗/斜体高亮段落detectable_format:multiple_sectionsSectionChecker回答包含指定数量的 Section 分节detectable_format:json_formatJsonFormat整个回答必须是合法 JSONdetectable_format:titleTitleChecker回答以 Title: 开头combination:two_responsesTwoResponsesChecker先拒绝再给出完整回答combination:repeat_promptRepeatPromptThenAnswer先原样复述 prompt 再作答startend:end_checkerEndChecker以指定结束语结尾startend:quotationQuotationChecker以引号包裹的引文结尾change_case:capital_word_frequencyCapitalWordFrequencyChecker全大写单词数量达到阈值change_case:english_capitalCapitalLettersEnglishChecker回答全部为大写英文change_case:english_lowercaseLowercaseLettersEnglishChecker回答全部为小写英文punctuation:no_commaCommaChecker整个回答不出现逗号注意注册表中有若干注释掉的 TODO 项如keywords:key_sentences、detectable_content:rephrase_paragraph、detectable_format:rephrase、multi-turn:constrained_start对应类虽然定义在 instructions.py 中如ConstrainedStartChecker、RephraseChecker、KeySentenceChecker、RephraseParagraph但未注册、未被任何数据集行引用属于从上游 Google 代码移植时保留的 dead code文件头部的文档字符串对此有明确说明。检查器的统一接口所有检查器都继承自Instruction基类instructions.py需要实现四个方法build_description(**kwargs)根据指令参数如阈值、语言构造人类可读的指令描述文本get_instruction_args()返回已构造的指令参数get_instruction_args_keys()返回参数键名列表check_following(value)核心判定方法输入模型回答字符串返回布尔值表示该指令是否被遵循。以 NumberOfSentences 为例它接受num_sentences与relationless than/at least二选一定义于_COMPARISON_RELATION两个参数check_following内部调用instructions_util.count_sentences统计句子数后与阈值比较当参数缺省时会用random.randint(1, 20)随机生成阈值。也就是说同一指令 ID 在不同样本上会带有不同的参数化约束这正是 IFEval 每个 prompt 包含一条或多条可验证指令的实现方式——指令的具体形态由数据行kwargs字段决定。指令冲突关系表instructions_registry.py 还维护了INSTRUCTION_CONFLICTS冲突表描述哪些指令之间不能同时出现在同一条 prompt 中例如json_format与大多数指令冲突two_responses与forbidden_words等冲突。conflict_make()函数将冲突关系对称化并保证每条指令与自身冲突用于在构造 prompt 时避免组合出不可能同时满足的指令对。strict 与 loose两种判定口径的源码剖析utils.py 是判分的核心。它以InputExamplekey、instruction_id_list、prompt、kwargs为输入对模型生成结果分别跑strict与loose两套判定。strict 判定test_instruction_following_strictutils.py逐条执行 prompt 中的每个指令检查器只对原始回答原文调用check_following全部通过all(is_following_list)才认为整条 prompt 被遵循。因此 strict 是字面、严格口径任何格式瑕疵如多余的星号、换行都可能导致判定失败。loose 判定test_instruction_following_looseutils.py是 strict 的上界估计。它先构造 8 个回答变体原始回答去掉所有*星号兼容 Markdown 加粗/斜体干扰去掉第一行去掉最后一行同时去掉首尾行 6-8. 上述三个去行变体再去掉星号。然后对每个指令检查器只要这 8 个变体中任一通过check_following即判定该指令被遵循。这模拟了宽松容忍的人工判读忽略 Markdown 语法字符、忽略可能出现的首行客套话如 Sure, heres your response:)从而估计模型遵循指令能力的上界。README 中对两套口径的定义是strict 直接检验回答loose 则检验去除首尾行与星号后的变体集合。四个核心指标与聚合逻辑process_resultsutils.py对每条样本同时计算 strict 和 loose 的结果返回四个指标值指标含义单样本取值聚合方式prompt_level_strict_acc严格口径下prompt 内全部指令都被遵循0/1mean样本均值inst_level_strict_acc严格口径下单条指令被遵循的比例布尔列表agg_inst_level_accprompt_level_loose_acc宽松口径下prompt 内全部指令都被遵循0/1meaninst_level_loose_acc宽松口径下单条指令被遵循的比例布尔列表agg_inst_level_accprompt-levelprompt 级以整条 prompt 是否被完全遵循为单位OutputExample.follow_all_instructions给出逐样本 0/1最终取均值反映模型完全照做的比例。inst-level指令级以单条指令是否被遵循为单位OutputExample.follow_instruction_list给出逐条布尔值。由于每条 prompt 包含多条指令样本返回的是列表不能直接取均值因此使用自定义聚合函数agg_inst_level_accutils.py先将所有列表展平再计算整体正确率。higher_is_better: true表明四个指标均为越大越好。理解这两组口径的差异是正确解读 IFEval 结果的关键prompt_level_*更严格要求指令组合整体成功inst_level_*更细粒度允许定位是哪些指令失败。依赖与运行方式环境依赖IFEval 任务在运行时需要额外依赖nltkinstructions_util.py顶部的download_nltk_resources()会校验 nltk 版本并自动下载punkt_tab分词资源。需要注意仓库明确要求nltk 3.9.1因为旧版本 nltk 的 punkt 下载存在远程代码执行漏洞对应 issue #2210版本不足会直接断言报错。langdetectlanguage:response_language、change_case:english_capital、change_case:english_lowercase等指令的判定依赖langdetect.detect()进行语言检测。检测失败LangDetectException时检查器按指令被遵循处理instructions.py这是一种宽容的降级策略。immutabledictLANGUAGE_CODES语言代码表使用不可变字典。LANGUAGE_CODESinstructions_util.py内置了 30 种语言en、es、pt、ar、hi、fr、ru、de、ja、it、bn、uk、th、ur、ta、te、bg、ko、pl、he、fa、vi、ne、sw、kn、mr、gu、pa、ml、fi语言类指令可指定其中任意一种作为目标语言。运行命令在仓库根目录下安装依赖如pip install -e .后使用 lm-evaluation-harness 的标准 CLI 运行lm_eval --model hf --model_args pretrainedmeta-llama/Llama-2-7b-hf --tasks ifeval --device cuda其中--tasks ifeval即指定本任务也可通过--limit参数限制样本数做快速验证。由于generate_until型任务与贪心解码temperature 0.0组合评测结果具有良好可复现性。结果解读示例运行结束后输出中会出现类似如下的指标表| Tasks |Version|Filter|n-shot| Metric | |Value | |Stderr| |-----------|-------|------|-----:|-----------|---|-----:|---|-----:| |ifeval | 4.0|none | 0|inst_level_loose_acc|↑| 0.523|±|0.011| | | | | |inst_level_strict_acc|↑| 0.422|±|0.011| | | | | |prompt_level_loose_acc|↑| 0.228|±|0.011| | | | | |prompt_level_strict_acc|↑| 0.111|±|0.008|以上数值仅为展示指标结构而虚构实际结果取决于被测模型。可以看到 prompt-level 普遍低于 inst-level这正是要求整条 prompt 的全部指令同时成功难度更大的体现。多语言扩展加泰罗尼亚语与西班牙语除英文原版外仓库还提供了 IFEval 的多语言变体位于 lm_eval/tasks/ifeval/multilingual/ 目录ifeval_ca.yaml加泰罗尼亚语版本数据源projecte-aina/IFEval_catest_split: test任务名ifeval_caifeval_es.yaml西班牙语版本任务名ifeval_es。两者的指标定义与英文版完全一致同样四个指标、同样的聚合函数生成参数也相同贪心解码、max_gen_toks 1280metadata 版本号为 1.0。多语言注册表 multilingual/instructions_registry.py 在英文 9 类前缀基础上为西语和加泰罗尼亚语各增加两类语言特有前缀letters:与西语/加泰语字母相关的检查器special_character:特殊字符检查器如enieñ、tildes重音符、dieresis分音符。注册表将西语字典与加泰语字典统一合并进INSTRUCTION_DICT并通过es:与ca:前缀区分同名指令例如ca:change_case:catalan_capital与es:change_case:spanish_capital。语言相关检查器同样使用langdetect检测回答语言如加泰语判定要求langdetect.detect(value) ca因此运行时同样需要langdetect依赖。从源码结构看 IFEval 的评测流程综合以上源码一条样本在 lm-evaluation-harness 中的完整评测链路可以概括为ifeval.yaml 声明数据源google/IFEval与generate_until输出类型框架按doc_to_text: prompt构造输入以贪心解码生成回答max_gen_toks: 1280每份(doc, results)进入 utils.py 的process_results通过InputExample携带instruction_id_list与kwargstest_instruction_following_strict与test_instruction_following_loose依据 instructions_registry.py 的INSTRUCTION_DICT查表实例化检查器对回答执行规则判定四个指标值返回给框架prompt_level_*用mean聚合、inst_level_*用agg_inst_level_acc展平聚合最终输出到结果表。这条链路清晰体现了 IFEval 的核心设计哲学把指令遵循转化为可编程验证的规则集合从而在零样本、零人工、可复现的前提下得到客观分数。小结IFEval 是本仓库中少数完全依赖规则检查器而非参考答案或评测 LLM 的任务其 strict/loose 双口径设计、25 类可验证指令、指令级与 prompt 级四级指标以及多语言扩展使其成为评估模型指令遵循能力的标准化工具。若需进一步了解任务配置规范或在本仓库添加类似任务可参考 docs/task_guide.md 与 docs/config_files.md如需查看本任务与其他生成型任务的实现差异可对照 lm_eval/tasks/gsm8k/gsm8k.yaml 等同类generate_until配置。【免费下载链接】lm-evaluation-harnessA framework for few-shot evaluation of language models.项目地址: https://gitcode.com/GitHub_Trending/lm/lm-evaluation-harness创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考