选择题评测中的输入盲控制与Oracle Headroom：控制信息缺失如何影响模型表现

1. 这个标题到底在说什么

第一次看到这个标题，很多人会以为是某个评测框架的更新日志。其实它讨论的是一个非常具体、也非常容易被忽略的问题：当评测程序（Layer Programs）在选择题任务中运行时，如果控制信息对被测模型不可见，会留下多大的“Oracle 空间”。

先把几个关键词拆开说清楚。

Layer Programs，这里指的是分层评测程序——不是单一模型，而是一套由外层调度、内层执行组成的评测流程。外层负责组织题目、控制流程、决定何时给出提示或约束；内层负责实际作答。很多选择题评测系统都是这种结构：外层像监考老师，内层像考生。

Input-Blind Controls，直译是“输入盲控制”。意思是：控制信号（比如题目类型、选项数量、约束条件、评分规则）在传给内层作答模块时，被有意或无意地屏蔽掉了。内层模型看不到这些控制信息，只能看到题目本身。

Oracle Headroom，Oracle 在这里指“理想上界”——如果模型能完美利用所有可用信息，它能达到的最好表现。Headroom 就是“上界与当前实际表现之间的差距”。所以 Oracle Headroom 可以理解为：因为控制信息不可见，评测系统白白浪费了多少潜在性能空间。

Multiple-Choice Evaluation，就是选择题评测。这是目前最主流的模型能力评估形式之一，从知识问答到推理测试，大量基准都采用选择题格式。

把标题翻译成人话：在选择题评测中，如果控制信息对作答模块不可见，分层评测程序会留下相当大的性能上界空间——这个空间大到值得认真对待，而不是当成噪声忽略掉。

这个结论为什么重要？因为它直接挑战了一个默认假设：很多人认为，只要题目本身给到位，控制信息看不见也无所谓。但实际评测中，控制信息往往携带了关键约束——比如“这道题只有一个正确答案”“选项之间互斥”“需要按特定格式输出”。这些信息一旦丢失，模型的表现会被系统性低估。

适合读这篇内容的人包括：做模型评测的工程师、设计基准测试的研究者、搭建自动化评分系统的开发者，以及任何关心“评测结果到底可不可信”的从业者。不需要你事先精通评测理论，我会把每个环节拆开讲。

2. 为什么“输入盲控制”会成为一个问题

2.1 评测系统的分层结构是怎么来的

要理解这个问题，得先知道现代选择题评测系统为什么会长成“分层”的样子。

最早的选择题评测很简单：一道题、四个选项、模型输出一个字母、对答案。这种单层结构在早期够用，因为任务单一、控制逻辑简单。但随着评测需求变复杂，单层结构撑不住了。

比如，同一套题目可能需要支持多种评测模式：有的要求模型只输出选项字母，有的要求输出完整推理过程，有的要求在多轮对话中逐步给出答案。再比如，不同基准对“正确答案”的定义不同：有的严格匹配，有的允许同义表述，有的需要按特定格式解析。

这些差异如果全部塞进一个模块，代码会变得极其臃肿，而且难以复用。于是自然演化出分层结构：

• 外层（调度层）：负责题目加载、模式选择、格式约束、评分规则、异常处理。
• 内层（作答层）：负责接收题目、生成答案、返回结果。

这种分层的好处很明显：外层可以独立演化，内层可以替换成不同模型，两者通过接口解耦。但问题也恰恰出在这个“解耦”上。

2.2 控制信息在传递过程中是怎么丢失的

分层结构天然存在一个风险：接口设计得越干净，信息丢失得越彻底。

我见过不少评测系统的接口长这样：

def answer(question: str, options: list[str]) -> str: ...

这个接口看起来没问题：题目和选项都传进去了。但外层知道的远不止这些。外层还知道：

• 这是单选题还是多选题
• 选项数量是否固定
• 是否存在“以上都对”这类特殊选项
• 评分时是否区分大小写
• 是否允许“不确定”作为答案
• 题目属于哪个知识领域
• 这道题的历史正确率是多少

这些信息在接口定义里全部消失了。内层模型只能看到 question 和 options，其他一概不知。这就是典型的Input-Blind Controls：控制信号在接口边界被截断了。

更隐蔽的情况是，有些系统虽然接口上传了控制信息，但在实际调用时被默认值覆盖了。比如接口定义了mode参数，但调用方永远传"default"，等于没传。这种“形式上有、实际上无”的情况，比彻底没有更危险，因为它会让人误以为控制信息已经生效。

2.3 Oracle Headroom 是怎么被高估或低估的

Oracle Headroom 的估算，本质上是在问：如果内层模型能完美利用所有控制信息，它的表现能提升多少？

