12. 指令遵循（Instruction Following）怎么评测？IFEval 等评测集解决了什么问题？

简单回答

指令遵循评测的目标是衡量模型 严格按用户要求执行 的能力——不是答得"对不对"，而是答得"符不符合要求"。比如"用 100 字回答"、"输出 JSON 格式"、"不要使用 emoji"、"用 5 个 bullet point"。这类要求的特点是 机器可验证——能用代码精确检查满足与否，不需要 LLM judge 或人类标注。Google 的 IFEval（Instruction-Following Eval）是这条路线的代表，定义了 25 类 verifiable instructions 并用代码自动验证。其他工作如 FollowBench、ComplexBench 在不同维度扩展。指令遵循能力是 production 模型最需要的能力之一——用户要 JSON 你给散文，应用就崩了。

详细解释

为什么指令遵循需要单独评测

模型的能力可以分两层：知识/推理能力 和 指令遵循能力。前者解决"会不会"，后者解决"听不听话"。

主流 benchmark（MMLU、GSM8K、HumanEval）测的是知识和推理。用户场景里这远远不够——用户问"用一句话总结这篇文章"，模型给了三段长篇大论，知识和推理都对但用户体验崩了。

指令遵循的具体维度有：

• 格式约束：JSON、Markdown、表格、特定模板
• 长度约束：最多 100 字、至少 5 段、恰好 7 个要点
• 风格约束：正式语气、面向小学生、用第二人称
• 内容约束：必须包含某些关键词、不能提某些话题、不能用 emoji
• 结构约束：开头/结尾必须是某句话、按某个顺序排列

这些约束理论上模型都"能"做到（语言能力够），但实际中模型经常违反。Production 应用里这种违反直接破坏下游解析或用户体验。

IFEval 的设计哲学

Google 2023 年发布的 IFEval 选了一条特别的路：只评测能用代码精确验证的指令。

原始论文定义了 25 类 verifiable instructions，每一类都能写一段几十行 Python 代码精确判断模型输出是否满足。例如：

• length_constraints:number_words：输出必须是 N 个单词。验证：split 后计数。
• format:json：输出必须是合法 JSON。验证：尝试 json.loads。
• keywords:existence：必须包含某些关键词。验证：substring match。
• keywords:forbidden_words：不能包含某些词。验证：substring 反向检查。
• startend:end_checker：必须以某句结尾。验证：endswith。
• change_case:capital_word_frequency：必须有恰好 N 个全大写词。验证：正则计数。

每个评测样本是一个 prompt + 一组 instruction（可以多个组合）：

prompt: "Write a summary of the article. Your response must be exactly 100 words. Do not use any emojis."
instructions:
  - length_constraints:number_words {num_words: 100}
  - keywords:forbidden_words {forbidden_words: [emoji classes]}

IFEval 跑一个模型时，对每个样本做：模型生成 → 用每个 instruction 的验证脚本检查 → 全部满足才算这个样本通过。最终给两个分数：Strict accuracy（所有约束都满足）和 Loose accuracy（满足大部分约束）。

为什么这个设计聪明

完全排除主观性。LLM judge 评测有偏见、人工评测贵且慢、benchmark 标准答案有污染问题。IFEval 用代码验证完全客观，跑得快、能复现。

直接对应 production 需求。production 应用里就是希望模型 100% 听话——用户要 JSON 必须给 JSON，要 200 字必须 200 字。IFEval 直接量化这种"听话度"。

天然防污染。IFEval 的题目可以无限批量生成（用模板 + 约束变量），不存在静态数据集被训练时见过的问题。

揭示模型的隐藏弱点。一个在 MMLU 上 85+ 的模型，在 IFEval 上可能只有 70%——揭示出"这模型懂很多但不太听话"。这种 gap 在生产里就是用户体验灾难。

主流模型在 IFEval 上的表现

公开数据（截至 2024 年中）：

• GPT-4 Turbo：strict 约 80%，loose 约 87%
• Claude 3 Opus：strict 约 78%
• Llama-3 70B Instruct：strict 约 75%
• 开源中等规模模型（7B-13B）：strict 多在 50-65%

