数学推理验证器实测：精度提升显著，但覆盖率代价高昂

摘要：这项研究评估一种将模型数学解答改写为类型化证明步骤，再交由 LLM 审查器逐项认证或拒绝的验证管线。开放权重模型在 GPQA 和 AIME-2025 上获得更高答案匹配精度，但只处理约 35% 与 21% 的尝试；与输出 Token 匹配的 self-consistency 基线相比，汇总优势仅 4.8 个百分点，置信区间跨越零。结果还暴露出证明构造失败、外部模型认可率偏低以及缺少人工或形式化真值等问题，说明高精度筛选不等于可靠的形式证明验证。

---

核心结果

研究把数学解题器输出的答案重写为带有类型的证明步骤，再由 LLM 审查器逐项执行 certify-or-decline：证据足够则认证，否则拒绝。其目标不是提高解题器本身的生成能力，而是在已经生成的候选答案中筛出更可信的结果。

在强 GPQA 配置下，认证后的答案匹配精度提高 31 个百分点；在 AIME-2025 上提高 46 个百分点。代价是覆盖率极低：前者只回答约 35% 的尝试，后者只回答约 21%。这是一种典型的选择性预测系统，以少答换取更高精度，而不是无条件的准确率升级。

在接近性能上限的 MATH-500 子集上，验证器的增益最多只有 5 个百分点，却损失了 13—27 个百分点的覆盖率。换言之，当基础求解器已经足够强时，额外审查带来的边际价值明显下降。

与 Self-Consistency 的公平比较

研究使用输出 Token 数匹配的 self-consistency 选择器作为基线。该基线在相同覆盖率下达到 82.9% 精度，而验证器汇总精度为 87.6%，配对差异为 +4.8 个百分点，95% 置信区间为 [-8.2, 18.5]。

这个区间跨越零，因此不能据此断言验证器在统计意义上稳定优于 self-consistency。更严谨的结论是：验证器在一个较高绝对精度点上运行，但现有样本不足以证明它相对强选择基线的优势具有统计确定性。

工程上还需要注意，self-consistency 依赖多次采样和投票，通常要求保存多个候选、扩大推理计算并承担更长延迟；逐步验证则增加结构化改写、审查器调用和状态管理成本。两者不能只按精度比较，还应纳入 Token 消耗、首 Token 延迟、总吞吐、拒绝后的兜底策略以及答案覆盖率。

失败发生在评审之前

诊断样本揭示了一条容易被汇总指标掩盖的失败路径：在 88 道已经完成的问题中，有 52 道最终形成无效证明，甚至没有进入审查器阶段。

这意味着系统至少存在三类独立故障：

1. 执行失败：解题器或证明构造器无法生成合法步骤；
2. 选择失败：执行完成，但审查器拒绝或选错候选；
3. 验证失败：系统给出认证结论，但该结论与真实证明有效性并不一致。

若把这些阶段合并为单一准确率，就会把解析器故障、模型推理错误和评审器误判混为一谈。论文主张分别报告执行成功率、选中答案精度和独立评估的证明有效性，这一拆分比单独展示“认证通过率”更具诊断价值。

证明有效性仍未被真正验证

外部 LLM 对渲染后的“已认证证明链”的接受率为 61.0%—67.6%，显著低于 87.6% 的答案键匹配精度。两个数字衡量的是不同对象：前者反映外部模型是否认可证明文本，后者只确认最终答案是否与标准答案一致。

但即使外部 LLM 接受率更低，也仍不能证明某条证明无效。LLM 审查可能产生漏检、误检、位置偏差和模型家族偏袒。论文进一步指出，开放权重审查器之间经机会校正后的协议接近零，说明不同审查器几乎不一致。不过，协议衡量的是一致性，不是相对于数学真值的准确性；审查器一致地犯错，同样会得到高一致性。

此外，研究没有提供人工专家审查或 Lean、Coq 等形式化内核的 ground truth。因而，论文中的“certify”更接近“由 LLM 判定可接受”，不能等同于可机器检查的数学证明。

类型化步骤如何实现

该方法可抽象为三段式管线：

1. 求解器生成候选答案及其推导；
2. 改写器将自然语言推导转换为类型化步骤；
3. 审查器对每一步进行局部判断，并汇总为认证或拒绝。

类型化步骤的价值在于把自由文本评审转化为局部约束检查。例如，代数步骤可以检查等式是否成立，推导步骤可以检查前提是否被误用，结论步骤则检查是否真正蕴含目标。但它高度依赖形式化 schema 的覆盖范围：schema 未表达的推理模式会被迫降级为自然语言判断，而 schema 解析错误又可能在评审前直接造成执行失败。

相较直接把整段答案交给一个 LLM 审查，逐步结构化的潜在优势是错误定位更细、上下文更容易局部化，也能记录每一步的状态。代价是额外的解析成本、序列长度以及步骤间依赖传播。形式化系统通常要求全链条成立，而不是每一步分别看起来合理；因此局部认证若缺少依赖图和全局一致性检查，仍可能把相互矛盾但局部有效的步骤拼成“认证证明”。

部署建议

将此类管线用于数学推理服务时，建议采用分层策略，而不是把所有请求都送入完整验证链：

• 先以答案长度、Token 预算和基础求解器置信度做低成本门控；
• 对高价值、高风险或基础模型不确定的样本再执行证明改写与逐步认证；
• 为每道题保留 execution_status、selected_answer、proof_status 和 review_evidence 四类独立字段；
• 对拒绝样本保留明确的兜底路径，如重新采样、降级为普通答案或转交人工审查；
• 使用形式化内核或盲审专家建立真实标签，验证 LLM 审查器的误报与漏报；
• 在同等输出 Token 预算下，与 self-consistency、best-of-N 及形式化工具增强方法进行配对比较。

部署指标也应拆开：覆盖率、选择性风险、条件精度、每次成功答案成本、P95 延迟，以及认证证明的独立有效率。若系统只公布“已认证答案准确率”，却不披露覆盖率与真值来源，系统实际上无法判断它是否值得上线。

研究边界

这项工作的主要价值在于揭示验证型数学推理的真实运行条件：LLM 审查可以改善选择性预测，却不能在没有形式化或人工真值的情况下自动升级为可靠证明系统。 对开发者而言，它更适合作为高成本、低覆盖率的第二阶段筛选器，而不是默认替代基础求解器。

---

消息来源：ArXiv AI (cs.AI) (2026-11-13)

—— 完 ——

主题标签： #数学推理 关注 #LLM审查器 关注 #选择性预测 关注 #自一致性 关注 #证明验证 关注