这个问题的难点在于，“完美利用”本身很难定义。不同控制信息对表现的贡献差异巨大。有些信息几乎不影响答案，比如题目所属领域；有些信息则直接决定答案是否正确，比如“这是多选题”。

我做过一个粗略的分类，把控制信息按对选择题表现的影响程度分成三档：

强约束型信息的丢失最致命。举个例子：一道多选题，正确答案是 A 和 C。如果内层模型不知道这是多选题，它很可能只输出一个选项，比如 A。即使它“知道”C 也对，但受限于单选假设，它不会把 C 写出来。这时候评测系统判它错，但错不在模型的知识，而在控制信息的缺失。

这就是 Oracle Headroom 的核心来源：不是模型能力不够，而是评测系统没把该给的信息给到位。

2.4 为什么这个问题在选择题评测中特别突出

选择题评测有几个特点，让它对 Input-Blind Controls 特别敏感。

第一，答案空间小且离散。选择题的答案通常只有几个选项，模型稍微偏一点就会错。不像开放问答，部分正确也能得分。选择题是“全对或全错”，控制信息缺失导致的偏差会被放大。

第二，控制信息与答案强相关。在开放任务中，控制信息（比如“用正式语气”）主要影响风格，不影响内容正确性。但在选择题中，控制信息（比如“多选”）直接改变答案集合。这种强相关性让信息丢失的代价变得很高。

第三，评测结果被广泛引用。选择题基准的分数经常被用来比较模型能力、写进报告、做决策。如果分数因为控制信息缺失而被系统性压低，那所有基于这些分数的结论都会失真。

我见过一个真实案例：某评测系统在跑一个多选基准时，内层模型只输出单个选项，导致整体准确率比预期低了将近 20 个百分点。排查了很久才发现，外层明明知道是多选，但接口只传了题目和选项，没传题型。加上题型参数后，分数立刻回到正常水平。这就是典型的 Oracle Headroom 被浪费。

3. 核心细节拆解：控制信息到底有哪些

3.1 题型约束：单选、多选、不定项

题型是最基础也最容易被忽略的控制信息。

单选题的答案空间是“恰好一个选项”。多选题的答案空间是“一个或多个选项”。不定项选择题更复杂：可能是一个，也可能是多个，甚至可能全选。这三种题型对模型的要求完全不同。

如果内层模型不知道题型，它会默认按最常见的情况处理。大多数模型在训练时见到的选择题以单选为主，所以默认行为往往是“输出一个选项”。这在多选题上就是系统性错误。

更麻烦的是，有些基准混合了单选和多选，但接口没有区分。模型只能靠题目内容猜测题型。猜对了是运气，猜错了是必然。这种不确定性会直接转化为 Oracle Headroom。

3.2 选项约束：互斥、包含、以上都对

选项之间的关系也是重要控制信息。

有些题目的选项是互斥的：选了 A 就不能选 B。有些题目的选项是包含关系：B 是 A 的子集。还有些题目有“以上都对”“以上都不对”这类特殊选项，它们的逻辑与其他选项不同。

如果内层模型不知道这些约束，它可能会选出逻辑上矛盾的组合。比如同时选“以上都对”和某个具体选项，这在逻辑上是冗余的，但模型不知道这是不允许的。

我在实际评测中遇到过一种情况：题目有“以上都不对”选项，正确答案就是它。但内层模型因为不知道这个选项的特殊性，倾向于选择某个具体选项，导致错误。加上选项类型标记后，这类错误明显减少。

3.3 输出格式：字母、文本、结构化

输出格式看似是小事，但在自动化评测中影响很大。

有的评测系统要求模型只输出选项字母，比如“A”。有的要求输出完整选项文本。有的要求输出 JSON 格式，包含选项和置信度。如果内层模型不知道期望格式，它可能输出一段解释文字，导致解析失败。

解析失败在评测中通常按错误处理。这就产生了一个荒谬的结果：模型其实选对了，但因为格式不对被判错。这种错误完全来自控制信息缺失，是纯粹的 Oracle Headroom。

我建议在接口中明确传递输出格式要求，并且在评分前做格式校验。如果格式不对，应该区分“格式错误”和“答案错误”，而不是混在一起。

3.4 评分规则：严格匹配、同义容忍、部分给分

评分规则是外层最清楚、内层最不清楚的信息。

严格匹配要求答案完全一致。同义容忍允许表述不同但意思相同。部分给分在多选中常见：选对一部分给部分分，选错扣分。

如果内层模型不知道评分规则，它可能会采取保守策略：只选最有把握的选项。这在部分给分规则下是次优的，因为放弃了一些可能正确的选项。反过来，如果模型知道是严格匹配，它可能会更谨慎。

评分规则不透明还会导致模型无法优化自己的输出策略。它不知道“多选一个”和“少选一个”哪个代价更大，只能凭感觉。这种不确定性就是 Headroom。

