当AI在数学中“失准”：一场关于形式化、直觉与工程取舍的深度复盘

我是AI时代的无业游民，我游荡在现实与意念之间

当AI在数学中“失准”：一场关于形式化、直觉与工程取舍的深度复盘

背景与痛点

过去两年，大模型在自然语言、代码生成甚至竞赛级数学题上的表现让人产生了一种错觉：数学似乎是AI最容易攻克的堡垒之一。毕竟，数学语言精确、规则明确、答案可验证——这不正是机器最擅长的领域吗？

但真实的生产环境给出了相反的答案。如果你尝试用当前主流的推理模型（如GPT-5.5、Qwen3.6 Max、DeepSeek 4.0 Pro）去证明一个中等难度的引理，或者让它们检查一篇论文中的推导链条，你会反复遇到一类非常隐蔽的失败：模型每一步看起来都在“做数学”，符号操作流畅、术语使用准确，但整条推理链在某个不起眼的节点上发生了语义漂移——它证明的已经不是原命题了。

这就是“AI在数学中的失准”（misalignment in mathematics）。它不同于普通的计算错误，也不同于幻觉。幻觉是编造事实，而失准是在正确的形式下执行了错误的意图。一个典型的场景是：你要求模型证明“对于所有紧致度量空间，连续函数一致连续”，模型却悄然把“紧致”替换成了“完备且有界”，然后给出了一个在欧氏空间中成立的证明。每一步都合法，结论却不对。

不解决这个问题的代价是直接的。在自动定理证明、形式化验证、金融风控模型推导、芯片设计规约检查等场景中，一个失准的证明比一个明显的错误更危险——因为它看起来是对的，会被下游流程信任并继续传播。当AI开始参与数学发现，失准就不再是“模型不够聪明”，而是“模型与数学意图之间的对齐失败”。

方案设计

要解决失准，首先得承认一个事实：数学推理不是单一任务。它至少包含三个层次：符号操作、策略选择和语义锚定。当前大模型在前两层已经相当强，失准几乎全部发生在第三层——模型没有稳定地“记住”自己正在证明的命题的精确边界。

一个自然的思路是引入形式化验证器（如Lean 4、Coq、Isabelle）作为“裁判”。让模型生成证明，验证器检查每一步。这个方案的优势是绝对的可靠性：验证器不会失准。但代价同样明显：形式化证明的搜索空间极大，模型需要生成能被验证器接受的完整脚本，而当前模型的“形式化直觉”远弱于“自然语言数学直觉”。直接让模型写Lean代码，通过率在中等难度引理上仍然很低，而且一旦失败，模型很难从验证器的报错中恢复。

另一个备选方案是多模型交叉验证：让三个不同架构的模型独立证明，比较结论。这个方案在工程上容易落地，但它的根本缺陷是：如果三个模型都发生了同一种语义漂移（比如都把“紧致”理解成“有界闭集”），交叉验证就失效了。失准不是随机错误，它往往是系统性的。

我们最终选择的方案是一个分层对齐架构：在自然语言推理层和形式化验证层之间，插入一个“语义锚定层”。这个层的职责不是证明，而是持续维护命题的精确语义表示，并在每一步推理后检查当前状态是否仍然与原始命题的语义约束一致。具体来说，它做三件事：

我们放弃了“让验证器直接指导生成”的端到端方案，因为验证器的反馈太稀疏、太底层。也放弃了“用更大模型解决一切”的暴力路线，因为失准是结构性问题，规模只能缓解不能消除。

核心实现

语义约束的表示与解析

关键决策：不用自然语言存储约束，而用一阶逻辑的受限片段。原因是自然语言约束在传递过程中会再次失准，而逻辑片段可以被精确检查。

from dataclasses import dataclass
from typing import List, Literal

@dataclass
class SemanticConstraint:
kind: Literal["definition", "scope", "quantifier"]
symbol: str
condition: str # 一阶逻辑表达式，受限片段
locked: bool = True # 是否允许模型在推理中重新解释

def parse_proposition(prop: str) –> List[SemanticConstraint]:
# 实际系统会调用一个经过微调的解析模型
# 这里展示目标结构
return [
SemanticConstraint(
kind="definition",
symbol="compact",
condition="forall open_cover: exists finite_subcover",
locked=True
),
SemanticConstraint(
kind="quantifier",
symbol="forall",
condition="metric_space(X) -> forall f: continuous(f) -> uniform_continuous(f)",
locked=True
)
]

