正确却不可选：多候选推理中的隐性界面税

1. 问题与价值

这篇论文解决的是小模型多候选推理系统中的一个隐蔽瓶颈：候选池里明明出现了正确答案，但最终选择器却选不中它，因为正确答案的格式、完整性或答案模式与固定选择器期望的输入不兼容。作者把这个损失称为 hidden interface tax，即隐藏在生成端和选择端之间的接口税。

这个问题重要，是因为小模型部署在成本、延迟、隐私受限的场景中，不能像大模型那样靠换更大模型来提升推理能力。多候选生成再重排是自然的测试时扩展路线，但如果候选池里正确候选无法被选择器消费，增加采样数量就白费了。受益者是需要在本地、内网、边缘离线环境部署小模型推理系统的工程师和研究者。他们可以通过先做接口审计，用低成本规则修复候选格式，在不重新训练生成器或选择器的前提下把已有正确候选转化为最终正确输出，从而节省采样预算和训练成本。

2. 已有工作的不足

在本文之前，多候选推理的优化主要分两条线。一条是候选源扩展，代表方法有 Self-Consistency、multi-sampling、Tree-of-Thought、搜索式推理，以及 Power Sampling 等测试时扩展方法。这些方法的目标是提高候选池中出现正确轨迹的概率，但它们不约束候选是否完整、是否可解析、是否与答案模式兼容，也不保证固定验证器能从扩大的池中选出正确候选。论文特别指出 Power Sampling 的分布塑形可以提高原始 oracle coverage，却因为与验证器不对齐而损害最终准确率。

另一条是验证器和重排器优化，代表方法有 Cobbe 等人的 verifier、Lightman 等人的 process supervision、以及各种 reward model 和 preference optimization。这些方法改进选择端，但选择器无法挽救一个 oracle miss；即使正确候选存在，候选格式、重复、答案模式和最终答案包装仍然会改变选择行为。

关键的不足是：没有任何已有工作把生成端和选择端之间的接口当作独立可优化的层来测量和处理。标准做法用 oracle coverage 作为最终准确率的上界，只测量候选池中是否有正确候选，却把两种不同失败混在一起：正确候选缺失是 coverage failure，正确候选存在但无法被选择器消费是 conversion failure。不分离这两者，实践者无法判断该加更多候选还是该修接口对齐。

3. 重建作者的思考路径

从旧方法出发，我会先看到这样的现象：Self-Consistency 和 multi-sampling 在增加候选数时，oracle coverage 上升，但最终准确率有时不升反降。一个自然的怀疑是选择器不够好，于是会想到换更强的 verifier 或 reward model。但换更强的选择器后，发现有些正确候选仍然选不中，因为它们的文本形态不对。

这时我会撞上一个矛盾：如果正确候选的语义内容是对的，为什么选择器不选它？检查具体案例会发现，有些候选是推理到一半就断了，没有最终答案；有些候选在 MCQ 任务里给了数值答案而不是选项字母；有些候选带着 prompt 残留或脚手架噪声，反而吸引了选择器。这些失败既不在生成器参数里，也不在选择器参数里，而在两者之间的文本接口上。

于是我会想到：能不能在不改生成器和选择器的前提下，只对候选池做后处理？先做诊断，把候选分成几类：不完整的、答案模式不匹配的、有噪声的。对不完整的候选，用生成器补全；对答案模式不匹配的，做格式对齐；对有噪声的，做清洗。这样形成一个接口层。

但接着会发现新问题：诊断规则从哪里来？如果在线推理时用 gold label 来校准规则，就是作弊。所以需要离线阶段用 benchmark schema、parser 合约和少量审计失败案例把规则冻结，在线阶段只用无 gold 信号。另一个问题是：修好格式后，oracle coverage 上升了，但最终准确率不一定上升，因为选择器可能仍然不选新加入的候选。这逼着我把 coverage 和 conversion 分开度量，定义 selectable coverage，即正确候选不仅要存在，还要可解析、模式匹配、干净。

再进一步，我会发现 MMLU-Pro 上出现一个反直觉结果：CACC 把 oracle coverage 从 0.4072 提到 0.4767，但最终准确率从 0.2362 降到 0.2277。这说明接口修复本身不够，还需要 proposer-side strengthening 从源头重塑候选分布，让新加入的候选对选择器更友好。这个分叉让我意识到接口层不是万能的，它必须和源端、选择端联合诊断。