3.5 上下文信息：题目来源、难度、历史表现

这类信息属于弱辅助型，但在某些场景下也有价值。

题目来源可以帮助模型判断领域。难度标签可以帮助模型调整推理深度。历史表现可以帮助模型判断这道题是否容易出错。

这些信息单独看影响不大，但累积起来可能产生几个百分点的差异。在竞争激烈的基准上，几个百分点往往决定排名。

不过要注意：这类信息如果使用不当，可能引入偏差。比如模型看到“高难度”标签就倾向于选更复杂的选项，但实际答案可能很简单。所以这类信息应该作为辅助，而不是决定因素。

4. 实操：如何测量和利用 Oracle Headroom

4.1 搭建一个可控的评测环境

要测量 Oracle Headroom，首先得有一个能控制信息可见性的评测环境。

我的做法是：在现有评测系统上增加一个“信息开关层”。这个层可以独立控制每类控制信息是否传递给内层模型。具体来说，在接口中增加一组布尔参数：

def answer( question: str, options: list[str], question_type: str = None, # "single", "multi", "indefinite" option_constraints: dict = None, # {"mutually_exclusive": True, ...} output_format: str = "letter", # "letter", "text", "json" scoring_rule: str = "strict", # "strict", "synonym", "partial" context: dict = None # {"domain": ..., "difficulty": ...} ) -> str: ...

然后在调用时，通过配置决定哪些参数传实际值，哪些传 None。这样就能在同一套题目上，对比“信息完整”和“信息缺失”两种条件下的表现差异。

这个环境的关键是可复现。每次实验都要记录哪些信息可见、哪些不可见，否则结果无法比较。

4.2 设计对照实验：逐步开放控制信息

有了环境之后，就可以做对照实验了。

我通常从最严格的条件开始：所有控制信息都不可见，内层模型只看到题目和选项。这是基线。

然后逐步开放信息，每次只开放一类，观察表现变化：

1. 基线：无控制信息
2. 开放题型
3. 开放题型 + 选项约束
4. 开放题型 + 选项约束 + 输出格式
5. 开放题型 + 选项约束 + 输出格式 + 评分规则
6. 全部开放

每一步都记录准确率、格式错误率、解析失败率。这样就能看出每类控制信息的边际贡献。

实测下来，题型信息的贡献最大，通常能带来 10 到 20 个百分点的提升。输出格式的贡献次之，主要体现在减少解析失败。评分规则的贡献取决于任务，在多选中比较明显。

4.3 参数计算：Headroom 到底有多大

Oracle Headroom 可以用一个简单公式估算：

Headroom = Accuracy(全部信息可见) - Accuracy(全部信息不可见)

但更细的分解是：

Headroom = Σ (Accuracy(开放第 i 类信息) - Accuracy(开放第 i-1 类信息))

这个分解能告诉你每类信息的边际价值。

我在一个多选基准上做过这个实验，结果大致如下：

可以看到，题型信息贡献了绝大部分 Headroom。这也符合直觉：不知道是单选还是多选，模型根本没法给出正确答案。

4.4 把 Headroom 转化为实际提升

测量出 Headroom 之后，下一步是把它转化为实际提升。

最直接的做法是：在接口中传递所有可用的控制信息。这听起来简单，但实际做起来需要注意几点。

第一，信息要准确。如果外层传的题型标记是错的，内层模型会被误导，表现可能比不传还差。所以传递前要校验。

第二，信息要一致。同一类信息在不同调用中应该用相同的格式和语义。比如题型统一用 "single"/"multi"/"indefinite"，不要混用 "单选"/"多选"/"不定项"。

第三，信息要可解析。内层模型需要能理解这些信息。如果模型不支持某个参数，传了也没用。这时候可能需要在外层做适配，把控制信息转化为模型能理解的提示词。

我通常的做法是：在题目文本前加一段控制说明。比如：

[题型] 多选 [输出格式] 只输出选项字母，多个选项用逗号分隔 [评分规则] 严格匹配 题目：... 选项：...

这样即使接口不支持结构化参数，模型也能通过文本理解控制信息。

5. 常见问题与排查技巧

5.1 为什么加了控制信息后表现反而下降

这种情况我遇到过几次，原因通常有三类。

第一类：信息冲突。外层传的题型是“单选”，但题目实际是多选。模型按单选处理，结果错了。这种错误比不传信息更严重，因为模型被明确误导了。

第二类：信息过载。一次性传入太多控制信息，模型注意力被分散，反而忽略了题目本身。特别是当控制信息用自然语言描述时，过长的前缀会挤占上下文空间。

第三类：格式不匹配。控制信息的格式与模型预期不符。比如模型期望 JSON，但外层传的是纯文本。模型解析失败后，可能退化为默认行为。

排查方法：先单独测试每类控制信息，确认没有冲突。然后逐步增加信息量，观察表现变化。如果某一步出现下降，就重点检查那类信息的准确性和格式。

5.2 内层模型忽略控制信息怎么办

有时候控制信息传了，但模型“视而不见”。这通常是因为模型在训练时没有见过类似的控制信号。

解决办法有两个方向。

方向一：在提示词中强化控制信息。把控制信息放在显眼位置，用明确的标记区分。比如用方括号、加粗、换行等方式，让模型更容易注意到。

方向二：在输出后做校验和修正。如果模型输出不符合控制要求，外层可以拦截并重新请求。比如模型输出了多个选项但题型是单选，外层可以要求它重新只选一个。

我倾向于两个方向结合：先用提示词强化，再用校验兜底。这样既能提高首次成功率，又能保证最终结果符合要求。

5.3 如何区分“模型能力不足”和“控制信息缺失”

这是评测中最容易混淆的问题。

区分方法很简单：在控制信息完整的情况下，看模型表现是否提升。如果提升明显，说明之前的低分主要来自信息缺失，而不是能力不足。如果提升不明显，说明模型确实不会做这类题。

我通常会做一个“信息完整度扫描”：从无信息到全信息，画一条曲线。如果曲线在某个点突然上升，说明那类信息是关键。如果曲线一直平缓，说明模型能力是瓶颈。

这个扫描还能帮你决定优化方向：如果 Headroom 很大，优先补控制信息；如果 Headroom 很小，优先提升模型能力。

5.4 常见问题速查表

5.5 几个容易踩的坑

坑一：以为接口传了就等于模型看到了。接口参数和模型输入是两回事。参数传了，但如果没有拼接到提示词里，模型还是看不到。一定要确认控制信息真正进入了模型上下文。

坑二：控制信息格式不统一。同一个系统里，有的地方用 "multi"，有的用 "multiple"，有的用 "多选"。模型需要额外精力去理解这些差异，容易出错。统一格式能减少这类问题。

坑三：忽略解析失败的影响。解析失败通常被计入错误，但它和答案错误是两回事。如果解析失败率高，应该单独统计并优化，而不是笼统地归为模型不行。

坑四：在评测报告里不说明控制信息可见性。这会导致不同报告之间无法比较。建议在报告里明确写清楚：哪些控制信息对模型可见，哪些不可见。这样读者才能正确解读分数。

6. 这个方向还能怎么扩展

6.1 从选择题扩展到其他题型

Input-Blind Controls 的问题不限于选择题。填空题、排序题、匹配题都有类似的控制信息。比如填空题需要知道“每空填一个词”还是“可以填多个词”，排序题需要知道“是否允许并列”。

把测量方法迁移过去，应该能发现类似的 Oracle Headroom。特别是那些答案空间离散、控制信息与答案强相关的题型，Headroom 可能更大。

6.2 从评测扩展到训练

如果控制信息在评测中重要，那在训练中可能也重要。一个自然的想法是：在训练数据中也加入控制信息，让模型学会根据控制信号调整输出。

比如，训练时同时给模型“题型”标签，让它在单选和多选之间切换。这样模型在评测时对控制信息更敏感，Headroom 会更小。

这个方向目前探索不多，但我觉得很有潜力。毕竟，与其在评测时补信息，不如在训练时就教会模型利用信息。

6.3 自动化控制信息推断

如果外层无法提供控制信息，能不能让内层模型自己推断？

比如，从题目文本中推断是单选还是多选。有些题目有明确提示（“以下哪些”“选出所有”），有些则没有。推断准确率直接影响表现。

我试过用规则加模型结合的方式做推断，在部分基准上能达到 80% 以上的准确率。但推断错误会引入新的错误来源，所以需要权衡。

更稳妥的做法是：外层尽量提供控制信息，内层做推断作为兜底。两者结合，既能保证大部分情况正确，又能在信息缺失时有一定鲁棒性。

6.4 建立控制信息可见性标准

最后，我觉得评测社区需要建立一个标准：在报告评测结果时，明确说明控制信息的可见性。

这就像实验报告需要说明实验条件一样。没有这个标准，不同评测系统的分数无法比较，Oracle Headroom 也无法被正确解读。

标准可以很简单，比如要求报告里包含一个表格：

有了这个，读者就能判断分数的可比性，也能估算 Headroom 的大小。

我个人在实际操作中的体会是：评测系统的接口设计，往往决定了评测结果的上限。接口传什么、不传什么，看起来是工程细节，实际上直接影响模型能发挥多少能力。Input-Blind Controls 这个问题之所以值得关注，就是因为它提醒我们：在追求更大模型、更多数据的同时，别忘了检查一下，该给模型的信息，是不是真的给到了。