你一定见过这类标题AI 又解出了一道数学难题AI 在奥赛级别的题目上超过了人类AI 数学推理再次取得突破。媒体通常把聚光灯打在“更强的模型”“更大的算力”“新的训练范式”上但最近这轮新闻里一个不太一样的信息成了传播点——一位高中辍学者被认为参与其中。这个细节为什么能成为新闻因为它击中了大家对数学的一种直觉数学是高度依赖学术训练、符号直觉和长期积累的领域一个没有走常规教育路径的人不应该在这个领域贡献出什么“突破性视角”。但如果你把这个新闻当励志故事看就错过了真正重要的技术信号。AI 数学能力的提升正在经历一次范式转变从“训练一个更聪明的模型让它一次答对”转向“在推理阶段给模型生成多条路径再用验证机制把不可靠的路径过滤掉”。一位非传统背景的参与者带来的往往不是更标准的解法而是一条不那么主流、但可能打破僵局的路径。这正是当前 AI 数学突破的核心隐喻。这篇文章不打算追逐人物故事而是要把“突破”翻译成开发者能看懂的技术机制。你会弄清楚三件事数学推理为什么一直是大模型最难啃的硬骨头这轮突破背后真正发生变化的四个技术点如果你想让 AI 在真实项目中做数学题、做逻辑推理应该怎么设计“生成 评估 验证”的闭环以及如何用代码快速跑通一个最小验证。文章后面的示例都不绑定特定厂商你只需要有一个可调用的推理模型接口就能跟着跑起来。1. 这篇博文真正要解决的问题先抛一个判断大模型在数学题上的进步很大程度上不是“记住了更多题”而是“学会了在推理阶段花更多时间去换正确率”。传统的大模型使用方式是一次前向传播输入问题输出答案。对于开放性文本生成这种方式足够自然但对数学这种强逻辑、弱歧义的领域一次生成就是一次赌博。模型可能在前三步完全正确第四步出现符号错误之后所有步骤全部跑偏。你没有办法单靠“再多问一次”来保证下一次一定对。很多关注 AI 数学进展的人会陷入两种误区误区一数学突破只属于微软、OpenAI、DeepMind 这类大厂普通开发者只能看新闻。误区二所谓突破就是把模型参数变大、训练数据变多然后基准分更高了。这两种理解都不能指导真实工作。一个做 AI Agent 的开发者真正需要的是模型在数学场景下如何从一次生成变成多次生成如何判断哪条解题路径是对的验证环节应该放在哪里成本控制在什么范围这篇文章要解决的问题就是把“新闻里的数学突破”拆成可以落地的方法论。你会看到一个清晰的闭环多样化生成候选路径 → 用投票或规则做初筛 → 用验证器做深度评估 → 在关键场景用形式化工具做最终确认。这套流程不只在数学题上有价值在代码生成、逻辑推理、Agent 规划等所有“对错可判”的任务里都同样适用。2. 基础概念与核心原理2.1 数学突破的三个层次先说清楚“AI 数学突破”到底突破了什么。如果只看基准测试分数很难理解技术变化的本质。更务实的观察维度有三个多步推理的稳定性模型能不能连续执行 10 步以上无差错推理而不是前几步正确、后几步崩盘。解法路径的多样性同一个问题模型能不能给出与标准答案不同但同样正确的路径。这代表模型不是在背题而是在理解结构。结论的可验证性模型得出的结论能不能被独立机制验证而不仅仅依赖模型自己的信心。传统模型在前两项上都很弱。它擅长模式匹配而数学需要的恰好是链条式的精确传递每一步都必须建立在上一部严格成立的基础上。一旦链条变长小概率错误就会累积最终表现为“前面很合理最后答案错了”。2.2 从训练时扩展走向推理时扩展这一轮 AI 数学进步里最值得关注的技术变量是“计算资源从训练阶段向推理阶段迁移”。过去几年模型能力提升主要靠训练时扩展更多的数据、更大的参数量、更长的训练步数。这套逻辑的天花板非常明显——训练一次大模型的成本是千万美元级别只有少数机构能持续跟进。现在越来越多的推理模型采用另一种思路在推理阶段允许模型生成更多内容、尝试更多路径用推理时的计算量换取更高的正确率。这就是常说的 test-time compute或者“推理时扩展”。一个直观的类比是考试。传统模型像“闭卷、一次作答写完就交卷”推理时扩展则像“允许你打草稿、尝试多种解法、检查后再交卷”。同样水平的学生后者的正确率一定更高。这个转变对普通开发者的意义很大你不需要训练一个模型也可以借用推理时扩展的思想来提升效果。最简单的方式就是接下来要讲的 Best-of-N 采样。2.3 为什么需要验证器多样生成只是第一步。让模型生成 10 条解题路径里面可能只有 3 条正确。你需要一个机制来区分哪些路径值得相信。这个机制就是验证器。它可以是朴素的规则检查比较最终结果与标准答案是否一致启发式评估检查解题过程中是否出现了关键公式、关键步骤模型验证器用另一个 LLM或者同一个 LLM 扮演“批改老师”判断解答过程是否逻辑完整确定性验证器用计算器、符号计算库重算关键步骤或使用形式化证明工具确认结论。验证器解决的核心问题是“撤销模型的自信”。大模型在生成答案时往往表现出极高的确定性即使答案完全错误语气也和正确答案一样肯定。没有外部验证你很难识别错误。2.4 形式化验证从“看似正确”到“机器可证明”数学领域还有一个更严格的验证方式形式化验证。普通验证器看到的是自然语言模型可能会给出语法正确的错误推理。形式化验证则要求把“推理”变成机器可检查的符号步骤每一步都由规则系统确认。Lean 是目前数学界关注度很高的形式化证明工具它把数学证明变成类似代码的文本由编译器逐行检查。我下面会给出一个极简的 Lean 示例让你感受一下“机器检查证明”和“大模型写解答”之间的区别。你会第一次直观地感受到数学证明本质上是一种可编译的程序。对比维度训练时扩展推理时扩展主要成本训练算力推理算力提升方式数据更多、模型更大路径更多、验证更强面向者模型训练团队应用开发者对单次推理的假设一次生成即最优多次生成后择优最佳实践训练专用推理模型采样 投票 验证3. 真正的关键路径多样性而不是更聪明的单次推理3.1 高中辍学者的隐喻价值关于“高中辍学者帮助 AI 数学突破”这类新闻大家最容易忽略的一点是他带来的可能不是更完善的数学知识而是一个不容易被学术训练框住的视角。数学史上很多重要的突破确实来自“非标准”路径。但要小心这不等于“不学数学就能做数学”。更准确的理解是解题路径的多样性本身就是一种稀缺资源。当所有人都按标准方法推导时问题可能卡在某一步无法跨越而一个非常规视角可能间接推动突破。如果你去观察当前 AI 数学模型的训练方式会发现极其类似的现象。模型需要被鼓励去探索不同的解题路径而不是每一个样本都输出最热门的解法。3.2 多路径采样是在模拟多种解题人格假设你现在用大模型解一道几何题。temperature 设为 0模型会输出概率最高的一条路径大多数情况下是标准解法。如果这道题恰好需要非常规辅助线标准解法可能直接失败。把 temperature 设置到 0.7 或 0.8连续采样 8 到 16 次模型可能产生完全不同的辅助线思路。有的路径完全错误有的路径不够简洁但其中一条可能就绕开了常规思路中的死胡同。换句话说采样不是让模型“猜更多次”而是让模型试着模拟多个不同倾向的解题者。之后的问题就是如何从这些路径中挑出最好的那条。3.3 保留非标准路径的价值很多开发者在做数学评测时会犯一个错误只比较最终答案然后丢弃所有错误路径。这在工程上省事却损失了宝贵的信号。正确的做法是把路径保留下来因为错误路径可以反过来定位模型的薄弱环节多条路径之间可以互相验证非标准路径虽然当前失败但经过针对性修正可能成为未来数据增强的素材。在自训练范式中这种“保留下所有尝试”的做法尤其重要。一些高水平的数学推理数据不是教科书里抄来的而是在大量失败路径的对比中挑出了那条最终成功的非常规路径。4. 核心流程拆解生成、评估、验证三步闭环如果让你设计一个“AI 数学解题系统”不要一上来就接一个最强模型然后期望它一次答对。更稳妥的架构是下面这个三步闭环。4.1 第一步多样化解题轨迹生成输入一道数学题后不止调用一次模型而是用多个采样参数生成多条候选解答。关键变量包括temperature控制随机性。数学题建议从 0.7 开始尝试而不是一直用 0。top_p控制候选 token 的累积概率范围和 temperature 搭配使用。n采样的候选数量。固定预算下n 越大越可能找到非标准路径但成本线性增长。系统提示词可以设计多套提示词让模型分别尝试“代数法”“几何法”“反证法”等不同倾向模拟不同解题风格。4.2 第二步候选答案评估与去重有了 N 条解答先做轻量级筛选提取每条的最终答案字段做答案归一化去掉空格、小数点和符号差异做多数投票。如果 8 条里有 6 条答案一致这个一致答案的置信度比单次生成高得多对答案一致的解答再做过程去重避免同一条路径反复出现而主导投票。多数投票是一种无需训练、成本极低的验证器。它对符号推理类的“有确定答案”的任务尤其有效。4.3 第三步验证与形式化确认多数投票只能证明“多条路径收敛到同一个答案”不能证明答案正确。对于高风险场景还需要更强的验证把解题过程重新输入给验证模型让它扮演严格批改老师检查逻辑漏洞如果题目属于代数计算、方程求解等适合计算机重算的类型用符号计算库直接重算关键结果在最高要求场景下用 Lean 等工具把结论形式化让机器从公理出发检查整个推理链。这三步的成本差别很大可以按场景灵活选择。日常实验跑一遍三步闭环大多数时候只需要前两步就足够得出结论。5. 完整示例一Best-of-N 采样提升数学题正确率下面用一个最小 Python 示例演示前面说的“多样生成 多数投票”闭环。代码里不绑定具体厂商模型你只需要把自己的推理接口替换到call_llm函数里即可。5.1 核心逻辑先把问题抽象成三个环节generate_solutions调用模型 N 次得到 N 条候选解答extract_answer从每条解答中用正则提取最终答案majority_vote统计出现次数最多的答案并输出投票分布。5.2 代码实现# 文件路径math_breakthrough_demo.py import re from collections import Counter def call_llm(prompt: str, temperature: float 0.7) - str: 调用你的推理模型接口返回模型生成的解答文本。 这里只是一个占位实现实际项目中请替换为你的模型调用。 # response your_model_client.chat( # modelyour-reasoning-model, # messages[{role: user, content: prompt}], # temperaturetemperature, # ) # return response.text raise NotImplementedError(请替换为真实的模型调用接口) def generate_solutions(question: str, n: int 8, temperature: float 0.8) - list[str]: 多次采样生成多条候选解题轨迹。 solutions [] for _ in range(n): prompt f请解下面这道数学题并给出详细推理步骤\n{question}\n最终的答案请以答案:开头。 solutions.append(call_llm(prompt, temperaturetemperature)) return solutions def extract_answer(text: str) - str: 从解答文本中提取最终答案。 这里假设模型按答案:的格式输出可以做简单归一化。 match re.search(r答案[:]\s*(.), text) if not match: return raw match.group(1).strip() # 去掉常见干扰字符便于投票时对齐 normalized raw.replace(,, ).replace(, ).strip() return normalized def majority_vote(solutions: list[str]): 对多条解答的最终答案做多数投票。 返回得票最高的答案、完整投票分布、有效解答数量。 votes Counter() for sol in solutions: answer extract_answer(sol) if answer: votes[answer] 1 if not votes: return None, {}, 0 best_answer max(votes, keyvotes.get) return best_answer, dict(votes), sum(votes.values())5.3 使用示例下面是一段调用示例用FakeLLM模拟一个虚构模型方便你在本地直接验证框架逻辑# 文件路径math_demo_with_fake.py import random from math_breakthrough_demo import generate_solutions, majority_vote class FakeLLM: 模拟一个以一定概率答对的模型用于本地验证框架逻辑。 def __init__(self, correct_rate: float 0.6): self.correct_rate correct_rate def __call__(self, prompt: str, temperature: float 0.8) - str: if random.random() self.correct_rate: return 设未知数为 x逐步解方程。\n答案: 42 return 设未知数为 x尝试错误路径。\n答案: 43 fake_llm FakeLLM(correct_rate0.6) # 注意这里需要把 generate_solutions 中的 call_llm 替换为 fake_llm # 为方便演示这里手写采样循环 def demo_with_fake(question: str, n: int 8): solutions [fake_llm(question, temperature0.8) for _ in range(n)] best_answer, votes, valid_count majority_vote(solutions) print(f问题: {question}) print(f采样次数: {n}) print(f投票结果: {votes}) print(f最终答案: {best_answer}) print(f有效解答数: {valid_count}) if __name__ __main__: demo_with_fake(求解某个一元一次方程答案是多少, n8)5.4 这个示例能说明什么这个框架的核心价值是它会稳定提升正确率。如果一个模型单次答对的概率只有 60%那么 8 次采样后多数投票选到正确答案的概率会显著高于 60%。原因很简单只要错误路径不是系统性偏向同一个错误答案错误投票就会被分散。真正的推理模型替换掉call_llm之后你会观察到类似效果只是提升幅度取决于模型本身的基准能力。这也解释了为什么当前推理模型在数学任务上常常需要“多跑几次再投票”而不是依赖一次输出的直觉。6. 完整示例二基于规则的验证器与 LLM Judge多数投票只能处理“有确定答案”的题目。遇到开放题、证明题或者需要检查过程正确性时还需要验证器。6.1 基于规则的验证器一个最简单的验证器是检查解题过程中是否出现了关键步骤。虽然粗糙但成本极低适合做第一层过滤。# 文件路径rule_validator.py KEY_STEPS { 代数方程: [设, 移项, 合并同类项, 解得], 几何证明: [因为, 所以, 由题意, 同理], 数列: [公差, 首项, 通项, 和], } def rule_validate(text: str, topic: str 代数方程) - bool: 检查解题文本是否包含该主题的关键步骤词。 steps KEY_STEPS.get(topic, []) hit_count sum(1 for step in steps if step in text) # 阈值按需调整这里要求至少命中一半以上关键步骤 return hit_count max(1, len(steps) // 2) if __name__ __main__: sample 设未知数为 x移项合并同类项解得 x 42。 print(是否通过规则验证:, rule_validate(sample, topic代数方程))这个验证器的问题在于它只能做表面检查关键步骤存在不代表步骤顺序正确也不代表逻辑成立。所以它只能作为初筛不能作为最终结论。6.2 基于提示词的验证器更实用的验证器是让另一个模型扮演“批改老师”。它需要看完整条推理链给出打分和错误点。为了避免“让模型批改自己”的偏差可以设计更严格的验证提示词。# 文件路径llm_judge_prompt.py VERIFY_PROMPT 你是一名严格的数学竞赛阅卷老师。请判断下面的解题过程是否逻辑正确。 要求 1. 检查每一步推导是否严格成立。 2. 如果发现错误指出错误发生的具体步骤。 3. 不要因为最终答案正确就忽略过程错误。 4. 最后输出格式为 正确性: 正确 / 错误 理由: 具体理由 问题 {question} 解题过程 {solution} def build_verify_prompt(question: str, solution: str) - str: return VERIFY_PROMPT.format(questionquestion, solutionsolution)实际使用时你可以把build_verify_prompt的输出发给模型然后解析“正确性”字段。关键点在于提示词中的“不要因为最终答案正确就忽略过程错误”这会显著降低“只看结果不看过程”的误判。6.3 示例三形式化验证的最小演示如果说前两个验证器解决“大概率正确”那么形式化验证要解决“机器可证明”。Lean 是一种形式化证明工具。下面这段代码证明了一个简单的算术命题每一行都由机器检查-- 文件路径MinimalProof.lean example : 2 3 5 : by norm_num在这个例子里norm_num是一个自动化策略它从自然数的定义出发逐步证明 2 3 确实等于 5。看起来简单但它代表的是完全不同的验证范式模型凭直觉生成的解答在形式上被编译成了可以逐行检验的证明脚本。在实际 AI 数学研究中这种形式化验证极其昂贵通常只在最高风险场景使用。但对开发者来说理解这一点就够了分级验证体系中形式化验证是最终防线它不依赖模型的语气是否自信只依赖符号规则是否成立。7. 运行结果与效果验证7.1 如何跑通建议你按这样的顺序在本机运行# 1. 先用假模型跑通框架 python math_demo_with_fake.py # 2. 测试规则验证器 python rule_validator.py预期输出大致如下问题: 求解某个一元一次方程答案是多少 采样次数: 8 投票结果: {42: 6, 43: 2} 最终答案: 42 有效解答数: 8如果FakeLLM的正确率设置为 0.68 次采样后正确结果 42 通常能获得多数票。这个输出可以给你直接观感单次生成可能出错但多数投票会拉高整体正确率。7.2 如何判断有效性不要只看“最终答案是不是对了”。一个可靠的数学推理方案应该同时满足正确率提升多次采样 投票的正确率要高于单次生成的正确率。投票分歧可控多次采样后有效答案不应该过度分散。如果 8 次采样产生了 7 个不同答案说明模型本身的基础推理能力不足或者 temperature 设置过高。验证器能发现错误你可以人为构造一个“答案为 42、过程错误”的解答看验证器是否能识别出来。如果验证器也给了高分就需要优化验证提示词。7.3 失败时看哪里如果跑出来的结果不符合预期按这个顺序排查先确认call_llm是否真的被替换成了你的模型接口打印原始解答文本检查答案:的格式是否被正确提取检查extract_answer的正则是否适配你的模型输出格式检查温度设置如果答案五花八门降低 temperature如果多条解答完全一致但结果是错的提高 temperature 或增加采样次数。8. 常见问题与排查思路问题现象可能原因排查方式解决方案多次采样后答案仍然五花八门temperature 过高或模型推理能力不足打印所有轨迹人工随机检查 3 到 5 条降低 temperature 至 0.5 左右或更换推理能力更强的模型多数投票选出了错误答案错误路径存在系统性偏差分析投票分布检查错误答案是否集中在同一类错误引入独立验证器不能只依赖投票尝试用不同提示词风格采样验证器总是给错误过程打高分验证提示词过松或模型自身推理能力弱用人工标注的反例测试验证器强化提示词要求指出具体错误步骤必要时使用更强的验证模型同一道题多次调用成本过高采样次数过多统计正确率随 n 的变化曲线根据预算选择 n通常 4 到 8 次是性价比不错的区间正则提取不到“答案:”字段模型没有按提示词的格式输出打印原始解答文本检查格式在提示词中强调固定输出格式或扩展正则匹配规则数学题里混入恶意指令题目文本被做成了提示词注入检查输入内容是否有可执行指令对输入做清洗把题目文本和指令分离不在未隔离环境执行9. 最佳实践与工程建议9.1 验证分级设计不是所有场景都需要三步全跑。建议按风险分级L0 轻量级多数投票 答案归一化。适合做批量筛选、大规模数据清洗成本极低。L1 标准级投票之后加一层 LLM Judge检查解题过程是否逻辑一致。适合日常评测和 Agent 工具链。L2 严格级在 L1 基础上对关键题目用符号计算或 Lean 做形式化验证。适合高风险的决策场景比如金融计算、学术结果复核。关键原则先跑低成本方案再对低置信结果升级验证级别。不要一开始就对所有请求启用形式化验证成本会让你寸步难行。9.2 成本控制采样 投票的本质是用推理成本换正确率。实际项目里可以有这些优化先让小模型做一次初步解答如果置信度高直接输出如果初始答案与历史相似问题的正确分布有明显差异才触发多路径采样多个问题批量发送利用缓存避免重复调用对采样结果做去重后再调用验证器避免同一路径重复产生费用。9.3 工程与安全边界把“AI 数学解题”放进生产系统时有几个容易被忽略的点输入的数据里可能嵌套了可执行代码或恶意指令数学题文本也必须当作不可信内容处理不要把大模型当作计算器涉及金额、数量等关键数值时用符号计算库或真实计算器交叉验证日志要保留完整的原始解答轨迹出现事故时才能回溯是哪一步路径导致的错误增加超时控制多次采样的整体耗时会显著大于单次推理必须有异步或超时兜底。9.4 团队指标的设定如果你的团队要评估一个模型适不适合做数学推理类 Agent不要只看一道题的通过率。建议建立三个指标单次首答正确率代表模型的基线能力多路径采样后正确率代表模型在推理时扩展下的能力上限验证器识别错误率代表验证环节是否可靠。这三个指标分别对应“模型行不行”“方法行不行”“工程行不行”缺一不可。10. 总结与后续学习方向把这篇文章的技术主线收拢一下核心判断只有一句话AI 数学突破不只是模型变强了更是推理范式从“一次生成”转向了“生成多条路径 验证机制把关”。高中辍学者的故事真正折射的是路径多样性在数学发现中的价值而这种多样性现在被编码进了采样、投票、验证的技术框架里。作为开发者你不需要拥有训练大模型的能力也能参与这条主线。从替换call_llm、跑通投票闭环开始到引入 LLM Judge、再到研究 Lean 形式化证明这条路径是一层层递进的。后续值得继续深入的方向包括学习 Lean 和形式化数学了解“机器可证明”的边界在哪里关注自训练和推理轨迹数据增强看模型如何从失败路径中学习研究树搜索类推理方法它比简单的 Best-of-N 采样更能处理需要决策分支的复杂数学题在你的 Agent 工作流中把“数学验证”注册成一个独立工具而不是让模型自己负责生成和验证。建议你把文章中的三个示例代码保存下来先跑通框架再逐步替换成自己的模型和真实题目。数学推理问题虽然看起来离业务很远但它几乎是检验大模型逻辑能力的标准试金石。能把这类任务在工程上做稳定你的 Agent 在处理其他确定性较高的任务时也会更可靠。 AI数学推理突破：多路径生成与验证机制取代单次推理
你一定见过这类标题AI 又解出了一道数学难题AI 在奥赛级别的题目上超过了人类AI 数学推理再次取得突破。媒体通常把聚光灯打在“更强的模型”“更大的算力”“新的训练范式”上但最近这轮新闻里一个不太一样的信息成了传播点——一位高中辍学者被认为参与其中。这个细节为什么能成为新闻因为它击中了大家对数学的一种直觉数学是高度依赖学术训练、符号直觉和长期积累的领域一个没有走常规教育路径的人不应该在这个领域贡献出什么“突破性视角”。但如果你把这个新闻当励志故事看就错过了真正重要的技术信号。AI 数学能力的提升正在经历一次范式转变从“训练一个更聪明的模型让它一次答对”转向“在推理阶段给模型生成多条路径再用验证机制把不可靠的路径过滤掉”。一位非传统背景的参与者带来的往往不是更标准的解法而是一条不那么主流、但可能打破僵局的路径。这正是当前 AI 数学突破的核心隐喻。这篇文章不打算追逐人物故事而是要把“突破”翻译成开发者能看懂的技术机制。你会弄清楚三件事数学推理为什么一直是大模型最难啃的硬骨头这轮突破背后真正发生变化的四个技术点如果你想让 AI 在真实项目中做数学题、做逻辑推理应该怎么设计“生成 评估 验证”的闭环以及如何用代码快速跑通一个最小验证。文章后面的示例都不绑定特定厂商你只需要有一个可调用的推理模型接口就能跟着跑起来。1. 这篇博文真正要解决的问题先抛一个判断大模型在数学题上的进步很大程度上不是“记住了更多题”而是“学会了在推理阶段花更多时间去换正确率”。传统的大模型使用方式是一次前向传播输入问题输出答案。对于开放性文本生成这种方式足够自然但对数学这种强逻辑、弱歧义的领域一次生成就是一次赌博。模型可能在前三步完全正确第四步出现符号错误之后所有步骤全部跑偏。你没有办法单靠“再多问一次”来保证下一次一定对。很多关注 AI 数学进展的人会陷入两种误区误区一数学突破只属于微软、OpenAI、DeepMind 这类大厂普通开发者只能看新闻。误区二所谓突破就是把模型参数变大、训练数据变多然后基准分更高了。这两种理解都不能指导真实工作。一个做 AI Agent 的开发者真正需要的是模型在数学场景下如何从一次生成变成多次生成如何判断哪条解题路径是对的验证环节应该放在哪里成本控制在什么范围这篇文章要解决的问题就是把“新闻里的数学突破”拆成可以落地的方法论。你会看到一个清晰的闭环多样化生成候选路径 → 用投票或规则做初筛 → 用验证器做深度评估 → 在关键场景用形式化工具做最终确认。这套流程不只在数学题上有价值在代码生成、逻辑推理、Agent 规划等所有“对错可判”的任务里都同样适用。2. 基础概念与核心原理2.1 数学突破的三个层次先说清楚“AI 数学突破”到底突破了什么。如果只看基准测试分数很难理解技术变化的本质。更务实的观察维度有三个多步推理的稳定性模型能不能连续执行 10 步以上无差错推理而不是前几步正确、后几步崩盘。解法路径的多样性同一个问题模型能不能给出与标准答案不同但同样正确的路径。这代表模型不是在背题而是在理解结构。结论的可验证性模型得出的结论能不能被独立机制验证而不仅仅依赖模型自己的信心。传统模型在前两项上都很弱。它擅长模式匹配而数学需要的恰好是链条式的精确传递每一步都必须建立在上一部严格成立的基础上。一旦链条变长小概率错误就会累积最终表现为“前面很合理最后答案错了”。2.2 从训练时扩展走向推理时扩展这一轮 AI 数学进步里最值得关注的技术变量是“计算资源从训练阶段向推理阶段迁移”。过去几年模型能力提升主要靠训练时扩展更多的数据、更大的参数量、更长的训练步数。这套逻辑的天花板非常明显——训练一次大模型的成本是千万美元级别只有少数机构能持续跟进。现在越来越多的推理模型采用另一种思路在推理阶段允许模型生成更多内容、尝试更多路径用推理时的计算量换取更高的正确率。这就是常说的 test-time compute或者“推理时扩展”。一个直观的类比是考试。传统模型像“闭卷、一次作答写完就交卷”推理时扩展则像“允许你打草稿、尝试多种解法、检查后再交卷”。同样水平的学生后者的正确率一定更高。这个转变对普通开发者的意义很大你不需要训练一个模型也可以借用推理时扩展的思想来提升效果。最简单的方式就是接下来要讲的 Best-of-N 采样。2.3 为什么需要验证器多样生成只是第一步。让模型生成 10 条解题路径里面可能只有 3 条正确。你需要一个机制来区分哪些路径值得相信。这个机制就是验证器。它可以是朴素的规则检查比较最终结果与标准答案是否一致启发式评估检查解题过程中是否出现了关键公式、关键步骤模型验证器用另一个 LLM或者同一个 LLM 扮演“批改老师”判断解答过程是否逻辑完整确定性验证器用计算器、符号计算库重算关键步骤或使用形式化证明工具确认结论。验证器解决的核心问题是“撤销模型的自信”。大模型在生成答案时往往表现出极高的确定性即使答案完全错误语气也和正确答案一样肯定。没有外部验证你很难识别错误。2.4 形式化验证从“看似正确”到“机器可证明”数学领域还有一个更严格的验证方式形式化验证。普通验证器看到的是自然语言模型可能会给出语法正确的错误推理。形式化验证则要求把“推理”变成机器可检查的符号步骤每一步都由规则系统确认。Lean 是目前数学界关注度很高的形式化证明工具它把数学证明变成类似代码的文本由编译器逐行检查。我下面会给出一个极简的 Lean 示例让你感受一下“机器检查证明”和“大模型写解答”之间的区别。你会第一次直观地感受到数学证明本质上是一种可编译的程序。对比维度训练时扩展推理时扩展主要成本训练算力推理算力提升方式数据更多、模型更大路径更多、验证更强面向者模型训练团队应用开发者对单次推理的假设一次生成即最优多次生成后择优最佳实践训练专用推理模型采样 投票 验证3. 真正的关键路径多样性而不是更聪明的单次推理3.1 高中辍学者的隐喻价值关于“高中辍学者帮助 AI 数学突破”这类新闻大家最容易忽略的一点是他带来的可能不是更完善的数学知识而是一个不容易被学术训练框住的视角。数学史上很多重要的突破确实来自“非标准”路径。但要小心这不等于“不学数学就能做数学”。更准确的理解是解题路径的多样性本身就是一种稀缺资源。当所有人都按标准方法推导时问题可能卡在某一步无法跨越而一个非常规视角可能间接推动突破。如果你去观察当前 AI 数学模型的训练方式会发现极其类似的现象。模型需要被鼓励去探索不同的解题路径而不是每一个样本都输出最热门的解法。3.2 多路径采样是在模拟多种解题人格假设你现在用大模型解一道几何题。temperature 设为 0模型会输出概率最高的一条路径大多数情况下是标准解法。如果这道题恰好需要非常规辅助线标准解法可能直接失败。把 temperature 设置到 0.7 或 0.8连续采样 8 到 16 次模型可能产生完全不同的辅助线思路。有的路径完全错误有的路径不够简洁但其中一条可能就绕开了常规思路中的死胡同。换句话说采样不是让模型“猜更多次”而是让模型试着模拟多个不同倾向的解题者。之后的问题就是如何从这些路径中挑出最好的那条。3.3 保留非标准路径的价值很多开发者在做数学评测时会犯一个错误只比较最终答案然后丢弃所有错误路径。这在工程上省事却损失了宝贵的信号。正确的做法是把路径保留下来因为错误路径可以反过来定位模型的薄弱环节多条路径之间可以互相验证非标准路径虽然当前失败但经过针对性修正可能成为未来数据增强的素材。在自训练范式中这种“保留下所有尝试”的做法尤其重要。一些高水平的数学推理数据不是教科书里抄来的而是在大量失败路径的对比中挑出了那条最终成功的非常规路径。4. 核心流程拆解生成、评估、验证三步闭环如果让你设计一个“AI 数学解题系统”不要一上来就接一个最强模型然后期望它一次答对。更稳妥的架构是下面这个三步闭环。4.1 第一步多样化解题轨迹生成输入一道数学题后不止调用一次模型而是用多个采样参数生成多条候选解答。关键变量包括temperature控制随机性。数学题建议从 0.7 开始尝试而不是一直用 0。top_p控制候选 token 的累积概率范围和 temperature 搭配使用。n采样的候选数量。固定预算下n 越大越可能找到非标准路径但成本线性增长。系统提示词可以设计多套提示词让模型分别尝试“代数法”“几何法”“反证法”等不同倾向模拟不同解题风格。4.2 第二步候选答案评估与去重有了 N 条解答先做轻量级筛选提取每条的最终答案字段做答案归一化去掉空格、小数点和符号差异做多数投票。如果 8 条里有 6 条答案一致这个一致答案的置信度比单次生成高得多对答案一致的解答再做过程去重避免同一条路径反复出现而主导投票。多数投票是一种无需训练、成本极低的验证器。它对符号推理类的“有确定答案”的任务尤其有效。4.3 第三步验证与形式化确认多数投票只能证明“多条路径收敛到同一个答案”不能证明答案正确。对于高风险场景还需要更强的验证把解题过程重新输入给验证模型让它扮演严格批改老师检查逻辑漏洞如果题目属于代数计算、方程求解等适合计算机重算的类型用符号计算库直接重算关键结果在最高要求场景下用 Lean 等工具把结论形式化让机器从公理出发检查整个推理链。这三步的成本差别很大可以按场景灵活选择。日常实验跑一遍三步闭环大多数时候只需要前两步就足够得出结论。5. 完整示例一Best-of-N 采样提升数学题正确率下面用一个最小 Python 示例演示前面说的“多样生成 多数投票”闭环。代码里不绑定具体厂商模型你只需要把自己的推理接口替换到call_llm函数里即可。5.1 核心逻辑先把问题抽象成三个环节generate_solutions调用模型 N 次得到 N 条候选解答extract_answer从每条解答中用正则提取最终答案majority_vote统计出现次数最多的答案并输出投票分布。5.2 代码实现# 文件路径math_breakthrough_demo.py import re from collections import Counter def call_llm(prompt: str, temperature: float 0.7) - str: 调用你的推理模型接口返回模型生成的解答文本。 这里只是一个占位实现实际项目中请替换为你的模型调用。 # response your_model_client.chat( # modelyour-reasoning-model, # messages[{role: user, content: prompt}], # temperaturetemperature, # ) # return response.text raise NotImplementedError(请替换为真实的模型调用接口) def generate_solutions(question: str, n: int 8, temperature: float 0.8) - list[str]: 多次采样生成多条候选解题轨迹。 solutions [] for _ in range(n): prompt f请解下面这道数学题并给出详细推理步骤\n{question}\n最终的答案请以答案:开头。 solutions.append(call_llm(prompt, temperaturetemperature)) return solutions def extract_answer(text: str) - str: 从解答文本中提取最终答案。 这里假设模型按答案:的格式输出可以做简单归一化。 match re.search(r答案[:]\s*(.), text) if not match: return raw match.group(1).strip() # 去掉常见干扰字符便于投票时对齐 normalized raw.replace(,, ).replace(, ).strip() return normalized def majority_vote(solutions: list[str]): 对多条解答的最终答案做多数投票。 返回得票最高的答案、完整投票分布、有效解答数量。 votes Counter() for sol in solutions: answer extract_answer(sol) if answer: votes[answer] 1 if not votes: return None, {}, 0 best_answer max(votes, keyvotes.get) return best_answer, dict(votes), sum(votes.values())5.3 使用示例下面是一段调用示例用FakeLLM模拟一个虚构模型方便你在本地直接验证框架逻辑# 文件路径math_demo_with_fake.py import random from math_breakthrough_demo import generate_solutions, majority_vote class FakeLLM: 模拟一个以一定概率答对的模型用于本地验证框架逻辑。 def __init__(self, correct_rate: float 0.6): self.correct_rate correct_rate def __call__(self, prompt: str, temperature: float 0.8) - str: if random.random() self.correct_rate: return 设未知数为 x逐步解方程。\n答案: 42 return 设未知数为 x尝试错误路径。\n答案: 43 fake_llm FakeLLM(correct_rate0.6) # 注意这里需要把 generate_solutions 中的 call_llm 替换为 fake_llm # 为方便演示这里手写采样循环 def demo_with_fake(question: str, n: int 8): solutions [fake_llm(question, temperature0.8) for _ in range(n)] best_answer, votes, valid_count majority_vote(solutions) print(f问题: {question}) print(f采样次数: {n}) print(f投票结果: {votes}) print(f最终答案: {best_answer}) print(f有效解答数: {valid_count}) if __name__ __main__: demo_with_fake(求解某个一元一次方程答案是多少, n8)5.4 这个示例能说明什么这个框架的核心价值是它会稳定提升正确率。如果一个模型单次答对的概率只有 60%那么 8 次采样后多数投票选到正确答案的概率会显著高于 60%。原因很简单只要错误路径不是系统性偏向同一个错误答案错误投票就会被分散。真正的推理模型替换掉call_llm之后你会观察到类似效果只是提升幅度取决于模型本身的基准能力。这也解释了为什么当前推理模型在数学任务上常常需要“多跑几次再投票”而不是依赖一次输出的直觉。6. 完整示例二基于规则的验证器与 LLM Judge多数投票只能处理“有确定答案”的题目。遇到开放题、证明题或者需要检查过程正确性时还需要验证器。6.1 基于规则的验证器一个最简单的验证器是检查解题过程中是否出现了关键步骤。虽然粗糙但成本极低适合做第一层过滤。# 文件路径rule_validator.py KEY_STEPS { 代数方程: [设, 移项, 合并同类项, 解得], 几何证明: [因为, 所以, 由题意, 同理], 数列: [公差, 首项, 通项, 和], } def rule_validate(text: str, topic: str 代数方程) - bool: 检查解题文本是否包含该主题的关键步骤词。 steps KEY_STEPS.get(topic, []) hit_count sum(1 for step in steps if step in text) # 阈值按需调整这里要求至少命中一半以上关键步骤 return hit_count max(1, len(steps) // 2) if __name__ __main__: sample 设未知数为 x移项合并同类项解得 x 42。 print(是否通过规则验证:, rule_validate(sample, topic代数方程))这个验证器的问题在于它只能做表面检查关键步骤存在不代表步骤顺序正确也不代表逻辑成立。所以它只能作为初筛不能作为最终结论。6.2 基于提示词的验证器更实用的验证器是让另一个模型扮演“批改老师”。它需要看完整条推理链给出打分和错误点。为了避免“让模型批改自己”的偏差可以设计更严格的验证提示词。# 文件路径llm_judge_prompt.py VERIFY_PROMPT 你是一名严格的数学竞赛阅卷老师。请判断下面的解题过程是否逻辑正确。 要求 1. 检查每一步推导是否严格成立。 2. 如果发现错误指出错误发生的具体步骤。 3. 不要因为最终答案正确就忽略过程错误。 4. 最后输出格式为 正确性: 正确 / 错误 理由: 具体理由 问题 {question} 解题过程 {solution} def build_verify_prompt(question: str, solution: str) - str: return VERIFY_PROMPT.format(questionquestion, solutionsolution)实际使用时你可以把build_verify_prompt的输出发给模型然后解析“正确性”字段。关键点在于提示词中的“不要因为最终答案正确就忽略过程错误”这会显著降低“只看结果不看过程”的误判。6.3 示例三形式化验证的最小演示如果说前两个验证器解决“大概率正确”那么形式化验证要解决“机器可证明”。Lean 是一种形式化证明工具。下面这段代码证明了一个简单的算术命题每一行都由机器检查-- 文件路径MinimalProof.lean example : 2 3 5 : by norm_num在这个例子里norm_num是一个自动化策略它从自然数的定义出发逐步证明 2 3 确实等于 5。看起来简单但它代表的是完全不同的验证范式模型凭直觉生成的解答在形式上被编译成了可以逐行检验的证明脚本。在实际 AI 数学研究中这种形式化验证极其昂贵通常只在最高风险场景使用。但对开发者来说理解这一点就够了分级验证体系中形式化验证是最终防线它不依赖模型的语气是否自信只依赖符号规则是否成立。7. 运行结果与效果验证7.1 如何跑通建议你按这样的顺序在本机运行# 1. 先用假模型跑通框架 python math_demo_with_fake.py # 2. 测试规则验证器 python rule_validator.py预期输出大致如下问题: 求解某个一元一次方程答案是多少 采样次数: 8 投票结果: {42: 6, 43: 2} 最终答案: 42 有效解答数: 8如果FakeLLM的正确率设置为 0.68 次采样后正确结果 42 通常能获得多数票。这个输出可以给你直接观感单次生成可能出错但多数投票会拉高整体正确率。7.2 如何判断有效性不要只看“最终答案是不是对了”。一个可靠的数学推理方案应该同时满足正确率提升多次采样 投票的正确率要高于单次生成的正确率。投票分歧可控多次采样后有效答案不应该过度分散。如果 8 次采样产生了 7 个不同答案说明模型本身的基础推理能力不足或者 temperature 设置过高。验证器能发现错误你可以人为构造一个“答案为 42、过程错误”的解答看验证器是否能识别出来。如果验证器也给了高分就需要优化验证提示词。7.3 失败时看哪里如果跑出来的结果不符合预期按这个顺序排查先确认call_llm是否真的被替换成了你的模型接口打印原始解答文本检查答案:的格式是否被正确提取检查extract_answer的正则是否适配你的模型输出格式检查温度设置如果答案五花八门降低 temperature如果多条解答完全一致但结果是错的提高 temperature 或增加采样次数。8. 常见问题与排查思路问题现象可能原因排查方式解决方案多次采样后答案仍然五花八门temperature 过高或模型推理能力不足打印所有轨迹人工随机检查 3 到 5 条降低 temperature 至 0.5 左右或更换推理能力更强的模型多数投票选出了错误答案错误路径存在系统性偏差分析投票分布检查错误答案是否集中在同一类错误引入独立验证器不能只依赖投票尝试用不同提示词风格采样验证器总是给错误过程打高分验证提示词过松或模型自身推理能力弱用人工标注的反例测试验证器强化提示词要求指出具体错误步骤必要时使用更强的验证模型同一道题多次调用成本过高采样次数过多统计正确率随 n 的变化曲线根据预算选择 n通常 4 到 8 次是性价比不错的区间正则提取不到“答案:”字段模型没有按提示词的格式输出打印原始解答文本检查格式在提示词中强调固定输出格式或扩展正则匹配规则数学题里混入恶意指令题目文本被做成了提示词注入检查输入内容是否有可执行指令对输入做清洗把题目文本和指令分离不在未隔离环境执行9. 最佳实践与工程建议9.1 验证分级设计不是所有场景都需要三步全跑。建议按风险分级L0 轻量级多数投票 答案归一化。适合做批量筛选、大规模数据清洗成本极低。L1 标准级投票之后加一层 LLM Judge检查解题过程是否逻辑一致。适合日常评测和 Agent 工具链。L2 严格级在 L1 基础上对关键题目用符号计算或 Lean 做形式化验证。适合高风险的决策场景比如金融计算、学术结果复核。关键原则先跑低成本方案再对低置信结果升级验证级别。不要一开始就对所有请求启用形式化验证成本会让你寸步难行。9.2 成本控制采样 投票的本质是用推理成本换正确率。实际项目里可以有这些优化先让小模型做一次初步解答如果置信度高直接输出如果初始答案与历史相似问题的正确分布有明显差异才触发多路径采样多个问题批量发送利用缓存避免重复调用对采样结果做去重后再调用验证器避免同一路径重复产生费用。9.3 工程与安全边界把“AI 数学解题”放进生产系统时有几个容易被忽略的点输入的数据里可能嵌套了可执行代码或恶意指令数学题文本也必须当作不可信内容处理不要把大模型当作计算器涉及金额、数量等关键数值时用符号计算库或真实计算器交叉验证日志要保留完整的原始解答轨迹出现事故时才能回溯是哪一步路径导致的错误增加超时控制多次采样的整体耗时会显著大于单次推理必须有异步或超时兜底。9.4 团队指标的设定如果你的团队要评估一个模型适不适合做数学推理类 Agent不要只看一道题的通过率。建议建立三个指标单次首答正确率代表模型的基线能力多路径采样后正确率代表模型在推理时扩展下的能力上限验证器识别错误率代表验证环节是否可靠。这三个指标分别对应“模型行不行”“方法行不行”“工程行不行”缺一不可。10. 总结与后续学习方向把这篇文章的技术主线收拢一下核心判断只有一句话AI 数学突破不只是模型变强了更是推理范式从“一次生成”转向了“生成多条路径 验证机制把关”。高中辍学者的故事真正折射的是路径多样性在数学发现中的价值而这种多样性现在被编码进了采样、投票、验证的技术框架里。作为开发者你不需要拥有训练大模型的能力也能参与这条主线。从替换call_llm、跑通投票闭环开始到引入 LLM Judge、再到研究 Lean 形式化证明这条路径是一层层递进的。后续值得继续深入的方向包括学习 Lean 和形式化数学了解“机器可证明”的边界在哪里关注自训练和推理轨迹数据增强看模型如何从失败路径中学习研究树搜索类推理方法它比简单的 Best-of-N 采样更能处理需要决策分支的复杂数学题在你的 Agent 工作流中把“数学验证”注册成一个独立工具而不是让模型自己负责生成和验证。建议你把文章中的三个示例代码保存下来先跑通框架再逐步替换成自己的模型和真实题目。数学推理问题虽然看起来离业务很远但它几乎是检验大模型逻辑能力的标准试金石。能把这类任务在工程上做稳定你的 Agent 在处理其他确定性较高的任务时也会更可靠。