最近有一条消息在 AI 社区里传得很快“OpenAI 连续攻克 10 道数学难题Fable 24 小时复现 5 道。” 第一次看人的本能是立刻对比“10 对 5”好像是在比模型强弱。但如果你真的在工程里做过模型评估会发现标题里最有分量的词不是“10”也不是“5”而是“复现”。我为什么这么说因为“解出一道题”可以是某一次采样的运气可以是提示词工程的作用也可以是某个模型版本刚好达到能力峰值。而“复现”意味着把输入、模型、采样参数、验证逻辑、运行环境全部还原然后在另一个时间、另一个执行者手里依然得到经过校验的结果。它把一次性的成功变成了可重复的流程。这篇文章不会去替 OpenAI 或 Fable 做成就排名因为目前公开的信息不足以支撑这种判断。我更想拆解的是当“复现数学难题”成为一个工程任务时我们要准备什么、会遇到什么、最后能沉淀下什么。这个过程对普通开发者的价值远大于一个模型排行榜。1. 先别急着比模型先搞懂“数学难题”在考什么1.1 这类任务为什么难倒大多数模型数学难题通常不是“记住公式”就能解出来的。它们往往需要多步推理先把题目翻译成可操作的条件再构造中间结论最后还要验证每一步是否自洽。对语言模型来说真正难的部分不是生成文字而是在长链条推理中不丢失前提。我见过不少实际评估项目模型在前两三步推理看起来非常顺但到了第五步突然忘记了一个关键约束又或者在某个计算符号上出错。这类错误不像写作用词偏差它会导致最终答案完全不对。所以“数学难题”的评估本质上是在测试一个系统的规划、执行和验证能力而不是语言流畅度。这也是为什么 OpenAI 连破 10 道题的消息值得关注。它说明模型在多步推理链路中的连贯性有了可见提升。但注意这只是对现象的合理理解不是某个官方结论。真正要在实践里确认这一点需要更透明的评测数据、输入提示词和运行日志而不是一个抽象的数字。1.2 从“答对一道题”到“证明一个答案”复现之前要先定义“破解一道题”是什么意思。如果只看最终答案例如一个数字、一个选项那么复现门槛较低。多跑几次采样总能提高命中率。如果要求完整推导过程要求每一步可验证那么复现本质上是把解题过程也作为输出的一部分去对齐。更严格的标准是形式化证明每一步都要放入证明助手或符号系统里检查。这个难度会成倍上升。我建议在搭评估环境前先把这道题的标准写下来是只比答案还是答案加过程还是答案加形式化验证。不同标准会直接决定判分器的复杂度和复现的可信度。这里有一个容易被忽略的细节很多数学题的“标准答案”并不唯一。比如一个方程可能有多个解一个几何题可能有多种构造方式一个组合题可能有多种计数路径。如果评估环境里只放了一个标准答案那么复现时很容易把正确但写法不同的结果判错。所以在数据阶段就要做一道工序为每道题写下“答案判定规则”而不是只写一个答案字符串。判定规则可以简单但必须明确。例如“数值误差小于 10^-6 即可”“必须包含某个中间结论”“接受等价代数表达式”。这个规则越早定后续判分器越不容易翻车。2. “复现 5 道”为什么比“打出 10 道”更有信息量2.1 复现的难点不是模型而是流程可以做一个思想实验你拿到一份评估报告上面写着“某模型在某数学测试上成功解决了 10 道题”。从研究角度看这份报告的信息量其实很低。因为没有提示词、没有日志、没有解码参数、没有版本信息你无法判断换个环境还能不能得到同样结果。反过来如果有人说“我们在另一个环境里仅用 24 小时就复现了其中 5 道”这个信息就包含了一个可验证的闭环已经知道输入、输出、校验方法并且在外部环境里重新运行成功。5 道的绝对数量可能不高但它证明这个任务不是一次偶然。标题里的 Fable在这个语境里可以是一个模型也可以是一套复现框架。具体是什么其实不影响后面的工程讨论因为复现动作本身考验的是流程设计和问题排查能力。它要求你把“隐性知识”变成“显性信息”用什么提示词、采用什么采样策略、如何判断答案、日志记了哪些字段、失败样本丢到哪去了。这些才是复现的真正成本。另一个容易忽略的点是“24 小时”这个时间约束。复现在时间压力下通常会暴露两类问题第一模型接口不稳定第一批调用可能因为超时或请求限制失败第二人们倾向于先跑最可能成功的几条路径导致没有时间去处理失败样本。所以 24 小时能复现 5 道意味着这个流程不仅是通的还具备一定的容错能力。2.2 复现的四个层次我一般会把“复现”分成四个层次用来判断一个团队对结果的理解深度复现层级定义能回答的问题典型产出物零复现只有榜单结果模型有没有做到一个成功数字黑盒复现用 API 和已知提示词得到相似结果换个调用方还能得到吗一份执行脚本白盒复现能分析成功样本的中间推理模型为什么这样走中间步骤分析记录工程化复现能自动跑批、判分、回归、对比模型升级后结果还稳定吗评估套件 持续回归这个框架可以帮我们定位自己处在哪一层。24 小时复现 5 道题如果只看最终数字大概处于黑盒复现到白盒复现之间如果它把评估脚本、判分器和失败案例都公开了那就接近工程化复现。3. 从零开始搭一个可复现的数学推理评估环境3.1 第一步先把样本和答案定义清楚一个可复现的评估环境起点不是模型而是一份标准化的数据集。建议先把题目整理成 JSONL每行包含题目 ID、题目原文、标准答案、答案格式、是否要求完整过程。下面是一个通用示例结构{ id: math_001, problem: 题目文本建议保持原始格式, golden_answer: 标准答案, answer_format: numeric, requires_steps: true, tags: [algebra, olympiad] }我第一次做这种评估时犯过大错误题目直接从 PDF 里复制换行符和 LaTeX 格式混乱导致模型输出同样混乱。所以数据清洗要放在模型调用之前而不是之后。每道题的“题面一致性”会直接影响复现的可靠性。这里还要强调一下不要一开始就追求大而全的数据集。先选 10 到 20 道代表性题目把端到端流程跑通比几百道题同时跑要有效得多。因为小样本环境下你能逐条检查成功和失败的案例能发现数据、提示词、判分器的结构性问题。一旦小样本流程稳定扩展到大批量只是时间问题。3.2 第二步用 API 或本地模型跑出原始输出假设你用的是兼容 OpenAI 接口的服务一个最小请求通常包含以下参数。这里给出的是常见写法具体参数名以你所用服务为准import os from openai import OpenAI client OpenAI( api_keyos.environ.get(API_KEY), base_urlos.environ.get(API_BASE_URL, https://api.openai.com/v1) ) response client.chat.completions.create( modelyour-model-id, messages[{role: user, content: problem}], temperature0.2, max_tokens2048, ) output response.choices[0].message.content从工程经验看有几个点很容易被忽略API Key 不要写死在代码里更不要提交到 Git 仓库。请使用环境变量或密钥管理服务。如果模型服务商提供 OpenAI 兼容协议同一套脚本可以低成本切换不同的模型。这是评估环境能长期复用的关键。不要只用模型别名要尽量记录真实的模型版本号。很多“今天能跑通明天跑不通”的问题都出在模型被悄悄更新。数学题输出通常是一段解释加一个最终答案。如果你直接把整段文本拿去判分会引入很多噪声。更稳的做法是让模型按结构化格式输出例如在提示词里要求“最后一行必须输出 ANSWER: 答案”然后用解析函数提取。def extract_final_answer(text: str) - str: marker ANSWER: if marker in text: return text.split(marker)[-1].strip() return text.strip()这个函数看起来简单但它的价值在于把自然语言输出和最终答案分离让判分器只看它该看的部分。同时完整输出仍然要保留在日志里因为过程检查还需要它。3.3 第三步设计“判分器”判分器是复现流程里最容易低估的部分。如果只判“字符串是否等于标准答案”很可能把正确但写法不同的答案判错也可能把答案碰巧相同但过程错误的情况放过去。一个更稳妥的判分流程是先用正则或结构化输出从模型回复里抽取出“最终答案”字段。如果是数学表达式用符号计算库做等价性判断而不是直接比较字符串。如果要求完整过程可以再让一个独立的模型做“可验证性检查”判断推导是否出现跳步、自相矛盾或无效结论。最后保留一份人工抽样的复核结果避免自动判分器系统性跑偏。下面是一个很简化的判分示意def is_correct(response, golden, checker): final_answer extract_final_answer(response) return checker.equals(final_answer, golden)看上去很简单真正复杂的是checker。一个好用的判分器要能处理约等、小数精度、表达式恒等、单位差异等问题。如果题目要求的是代数化简1/2和0.5应该都算对如果题目要求的是计数结果那么2和2.0也算等价。还有一个更微妙的问题判分器本身可能出错。所以我建议每次评估结束后单独导出一份“模型被判对但人工觉得不对”和“模型被判错但人工觉得对”的样本列表。只要这个列表不是空的就说明判分器还需要继续打磨。3.4 第四步多轮采样与日志记录数学题不应该只跑一次。建议对每道题跑 3 到 5 个不同的 Random Seed并记录每轮结果。日志至少包含这些字段字段示例题目 IDmath_001模型版本your-model-id提示词哈希7f3a...temperature0.2seed42答案...判分结果true/false耗时 / Token 数1234ms / 809 tokens这里有个重要原则不能只看最好一次的成绩。如果 5 次采样里只有 1 次成功那么这个成功很可能来自随机性而不是模型能力。记录失败样本同样重要因为它能告诉我们是“提示词不够好”“题面有歧义”还是“推理逻辑确实中断了”。建议先从 10 道题的小样本开始把整套流程跑通再决定要不要扩展到更大规模。小样本阶段的核心目标是让“输入—推理—输出—判分—日志”五个环节都稳定。4. 最容易翻车的 5 个地方以及排查顺序4.1 翻车点提示词版本混乱复现结果对不上最先怀疑的往往就是提示词。有人在本地改了一行提示词没有同步到评估脚本于是日志里记录的结果和最新代码已经不对应。排查方式把提示词纳入版本管理并在每条日志里存提示词哈希。只要哈希不一致就说明复现环境没有对齐。同时要注意提示词不是只指第一轮输入。如果模型需要多轮对话那么后续每一轮的 message 构造方式也要固定。很多复现失败不是因为模型变了而是因为 messages 数组里多了一段历史记录或少了一段系统指令。4.2 翻车点随机性掩盖了真实能力即便 temperature 设为 0某些硬件和推理服务下结果仍可能有波动。更常见的是团队为了提高成绩把 temperature 调得很高反复跑几十次只记录成功的那一次。排查方式固定 seed至少跑 3 到 5 次记录成功率。如果成功率不稳定不要急着判断模型强弱先把采样策略定下来。这里要补充一个细节很多 API 并不保证 seed 参数一定会产生完全确定的结果。尤其是在负载均衡、多副本部署、模型量化差异等情况下相同 seed 也可能得到不同输出。所以“固定 seed”只是降低随机性的手段不是绝对保证。更可靠的评估指标是“多次采样下的成功率”。4.3 翻车点答案等价性判断失误一个题目的正确答案可能是“0.5”模型输出“1/2”字符串比较会误判为错误。反之如果只提取答案而不看过程模型可能在推理中使用错误公式却碰巧得到相近答案。排查方式单独保存所有“判分器判定为错误、但人工复核为正确”的样本定期优化等价性判断逻辑。另外模型可能输出“答案是 0.5”也可能输出“答案0.5”还可能把最终答案藏在一大段解释中间。如果你的抽取逻辑只匹配一个固定字符串那么很多正确样本会在判分前就被丢掉。更好的做法是设计多级抽取规则先查结构化标记再查关键词最后取整段文本中的最后一个表达式。4.4 翻车点工具调用和沙箱限制有些数学题需要模型调用计算器、执行 Python 代码或使用证明工具。如果评估环境没有安装对应依赖或者沙箱禁用网络执行复现就会中断。这个环节的失败率往往不体现在模型能力上而是体现在环境配置上。排查方式把“是否需要工具调用”作为题目的一个字段提前记录。每道题运行前先检查环境里缺少哪个依赖再决定是否执行。在复现别人的结果时尤其要注意对方是否使用了某个特殊工具包。比如符号计算用 sympy数值计算用 numpy几何题可能还需要可视化工具。不要假设所有环境都预装了这些依赖。4.5 翻车点超时与流式输出处理数学推理容易产生长输出。如果max_tokens设得太小结果会截断在关键步骤如果调用接口设置了很短超时模型可能还没来得及完成推理就被终止。排查方式先看现象“无输出”和“输出到一半”对应的原因完全不同。确认日志里有没有finish_reason字段如果是长度截断就调大max_tokens并启用延长输出机制。这里要特别注意流式输出。如果你用streamTrue实时读取内容那么网络中断、响应流异常、客户端 bug 都可能造成输出不完整。复现场景下我建议第一次先关掉流式拿到完整的消息内容再考虑性能优化。流式处理适合产品化阶段不宜用它来做严格评估。遇到问题时的常规排查顺序我一般按这个链路走看现象是报错、空输出、截断、乱码还是结果不稳定。看输入题面是否完整格式是否一致有没有被额外指令污染。看环境依赖版本、沙箱权限、资源占用是否正常。看参数模型版本、temperature、max_tokens、response_format 是否被记录。看工具边界当前服务是否支持代码执行、长上下文、结构化输出。大多数所谓“复现不了”的问题最后都会落在这个链路的前四步里而不是真的模型能力退化。5. 复现这件事最终会沉淀成什么5.1 一个可复用的评估工作流框架从开头到现在我想说明的核心判断是数学难题的复现本质上是一次评估工程。你可以把整个工作流抽象成三步单例验收拿 1 道题跑通完整链路人工确认输入、输出、判分和日志都正常。小批量回归扩大到 10 道题跑多轮采样统计成功率记录失败原因。开放接口化把评估脚本封装成可复用工具支持替换模型 API、切换数据集、输出统一报告。这个框架不局限于数学题。代码生成、文档理解、数据提取、智能体任务其实都可以用同样的逻辑先跑通再回归最后接口化。不同任务的差异只在输入格式和判分器设计。下面的表格展示了每个阶段的检查重点阶段检查重点完成标志单例验收题面干净、提示词可回放、输出不截断、判分逻辑正确1 道题人工确认通过小批量回归多 seed 成功率、失败原因分类、日志完整10 道题有稳定成功率记录开放接口化支持不同模型协议、数据集可替换、报告自动生成其他成员可一键运行5.2 对普通开发者的实际意义如果你只是一个普通 AI 应用开发者可能不会去跑数学竞赛题。但“复现”带来的观点可以迁移到很多场景你在做一个聊天机器人不能只看一次回答好不好要看同一个问题换参数后会不会崩。你在接某个大模型 API不能只看上线时正常要记录模型版本和接口行为。你在做自动化内容流程不能只跑通一次就交给业务要监控输出格式、失败率和人工修正率。真正拉开差距的不是“能调用模型”而是“能对模型的行为做过回归测试”。这个过程会逼你把提示词、参数、日志、判分、异常处理都变成一等公民而不是临时脚本。我经常看到开发者在项目早期说“先别管评估把功能做出来再说。”结果上线后一旦模型表现波动就陷入“改提示词—再试—再改”的循环。你不是在跟模型协作你是在追一个永远追不上的随机数。如果从一开始就保留一份可重复的评估脚本每次修改都能看到对一小批样例的影响情况会完全不同。5.3 这类新趋势的长期关注点这段时间社区里关于 Codex Harness、OpenAI 开放评估工具链的讨论热度很高。如果这类工具真的像社区期待的那样成熟那么复现的门槛会进一步下降更多人可以在统一的环境里跑同样的任务对比不同模型的真实能力。但截至现在我还没有看到足够权威的定论所以更合适的做法是观察和试用而不是盲信某个说法。未来值得长期关注的关键点有三个评估基准的标准化程度题目、答案格式、判分规则是否统一。工具链的可移植性评估 harness 是否能跨模型、跨环境运行。自动化判分的可靠性自动判分与人工判分之间的偏差有多大。如果你从一开始就把这三个问题纳入自己的评估设计那么无论模型榜单怎么变化你手里的流程都不会过时。回到“OpenAI 连破 10 道数学难题Fable 24 小时复现 5 道”这条消息。如果你只记住 10 和 5 这两个数字过几个月就会被新的数字覆盖但如果你记住的是“复现背后是一套从题面管理、模型调用到判分器设计、日志追踪的工程闭环”那么无论未来模型怎么升级你都可以用这套闭环去验证它。这才是这条消息里最值得留存下来的部分。