🤖 AI

Judging Is Not Enumerating: Silent Omissions in LLM-Authored Acceptable Sets

本文表明，尽管大语言模型擅长判断候选对象是否属于正确集合，但由于存在一种倾向于“静默遗漏”而非“过度包含”的系统性偏差，它们在构建完整的合格集合方面表现出显著失败，且这种缺陷在不同领域和参数规模下均持续存在。

原作者： Wenhui Chen, Jianlin Chen, Ziyao Lin, Peiji Long, Chi Man Vong

发布于 2026-08-04

📖 1 分钟阅读☕ 轻松阅读

原作者： Wenhui Chen, Jianlin Chen, Ziyao Lin, Peiji Long, Chi Man Vong

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

伟大的角色反转：当 AI 成为老师

想象一个教室，学生们不再仅仅是回答问题，他们正在编写教科书、评改考试，并决定什么才算作“正确”的答案。这正发生在人工智能的世界里。大语言模型（LLMs）正在从“考生”（答题者）晋升为“监考官”（出题者）。它们正在编写规则、标准答案和检查清单，用以告诉其他 AI 系统它们做得是否出色。

要理解为什么这很棘手，请思考两种不同的技能。第一种是判断（Judging）：观察一个单一的答案并说，“是的，这是对的，”或者“不，那是错的。”第二种是创作（Authoring）：从零开始创建包含所有可能正确答案的完整列表。这就像是裁判在球员越界时吹哨，与教练试图编写一本规则书来列出球员所有可能的越界方式之间的区别——后者必须确保不遗漏任何一种情况。我们之所以关注这一点，是因为如果编写测试题的 AI 犯了错，它不仅仅是答错了一个问题，它还改变了对所有人的“正确”定义，可能会惩罚优秀的答案并奖励错误的答案。

论文的大发现：机器中的无声幽灵

本研究调查了 AI 在处理这些新角色时出现的一种奇怪且危险的故障。研究人员发现，虽然 AI 模型实际上非常擅长判断（识别特定答案的正误），但它们在创作（写出所有正确答案的完整列表）方面却表现得极其糟糕。

把这想象成一场“老师说”的游戏。如果你问 AI：“‘苹果’是一种水果吗？”它几乎总是能正确回答“是”。但如果你问它：“列出所有存在的各种水果，”它会开始列举苹果和香蕉，然后……就停住了。它会忘记橙子、奇异果和芒果。它忘记并不是因为它不知道这些东西，而是因为它不擅长执行“写出完整列表”这一特定任务。

作者称之为**“判断-枚举剪刀差”（Judging-Enumerating Scissors）**。想象一把剪刀，其中一个刀片是“判断”（锋利且强壮），另一个刀片是“创作”（钝且无力）。随着 AI 模型变得越来越大、越来越聪明（从小型向大规模扩展），“判断”的刀片变得越来越锋利，但“创作”的刀片几乎没有变得更锋利。它们永远无法追赶上来。它们在判断能力与列举能力之间的差距始终存在，无论你投入多少计算能力。

无声的幽灵：为什么我们察觉不到错误

这一发现最可怕的部分在于 AI 是如何失败的。当它编写正确答案列表时，它通常不会添加错误的答案（比如把“石头”列为水果）。相反，它会犯下**沉默遗漏（Silent Omissions）**的错误。它只是简单地漏掉了真实的答案。

以下是为什么这如此危险：

过度包含（添加错误项）： 如果 AI 不小心把“石头”加入了水果列表，人类审核员可以很容易地发现。“嘿，石头不是水果！”他们会这么说。这是一个可见的错误。
遗漏（漏掉正确项）： 如果 AI 忘了列出“奇异果”，就没有明显的错误可以观察。列表看起来只是稍微短了一点。要找到缺失的奇异果，审核员必须自己知道答案，然后去搜寻它。

论文显示，AI 模型发现自己多加了错误项的能力，比意识到自己漏掉了某些项的能力要高出 6 到 7 倍。 这就像一个学生非常擅长寻找作文中的错别字，却完全意识不到自己忘了写结论。因为缺失的部分是隐形的，AI 生成的“标准答案”最终会是不完整的，而基于这些答案进行评分的 AI 系统也会因为这些答案不在列表中而惩罚正确的答案。

“魔法规则”的漏洞

研究人员测试了一个聪明的变通方法。他们要求 AI 不要列出水果，而是编写一条关于“什么是水果”的规则（例如：“如果它生长在树上并且有种子”）。当他们这样做时，AI 变得近乎完美（得分 99% 的准确率）。

这证明了 AI 并不笨。它知道规则。问题纯粹在于列举这个动作本身。这就像一位厨师可以完美地描述蛋糕的食谱，但在被要求写出完整的购物清单时，却总会忘记写下最后三种配料。论文表明，如果你让 AI 写规则而不是写列表，问题就会消失。但在许多现实场景中（例如为计算机代码编写测试套件），不存在简单的规则可以编写；你必须列出具体的测试用例，而这正是 AI 栽跟头的地方。

为什么“检查自己的工作”不起作用