与论文实际路径的差异：我猜的路径是先怀疑选择器、再发现接口问题、然后做后处理，这和论文实际路径基本一致。但论文实际路径中有一个我一开始不会想到的关键设计：他们明确区分了 raw oracle coverage 和 selectable coverage，并用一个形式化的 coverage–conversion decomposition 来量化接口税。我猜的路径里没有这么早把形式化分解作为核心贡献，而是更偏向工程化的后处理。另外，论文实际路径中 MMLU-Pro 的负增益被当作 gap exposure 的证据，而不是方法的失败，这种把负面结果转化为诊断信号的思路，我猜的路径里没有预先设计。

4. 核心 intuition

把多候选推理想象成一个餐厅点餐系统。生成器是厨房，选择器是服务员，候选池是厨房做出来的一堆菜。oracle coverage 衡量的是厨房有没有做出客人点的菜。但服务员能不能把菜端给客人，还取决于菜是不是装盘完整、有没有按菜单上的编号标好、有没有混入不该有的杂物。

如果厨房做了一道味道正确的菜，但没装盘，或者装盘时把菜名写错了，或者盘子里混了刷锅水，服务员就可能不端这道菜，或者端错菜。CACC 相当于在厨房和服务员之间加了一个传菜口检查员：看到没装盘的菜就补装，看到菜名写错的就改成菜单编号，看到盘子里有杂物的就清掉。这个检查员不改变厨房的做菜方式，也不改变服务员的端菜规则，只保证送到服务员面前的菜是服务员能认出来的形态。

这个类比能对上机制：CCR 对应补装盘，即修复不完整候选；AMC 对应改菜名编号，即把答案模式对齐到 benchmark 锁定的格式；SCH 对应清杂物，即去掉选择器吸引噪声。selectable coverage 对应的是服务员真正能认出来的菜的比例，而不是厨房做出来的菜的比例。

5. 方法 pipeline 举例

编一个具体输入：MMLU-Pro 的一道多选题，问题是“Which of the following is a prime number?”，选项 A 是 13，B 是 15，C 是 21，D 是 27，gold 答案是 A。答案模式 m 是 choice_letter。

第一步，生成器 Qwen3-1.7B 采样 16 个候选，形成原始候选池 C0。假设其中 8 个候选被保留，它们的形态如下：候选 1 是“13 is prime because it has no divisors other than 1 and itself.”，没有选项字母；候选 2 是“Final answer: 13”，是数值模式；候选 3 是“The answer is A. 13 is prime.”，模式正确；候选 4 是“Let me think... 13 divided by 2 is 6.5, so”，推理中断；候选 5 是“Final answer: A”，正确但带 scaffold 残留；候选 6 是“B. 15 is not prime because 15 = 3 × 5”，错误；候选 7 是“A. 13”，正确且干净；候选 8 是“C. 21”，错误。

第二步，CACC 在线诊断。对每个候选计算诊断向量 φ(x, c, m)。候选 1 触发 AMC，因为它是数值答案但 benchmark 要求选项字母；候选 2 也触发 AMC；候选 3 通过；候选 4 触发 CCR，因为推理中断没有最终答案；候选 5 触发 SCH，因为有 scaffold 残留；候选 6、7、8 通过诊断。

第三步，应用冻结规则。CCR 对候选 4 做补全，调用生成器补出“Final answer: A. 13 is prime.”。AMC 对候选 1 和候选 2 做模式对齐，把它们改成“Final answer: A. 13 is prime.”和“Final answer: A”。SCH 对候选 5 做清洗，去掉 scaffold 残留，变成“Final answer: A”。

第四步，形成保留池 CK。原始候选和构造候选取并集，去重后按保留上限 8 个保留。假设最终保留池里有 8 个候选，其中 5 个是模式正确且干净的 A 候选。

第五步，固定选择器 S 对保留池打分。假设选择器是一个训练过的 verifier，对每个候选给出 yes/no 分数。多数投票或 verifier 选择得分最高的候选。最终选择器选中“Final answer: A”，parser 提取出 A，与 gold 匹配，最终正确。

中间结果总结：原始池中正确候选存在但多数不可选择，oracle coverage 可能已经满足，但 selectable coverage 低；经过 CACC 后，selectable coverage 上升，最终选择器能消费正确候选。

6. 核心数学推导

先解释符号。x 是输入问题，y_x 是 ground-truth 答案，m 是 benchmark 锁定的答案模式，比如 numeric 或 choice_letter。C0(x) 是生成器产生的原始候选池，包含 c1 到 cn 共 n 个候选。CK(x, m) 是经过候选构造层处理后的保留池，保留上限是 K。S 是固定选择器，parse_m 是 benchmark 特定的答案解析器。

