首页
/
行业洞察
/
正文
INDUSTRY INSIGHT · 深度
ChatGPT破解千禧难题?低复现率背后的AI数学科研真相
📅 2026/10/18 4:38:08
✍️ 爱科研究院
👁 阅读 3,247
刚看到“ChatGPT能破解千禧数学难题”的时候我的第一反应是好家伙这标题也太唬人了。可紧接着又刷到另一个统计说涉及大模型辅助科研的论文复现率低到13.98%。这两个消息放一起就像前脚有人夸你跳了三米高后脚又公布你百米赛跑基本每回都摔。我平时的工作就是大量接触AI辅助数学推导和论文复现说实话刚看到这组数据时我也觉得矛盾翻来覆去看了几轮资料才想明白这两件事其实根本不冲突它们描述的根本不是同一层科研能力。这篇东西想跟你掰扯清楚的就是这组矛盾数字背后的逻辑所谓的“破解千禧难题”到底做到了什么程度、13.98%这个低复现率是怎么被统计出来的、为什么两者能同时成立以及如果你自己也想把大模型用进研究里哪些场景真能落地、哪些场景目前就是个雷区。无论你是研究生、刚接触AI辅助科研的年轻学者还是单纯对“AI能不能搞数学”感兴趣的人这篇都值得读下去。我尽量不用玄乎的术语把话往白里说该给的操作细节和踩坑经验也会直接给到。1. 先把这个矛盾拆开看一边是“顶级难题”一边是“低复现率”很多人看到“破解千禧难题”和“13.98%复现率”放在一起第一反应就是ChatGPT不行、AI造假、媒体吹牛。但真实情况往往更平淡也更值得琢磨。要理解这两件事为什么能在同一个行业里同时发生得先逐层把两个消息各自的真实含义拆开。1.1 “AI破解千禧难题”到底指什么千禧年大奖难题是七个数论与分析领域著名难题的合称包括黎曼猜想、P对NP问题、纳维-斯托克斯方程的正则性等。任何宣称“破解”这些问题的说法都必须先回答一个关键问题破解到什么程度算破解实际出现过的所谓“AI破解”事件绝大多数并不是模型真把黎曼猜想写成了一个完整的、被全人类认可的证明。更常见的情况是下面几种模型针对其中一个子问题给出了新的构造思路比如某种特殊函数的展开形式。模型生成了一段推导链人类数学家顺着它往下走发现其中某个引理是新的、可验证的。模型在对话里给出了一种等价转化把原问题映射到另一个已知领域后续研究者根据这个提示做出了实际成果。我在自己的研究里也体会过这种“阶段性成果”模型给出了一段组合不等式分解的思路单独看没有任何一个小步骤超纲但组合起来确实帮我节约了几天试错时间。这类成果就是真实的也确实值得宣传但它和“用严谨的公理化语言完整证明了一个千禧问题”完全是两回事。做一个生活化比喻你想从山脚爬到山顶AI画出了一张局部地图其中一段路标得非常准你按着它走确实省了不少弯路。但整条登山路线它并没有走通山顶也没有插上旗子。这就是“阶段性验证通过”而非“全程走通”。所以“ChatGPT能破解千禧数学难题”这个说法的标准版本应该是“在千禧问题的某个局部或相关问题上大模型给出了有启发性的思路且这个思路通过了人类或工具的验证”。理解了这一点再看复现率就不会觉得魔幻了。1.2 13.98%复现率是怎么统计出来的那个流传甚广的13.98%一般被引用成“LLM相关论文复现率低至13.98%”。实际上这类统计大多来自某个团队对特定时间段内、一定数量论文样本的系统性复现检验。流程大致是收集标题或摘要里明确提到用某种对话式大模型辅助完成科研工作数学证明、代码生成、数据处理等的论文然后由独立复现团队严格按照论文描述去重跑实验统计能够稳定复现主要结论的比例。注意几个细节这些细节决定了这个数字的适用范围统计对象不限于“破解千禧难题”类别而是一大批使用大模型的科研论文数学只是其中一部分。复现标准通常分“完全复现”和“部分复现”。完全复现要求模型输出、关键实验数据、最终结论全部一致部分复现只要求核心结论方向一致即可。放进13.98%里的多半是“完全复现”那一档。复现需要相同或等价版本的大模型、相同提示词、相同采样参数、相同算力环境。这四个条件只要有一个对不上结果就可能跑偏。换句话说13.98%描述的不是“这些论文全在造假”而是“在当前条件下想让一个已发表的、用大模型帮忙做出来的研究结果被另一个人稳定跑出来成功率很低”。这其实反映的是AI辅助科研目前缺乏工程化标准而不是模型能力本身为负。1.3 两个数字放在一起说明什么把两件事叠在一起就能看到一个清晰的结论LLM在创造“一次性亮点”上确实有惊喜但在“可重复、可维护、可交付”的工程维度上还非常稚嫩。这两种属性有个专门的学术化说法前者叫探索性价值后者叫复现性价值。你可以在自家院子里用一个下午搭出个能走的机器人小车这证明你懂机械和编程但如果你想量产十万台同样的小车那就得解决注塑模具、品控、供应链、售后一堆问题两者难度不在一个量级。“破解千禧难题局部”是其中一台炫酷的原型车“复现率13.98%”则是量产线上惨淡的合格率。它们说的是同一个行业的两个阶段。这事儿放到任何一个工具演进过程中都成立第一台珍妮纺纱机效率未必比手纺车高多少但它证明了机器纺纱的可能性真正改变世界的是后续几十年里把纺纱机变成稳定工业设备的人。所以对这组数字最准确的态度不是“AI吹牛被戳穿”而是“AI在科研中的工程化成熟度还没有跟上它的能力兑现速度”。搞明白这一层我们才有动力去追问为什么复现这么难以及该怎么让它变简单2. 为什么复现率这么低AI辅助科研的四道拦路虎13.98%不是凭空掉下来的它背后是四类很具体、很琐碎的原因。我自己在实际复现过几篇同类论文之后只能说这个数字一点不冤。想提升它先得知道它低在哪。2.1 复现的定义与判据不一致先说一个最隐蔽却最致命的坑不同论文对“结果成功”的定义根本不一样。有的作者把“模型给出了一个可被形式化验证的证明脚本”当作核心成果复现者只需要跑通脚本并验证正确性就算复现。有的作者把“模型生成了一段可读的推导链且人工检查没发现漏洞”当作成果这就不需要完全自动化验证但需要人工判断。还有的论文核心卖点就是“模型在对话中给出了若干有启发性的表述我们在其基础上找到了证明”这种“半成品”性质的成果复现起来基本无解因为你复现不出来“启发”本身。我见过最典型的纠纷是这样的某论文写“大模型提出了一个构造我们将其形式化后证明了关键引理”。复现团队照着做发现不同的提示词得到的构造不一样偶尔能对上偶尔不能。于是复现方判定“复现失败”作者却坚称“你换个随机种子多跑几次就能复现”。双方在法庭上争执的核心其实是“复现判据”没对齐而不是模型真的不行。打比方说菜谱上写“加少许盐”每个人对“少许”的理解都不同做出来的菜味道当然千差万别。论文里如果不对“成功条件”做明确定义复现率低就是必然的副产品。2.2 实验链路太长一处波动满盘皆输LLM辅助科研的完整链路比传统算法实验长得多。我拆了一下大致是数据清洗 → 提示词构造 → 模型推理 → 候选输出筛选 → 后处理如转换为证明语言 → 人工标注 → 最终验证。这条链路里的每一环都可能有参数波动。传统代码实验里影响结果的因素无非是随机种子、数据划分、超参数。到LLM这里就复杂了模型权重版本、温度系数、top_p、max_tokens、系统提示词的措辞甚至同一天不同时段API服务端有没有悄悄更新推理引擎都会让输出变化。而很多论文只写了“使用某主流模型完成”连版本日期都没标注复现者想对齐都无从对齐。有个朋友做组合优化复现一篇论文时发现对方用的还是几个月前的旧版模型而他已经按新版本去跑了结果自然天差地别。这就像别人给了你一张地图但地图上的标注用的是一套旧地名体系你拿着一套新地名表去查查到的都是错的。更麻烦的是有些论文连“提示词原文”都不公开只给了一句概述“我们让模型生成候选反例”。你可能得自己写提示词而提示词在整条链路里恰恰是最敏感的一环我把它单独拎出来说。2.3 提示词与随机性被低估提示词对LLM输出的影响怎么强调都不过分。几个字的差异就可能让模型从“给出正确推导”变成“编造一套漂亮但错误的理论”。但很多论文作者自己没有意识到这一点或是潜意识里认为这不重要于是在论文里对提示词的描述非常模糊。更隐蔽的问题是随机性。绝大多数对话式大模型在默认接口下不是确定性的温度不为0每次调用结果不同。有的论文展示的“优秀结果”可能恰好是作者跑了20次之后挑出来的最好一次。复现者如果只跑一次抽到的是普通结果甚至差结果就会判定复现失败。这不是造假而是把“偶发最优”当成了“稳定能力”。我自己在做复现时有个习惯只要是我要下结论的实验至少跑5次并记录分布。如果5次里只有1次成功我不会把这次当成代表性结果这既是对自己负责也是为了让论文经得起别人复现。可惜不是所有人都这么做。2.4 评估口径错位能聊≠能证大模型的表达能力极强你让它聊数学它能聊得头头是道甚至每个括号、每个符号都像模像样。但“像模像样”不是“正确”LLM生成的数学文本里经常藏着致命的逻辑跳跃有时是漏了一个条件有时是应用了一条并不成立的引理。这就导致一个尴尬的局面论文作者用肉眼检查模型输出觉得“这个推理链看着没问题我采用了”但真正的形式化验证工具跑不过去或者计算实验的某项结果只是巧合换一个例子就崩了。说白了现在的大模型更像一个“极其自信的实习生”它给你的往往不是答案而是“答案的候选”。能聊出一个看起来合理的故事跟能用公理体系严格论证一个定理中间隔着十万八千里。复现者如果只拿着“能聊出来”作为成功判据就容易被偶然性欺骗如果拿着“完整验证”做判据刷出来的复现率自然难看。3. 从科研一线角度看LLM在数学研究里到底能做什么前面讲了那么多“不行”的地方很容易让人产生反感那这玩意儿到底还有没有用我的答案是有用而且用处不小关键看你把它放在什么位置上用。它不适合当“最终答案生成器”但非常适合当“探索催化剂”。3.1 真正可见效的三个场景结合我和一些做理论研究的同行的真实使用经历目前大模型在数学研究里最能落地的场景是这三个反例搜索。给定一个猜想或假设让模型尝试构造满足部分条件但不满足结论的小规模实例。这类任务容错率很高模型生成100个实例里哪怕只有一个真反例也值回票价剩下的99个扔了也不心疼。文献与知识组织。让模型帮忙梳理某个研究分支的关键定义、已知引理和证明技巧快速生成一份知识地形图帮研究者定位“这个问题的突破口可能在哪个方向”。注意这里必须把模型输出的文献来源全部人工核验因为它可能编造出处但“结构梳理”本身还是很有参考价值。证明框架建议。给模型描述一个目标定理让它建议从哪些中间引理入手、可能用到哪些经典方法比如归纳法、反证法、生成函数法。它不会直接给出完整证明但能帮你从一个更高的视角看到证明的路径组合。这三类场景有一个共同点它们都不要求模型“一次做对”而是依赖“大量生成 人工判断”模型犯错的成本被控制得很低。这是目前LLM在科研里的正确打开方式。3.2 一个让我印象深刻的实操案例有次我在做某个组合不等式问题时卡在一个关键步骤上。随手把问题描述丢给模型让它“构造一个满足约束A但不满足约束B的小例子”。前五轮它给的例子全部被我的验证脚本秒杀不是不满足A就是也满足了B毫无价值。我几乎要放弃但第六轮它给了一个我完全没想过的参数组合。我当时也是习惯性丢进脚本里验结果这组参数真的避开了B。我顺着这组参数反推结构找到问题的关键边界最终把证明补全了。这事的启示不在于“模型聪明”而在于“无监督生成快速验证”的组合拳在探索性问题上是真好用。你不需要模型每次都对只需要它偶尔提供一个人类惯性思维想不到的角度就行。值得一提的是如果当时第五轮我就停下这个故事就是另一个结局。所以我的经验是这种探索型提示词至少得追问五到八轮中途换个表达方式再来五轮不要轻易放弃。投入的时间成本不高收获可能是纯人工搜索完全绕不过去的墙角。3.3 一个可参考的提示词模板与工作流如果你也想在数学研究里试试水可以直接从我用的这套提示词模板开始你是一名专业的数学研究助理。请针对以下命题 [粘贴你的命题] 按下面的要求进行分析 1. 尝试构造一个3到5维的具体实例要求尽可能接近满足条件B但不满足条件C 2. 列出这个实例的明确数值参数 3. 给出该实例中为什么它满足B、但不满足C的推理过程 4. 如果无法给出实例请列出你认为最有希望构造成功的三个方向并解释依据 5. 给出一个可以被Python或SageMath执行的验证脚本模板。 请把每一项结果分开编号不要混在一起。这套模板有几个设计意图第一把目标拆成可验证的小步骤避免模型泛泛而谈第二强制要求输出“可执行验证脚本”这就把我们拉回到科学方法的地基上第三允许模型承认失败并给方向这比让它硬编一个错误结果强得多。配套的工作流也很重要我建议固定一个实验记录表内容至少包括模型版本、模型温度参数、提示词版本号、输出时间、验证工具、验证结果。格式可以用简单的Markdown表格半小时能维护完。这份记录不仅是复现的基础也是你将来跟合作者解释“这个结论怎么来的”的唯一凭证。4. 想把复现率拉上去需要研究者、平台和评审一起改13.98%这个数字往小了说是一批论文质量的问题往大了说是整个学术圈还没为大模型时代准备好“质量标准”。要抬升这个数字靠任何单方面努力都不够得从研究者、模型平台、评审体系三个方向同时动刀。4.1 研究者侧把提示词当作实验变量来管理很多研究者写传统算法代码时会严格记录随机种子、数据版本、依赖环境但一到大模型就放松了觉得“提示词嘛随便写写就行”。这种心态是复现率的最大杀手。我自己在试过把一些提示词输出归档之后就再也没法忍受“凭记忆复现”了。具体操作建议是为每个提示词建立独立文件文件名带版本号例如prompt_v03_ineq_approach.md。改动提示词前先复制一个新版本文件再在副本上改绝对不在原文件上直接覆盖。在最终成文时保证论文的附录或补充材料里有完整的提示词原文一个标点都不能少。对使用了随机采样参数的实验明确记录温度、top_p、max_tokens并在可能的情况下固定随机种子。不要只保留“最美的那次输出”把成功输出旁边的其他输出也存下来这能避免日后合作者问“为什么我复现出来不一样”时陷入窘境。这个过程本质上就是软件工程里的“可复现构建”思路你写代码时都知道要锁依赖版本做LLM实验时为什么就默认提示词不需要锁版本呢另外强烈建议给关键结果建立“三明治验证”原始输出留档、后处理脚本留档、最终计算验证脚本留档三样东西缺一不可。有这套东西在手你甚至不用等别人来复现自己提前就算出来了复现成功率。4.2 平台侧提供可复现的模型版本与推理参数研究者能做的只是规范自身模型平台侧的配合才是真正的大头。为什么很多论文的复现失败因为复现者根本拿不到跟原文一模一样权重和推理行为的大模型。平台可以通过三件事大幅改善现状长期保留并公开具体时间周期的模型版本。哪怕一个模型今天发布下月就更新平台也得允许查询和调用“发论文那天用的那个具体版本”。如果没有版本锁定的能力论文复现就是一个无条件赌博——你永远不知道今天调的模型和作者调的是不是同一个。完整记录并给出采样参数接口。温度、top_p、seed等信息应该可以被完整设置并写入论文附录平台不应当把采样参数当成暗盒不公开。开放推理日志或推理脚本模板。至少让复现者能用一个官方推荐的脚本一键重放“论文中提到的prompt → 模型输出”过程。这三件事目前只有个别平台做到了前一半大多数还停留在“我知道你说的是什么问题但短期解决不了”的状态。好消息是业界对这个问题的共识正在快速增加把“模型版本”像软件版本一样对待已经是迟早的事。4.3 评审侧把AI使用透明性写进审稿要求里学术期刊和会议是论文质量的总闸门。如果评审环节对所有“用大模型做科研”的投稿一视同仁不加额外约束那低复现率就永远不会得到系统性改善。我建议的落地方案很具体投稿时要求作者额外提交一份“AI使用透明性声明”内容至少包含本论文是否在数据处理、定理证明、代码生成、文献综述等环节使用了AI工具若使用具体在哪几个环节使用了哪个模型的哪个版本核心实验提示词的完整文本每次关键实验的采样参数与随机种子已获得的核心结果中可完全复现和不可完全复现的比例各是多少。评审系统还应该分档判断复现程度弱复现要求核心结论方向正确、关键验证可跑通强复现要求主要实验的输出完全一致。一篇论文哪怕只能做到弱复现只要作者诚实声明且结果本身有启发我认为也值得发表但必须标注“复现等级”让读者心里有数。把这个机制立起来以后高复现率的论文天然会获得更高的学术信誉低复现率的论文也不是被一棍子打死而是被贴上一个“初步探索”的标签需要读者自行判断使用价值。这比现在一边疯狂宣传“AI改变科研”一边让所有人在复现迷雾里互相猜疑要健康得多。5. 说点真实体会这组数字最该被记住的是哪一半绕了一大圈回到最初那组矛盾的数字上。我个人的看法是不要太纠结13.98%像不像一记耳光也不要把“局部破解千禧难题”当成AI已经封神的证据。这两个信息加在一起其实是在给所有做AI辅助科研的人敲黑板现在是大模型的探索红利期但远未到可以放松复现标准的时候。5.1 低复现率不等于“没用”但等于“还没制造好”一个工具如果复现率低未必说明它没用很可能说明它还没到能被当作标准工具的成熟度。望远镜刚发明时造出来十台有八台画面模糊复现率也不高但不影响它开启天文学革命。问题在于我们不能因为画面曾有一次特别清晰就假装其余八台模糊的问题不存在。在数学研究里LLM现在最合适的定位是“探索放大器”帮你更快地遍历思路、更快地发现异常案例、更快地组织知识而不是“自动证明机”。你让它直接生成最终定理的严谨证明十次里大概率能给你一部看起来像《战争与和平》的错误大全。但你让它生成100个候选小例子、帮你找反例它可能在第七轮给你一个真正有价值的线索。这就像你在森林里找路让AI当你的“侦察兵”而不是“向导”。向导带你走错一步就可能全盘崩坏侦察兵报告十个方向里有九个错误也没关系只要有一个方向是对的你省下的时间就远超成本。5.2 给想入局者的三个建议如果你看到这个领域的热闹也想把LLM引入自己的研究我有三条很朴素的建议。第一从风险最低的任务入手。别上来就挑战“让模型证明某个猜想”先让它做文献梳理、反例搜索这类一条路走不通也不会伤害你研究主线的工作。成功率不重要探索效率才重要。第二从第一天起就记录一切。至少记清楚每次实验用的提示词版本、模型版本、采样参数以及验证结果。宁可前期多花十分钟整理记录也不要等论文被拒、合作者质疑时拿不出证据。第三所有AI输出都必须经过独立的验证环节。这条没有任何例外哪怕你觉得那段推导漂亮得惊人也一样要丢进形式化验证工具或写一段独立校验脚本去过一遍。漂亮是毒药可验证才是解药。我平时有个特别土但是特别管用的习惯所有从大模型那边拿来的结论我都要问自己一句“如果我是它的批评者我会怎么攻击这个结果”带着这个问题去检查通常十几分钟就能发现至少一个薄弱点。这比盲目相信输出然后陷入复现困境强得多。最后再分享一个小技巧。做LLM辅助数学探索时如果你觉得模型给的结果“感觉哪里不对”但又说不出具体哪里不对先不要急着重写提示词试着让它“反过来解释三遍”第一遍用通俗语言解释第二遍用一个类比解释第三遍用一个更简单、更小的例子解释。这个过程经常能让隐含的逻辑错误直接暴露出来甚至帮你找到自己原问题里的隐藏假设。我在多次复现失败和成功之间靠这一招躲过不少坑。希望这篇把关键道理讲明白的文章也能让你少走几次弯路。
📌 标签:
工业官网
设计趋势
AI 建站
SEO
获取完整报告 →
RELATED ARTICLES
推荐阅读
2026/10/18 4:38:08
MySQL视图实战:从虚拟表原理到权限隔离与性能优化
2026/10/18 4:33:08
MCP入门指南:6000字深度解析+6个实战案例,普通人也能轻松掌握!
2026/10/18 4:33:08
Transformer时序预测:解决长期依赖失效的工程实践方案
2026/10/18 5:23:10
手写32位操作系统内核:从实模式到保护模式的底层实践
2026/10/18 5:23:10
Linux字符设备驱动开发基础:从设备号到ioctl的完整实战
2026/10/18 5:23:10
用Python tkinter打造轻量SQLite可视化工具
2026/10/18 5:23:10
AI论文写作全流程实战指南:从选题到排版的高效工作流
2026/10/18 5:23:10
企业AI落地实践(三):用TaoToken统一网关打通AI Agent与LLM的交互链路
2026/10/18 5:18:10
Godot RE Tools 使用指南:如何从 .gdc 字节码恢复完整游戏项目
2026/10/18 0:02:43
OpenResearch实战:Claude Code、Codex、OpenCode、Cursor 工作流搭建与故障排查
2026/10/18 0:02:43
知识管理核弹:用Obsidian构建第二大脑的工程化方案(TaoToken 统一 Key 接入版)
2026/10/18 0:02:43
金融AI落地指南:从调研报告到技术选型与工程实践
2026/10/18 0:02:43
OpenResearch实战:Claude Code、Codex、OpenCode、Cursor 工作流搭建与故障排查
2026/10/18 0:02:43
知识管理核弹:用Obsidian构建第二大脑的工程化方案(TaoToken 统一 Key 接入版)
2026/10/18 0:02:43
金融AI落地指南:从调研报告到技术选型与工程实践
2026/10/17 10:15:50
我发现了一个新思路:用 Remotion + Claude Code 像写代码一样自动化生成短视频
2026/10/16 18:46:48
Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式:TaoToken 统一 Key 配置与验证
2026/10/16 18:46:46
2026 大模型集体涨价:用 Python 做企业 Token 成本测算与选型避坑(附配置)