这篇是对论文 Instruction-Following Evaluation for Large Language Models 的学习笔记。
IFEval 是一篇很适合工程团队读的论文。它没有追求宏大的“智能”定义，而是盯住了 LLM 产品里一个非常常见、也非常烦人的问题：
模型到底有没有照用户说的做？
这个问题听起来简单，但日常使用里非常高频。你让模型“只返回 JSON”，它前面加一句解释；你让它“不要超过 100 字”，它写了 300 字；你让它“必须包含三个字段”，它漏一个；你让它“用中文回答”，它夹英文；你让它“不要提某个词”，它偏偏提了。
这类失败不一定说明模型不聪明。很多时候它能理解任务，也能生成高质量内容，但没有严格遵守外层约束。对产品来说，这已经足够造成问题。
1. 为什么指令遵循需要单独评测
传统能力评测常常关心模型是否知道答案、能否推理、能否写代码。但产品里的 prompt 往往由两层东西组成：
任务内容：你要回答什么
形式约束：你必须怎么回答比如：
总结下面的客服记录。
要求：
1. 只输出 JSON。
2. 字段必须包含 severity、reason、next_action。
3. severity 只能是 low、medium、high。
4. 不要输出 Markdown。这里模型不但要理解客服记录，还要遵守格式、字段、枚举值、禁止项。如果格式不对，下游程序就会崩；如果字段漏了，数据管道就断；如果多说一句，解析器可能失败。
IFEval 的出发点是：指令遵循不应该只靠人类主观评，也不应该完全交给 LLM judge。很多指令本身是可验证的，我们应该用程序检查。
2. IFEval 怎么设计
IFEval 选择了一组“verifiable instructions”，也就是能被自动检查的指令。
论文给出的例子包括：
- 写作长度超过某个字数。
- 至少提到某个关键词几次。
- 使用指定语言。
- 用特定格式输出。
- 不包含某些词。
- 按指定结构组织回答。
论文识别了 25 类这样的可验证指令，构造了大约 500 条 prompts。每条 prompt 包含一个或多个约束。模型生成答案后，评测脚本不需要理解答案“好不好”，只检查它是否满足这些约束。
这个设计非常克制，也非常实用。
IFEval 不试图判断模型内容是否深刻，不评估事实性，不评估审美。它只问一件事：给定明确可检查的要求，模型有没有遵守？
正因为问题被收窄，它才能做到可复现、低成本、少主观偏差。
3. 可验证指令的价值
IFEval 最值得迁移到工程里的思想，是把评测从“模型输出质量”拆出一个更底层的维度：约束满足。
很多系统失败并不是答案错，而是契约破坏。
比如：
业务逻辑要求：返回三个分类标签
模型返回：一段自然语言解释这个回答可能写得很好，但对系统来说是失败。
再比如：
安全要求：不能给出具体危险步骤
模型返回：先拒绝，然后又补了一个“理论上可以这样做”它看起来有拒答姿态，但实际违反约束。
IFEval 这种方法提醒我们：在 LLM 应用里，prompt 不只是“建议”，而是接口契约的一部分。既然是契约，就应该能被测试。
4. 如何把 IFEval 变成自己的发布门禁
我觉得每个 LLM 应用都应该有一套自己的 mini-IFEval。
第一类样本是格式约束。
只返回 JSON
必须是合法 YAML
只能输出 CSV
不得包含 Markdown code fence第二类样本是结构约束。
必须包含指定字段
字段顺序固定
数组长度不能超过 5
枚举值只能来自给定集合第三类样本是语言和风格约束。
必须用中文
不能使用第一人称
不能出现营销语气
必须用用户同样的语言回答第四类样本是安全和边界约束。
不知道就说不知道
没有证据不能编造来源
不能输出隐私字段
不能提供危险步骤第五类样本是多约束组合。
真实系统里最容易失败的往往不是单条约束，而是组合约束。比如同时要求中文、JSON、三个字段、字段值枚举、不得解释、不得编造。这才接近生产环境。
5. IFEval 和 LLM judge 的关系
IFEval 和 LLM-as-a-Judge 不是竞争关系，它们负责不同层。
LLM judge 适合评估开放质量：
- 哪个回答更清楚。
- 哪个总结更有帮助。
- 哪个解释更符合用户偏好。
IFEval 适合评估硬约束：
- 是否超过字数。
- 是否包含关键词。
- 是否输出合法格式。
- 是否遵守禁止项。
如果一个约束能用程序检查，就不应该交给 LLM judge。因为程序检查更便宜、更稳定、更可复现。
我的建议是：评测流水线里先跑 IFEval 类硬检查，再跑 judge。硬检查不过，开放质量再高也不应该算成功。
6. 这篇论文的局限
IFEval 的优点也是它的边界：它只评估可验证指令。
很多重要指令并不容易自动检查。比如“语气要真诚”“回答要有洞察”“解释要适合初学者”“不要过度自信”。这些仍然需要 LLM judge、人类评审或用户反馈。
另外，满足形式约束不代表任务完成。模型可以输出合法 JSON，但字段内容全错；可以控制字数，但总结漏掉关键信息；可以不出现违禁词，但仍然表达了有害含义。
所以 IFEval 不能替代完整评测。它更像第一道闸门：先确认模型能不能遵守明确规则，再谈内容质量。
还有一点要注意：如果过度优化 IFEval，模型可能学会机械满足表层约束，却牺牲回答自然度或任务效果。生产 eval 里要把它和任务成功率一起看。
7. 我的 takeaway
IFEval 最有价值的提醒是：不要把所有问题都包装成“模型能力”。有些问题其实是接口契约问题。
当你发现模型经常“不按格式输出”“多说废话”“漏字段”“越过边界”时，不要只靠 prompt 里写更多强调句。你应该把这些约束变成测试。
一个很实用的发布门禁可以长这样：
格式合法率 >= 99%
必填字段完整率 >= 99%
枚举值合法率 >= 99%
禁止内容命中率 = 0
多约束组合通过率 >= 95%这些指标不玄学，也不需要昂贵人工评审。它们不能证明模型“聪明”，但能证明模型是否足够“听话”。
很多时候，产品里最先需要的不是更聪明的模型，而是更守契约的模型。IFEval 就是这件事的评测起点。