第一个量是 oracle coverage，记作 A_oracle。它定义为数据集中所有样本里，保留池中至少存在一个候选能被 parser 解析出 ground-truth 答案的比例。公式是 A_oracle = (1/∣D∣) Σ I{∃c ∈ CK(x,m) : parse_m(c) = y_x}。这里 I{·} 是指示函数，条件成立时为 1，否则为 0。这个量只关心正确候选是否出现，不关心选择器能否选中它。

第二个量是 final accuracy，记作 A_final。它定义为选择器选中的候选被 parser 解析后等于 ground-truth 的比例。公式是 A_final = (1/∣D∣) Σ I{parse_m(S(x, CK)) = y_x}。

第三个量是条件转换率，记作 A_verifier∣oracle，缩写为 V∣O。它定义为在 oracle coverage 满足的条件下，选择器最终选对的概率。公式是 A_verifier∣oracle = Pr[parse_m(S(x, CK)) = y_x ∣ ∃c ∈ CK(x,m) : parse_m(c) = y_x]。

对于抽取式选择器，有一个精确恒等式：A_final = A_oracle × A_verifier∣oracle。这是因为最终正确要求池中至少有一个正确候选，且选择器在正确候选存在时选对它。这个分解把两种失败分开：A_oracle 低是 coverage failure，A_verifier∣oracle 低是 conversion failure。

接下来定义 selectable coverage。普通 oracle coverage 只要求正确候选可解析。selectable coverage 额外要求正确候选满足四个条件：语义正确 Correct(c, y_x)、可解析 Parseable(c, m)、答案模式匹配 ModeMatch(c, m)、干净无噪声 Clean(c)。定义 selectable-correct hit 事件 H_sel(CK, x, m) 为存在候选同时满足这四个条件。selectable oracle coverage 记作 A_sel_oracle = Pr[H_sel(CK, x, m) = 1]。

设 h = A_sel_oracle，q_1 = Pr[parse_m(S(x, CK)) = y_x ∣ H_sel = 1]，q_0 = Pr[parse_m(S(x, CK)) = y_x ∣ H_sel = 0]。由全概率公式得到 A_final = h·q_1 + (1-h)·q_0。设 r = (1-h)·q_0，A_sel_verifier∣oracle = q_1，则 A_oracle - A_final = (A_oracle - h) + h·(1 - q_1) - r。

这个公式在算什么：它把 oracle coverage 和 final accuracy 之间的差距拆成三部分。第一部分 A_oracle - h 是正确候选存在但不满足 selectable 条件的损失，即接口税的主体。第二部分 h·(1 - q_1) 是 selectable 正确候选存在但选择器仍然选错的损失。第三部分 r 是残差项，表示诊断谓词不完美时，被诊断拒绝的候选反而被选择器选对的情况。当 r = 0 时，selectable coverage 是 final accuracy 的上界。

7. 实验设计

数据集包括四个：GSM8K 和 competition_math 的 numeric 子集用于数值开放题；MMLU-Pro 和 GPQA Diamond 用于多选题。GSM8K 用 clean test 的 1319 题，competition_math 用 numeric 子集 3199 题，MMLU-Pro 用 test 的 12032 题，GPQA Diamond 用 198 题。另外还有 MMLU-Pro confirm-512 和 GPQA-128 用于第二家族配对恢复实验。

基线是 Base。但它不是一份统一的池子：数值任务上 Base 是原始 generate-then-rerank 池、不做接口处理；MMLU-Pro 上 Base 是只含 CCR 的 legacy 池、在 benchmark-locked MCQ reparse 下评分（原文：Base is a CCR-only legacy pool）。所以 MMLU-Pro 上 Base→CACC 的 −0.85pp 隔离的是 AMC+SCH 的边际作用，不能读成「整个接口层损害 final」。SP 是 proposer-side strengthening，用 Qwen3-8B 作为更强的 proposer，属于不同计算量级。CACC 是本文方法，CACC+SP 是组合。主生成器是 Qwen3-1.7B，固定选择器是一个在 GSM8K 训练集上微调的 Qwen3-1.7B verifier，没有在 MMLU-Pro 或 GPQA 上训练过。

指标有四个：oracle coverage、V∣O 条件转换率、final accuracy、以及 selectable coverage。核心分解是 Final = Oracle × V∣O。