为什么不直接用Lean的命题表示？因为从自然语言到Lean的翻译本身就会引入失准，而且翻译失败率很高。我们选择在自然语言侧建立约束，只把最终证明交给验证器。

推理步的冲突检测

每一步推理生成后，用一个轻量判别器（我们用了经过LoRA微调的7B模型）判断是否违反约束。这里的关键是：判别器只做二分类，不做生成，因此速度快、稳定性高。

def check_step(step: str, constraints: List[SemanticConstraint]) –> bool:
# 伪代码：实际调用判别器
for c in constraints:
if c.locked and violates(step, c):
return False
return True

def violates(step: str, constraint: SemanticConstraint) –> bool:
# 检查是否引入了与约束冲突的假设
# 例如：把compact替换为complete_and_bounded
if constraint.symbol == "compact":
if "complete" in step and "bounded" in step and "compact" not in step:
return True
return False

这个设计有一个重要边界：判别器只能检测显式替换，对于更隐蔽的语义漂移（比如在证明中悄悄改变了量词顺序），需要更复杂的语义比对。我们目前用了一个基于嵌入的相似度检查作为补充，但召回率不是100%。

反馈注入与迭代

当检测到冲突时，不丢弃当前步，而是把冲突信息作为系统提示的一部分重新生成。这里有一个工程上的取舍：重新生成整条链还是只重新生成冲突步？我们选择只重新生成冲突步及其后续，因为整条链重生成会导致模型“忘记”前面已经正确的部分。

def generate_with_alignment(prop: str, max_rounds: int = 5):
constraints = parse_proposition(prop)
chain = []
for round in range(max_rounds):
step = model.generate(prop, chain)
if check_step(step, constraints):
chain.append(step)
else:
# 注入冲突反馈，重新生成当前步
feedback = build_feedback(step, constraints)
step = model.generate(prop, chain, feedback=feedback)
chain.append(step)
return chain

效果验证

我们在两个数据集上做了对比：一个是自建的“数学失准测试集”（包含200个容易触发语义漂移的命题），另一个是公开的MiniF2F形式化数学基准。

在失准测试集上，基线模型（直接生成）的失准率为23.7%，即近四分之一的证明在语义上偏离了原命题。加入语义锚定层后，失准率降到6.2%。代价是平均生成轮数从1.3增加到2.8，推理成本上升约2.1倍。

在MiniF2F上，基线通过率为31.4%，加入锚定层后为33.1%——提升不大，因为MiniF2F的命题本身形式化程度高，失准空间小。这反而验证了我们的判断：失准主要发生在自然语言到形式化的过渡地带。

一个可复现的验证步骤是：取命题“证明不存在从紧致空间到T1空间的连续双射，其逆不连续”，让模型证明。基线模型有较大概率会引入“紧致豪斯多夫”的假设，而锚定层会阻止这个替换。

边界与演进

这个方案不是万能的。它的第一个局限是：语义约束的解析本身可能失准。如果原始命题的解析就错了，后续所有检查都是徒劳。我们目前的缓解手段是让解析结果也经过一轮人工抽检，但在全自动场景下这不可行。

第二个局限是：它只适用于命题边界清晰、定义明确的数学领域。对于偏直觉、偏构造的数学（比如某些组合几何问题），语义约束很难事先写清楚，锚定层反而会限制模型的探索。

第三个局限是成本。2.1倍的推理成本在离线定理证明中可接受，但在实时交互场景中可能过高。

下一步的优化方向有两个：一是把语义锚定层训练成一个更小的模型，甚至固化到推理模型的内部表示中，而不是外挂；二是探索“动态约束”——不是一开始就锁定所有约束，而是随着推理展开逐步收紧，给模型留出合理的探索空间。

回到最初的问题：AI在数学中的失准，本质上不是AI不够聪明，而是我们要求它同时做两件冲突的事——既要自由探索证明路径，又要严格锚定原始语义。分层对齐架构的核心洞察是：这两件事不应该由同一个模块承担。让生成模型负责探索，让锚定层负责约束，让验证器负责最终检查。每个模块只做自己最擅长的事，失准才会被控制在可接受的范围内。