也就是说哪怕顶尖模型也只能严格遵守约 80% 的指令——20% 的样本上某个约束被违反。这个数字比很多人直觉的高。

IFEval 的局限

只测 verifiable 维度。"用专业但友好的语气"、"逻辑清晰"这类主观约束 IFEval 覆盖不到。需要其他评测补。

单轮指令为主。多轮对话中"在第三轮回答时遵守新约束"这种场景没有完全覆盖。FollowBench 等扩展评测在做这个。

约束的组合复杂度有限。真实用户经常给 5-6 个嵌套约束（"先用一段话总结，然后用 bullet point 列出 3 个要点，最后用一句话给建议"），IFEval 的约束组合还相对简单。

英文为主。原始 IFEval 是英文，中文版（C-IFEval、CIF-Bench）效果不如英文成熟。

其他指令遵循 benchmark

FollowBench：北大提出，5 个层次的指令复杂度，约束之间有依赖。比 IFEval 复杂，但需要 LLM judge。

ComplexBench：微软的工作，专门测复合指令——多个约束嵌套组合。

InfoBench：把指令 verifiability 分级，不同级别用不同评测方法（代码验证、LLM judge、人工）。

MT-Bench / Arena 多轮：间接也评测指令遵循（用户在多轮中调整要求模型是否跟得上）。

怎么用 IFEval 改进自己模型

如果发现自家模型在 IFEval 上分数低，几个方向：

SFT 数据补强。生成一批"含明确格式/长度/风格约束的 prompt + 满足约束的 response"作为 SFT 数据。模型见多了这种模式自然学会听话。

DPO 偏好对。构造 (chosen=满足约束, rejected=违反约束) 的偏好对训 DPO。让模型学到"严格遵守约束 > 自由发挥"。

Constrained Decoding。从工程层面强制约束（JSON schema、长度上限）。详见推理服务专题第 18 篇。

评估时做迭代。把 IFEval 上失败的样本类型分析出来——是长度约束最难？是格式约束最难？针对性补数据。

面试时可以这样答

指令遵循评测的目标是衡量模型严格按用户要求执行的能力——不是答得对不对，而是答得符不符合要求。比如格式 JSON、长度 100 字、不能用 emoji、必须按某个顺序。这类约束 production 应用里至关重要，模型不听话直接破坏下游解析。

单独评测的原因是知识/推理能力强不等于听话。一个 MMLU 80+ 的模型在 IFEval 上可能只有 70%，揭示出"懂很多但不太听话"的 gap，这在生产里是用户体验灾难。

IFEval 是 Google 提出的代表性评测。它的设计哲学是只测 verifiable instructions——能用代码精确验证的约束。定义了 25 类 instruction，每个样本是 prompt + 一组约束，模型生成后用脚本检查是否满足。给 strict accuracy（全满足）和 loose accuracy（部分满足）两个分数。

设计上的聪明之处是完全客观（不需要 LLM judge 也不需要人工标注）、跑得快、可复现、天然防污染（题目可以模板化无限生成）、直接对应 production 需求。

主流模型公开数据：GPT-4 Turbo strict 80%、Claude Opus 78%、Llama-3 70B 75%、开源 7B-13B 50-65%。最强模型也只能严格遵守 80%，20% 的样本上某个约束被违反。

局限是只测 verifiable 维度，"语气专业友好""逻辑清晰"这类主观约束覆盖不到；单轮为主多轮场景需要 FollowBench 等补；约束组合复杂度有限真实用户的嵌套要求更复杂；英文为主中文版相对薄弱。

改进自家模型的方向包括：SFT 数据补强（含约束的 prompt-response 对）、DPO 偏好对（chosen 满足约束 rejected 违反约束）、工程上 constrained decoding 硬约束、按 IFEval 失败类型针对性补数据。

常见追问

1. Constrained Decoding 是不是把 IFEval 分数刷到 100% 了？这种做法有什么副作用？
2. 多轮对话中模型遵守约束的能力评测怎么设计？跨轮依赖怎么验证？
3. IFEval 测不到的"逻辑清晰、表达专业"这种维度怎么评测？