消融包括：readout 路径消融，即 MMLU-Pro 从 numeric scoring 切换到 MCQ reparse；AMC 消融，即 MCQ reparse 到 CACC；SP 消融，即 CACC 到 CACC+SP；recovery 消融，即 CACC 到加 hygiene；rescue 消融，即 CACC+SP 到加 conversion-aware rescue；以及 Power Sampling × CACC 作为 coverage-pressure 诊断。

实验能否支撑结论：数值任务上，GSM8K 的 CACC 把 oracle 从 0.4882 提到 0.6391，final 从 0.2873 提到 0.3632；competition_math 的 oracle 从 0.3210 提到 0.4436，final 从 0.1519 提到 0.2579，支撑了 CCR 修复不完整候选能同时提升覆盖和最终准确率的结论。GPQA 上 CACC 把 final 从 0.0556 提到 0.1919，支撑了接口对齐在 MCQ 上更关键的结论。但 MMLU-Pro 上 CACC 把 oracle 从 0.4072 提到 0.4767，final 却从 0.2362 降到 0.2277，这个负增益被解释为 gap exposure，即接口修复暴露了 coverage–conversion gap，需要 SP 才能转化。这个解释有 SP 组合实验支撑，CACC+SP 把 final 提到 0.2936。

缺什么：缺少对选择器内部机制的更细粒度分析，比如为什么某些 selectable 正确候选仍然不被选择。缺少对自由形式生成任务的验证，论文自己也承认当前只覆盖 numeric 和 MCQ 两种答案模式。缺少对离线规则校准所需人工成本的量化，规则书是手工校准的，但论文没有报告校准需要多少审计案例和多少时间。

8. take-aways

• 在 GPQA Diamond 上，仅靠 CACC 接口层就能把 final accuracy 从 5.6% 提到 19.2%，绝对提升 13.6 个百分点，不需要重新训练生成器或选择器。
• 在 MMLU-Pro 上，把 scoring 从 numeric 切换到 benchmark-locked MCQ reparse，final accuracy 从 0.0096 跳到 0.2362，提升 22.66 个百分点，说明答案模式对齐本身就能挽回大部分接口损失。
• 在 GSM8K 上，CACC 把 oracle coverage 从 0.4882 提到 0.6391，提升 15.1 个百分点，同时 final 从 0.2873 提到 0.3632，提升 7.59 个百分点，说明数值任务的接口修复能同时改善覆盖和转换。
• 在 GSM8K 上，Power Sampling × CACC 把 oracle 从 0.6111 提到 0.7195，但 V∣O 从 0.5943 跌到 0.4700，final 从 0.3632 跌到 0.3381，说明在错误层做分布塑形会扩大 coverage–conversion gap。
• 在 MMLU-Pro confirm-512 上，CACC 加 hygiene 的配对恢复把 final 从 0.1992 提到 0.2246，McNemar p 值为 0.0072，说明第二家族生成器的接口兼容性可以通过规则迁移恢复。

9. 最脆弱的假设

最脆弱的假设是：selectable coverage 的诊断谓词，即 Correct(c, y_x) ∧ Parseable(c, m) ∧ ModeMatch(c, m) ∧ Clean(c)，能够准确区分哪些正确候选会被固定选择器消费。这个假设一倒，整个 coverage–conversion decomposition 的解释力就崩了，因为 h = A_sel_oracle 作为 final accuracy 上界的性质依赖于诊断谓词与选择器行为的一致性。

论文自己给出的证据是公式 11 中的残差项 r，它明确承认当 r ≠ 0 时，selectable coverage 不一定是上界。论文还报告了 MMLU-Pro 上 CACC 的负增益，即 oracle 上升但 final 下降，这本身就是诊断谓词不完美的表现。但论文没有直接验证诊断谓词与选择器行为的一致性程度，比如计算被诊断拒绝的候选中实际被选择器选对的比例。附录 G.6 的格式干预实验显示，仅改变 final-answer marker 就能翻转 9.89% 的 eligible selections，说明选择器对格式的敏感性很高，但这也意味着诊断谓词对 Clean 和 ModeMatch 的判断可能过于粗糙，无法捕捉选择器的全部偏好。

10. 一周最小复现

目标：复现 GPQA Diamond 上 CACC 的核心结论，即接口对齐能大幅提升 final accuracy。