你可能会想：“既然 AI 不擅长列举，也许它可以直接检查自己的列表来修复错误？”研究人员也测试了这一点。他们让 AI 生成一个列表，然后生成第二个列表，最后用第二个列表来过滤第一个列表。

结果如何？行不通。 AI 无法修复它自己的遗漏。这就像要求一个不擅长数数的人去数自己的手指，看是否漏掉了。AI 的“判断”技能在面对一个清晰、预先制作好的列表时很强大，但当它试图判断自己生成的混乱列表时，这种能力就会崩溃。论文得出结论，要求 AI 检查自己的答案表是一个陷斗；它需要一个外部的、经过人类验证的“金标准”来捕捉那些缺失的部分。

现实世界的代价：“AI 税”

最后，论文测量了当这种有缺陷的答案表被用于训练其他 AI 时会发生什么。他们设定了一个场景，即 AI 通过获得正确答案来学习。

当使用完美的、由人类制作的答案表时，AI 学习得很好。
当使用模型制作的答案表时，AI 的学习效果显著变差。

在一个特定的语言任务中，使用模型制作答案表的 AI 比使用完美答案表的 AI 低了 18.5 分。即使是在规则非常简单的数学任务中，它仍然损失了 1.9 分。这种“税”之所以存在，是因为模型制作的答案表过于严格：它拒绝了 AI 生成的正确答案，仅仅因为这些答案没被包含在它自己的列表中。AI 会感到困惑，认为自己的正确答案是错误的，从而停止尝试进行创造性表达。

总结

论文并不是说 AI 是没用的。它是在提醒我们，当我们要求 AI 担任“监考官”并编写正确性的规则时，必须非常小心。

不要要求列出清单，要要求编写规则。 如果 AI 可以编写一条规则（如 Python 脚本）来检查答案，请使用该方法。它是近乎完美的。
不要盲目信任列表。 如果 AI 必须编写正确答案列表，它几乎肯定会遗漏一些内容。
使用“守门人”。 在信任 AI 的答案表之前，检查它是否接受一个已知的正确答案。如果它拒绝了一个已知的正确答案，请弃用该表。
修复，而非丢弃。 如果答案表拒绝了一个正确的答案，你通常可以直接修复那个特定的错误（例如预期的输出结果），而不是把整个东西都扔掉。

底线是：AI 擅长发现错误，但并不擅长确保自己没有遗漏任何东西。在解决这个“沉默遗漏”问题之前，我们不能完全信任 AI 去给自己的作业打分。

技术摘要：评判不等于枚举

问题陈述

语言模型（LLMs）正日益被部署为不仅是回答问题的受试者，更是作为定义下游系统正确性的规范、测试套件、答案解析和奖励函数的考官。本文研究了这种角色转变中一个关键的不对称性：虽然模型在判断特定候选对象是否属于一个可接受集合方面表现出强大的能力，但在构建该集合本身时，其表现却显著下降。

核心问题在于“构建差距”（authoring gap）：即模型无法以其在判断个体候选对象时所具备的保真度，将正确性规范的外延（即所有有效答案的列表或接受它们的测试套件）具象化。这种差距之所以危险，是因为所生成的产物（解析、准则、套件）成为了其他系统（包括带有可验证奖励的强化学习，RLVR）运行时的正确性定义。本文认为，主要的失效模式是沉默遗漏（silent omission）——即未能包含有效成员的现象——这在审计上具有内在的难度，因为对于缺失项，局部审查者无法像对待过度包含项那样进行质疑。

方法论

作者采用了一种基于构建真值（ground truth）的严谨、无裁判测量框架，以避免循环论证（即使用模型来评估模型自身的规范）。研究利用四种不同的构建方式，在不同领域和不同完备性水平上对这一现象进行三角测量：

算法构建（完全真值）：
- 字符串： 模型被给定一个包含 15 个单词的有限列表和一个机械可判定的谓词（例如“包含双字母”）。任务是列出所有满足该谓词的单词。
- 算术： 与字符串任务类似，但在整数列表上使用数值谓词（例如“能被 3 整除”）。
- 意义： 这些构建消除了词汇不完备性的干扰；其真值是可计算且精确的。
可执行构建（可执行真值）：
- 基于 HumanEval+ 和 MBPP+。模型根据文档字符串生成测试套件。正确性通过将套件在针对预设验证解（1,560 个正确，904 个错误）的池中执行来确定。
- 意义： 这衡量了“内涵式”构建能力，其中集合是无界的，并由代码执行定义。
词汇构建（词汇真值）：
- 基于 WordNet 同义词集（synsets）。模型列出符合特定语义的单词。
- 意义： 用于三角测量，尽管承认其具有不完备性（词汇表可能遗漏有效的同义词）。本文将其精度视为下界，并依赖于召回率趋势。

实验设计：

对比接口：
- 评判（执行）： 模型获得一个候选对象并被问及“ $x \in S^*$ 是否成立？”（逐点分类）。
- 构建： 模型必须输出整个集合 $\hat{S}$ （外延枚举）或谓词/套件（内涵构建）。
控制变量： 研究控制了规模（3B 到 72B 参数）、模型家族（Qwen2.5, Qwen3, Llama, Mistral, Phi, gemma）、提示词变化以及解码策略（贪婪搜索 vs. 启用推理的策略）。
缓解测试： 本文测试了“采样后验证”（自我修复）、“已知正确探针”门控以及“追踪修复”（根据参考执行重写预期值）。
下游影响： 作者通过使用模型构建的键与预设（oracle）键进行训练，测量“RLVR 税”，以量化准确率损失。

