Meta 在奥赛类推理题上的表现让“纯推理”这个词重新成为技术讨论的焦点。这里的纯推理并不是指模型不使用训练数据而是指模型在训练完成之后不再针对具体任务做微调而是把额外计算全部放在推理阶段生成更多候选、运行更长的思维链、反复验证并修正。奥赛题恰好是一种很难靠记忆和检索解决的任务因此被当作测试模型推理能力的试金石。这篇文章不讨论 Meta 具体模型在哪一天、哪场比赛拿了几块金牌也不对分数做二次确认。文章真正想解决的问题是纯推理为什么能让模型解出高难度数学和逻辑题在工程侧要搭建一套可复现的纯推理评估流程需要做哪些事在评估结果时什么情况说明模型真的会推理什么情况只是验证器筛选出来的巧合。1. 先理解“纯推理”为什么能在奥赛题上出成绩讨论任何一个模型成绩之前先要把“纯推理”这个词说清楚。它和“微调后做题”是两种完全不同的技术路线评估口径也不同。1.1 什么算纯推理什么不算纯推理可以通俗理解为模型已经训练完成权重固定不变做题时通过额外消耗推理阶段的计算量来提升正确率。它可以包括多次采样、思维链延长、自一致性投票、搜索树展开、验证器筛选等操作但不包括继续训练、LoRA 微调、领域数据二次预训练。很多团队遇到一个新任务第一反应是“找一批数据微调”。这个思路在垂直场景里仍然有效但它的代价是数据清洗、标注、训练、评估、发布一整套流程。纯推理绕开了训练环节直接让模型在推理阶段更“用力”。它依赖一个前提基座模型已经具备足够的知识和逻辑能力只是单次生成时没有找到正确路径需要更多尝试和校验。对比维度微调路线纯推理路线权重是否变化会变化模型被更新不变只改变采样和搜索策略需要任务数据通常需要几百到几千条标注数据需要少量题目做验证不需要重新训练成本集中点训练算力和数据标注推理算力、时间、验证器适合场景输出格式固定、领域知识密集多步推理、答案可自动验证上线速度数据准备和训练周期长配置好采样参数即可跑从这个角度看纯推理更像是在“用计算量换准确率”。对奥赛题这类单题难度大、题目数量少、答案高度可验证的任务纯推理的性价比会明显高于准备一批真题去微调。1.2 高难度奥赛题难在哪里奥赛题和普通聊天题最大的区别是它很少能被检索到也很难凭“见过类似题”直接命中答案。一道数学奥赛题往往需要多个步骤的组合先识别题目隐含结构再构造辅助线或代数变换中间可能要尝试反例最后还要证明每一步推导成立。模型单次生成时思维链只要在中间某一步跑偏后面的推导全部作废。更麻烦的是它可能连续输出很长一段“看起来很合理、但根本不合逻辑”的推导。人类阅卷时能看出中间错误但模型自己缺少外部检查。纯推理解决的就是这个“中间错误”问题。它不再只用一条思维链走到黑而是生成多条路径再通过投票、评分、搜索选出更优路径。奥赛题的结构越复杂单次生成的失败率越高多次生成和校验带来的提升就越明显。1.3 从成绩单看评估协议奥赛成绩背后有一个经常被忽略的问题评估协议。同样是“拿金牌”不同模型参与评估时可能面对完全不同的条件是否允许每个题目尝试多次是否允许运行外部代码或符号计算库是否使用验证器对答案进行自动打分是否有人工评委检查完整证明模型在训练阶段是否看过该届真题。这些条件任何一个发生变化成绩就没有可比性。公开讨论中经常把“模型拿了金牌”简化为“模型很聪明”但工程视角应该把它还原为“在某种评估协议下模型配合推理预算和验证器取得了某个分数”。协议比分数更重要。注意看到“XX 模型拿下奥赛奖牌”的消息第一步不是转发而是确认题目集合、训练数据隔离方式、允许的尝试次数和验证规则。这些条件全部对齐之后成绩才能用来横向比较。2. 推理阶段的计算从哪来采样参数与自一致性纯推理的第一个可操作方法就是让模型多生成几次。同样是“根据四则运算、代数方程等基础知识解题”不同采样参数下模型的行为差别很大。2.1 采样参数决定一次生成的质量在常见的生成接口中以下参数会直接影响推理结果参数常见默认值调小的影响调大的影响奥赛推理场景的参考temperature0.0 到 1.0输出更确定容易重复输出更多样思路开阔多步推理可用 0.6 到 0.9 增加探索top_p0.9候选词束窄结果集中候选词束宽结果发散与 temperature 配合不必同时调到极大max_new_tokens不同框架不同可能截断关键推导可承载完整思维链奥赛推导建议 2048 以上n1只生成一条路径生成多条路径用于投票8、16、32、64 按预算选择stop无影响输出完整性影响响应速度按数据集格式设置终止符这里要解释一个容易混淆的点temperature 不等于“让模型更聪明”。它改变的是采样概率分布低温让模型选最高概率 token高温让模型在概率接近的 token 之间有更多随机性。对高难度数学题单次低温生成很可能陷入同一类错误而高温多次生成反而能覆盖更多解题方向。2.2 多次采样后如何汇总结论自一致性对同一道题生成多条答案后怎么知道哪条是对的一个简单有效的方法是自一致性让模型对同一个问题生成多条独立推理路径每个路径给出最终答案然后统计答案出现次数次数最多的答案作为模型输出。下面是一个基于 transformers 的最小示例。代码前的说明是这个示例只用于演示思路实际项目要根据模型路径、对话模板和数据集格式调整。from transformers import AutoModelForCausalLM, AutoTokenizer import torch model_name your-local-model-path tokenizer AutoTokenizer.from_pretrained(model_name) model AutoModelForCausalLM.from_pretrained( model_name, torch_dtypetorch.bfloat16, device_mapauto ) def generate_answer(question: str, temperature: float, max_new_tokens: int 2048) - str: messages [{role: user, content: question}] prompt tokenizer.apply_chat_template(messages, tokenizeFalse) inputs tokenizer(prompt, return_tensorspt).to(model.device) outputs model.generate( **inputs, max_new_tokensmax_new_tokens, temperaturetemperature, do_sampleTrue, top_p0.9, ) output_text tokenizer.decode( outputs[0][inputs[input_ids].shape[1]:], skip_special_tokensTrue ) return output_text生成单个答案只是一个起点。下面这段代码把多次生成的结果收集起来提取最终答案并投票from collections import Counter def extract_answer(text: str) - str: # 按数据集约定提取最终答案这里只做示例 if 最终答案 in text: return text.split(最终答案)[-1].strip() return text.strip() def self_consistency(question: str, n: int 8, temperature: float 0.8): answers [ extract_answer(generate_answer(question, temperaturetemperature)) for _ in range(n) ] counts Counter(answers) best_answer, best_count counts.most_common(1)[0] return best_answer, counts代码中n表示采样次数。n越小推理成本越低但答案稳定性也越差n越大最终结果通常越稳定但耗时和 token 消耗会成倍增长。自一致性本质上不是在“认识题”而是在“合并多条解题路径的结论”。2.3 推理预算n1 和 n64 代表两种解法从产品视角看n 是纯推理最直观的旋钮。同一条问题n 不同解题策略也不同推理预算实际效果主要成本适合场景n1快速给出一个答案可能错最低普通对话、低延迟场景n8有一定多样性能纠正部分粗心错误中数学选择题、短答案n32多数情况下能找到稳定答案高高难度多步推理题n64接近投票收敛但收益递减很高奥赛题离线评测、答案难以确定时实际项目里不建议一上来就开 64 路采样。更稳妥的做法是先跑 n8 和 n16观察答案分布。如果多次生成的结果高度一致说明模型对这道题有把握如果答案分散说明题目难度超出模型单次推理能力再继续增加 n 或者引入搜索和验证器。3. 用验证器替代人工阅卷搜索机制和奖励模型多次采样加投票能解决一部分问题但它有一个明显弱点投票只统计“模型自己认为的答案”不判断“答案是否正确”。如果模型存在系统性偏差投票结果同样会错。要进一步提升需要引入外部评分和搜索机制。3.1 结果奖励模型和过程奖励模型的取舍奖励模型是给模型候选答案打分的模型。按照打分粒度可以分为结果奖励模型和过程奖励模型。比较面结果奖励模型 ORM过程奖励模型 PRM打分对象最终答案每一步推理过程数据标注成本低只需知道对错高需要标注每一步是否正确应用方便程度高直接排序候选中需要把生成拆成步骤对“蒙对”的容忍度容易被结果误导能发现中间逻辑错误适用场景答案可验证、步骤不重要的场景数学证明、复杂推理链条工程落地时很多团队先使用结果奖励模型因为标注成本低、实现简单。它的代价是奖励模型可能给错误推导打高分只要最终答案碰巧对。奥赛题更关注过程因此过程奖励模型往往更合适但它的训练数据更难准备。3.2 在解码过程里搜索从一条链到一棵树自一致性是“多条链并行”搜索则是“生成一步评估一步决定下一步”。搜索方法中最常被讨论的是蒙特卡洛树搜索及其变体。下面是一段用于说明搜索结构的伪代码def search(question, model, verifier, budget64): root Node(promptquestion) for _ in range(budget): node select(root) candidate model.generate(node.prompt) score verifier(candidate, question) backpropagate(node, score) return best_answer(root)伪代码里的四个关键步骤select从已有搜索树中选择一个值得继续扩展的节点model.generate基于该节点生成下一段推理候选verifier对候选打分判断这一步是否离正确答案更近backpropagate把分数传回路径上的节点更新后续扩展优先级。相比单纯的多次采样搜索的优势是“不平均用力”。它会把计算集中在看起来更有希望的分支上避免在明显错误的分支上浪费 token。代价是工程复杂度明显上升需要管理搜索树、缓存生成结果、并发执行节点展开还要额外处理奖励模型的分数噪声。3.3 验证器也有上限验证器不是万能判卷员。它本身也是一个模型可能存在以下偏差偏好某种措辞风格而不是数学正确性对长答案过度惩罚或过度奖励被“看似严谨但实际错误”的推导欺骗在训练数据分布之外的题目上失效。因此在评估纯推理效果时不能把验证器分数和真实答案正确率混为一谈。好的做法是把验证器当做一个排序工具而不是绝对真理来源。最终结论仍然要回到标准答案上做判定验证器主要用于减少无效生成和引导搜索方向。4. 在工程上搭一套纯推理评估流程理解原理之后下一步是落地。这里给出一套可以在本地跑通的最小评估流程。它不依赖具体模型名称重点在于把输入、输出、日志、指标都整理成结构化结果。4.1 环境准备和前置检查建议使用虚拟环境隔离依赖。以下命令在 Linux 或 macOS 环境下适用python -m venv .venv source .venv/bin/activate pip install transformers torch pandas如果后续需要提高推理吞吐可以再安装 vLLM。安装前先确认 CUDA 版本和 PyTorch 版本匹配避免出现“安装成功但无法加载模型”的问题。环境准备完成后建议先做一次极小的验证加载模型生成一句话确认 tokenizer 和模型能正常工作。不要直接开始跑奥赛题否则一旦基础环境有问题排错成本会高很多。注意不要只验证模型能启动还要验证输入输出格式。很多评估脚本的错误不在模型而在 prompt 模板、答案提取规则和数据集字段名不一致。4.2 定义统一的题目输入格式评估集建议使用 JSONL 文件每个题目一个对象关键字段如下{id: olympiad-001, question: 证明对于任意正整数 n表达式 n^2 n 41 是否可能为完全平方数, answer: 不可能}字段id用于追踪题目question是输入给模型的完整题目answer是实现定义的标准答案。实际项目中还要增加source、question_type、tags等字段方便按题型分析模型表现。4.3 批量跑题并记录日志有了输入格式之后编写一个批量评估入口。下面的示例会遍历所有题目对每个题目使用自一致性策略生成答案并记录耗时和候选答案分布。import time import json from collections import Counter def evaluate_dataset(dataset_path, n8, temperature0.8): results [] with open(dataset_path, r, encodingutf-8) as f: items [json.loads(line) for line in f] for item in items: start time.time() pred, counts self_consistency(item[question], nn, temperaturetemperature) elapsed time.time() - start results.append({ id: item[id], question: item[question], expected: item[answer], pred: pred, pass: pred item[answer], latency_seconds: round(elapsed, 2), candidate_counts: dict(counts), }) accuracy sum(r[pass] for r in results) / len(results) return results, accuracy这段脚本的关键点在于它不只记录最终对不对还记录每个题目的耗时和候选答案分布。后续调优时即使准确率没有变化也能通过耗时和候选分布判断模型是“犹豫但最终答对”还是“稳定答对”。4.4 跑一组参数矩阵单次评估只能回答“这个模型在固定参数下表现如何”。更完整的做法是跑一组参数矩阵比较不同n和temperature的效果。import csv configs [ {n: 1, temperature: 0.0}, {n: 8, temperature: 0.6}, {n: 16, temperature: 0.8}, {n: 32, temperature: 0.8}, ] summary [] for cfg in configs: results, acc evaluate_dataset(dataset.jsonl, ncfg[n], temperaturecfg[temperature]) summary.append({**cfg, accuracy: round(acc, 4)}) with open(fresults_n{cfg[n]}_t{cfg[temperature]}.json, w, encodingutf-8) as f: json.dump(results, f, ensure_asciiFalse, indent2) with open(summary.csv, w, newline, encodingutf-8) as f: writer csv.DictWriter(f, fieldnames[n, temperature, accuracy]) writer.writeheader() writer.writerows(summary)运行后重点看两个方向准确率随n增大是否明显提升。如果 n 从 8 增加到 32 准确率几乎不变说明投票已经收敛继续加预算没有意义。准确率随temperature变化是否剧烈。如果变化很大说明模型本身对采样很敏感此时更需要验证器或搜索来稳定结果。5. 评估奥赛题时最容易踩的五个坑纯推理评估看起来只要“跑脚本、算准确率”实际执行时有很多地方会悄悄污染结果。下面五个问题在真实项目里非常高发。5.1 数据泄漏模型可能在训练时见过真题如果模型训练时已经看过目标奥赛题那么评估出的成绩并不是纯推理能力而是记忆能力。问题现象常见原因检查方式处理建议准确率异常高单题推理时间却很短题目曾出现在训练语料中换新题、改数字、改人名、调整题干描述评估集必须与训练集隔离并使用新题或仿写题模型对题目非常熟悉直接输出结论训练语料包含真题和解析检查模型复述内容是否和网上解析雷同记录模型输出人工抽查原文相似度避免数据泄漏的最有效方法是使用新题目。如果只能用历史奥赛题就要把“模型见过题”作为一个风险写进评估报告不要简单认为分数代表推理能力。5.2 答案格式解析失败导致误判很多评估脚本的 bug 出在答案提取。模型可能输出“答案是 A因为……”也可能输出“我认为最终答案可以是 42”。如果extract_answer规则写得太简单大量正确回答会被判错导致模型真实能力被低估。解决方式是在 prompt 中强制要求模型把最终答案放在固定标记后面例如“最终答案”。同时在提取时保留原始输出方便人工检查失败样本。def extract_answer(text: str) - str: marker 最终答案 if marker in text: return text.split(marker)[-1].strip().split(\n)[0] return text.strip()不要直接对整段输出做全等比较。除非数据集本身是选择题否则应把“答案提取”和“答案比对”分开处理。5.3 验证器只看最终答案忽略过程错误如果使用结果奖励模型验证模型给出的过程完全错误但最终答案正确验证器可能打高分。这本身不是问题问题在于很多人把这种结果解释为“模型会推理”。要判断模型是否真的会推理至少要做两件事对输出进行步骤级检查抽看关键推导是否成立改变题目中的数字或条件看模型是否还能得到正确结果。如果题目一换条件准确率大幅下降说明模型更多是在匹配表面模式而不是理解逻辑。5.4 显存不足或推理超时纯推理对资源的要求很直接。n32 时每道题要生成多轮完整推理显存不够会直接触发CUDA out of memory或者推理时间超过接口超时限制。处理方式降低max_new_tokens但要注意可能截断推导限制并发数量避免多路生成同时占满显存使用批量推理框架例如动态批处理开启缓存同一题目重复评估时复用已生成结果。超时问题在本地脚本里不明显一旦接入在线服务必须把推理预算和超时时间一起设计好。5.5 评估集太小导致结论不稳定如果评估集只有 5 道题正确率 80% 意味着只错了 1 道换一道题结果可能变成 40%。这种波动会让参数调优失去意义。建议至少准备 20 道以上题目并按时长、难度、题型分层统计。奥赛题数量有限可以混合历年真题、模拟题和人工构造题但必须注明数据来源。6. 从奥赛题迁移到工程任务边界在哪里奥赛题是纯推理能力很好的测试场但它和真实工程任务并不完全一样。迁移时要先判断任务是否适合“用推理预算换准确率”。6.1 适合纯推理的任务特征以下任务特征越明显纯推理收益越高任务特征例子不适合的例子答案可自动验证数学题、代码题、SQL 生成开放式写作多步推理链条证明题、复杂数据清洗规则单轮分类允许较长响应时间离线批量处理、异步任务实时聊天机器人高错误代价财务对账、合同条款提取低风险文本摘要逻辑链条可以被拆成可检查步骤代码评审、数学证明风格迁移如果任务同时满足“答案可验证”和“可接受长延迟”纯推理往往比继续微调更快上线。6.2 不适合纯推理的场景在以下场景里增加推理预算可能带来负面效果接口延迟要求小于 1 秒无法等待多轮生成任务本身依赖实时数据库查询推理模型无法自行获取数据输出必须完全确定不允许多次生成得到不同结果token 成本非常敏感每次请求都要控制开销问题本身没有标准答案验证器也无法给出可靠分数。这些场景更适合把模型能力固化到规则、小模型或微调模型中。不要把奥赛题上的成功直接推导为“所有任务都应该加长思维链”。6.3 继续训练和纯推理不是二选一Meta 这次成绩引发的讨论里最容易被误解的一点是“纯推理已经可以取代针对任务的训练”。实际情况更接近推理阶段的计算能放大模型已有的能力却不能凭空制造完全不了解的领域知识。如果一个模型完全不知道项式、完全看不懂几何符号给它再多的推理预算也无法证明几何题。它必须先具备基础数学知识。因此更稳妥的技术路线是用通用数据和领域数据训练/微调让模型具备知识在推理阶段通过采样、搜索、验证器释放这些知识根据评估结果决定下一步是继续训练还是继续增加推理预算。这条路线可以简单表达为训练决定能力上限推理决定能力释放多少。两者不是替代关系而是配合关系。7. 最佳实践与下一步可以做的事纯推理不是一个固定公式它是一套由多个模块组成的推理系统。上线前需要把整个链路检查清楚。7.1 推理任务上线前检查清单以下清单可以在每次实验或上线前逐项确认评估集是否与训练集隔离是否包含新题题目输入格式是否统一字段是否完整prompt 是否明确要求模型输出“最终答案”标记max_new_tokens是否足够容纳完整推理过程采样次数 n 是否经过了参数矩阵实验结果提取脚本是否有对应的失败样本人工检查流程日志是否记录了模型原始输出、候选答案分布、耗时指标是否区分准确率、验证器分数和人工抽样通过率推理服务的并发和超时是否与预算匹配是否记录了当前模型版本、prompt 版本、评估集版本。7.2 参数调优的顺序不要同时调多个参数否则很难定位结果变化来自哪里。推荐顺序是先修正输出格式保证答案提取准确固定temperature0.8调 n找到准确率拐点固定 n调 temperature找到稳定区间加入验证器或搜索对比加之前后的准确率和耗时最后计算成本决定线上选择多大预算。每一步只改一个变量并把结果记录到表里。7.3 扩展方向如果已经跑通自一致性评估下一步可以继续深入以下方向引入过程奖励模型对中间步骤打分而不是只看最终结果实现搜索树并接入验证器观察解题效率是否高于等量采样使用更强的基座模型比较“更强的模型配合小预算”和“较弱模型配合大预算”的性价比把奥赛题替换为代码竞赛题、数学应用题或 SQL 生成题验证迁移能力用日志和评估结果构建回归集防止后续模型版本迭代导致推理能力下降。如果把奥赛成绩当作一个观察点更值得关注的是推理计算的价值正在被重新定价。过去注意力集中在“如何让模型记住更多知识”而现在越来越多的实验表明模型在训练阶段学到的推理能力可以通过推理阶段的计算被进一步释放。对工程团队来说这意味着评估流程、成本模型和参数策略都要重新设计。先搭好一套可复现的纯推理评估链路再去讨论分数和排名才不会把一个有意思的技术现象误读成单纯的新闻事件。