步骤：第一天，准备环境，下载 Qwen3-1.7B 模型和 GPQA Diamond 的 198 题。用 Qwen3-1.7B 对每题采样 16 个候选，每个候选最多 128 个新 token，温度 0.7，top-p 0.95，保留 8 个候选。这构成 Base 池。第二天，实现三个规则模块：CCR 用正则匹配找不完整候选，调用生成器补全，每个补全最多 160 个新 token；AMC 用正则提取最终答案，如果是数值或选项文本，映射到 benchmark 要求的选项字母；SCH 用正则去掉 prompt 残留和重复 scaffold。第三天，实现一个简单的固定选择器，可以用多数投票或一个现成的 reward model，关键是 Base 和 CACC 用同一个选择器。第四天，跑 Base 和 CACC 的完整流程，记录 oracle coverage、V∣O 和 final accuracy。第五天，做消融，分别关掉 CCR、AMC、SCH，看各自贡献。第六天，做配对显著性检验，用 McNemar test 比较 Base 和 CACC 的 final accuracy。第七天，整理结果。

预期指标：Base 的 final accuracy 大约在 5% 到 6% 之间，CACC 的 final accuracy 应该能到 15% 以上。如果 CACC 的 final accuracy 不到 10%，说明 AMC 的规则实现有问题，因为 GPQA 上大部分损失来自答案模式不匹配。数据规模用全部 198 题即可，不需要更多。24GB 显卡足够跑 Qwen3-1.7B 的推理，不需要训练。

11. 反例设计

设计一个实验：如果成功，就能推翻本文的核心主张，即接口层是独立于生成器和选择器的可优化瓶颈。

实验设计：选一个生成器，它产生的候选池中正确候选的格式已经高度规范，比如用 constrained decoding 强制每个候选都以“Final answer: <LETTER>”结尾，且没有 scaffold 残留。然后在这个生成器上比较 Base 和 CACC。如果 CACC 在这种已经接口兼容的候选池上仍然显著提升 final accuracy，说明 CACC 的收益不是来自接口修复，而是来自其他机制，比如补全生成引入了额外的正确候选，或者去重改变了选择器的输入分布。这就会推翻“接口税是独立瓶颈”的主张，因为当接口已经干净时，CACC 不应该有额外收益。

判据：在 constrained decoding 生成器上，Base 的 selectable coverage 应该已经接近 raw oracle coverage，即接口税接近零。如果此时 CACC 的 final accuracy 仍然比 Base 高出超过 5 个百分点，且这个提升不能完全归因于补全生成带来的额外候选，那么本文的核心主张就被削弱。论文附录 G.3 实际上做了类似的 constrained decoding 对照，结果显示 CD 在 GPQA 上超过 CACC 6.57 个百分点，CD+CACC 相比 CD 没有提升 final accuracy，这在一定程度上支持了接口层的解释，但也说明当 constrained decoding 已经解决接口问题时，CACC 的边际价值消失。

12. 落地判断

能用于抢占式 GPU 自托管 27B 模型做多智能体脚手架，但需要改造。

怎么用：在多智能体系统中，27B 模型作为中心推理引擎，各 agent 产生的候选答案在汇总给最终选择器之前，先经过 CACC 接口层。具体做法是，为每个 agent 的输出定义答案模式合约，比如数值任务要求最终答案在 boxed 里，MCQ 任务要求输出选项字母。用一个轻量规则引擎做 CCR、AMC、SCH，规则引擎可以用正则和模板，不需要 GPU。补全生成可以复用 27B 模型本身，但只在检测到不完整候选时触发。

成本量级：规则引擎的 CPU 成本可以忽略。补全生成的成本取决于触发频率，假设 30% 的候选触发 CCR，每次补全 160 个 token，27B 模型在 24GB 显卡上的推理速度大约每秒 20 到 40 个 token，每个候选补全大约 4 到 8 秒。如果每个问题有 8 个候选，大约 2 到 3 个触发补全，额外耗时 10 到 25 秒。对于抢占式 GPU 场景，这个延迟可以接受，因为补全可以在 GPU 空闲时批量执行。

最大的坑：规则书是 benchmark 特定的，论文的规则书是针对 GSM8K、MMLU-Pro、GPQA 的 schema 手工校准的。在多智能体脚手架中，任务类型多样，答案模式不固定，规则书需要持续维护。如果 agent 输出的是自由形式文本或代码，当前的 CCR、AMC、SCH 规则无法直接迁移。另一个坑是选择器敏感性，论文附录 G.6 显示仅改变 final-answer marker 就能翻转 9.89% 的选择，说明规则引擎对格式的微调可能意外改变选择器行为。建议在部署前用一小批标注数据做格式敏感性审计，确认规则修改不会引入新的选择偏差。