核心贡献与结果

1. 评判与构建的剪刀差

主要发现是在所有规模和模型家族中，评判性能与构建性能之间存在持续且具有统计学意义的差距。

完全真值： 在算法任务中，评判的 F1 分数范围在 0.60 到 0.77 之间，而构建的 F1 分数范围在 0.26 到 0.48 之间。差距（ $\Delta$ ）始终为正（+0.25 到 +0.34），且并未随着模型规模的增加而消失。
可执行代码： 在此任务中差距最为严重。模型在判断代码正确性时 F1 可达 0.74–0.90，但其构建的测试套件仅能接受 19–42% 的预设正确解（Llama 构建的套件甚至更低，仅为 8–10%）。
规模无关性： 该差距在 24 倍的参数跨度和不同的模型世代（包括 GPT-5.1 和 Opus 等前沿模型）中依然存在，尽管在最强模型的简单构建任务上略有缩小。

2. 机制：沉默遗漏

论文指出遗漏是主要的错误模式，这种模式是“缺乏见证”的。

审计不对称： 局部审查（减法操作）在检测过度包含（假阳性）方面非常有效，但在检测遗漏（假阴性）方面却失效了。在受控实验中，模型检测植入的过度包含项的频率比检测植入的遗漏项高出 6–7 倍。
审查后果： 由于审查流程倾向于移除过度包含项，却无法恢复遗漏项，因此迭代优化过程使产物向欠接受（高精度、低召回率）偏移，而非修复它们。

3. 缺陷的本质：枚举 vs. 规范

论文区分了“无法指定规则”与“无法枚举其外延”之间的区别。

谓词发射： 当被要求编写规则（例如 Python 谓词 def accepts(w)）而非答案列表时，模型的 F1 分数接近完美（~0.99）。
结论： 缺陷并非源于知识匮乏或无法指定逻辑。它是一种单次具象化（one-shot materialization）的失败：即在没有提供可重述的紧凑规则的情况下，无法详尽地枚举由规范所诱导的集合。

4. 缓解与修复

自我验证失效： “采样后验证”（生成多个候选对象并使用模型自身的评判器进行过滤）并不能弥合差距。样本的并集无法覆盖真值（检索受限），且模型自身的评判器会在其自身生成的边界候选对象上崩溃。
外部门控： 丢弃任何拒绝了已知正确探针（例如参考解）的构建套件，可将假拒绝率从 58–92% 降低到 $\le$ 5%。然而，这会丢弃大部分套件（收益仅为 5–39%）。
追踪修复： 将失败套件中的预期值重写为匹配参考执行的输出，可使可用套件的数量恢复 3.3 倍至 10.6 倍。这证明失败在于计算预期输出（内涵），而非选择输入（外延）。

5. 下游成本：RLVR 税

当使用模型构建的键作为 RLVR 中的奖励信号时：

词汇任务： 使用构建的键进行训练，相对于预设键，准确率损失了 18.5 个点（相对于 WordNet）。
完全真值任务： 即便使用机械精确的集合，成本也是 1.9 个点。
机制： 构建的键充当了一个“双向通道”，既剥夺了正确行为（遗漏），又奖励了错误行为（污染）。策略学会了针对错误的键进行优化，导致了永久性的准确率赤字，且该赤字不会随模型规模的增加而消失。

重要性与主张

本文声称确立了当前使用 LLM 作为验证器和奖励设计者的范式中的一个基本局限。

“元层级”不对称性： 虽然“验证比生成解更容易”已广为人知，但本文表明，生成验证标准本身比针对标准验证候选对象更难。这种“验证优势”并不能转移到验证器的构建上。
方向性错误： 失败并非随机噪声，而是一种系统性的偏向遗漏。这使得构建的规范在方向上是错误的，以至于局部审查无法对其进行认证或修复。
实际意义： 论文认为，绝不应信任单次构建的规范作为真值。相反，系统应当：
1. 尽可能提取规则（谓词）而非清单（列表）。
2. 将所有构建的验证器针对已知正确探针进行门控。
3. 利用外部执行来修复预期值，而不是直接丢弃整个产物。
谦逊态度： 作者明确指出，该差距特指单次、贪婪构建且未经过测试时推理的情况。他们承认，测试时推理（思维链/scratchpads）可以在存在规则的算法任务上缩小差距，但对于必须从文本中推断规则的测试套件构建，它并不能可靠地进行修复。他们并非声称 LLM 无法被训练出更好的验证器，而是强调目前大规模部署的零样本/单次模式是不够的。

总之，本文证明了在最苛刻的形式下（详尽枚举），LLM 目前仍无法胜任“考官”的角色，这造成了一个沉默且无法审计的瓶颈，从而削弱了下游系统，尤其是 RLVR 流水线。