1. 这个标题到底在说什么第一次看到这个标题很多人会以为是某个评测框架的更新日志。其实它讨论的是一个非常具体、也非常容易被忽略的问题当评测程序Layer Programs在选择题任务中运行时如果控制信息对被测模型不可见会留下多大的“Oracle 空间”。先把几个关键词拆开说清楚。Layer Programs这里指的是分层评测程序——不是单一模型而是一套由外层调度、内层执行组成的评测流程。外层负责组织题目、控制流程、决定何时给出提示或约束内层负责实际作答。很多选择题评测系统都是这种结构外层像监考老师内层像考生。Input-Blind Controls直译是“输入盲控制”。意思是控制信号比如题目类型、选项数量、约束条件、评分规则在传给内层作答模块时被有意或无意地屏蔽掉了。内层模型看不到这些控制信息只能看到题目本身。Oracle HeadroomOracle 在这里指“理想上界”——如果模型能完美利用所有可用信息它能达到的最好表现。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 的估算本质上是在问如果内层模型能完美利用所有控制信息它的表现能提升多少这个问题的难点在于“完美利用”本身很难定义。不同控制信息对表现的贡献差异巨大。有些信息几乎不影响答案比如题目所属领域有些信息则直接决定答案是否正确比如“这是多选题”。我做过一个粗略的分类把控制信息按对选择题表现的影响程度分成三档控制信息类型典型示例对答案的影响丢失后的典型表现下降强约束型单选/多选、选项互斥、必选数量直接决定答案空间10%~30%格式型输出格式、大小写、标点要求影响解析而非答案本身5%~15%弱辅助型题目领域、难度标签、历史统计间接影响推理策略0%~5%强约束型信息的丢失最致命。举个例子一道多选题正确答案是 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 Headroom4.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 设计对照实验逐步开放控制信息有了环境之后就可以做对照实验了。我通常从最严格的条件开始所有控制信息都不可见内层模型只看到题目和选项。这是基线。然后逐步开放信息每次只开放一类观察表现变化基线无控制信息开放题型开放题型 选项约束开放题型 选项约束 输出格式开放题型 选项约束 输出格式 评分规则全部开放每一步都记录准确率、格式错误率、解析失败率。这样就能看出每类控制信息的边际贡献。实测下来题型信息的贡献最大通常能带来 10 到 20 个百分点的提升。输出格式的贡献次之主要体现在减少解析失败。评分规则的贡献取决于任务在多选中比较明显。4.3 参数计算Headroom 到底有多大Oracle Headroom 可以用一个简单公式估算Headroom Accuracy(全部信息可见) - Accuracy(全部信息不可见)但更细的分解是Headroom Σ (Accuracy(开放第 i 类信息) - Accuracy(开放第 i-1 类信息))这个分解能告诉你每类信息的边际价值。我在一个多选基准上做过这个实验结果大致如下条件准确率相对基线提升无控制信息52.3%—题型68.7%16.4%选项约束71.2%2.5%输出格式73.8%2.6%评分规则75.1%1.3%全部信息75.4%0.3%可以看到题型信息贡献了绝大部分 Headroom。这也符合直觉不知道是单选还是多选模型根本没法给出正确答案。4.4 把 Headroom 转化为实际提升测量出 Headroom 之后下一步是把它转化为实际提升。最直接的做法是在接口中传递所有可用的控制信息。这听起来简单但实际做起来需要注意几点。第一信息要准确。如果外层传的题型标记是错的内层模型会被误导表现可能比不传还差。所以传递前要校验。第二信息要一致。同一类信息在不同调用中应该用相同的格式和语义。比如题型统一用 single/multi/indefinite不要混用 单选/多选/不定项。第三信息要可解析。内层模型需要能理解这些信息。如果模型不支持某个参数传了也没用。这时候可能需要在外层做适配把控制信息转化为模型能理解的提示词。我通常的做法是在题目文本前加一段控制说明。比如[题型] 多选 [输出格式] 只输出选项字母多个选项用逗号分隔 [评分规则] 严格匹配 题目... 选项...这样即使接口不支持结构化参数模型也能通过文本理解控制信息。5. 常见问题与排查技巧5.1 为什么加了控制信息后表现反而下降这种情况我遇到过几次原因通常有三类。第一类信息冲突。外层传的题型是“单选”但题目实际是多选。模型按单选处理结果错了。这种错误比不传信息更严重因为模型被明确误导了。第二类信息过载。一次性传入太多控制信息模型注意力被分散反而忽略了题目本身。特别是当控制信息用自然语言描述时过长的前缀会挤占上下文空间。第三类格式不匹配。控制信息的格式与模型预期不符。比如模型期望 JSON但外层传的是纯文本。模型解析失败后可能退化为默认行为。排查方法先单独测试每类控制信息确认没有冲突。然后逐步增加信息量观察表现变化。如果某一步出现下降就重点检查那类信息的准确性和格式。5.2 内层模型忽略控制信息怎么办有时候控制信息传了但模型“视而不见”。这通常是因为模型在训练时没有见过类似的控制信号。解决办法有两个方向。方向一在提示词中强化控制信息。把控制信息放在显眼位置用明确的标记区分。比如用方括号、加粗、换行等方式让模型更容易注意到。方向二在输出后做校验和修正。如果模型输出不符合控制要求外层可以拦截并重新请求。比如模型输出了多个选项但题型是单选外层可以要求它重新只选一个。我倾向于两个方向结合先用提示词强化再用校验兜底。这样既能提高首次成功率又能保证最终结果符合要求。5.3 如何区分“模型能力不足”和“控制信息缺失”这是评测中最容易混淆的问题。区分方法很简单在控制信息完整的情况下看模型表现是否提升。如果提升明显说明之前的低分主要来自信息缺失而不是能力不足。如果提升不明显说明模型确实不会做这类题。我通常会做一个“信息完整度扫描”从无信息到全信息画一条曲线。如果曲线在某个点突然上升说明那类信息是关键。如果曲线一直平缓说明模型能力是瓶颈。这个扫描还能帮你决定优化方向如果 Headroom 很大优先补控制信息如果 Headroom 很小优先提升模型能力。5.4 常见问题速查表问题现象可能原因排查方法解决方向多选基准准确率异常低题型信息未传递检查接口是否传 question_type传递题型并校验格式错误率高输出格式未指定检查 output_format 参数明确格式要求并做后处理加了信息后表现下降信息冲突或过载单独测试每类信息修正冲突、精简信息模型忽略控制信息提示词不显眼检查控制信息位置强化标记、增加校验部分给分任务表现差评分规则未传递检查 scoring_rule 参数传递规则并调整策略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 这个问题之所以值得关注就是因为它提醒我们在追求更大模型、更多数据的同时别忘了检查一下该给模型的信息是不是真的给到了。