论文精读这个系列断更了挺久今天想认真拆一篇让我反复琢磨的工作SequenceO1。如果你过去半年也泡在大模型推理这一块应该早就注意到一个风向的转变——大家不再只盯着模型规模和训练数据的堆量而是开始认真研究让模型在回答之前多想一会儿这件事也就是o1引爆的推理时计算test-time compute路线。SequenceO1做的就是把这套慢思考逻辑下沉到序列生成这个最底层的环节上把一次性的自回归解码重构成一个带着验证和回溯的搜索过程。这篇文章适合所有正在做推理加速、解码策略、强化学习和奖励模型的同学读我会从背景动机、整体框架、技术细节、训练流程、实验结果到落地踩坑把一个完整的搜索式生成系统彻底拆开。1. 为什么SequenceO1值得精读一次解码的天花板与推理时计算的兴起1.1 从快思考到慢思考o1真正改变了什么在o1出现之前大模型生成回答的路径基本是固定的给定prompt自回归地一个token一个token往下蹦beam search或者greedy decoding选一个看起来最顺的序列。这套流程简洁但有个隐含假设——你已经知道什么是最好的下一个token。这个假设在简单续写场景勉强成立但在数学、代码、规划这类需要多步推理的任务上根本站不住脚。o1带来的范式转移本质上是把生成质量从模型的静态能力问题变成了推理预算的动态资源问题。模型不再是写完就算完而是先产生一段内部推理轨迹在轨迹上反复推敲最终给出答案。这里的关键不是模型会写推理过程这层表象而是允许模型消耗更多推理时计算来换取正确率这个底层逻辑。你可以把它理解成考试时先打草稿再誊写打草稿本身不产生分数但它大幅降低了你最终誊写时出错的可能性。这个转变对研究者和工程团队的意义非常大。以前提升准确率的路径只有三条加参数、加数据、加训练算力。现在多了一条性价比很高的路——加推理时计算而且这条路上的资源开销是可控的你可以根据任务难度动态调整这给了部署侧很大的操作空间。1.2 序列模型面临的独特问题错误是滚雪球的虽然o1的思路很诱人但直接套到序列生成任务上你会立刻撞上一个棘手问题自回归生成是一步错、步步错的过程。在第5个token上犯一个看似轻微的错误到第50个token时可能已经完全偏离正确方向而且模型自己毫无感知因为它没有回头看的能力。人写代码、写推导过程的时候会不断回头检查、推翻、重写。现在的Transformer做生成时却是一次性的前向传播从头跑到尾中间没有任何修订机制。beam search看似提供了多条候选路径但它实际上只是在每一步保留概率最高的几个分支选择依据是语言模型的概率分布而不是这条路径是不是正确。问题在于语言模型的高概率token和正确token之间没有必然联系——一个流畅但与事实相悖的推导概率往往比磕磕绊绊但正确的一步更高。这正是SequenceO1这类工作要补上的东西给序列生成过程加一个编辑和质控环节让模型像人一样先铺开几条路、用验证信号筛选、不合适就回溯重来。这个想法说起来直白真正难的是把验证信号做出来以及把搜索过程调得既高效又稳定。1.3 SequenceO1要回答的核心问题读这篇论文之前我先把作者要面对的问题清单列了出来一共四个如何把序列生成组织成一个可搜索、可验证的过程搜索的节点和边怎么定义才不会因为token粒度过细而爆炸。如何训练一个能对部分序列打分、而不仅是给完整答案打分的验证器这是整个框架的地基。在给定推理预算下如何决定往哪条分支扩展、什么时候回溯、什么时候停止这决定了搜索的性价比。搜索得到的优质轨迹怎么反哺策略模型本身让模型在单次生成时也能变强后面所有技术细节其实都是围绕这四个问题的回答展开的。这篇论文里大多数设计决策都可以拿这四问当坐标去理解。2. 整体框架拆解策略、验证器、搜索控制器如何各司其职2.1 三个模块的分工写手、编辑和主编SequenceO1的框架并不复杂经典的三件套策略模型policy、验证器verifier、搜索控制器search controller。我习惯用编辑部来类比策略模型是写手负责产出候选文本验证器是编辑负责判断每一篇稿子的质量搜索控制器是主编决定让哪个写手继续写、哪个稿子毙掉、版面预算还剩多少。写手策略模型就是普通的生成模型负责在选定节点上采样若干续写片段。需要说明的是它不一定要很大。这类工作的一个共同发现是在验证器足够强的前提下一个中等规模的策略模型配合搜索可以逼近甚至超过一个更大规模模型直接贪婪解码的效果。原因后面在实验部分细说。验证器verifier是整个框架的灵魂。它接收一个部分序列前缀输出一个分数表示从这个前缀继续往下走最终得到正确答案的可能性。注意它评估的不是当前这段文字通不通顺而是顺着这条路走下去有没有前途。这两者的区别非常关键——通顺的废话和正确的推导在语言模型眼里可能分数相近但在验证器眼里必须拉开差距。搜索控制器则是容易被低估的模块。它维护一棵搜索树负责节点选择、扩展、回溯和终止。它的决策直接决定了同样的推理预算能换来多少收益预算分配得好小成本就能达到大效果分配得差搜索一万步还不如直接生成。2.2 和beam search、MCTS解码的本质区别很多读者第一次看到这个框架会觉得这不就是beam search吗或者这不就是MCTS解码吗我一开始也有这个疑惑但仔细对比之后区别其实很本质。方法选择依据是否有正确性验证是否支持回溯计算分配方式标准beam searchtoken似然概率无无固定宽度贪心MCTS解码UCB/访问次数叶子奖励部分通常只看最终结果有动态但状态管理复杂SequenceO1式搜索验证器对前缀的过程评分有每一步都能打分有预算自适应beam search的选择依据是似然概率它本质上假设概率高的路径更可能是好路径这在开放式续写里大致成立但在需要精确推理的任务里会系统性偏向流畅的平庸。MCTS解码引入了探索和回溯但大多数实现里的奖励信号来自完整的最终结果叶子节点的反馈很难定位到中间哪一步出了问题而且MCTS需要维护复杂的访问计数、父节点回溯工程成本不低。SequenceO1式的设计把验证放在了前缀层面每扩展出一个新节点验证器立刻给它一个过程分数控制器可以基于这个分数决定是继续深耕这条分支还是回到别的分支重新试。这个边生成边判断的能力是从根本上区别于前两种方案的地方。2.3 几个关键设计选择背后的动机为什么要让验证器独立于策略模型而不是直接用策略模型自己的概率当验证信号原因有两个。第一验证比生成容易判断一个部分推导是否有希望通常比从零写出正确推导要简单得多所以验证器可以用更小的规模达到不错的准确率推理成本低。第二策略模型的目标分布和正确性不是一回事用同一个模型既当选手又当裁判等于让考生自己改自己的卷子很容易出现自信但错误的系统性偏差。为什么搜索节点不切到token粒度而是切到片段segment粒度这个也是实操里非常关键的选择。token粒度的树深度动辄几百上千搜索空间以指数级别膨胀验证器要调用的次数也多到无法接受。切成一个推理步骤、一行代码、一个句子这样的片段树的深度降到几十同时保留了对错误发生在哪一步的定位能力。代价是语义级别的片段切分需要一点任务特定设计这是工程上必须接受的灵活性。整个框架最妙的地方是把生成什么内容和什么内容算好这两件事彻底解耦了。解耦之后你可以独立升级验证器而不动生成模型也可以在部署时只调搜索控制器的预算参数不需要重新训练任何模型。这种模块化设计是它区别于很多思路相似但绑死在一起的方案的最大优势。3. 搜索过程的技术细节从节点定义到预算分配3.1 搜索空间的节点和边为什么片段级粒度是工程底线如果把搜索过程形式化一棵搜索树的根节点是空序列叶子节点是完整生成的序列中间节点是各种长度的前缀。从父节点走到子节点就是策略模型生成了一段新的续写内容这个续写可以是几个token也可以是一整段有语义的单元。我在复现这类工作的时候试过token级节点很快就放弃了。假设答案平均长度200 token深度就是200哪怕每层只扩展2个候选整棵树的理论节点数也远超能接受的范围。更麻烦的是验证器要对每个新节点打分每一分都要一次模型前向token级树会让推理开销爆炸。换成片段级节点之后深度通常能压到10到30搜索树的规模立刻可控了。片段怎么切论文里通常不会给你一个万能答案因为不同任务差异很大。代码任务可以按行切或按语句切数学推导可以按等式/逻辑步骤切结构化生成比如SQL可以按子句切。我的实际经验是宁可把片段切得稍微大一点也不要切得太碎太碎的片段会让验证器难以判断这一步本身是否有价值因为单个token几乎不携带语义信息。3.2 验证器PRM是怎么训练出来的从结果标签到过程标签验证器的训练是整个框架里最核心、也最容易被低估的部分。SequenceO1里用的验证器本质是一个过程奖励模型Process Reward Model, PRM它输出的分数要反映给定这个前缀最终得到正确结果的概率。问题来了结果标签是好拿的——数学题的正确答案、代码题的单元测试、SQL题的执行结果都是自动可以判定的。但部分前缀没有天然的正确答案你怎么给一个只写到一半的推导步骤打标签常见的做法是蒙特卡洛估计对每个前缀从这个前缀出发让策略模型采样N个完整生成结果用自动判定器判断每个结果的正确性然后把这个前缀的标签设为N次采样中成功次数的比例。比如某个前缀采样8次其中6次最终得出了正确答案那这个前缀的过程分数就标成0.75。这个做法看起来简单暴力但实际效果很好是很多开源PRM项目的标准方案。需要注意的坑是N不能太小太小标签噪声大验证器学出来的分数会非常不校准N的典型取值在8到32之间看算力而定。除了蒙特卡洛标签通常还会混入一部分人工或更强模型标注的数据用来修正那些采样结果正确但推理过程本身有缺陷的边界情况。这类数据不需要很多但能明显提升验证器对中间步骤的判断力。3.3 计算预算分配什么时候该继续搜什么时候该收手有了策略模型和验证器搜索控制器要解决的核心问题就是预算怎么花。最基本的是固定预算模式——给定总计算量上限控制器把这笔预算分配到各个分支上。更实用的则是自适应模式控制器根据当前搜索情况动态决定是否提前停止。自适应停止的直觉是当验证器对某条分支的分数已经很高且继续扩展的分值提升非常小比如连续两轮的变化小于一个阈值再往下搜就是浪费算力反过来如果所有分支的分数都很低而且互相之间拉不开差距说明这个任务对当前策略模型太难继续盲目加宽意义也不大不如早点停。我给出一个搜索主循环的伪代码方便对照理解def search_with_budget(prompt, budget): root create_node(prompt) tree [root] used 0 while used budget: node select_node(tree) # 综合验证器分数与探索奖励选节点 children expand(node, k5) # 策略模型采样5个续写片段 for child in children: child.score verifier(child) # 过程奖励模型打分 used child.token_count # 记账这轮花了多少token if should_stop(tree, delta0.03): break return best_leaf(tree)select_node这一步主流做法是在验证器分数的基础上加一点探索项避免控制器每次都只盯着当前最高分分支陷入局部最优。简单的做法是用epsilon概率随机挑一个次优节点复杂的做法是上个UCB风格的公式。从我自己的复现经验来看对于大部分任务简单的epsilon探索就够用了UCB带来的提升往往被实现复杂度和额外调参抵消。should_stop的判定我习惯同时看两个信号当前最优叶子分数有没有在持续爬升以及剩余预算下的期望边际收益是否低于阈值。这两个信号都不需要精确计算经验值后面复现章节会给。3.4 搜索过程的工程实现要点最后补一点工程层面的细节这部分论文不会写但真跑起来全是坑。搜索过程里大量节点共享相同前缀一定要做KV cache复用不然同一个前缀被反复计算推理开销会翻好几倍。其次对同一节点的多个候选采样可以并行化充分利用batch推理——这一步带来的提速比优化搜索算法本身还明显。另外验证器打分尽量和策略模型分开跑避免抢占显存导致吞吐抖动。4. 训练流程先把搜索蒸馏进权重再用过程奖励强化4.1 阶段一把搜索结果蒸馏回策略模型如果只有搜索过程模型在部署时的成本会很高——每个请求都要跑一整棵搜索树。所以论文通常都会有一个把搜索收益压缩回模型权重的步骤也就是蒸馏。思路很直接用搜索过程在训练集上跑出一批高质量轨迹每条轨迹都是prompt → 最终被验证器认可的结果然后拿这批数据对策略模型做监督微调SFT。这个阶段的效果很神奇却又在情理之中——搜索相当于给模型当了一个会反复检查修改的老师模型通过模仿老师的输出把一部分原本需要推理时计算才能达到的能力提前内化到了参数里。经过蒸馏的模型即使用贪婪解码准确率也会比原始模型高一截这就是为什么这类框架在部署时可以搜索/直接生成两用算力充足时跑搜索算力紧张时直接单次生成两头都不亏。蒸馏数据里要不要包含中间推理轨迹本身是个值得斟酌的点。我的经验是对于数学、代码这类任务把搜索过程中被验证器高分认可的中间步骤也作为监督信号效果会更好但如果任务比较开放中间步骤的格式自由度太大容易让模型学到啰嗦而不是正确这时候只蒸馏最终结果反而更稳。4.2 阶段二用过程奖励做强化学习解决信用分配问题蒸馏能提升单次生成的下限但要让模型学会主动进行长线思考还需要强化学习的推一把。这里的关键是用过程奖励而不是结果奖励。结果奖励的问题在于信用分配credit assignment一条100步的推导最后错了你不知道是第10步错还是第80步错把同样的惩罚给到所有步骤模型很难学到在哪一步改。过程奖励的粒度是每一步验证器给每个前缀都打了分你可以把这个分数当作每一步的奖励信号用策略梯度方法PPO或者简化的REINFORCE去优化策略模型让模型在那些验证器认为有前途的方向上增加概率在验证器认为绝望的方向上降低概率。这轮强化学习做完模型的行为会发生一个明显变化它开始学会先试探再确认生成的轨迹里会出现更多回头修正、换个角度重推的步骤。换句说o1式的慢思考行为不是靠提示词教出来的是靠过程奖励一步步塑形出来的。4.3 训练稳定性的实战经验这个两阶段流程看起来清晰真跑起来问题不少我把自己踩过的坑列几个奖励漂移。强化学习跑一段时间后验证器分数的分布会整体偏移原本0.6算高分后来0.6变成低分。原因是策略模型的输出分布变了验证器在分布外前缀上的行为不稳定。对策是定期用新策略模型重新采样一批搜索轨迹对验证器做校准甚至微调。KL失控。策略模型在奖励压力下容易往高分但语义异常的方向坍缩比如生成一些让验证器误判的模板化文本。PPO里KL散度惩罚的系数要盯紧我用下来0.1到0.5之间的量级比较常见具体要看模型规模。验证器和策略模型螺旋上升。搜索轨迹越来越偏验证器和模型互相适应最后在训练分布上分数虚高一到真实评测就崩。这个没什么灵丹妙药只能靠定期在固定的外部测试集上做检查发现分数虚高就回滚数据分布。提示如果你看到训练损失正常下降但外部验证集分数异常波动先查验证器校准再查搜索轨迹分布大概率是两者已经互相适应了。5. 实验揭示的三个关键规律算力缩放、验证器天花板、宽深权衡5.1 评测任务怎么选为什么都是可自动验证的任务读这类论文的实验部分第一件事是看任务选择。SequenceO1式的方法挑基准是有讲究的必须选那些最终结果可以自动判定对错的任务因为验证器训练依赖大量的结果标签。数学应用题、代码生成、SQL生成、结构化规划都是这类任务的典型代表。反过来开放域问答、创意写作这类任务结果对错没法自动判定过程验证更是无从谈起所以这类方法很少拿它们当主战场。理解了这个前提你再去看实验结果就不会被看起来提升很大的标题党带偏这些提升本身是真实的但它的适用范围是被可验证性划了界的。5.2 第一个规律推理时计算和准确率近似对数线性关系这类工作反复出现的一个规律是准确率随推理时计算量的对数近似线性增长然后逐渐饱和。换句话说你把搜索预算从1倍调到2倍准确率涨一截从2倍调到4倍再涨一截但每一截都比上一截小。这个规律和模型的训练阶段缩放律非常像只不过自变量换成了推理时的计算量。这个规律的工程意义很强。它意味着你可以给预算和准确率建模提前算出为了达到某个准确率目标我需要给每条请求分多少计算量而不是靠感觉拍脑袋。我自己做容量规划时会先在少量数据上画出一条计算量-准确率曲线然后据此反推部署成本比直接上全量搜索靠谱得多。5.3 第二个规律验证器质量是搜索收益的天花板这个结论是我认为整篇论文里最值得记住的一句话搜索的收益上限由验证器决定而不是由策略模型决定。如果你把验证器换成一个很弱的信号——比如直接用语言模型的似然概率打分——搜索的效果会迅速退化到接近beam search的水平甚至更差因为似然概率会系统性地偏好流畅的废话。反过来一个强验证器配合中等策略模型效果常常可以超过大模型直接贪婪解码。这个结论解释了这类框架为什么在工程上划算训练一个中等规模的验证器比训练一个大一个量级的生成模型便宜得多而部署时的搜索开销又是可控的。验证比生成容易这个直觉在这里变成了实实在在的性价比优势。5.4 第三个规律搜索宽度和深度的权衡消融实验里最典型的发现是加宽每层扩展更多候选和加深允许更多轮回溯重写带来的收益不是对称的。策略模型比较弱的时候加宽更有效——因为主要瓶颈是候选里根本没有正确答案多采几个样就能提高命中率。策略模型本身已经不错的时候加深更有效——因为主流错误是局部的推导失误给模型更多回头修正的机会比给它更多平行候选更管用。这个规律给调参提供了明确方向先评估你的策略模型是弱生成还是强生成再决定搜索树该长得胖一点还是高一点。我见过不少团队一上来就把width和depth都拉到很大结果算力烧掉大半收益却只来自其中一维另一维纯属浪费。6. 复现路上的坑算力估算、验证器过拟合与超参数经验值6.1 先算清楚账一条搜索请求到底要烧多少token复现这类工作的第一道坎不是代码是算力预算。先给出估算公式单条请求的搜索开销token≈ 每节点采样数 k × 搜索宽度 width × 搜索深度 depth × 平均片段长度。举个实际例子k5、width4、depth8、平均片段长度50 token那么单条请求大约会消耗 5×4×8×50 8000 token。对比一下普通贪婪解码的答案长度可能就200 token直接差出40倍。如果你没有把这笔账提前算清楚第一批实验跑完就会发现自己把周预算烧光了。注意算力账要按最坏情况算因为搜索中会有重复路径、验证器额外前向、框架调度开销实际开销往往比公式估算再高20%到30%。应对办法是分档先在小规模数据上用宽度2、深度3的低配版本跑通主链路验证收益方向正确再逐步往上加预算。不要一上来就追求论文里的最大配置那通常是为了刷指标不是为复现者准备的。6.2 验证器过拟合的三种典型症状验证器是整个框架的天花板也是复现时最容易出问题的环节。我总结了三个高频症状遇到可以直接对号入座症状可能的根因处理方式训练集验证器准确率很高但搜索收益几乎为零验证器只在训练分布上有效对策略模型新采样的前缀失效采样前缀时混合多种策略模型增加分布覆盖定期用新轨迹重训PRM搜索越久验证器分数越高最终答案反而变差验证器被格式漂亮但语义错误的文本欺骗检查分数校准给过长的候选加长度惩罚补充高分错误样本到训练集自适应停止阈值完全失效早停早坏或晚停浪费验证器分数分布漂移原阈值不再适用改为按相对变化量停止而不是绝对分数阈值这些症状的共同根源是验证器没有见过策略模型在探索过程中产生的各种奇怪前缀。所以训练验证器时采样数据一定不能只来自最终答案要多去获取那些半路夭折的中间节点让验证器见过足够多的失败形态。6.3 搜索超参数的经验取值范围给出我试过且比较稳的参数范围仅供参考具体任务上需要微调参数作用常用范围备注采样温度控制候选多样性0.7 ~ 1.0探索阶段略高蒸馏数据生成时可低些top_p截断低概率token0.9 ~ 0.95太高容易散太低容易重复每节点采样数 k候选数量4 ~ 8策略越弱k越该取大搜索宽度 width并行分支数2 ~ 8预算有限优先砍宽度搜索深度 depth回溯重写轮数3 ~ 10策略较强时可加深长度惩罚抑制无意义长输出-0.1 ~ 0.3防止验证器被废话刷分停止阈值 delta自适应停止灵敏度0.02 ~ 0.05以分数变化量为准别用绝对分数这些参数是强耦合的调参时一次只动一个并且每次改完都要在固定的验证集上画计算量-准确率曲线而不是只看一个点的分数。只看单点容易把偶然当规律。6.4 什么时候不该用SequenceO1最后泼一盆冷水这个框架不是银弹。以下场景我建议慎用甚至不用延迟敏感的在线服务。一次搜索要跑几千token用户体验上就是多等好几秒甚至几十秒除非收益大到值得否则别硬上。没有可靠结果判定的任务。开放域写作、闲聊、情感陪伴结果对错本身模糊验证器没有靠谱的监督信号训练出来就是个风格打分器套上去只会增加成本不会增加质量。策略模型和验证器都很弱。两弱相叠搜索只会把错误放大。先把验证器质量做上去再谈搜索框架。我自己判断的标准就一条这个任务是否答案可验证。能就值得上搜索制胜不能就别为了技术新鲜感牺牲成本和延迟。7. 我的评价与后续可以延伸的方向7.1 这篇工作最大的贡献把推理时计算变成可设计的系统读完整个框架我认为SequenceO1最大的贡献不是某个单一模块而是提供了一个完整的、可模块化替换的推理时计算系统设计。策略模型、验证器、搜索控制器三个组件各自独立演进互不绑架训练阶段有蒸馏、有强化、有迭代自我提升部署阶段有固定预算和自适应预算两种模式。这种系统性让后来者可以在它基础上做很多换零件的工作而不用从头造轮子。对研究者的价值在于它把搜索这个经典话题重新拉回到大模型时代的聚光灯下并且给出了一个工程上可落地的形态。对工程师的价值则更直接你想在已有模型上提升推理任务的准确率不一定要重新训练一个更大的模型可以先训练一个验证器、加一个搜索控制器看看收益再说。7.2 我看到的局限首先是验证器这个瓶颈并没有被真正解决。PRM的训练依赖蒙特卡洛采样标签噪声大成本高验证器在分布外前缀上的失效问题也没有根本性的解法只能靠数据多样性和定期重训来缓解。其次是搜索的语义粒度需要任务特定设计token级不可行、片段级又要人工定规则这限制了框架迁移到新任务的速度。另外搜索过程仍然是在离散token的序列空间里进行的而人和模型真正的高效思考其实发生在更抽象的语义或者潜在表示层。离散空间搜索的每一步都在把想法写成文字之后才能验证这个环节本身就是很大的浪费。我猜测下一代的这类工作会逐步往潜在空间latent space的搜索上走。7.3 可以延伸的方向如果我想在这个框架上继续做点东西会优先考虑四个方向潜在空间搜索直接在模型的隐藏状态上做搜索和验证省掉把想法落成token再验证的浪费。这个方向技术难度高但一旦跑通推理成本和质量的性价比会再上一个台阶。难度自适配训练一个轻量的难度预测器简单问题上直接贪婪解码难题上才启用搜索。这相当于给SequenceO1加了一个预算调度层能把平均成本拉低好几个数量级非常值得做。蒸馏的深挖用搜索生成的高质量轨迹不只是做SFT还可以生成带过程标注的数据去训练更小的模型让小模型在部署端也能继承一部分搜索收益。验证器的轻量化尝试用更小规模的验证器配合知识蒸馏把PRM做到可以随策略模型一起本地部署的规模扩大框架在边缘设备上的适用范围。最后说说我自己的实操体会。当时复现这套流程最花时间的不是搜索代码而是验证器的数据构造——蒙特卡洛采样怎么选N、前缀怎么采、要不要掺人工标注每一步都在影响最终效果。如果你也想在这条路上试一把我建议先别急着搭完整的搜索框架而是先做一个最简版本用策略模型采一批候选拿一个现成的判别器LLM-as-a-judge也行当验证器把这个候选生成验证链路的准确率上限测出来。如果这条链路的收益连一个简单的多采样投票都打不过那说明问题出在生成或验证本身搜索控制器的优化做得再好也白搭反过来只要这条链路有明显提升空间后面每一步投入就都值得。
