SequenceO1：当推理从token级跃升到序列级，长文本生成的新范式

开篇先说清楚一件事这篇论文的标题挂着“SequenceO1”但别被名字骗了。它讲的不是又一个“把O1的结果蒸馏成SFT数据”的跟风工作而是把O1那套“先想后答”的推理范式从“单步思考”推广到了“整段序列生成”的层面。我读第一遍的时候以为又是“Long CoT 过程奖励”的老配方读到训练目标那块才意识到它在思考粒度、奖励建模和推理时预算分配上都做了跟以往不一样的设计。这篇文章我会按自己的精读习惯来写先拆清楚它到底要解决什么问题再逐层过核心模块最后给出我复现和实测时踩过的坑。适合正在做长文本生成、Agent任务规划、以及推理时扩展inference-time scaling方向的人参考。1. 论文要解决的问题与整体设计思路1.1 从O1到SequenceO1思考粒度从“句子”升级到“序列”O1系列模型出圈的时候大家最直观的感受是“模型会思考了”。但仔细看O1的思考方式本质上还是围绕着“下一步该输出什么token”做展开思维链再长落脚点也是逐字逐句地推演。这种粒度在数学题、代码题这种“目标明确、路径单一”的任务上非常管用可一旦换到长文档生成、多步骤工具调用、长对话规划这类场景问题就变了模型需要的不是“下一个词怎么接”而是“这一段整体该怎么组织资源往哪里分配”。SequenceO1的核心切入点就在这里。论文把推理的主体从token级别提升到sequence级别让模型在生成正文之前先产出一份“序列级方案”再基于方案分块执行。说得直白一点普通大模型生成一篇技术报告是拿着第一句话一路往下“滑”SequenceO1生成同样的报告会先在草稿纸上写下“第一段讲背景、第二段给方法、第三段贴实验数据、最后一段放结论”然后才动笔。它不改变模型底座而是在训练和推理阶段分别引入了“规划模块”和“执行模块”两者由一套统一的序列级目标串起来。这个shift最有价值的地方是它把“推理时计算”重新定义了。以前加推理时计算无非是增加思维链长度、加大beam search宽度本质上是在同一个决策空间里多采样。SequenceO1的做法是在“方案空间”里做搜索方案数量通常比token数量少几个数量级但每个方案的“含金量”高得多。论文里反复强调一个观点推理时扩展的效率不取决于你消耗了多少FLOPs而取决于你在正确的抽象层次上消耗了多少FLOPs。从实验结果来看同样是2倍推理开销SequenceO1在长文档连贯性和任务完成度上的提升明显大于单纯拉长CoT。1.2 整体架构拆解规划、执行、校验三层各司其职整套框架可以粗分成三层对应着“做事之前想什么、做事时怎么做、做完怎么判断”。规划层负责生成skeleton也就是把输入任务拆解成若干子目标的有序列表。这个skeleton不是自然语言的“思考草稿”而是带结构标记的“意图序列”每个节点由“动词意图 携带参数”组成。比如“写一篇产品调研报告”skeleton可能是这样[分析需求] - [收集竞品信息] - [对比优劣势] - [输出建议章节]。有意思的是论文让规划模块同时输出“预估开销”也就是给每个子目标标注一个token预算权重比如竞品分析占30%、对比占40%。这个设计直接影响后面的动态预算分配是整个框架里很容易被忽略但很关键的点。执行层拿到skeleton之后不是一口气把整篇内容写完而是按子目标逐个生成每个子目标内部再走一遍“块级解码”。所谓块级解码就是每生成一个段落块执行层会把当前已生成的上下文交给校验层做一次“过程检查”而不是等到全文生成完再回头算总分。这个机制把长文本生成从“一锤子买卖”变成了“边做边改”任何偏离skeleton意图的生成在损失蔓延之前就会被拦下来。校验层本质上是一个过程奖励模型Process Reward Model, PRM不过它的打分单元不是token而是“子目标块”。它会同时评估两个维度生成内容是否忠实于当前skeleton节点以及生成内容对后续节点有没有正向铺垫作用。注意第二点这跟很多只做“局部正确性”打分的PRM不一样它引入了“前瞻性”评估。举个例子写竞品分析那一段的时候如果内容里顺带埋了“该竞品的定价策略”这个伏笔而skeleton里正好有“对比定价”的后续节点这一块的奖励就会上调因为它在为后面的节点蓄力。这三个模块不是简单串起来就完事论文给它们设计了一个共同训练目标用强化学习统一优化“规划收益 执行收益 校验收益”。训练时三个模块梯度互通不是各训各的这也是它跟我之前读过的“Plan-then-Write”类模型最大的区别。那些模型通常是规划训完冻结生成再单独训本质上还是pipeline错了就只能错着往下传。SequenceO1允许执行阶段的反馈反向修正规划阶段相当于给规划模块开了“复盘”通道。1.3 方案选型背后的考量为什么不用两阶段pipeline读论文的时候我专门停下来想过一个问题规划器和生成器分开训其实技术上也能跑通为什么作者非要搞成联合优化多麻烦啊。答案藏在实验的消融里。如果规划模块冻结不动执行模块单独训效果比完整版掉了将近12个点这个差距在长文档任务里非常明显。原因也好理解冻结规划器的时候规划器不知道执行器能干什么、不能干什么经常规划出“当前模型能力根本做不到”的子目标。这就像项目经理不懂程序员的技术栈排了个“两周内上线一个分布式数据库”的计划执行团队只能干瞪眼。反过来如果只有规划模块参与反向传播执行模块冻结效果也掉但掉得少一些说明主要矛盾还是“规划与执行之间的信息不对称”。联合优化让规划器学会“按执行器的真实能力来规划”执行器也会慢慢学会“把规划器的意图执行得更忠实”。这两者互相咬合形成了正反馈。论文里把这种现象叫做“能力对齐”我觉得翻译成大白话就是目标和能力必须在一个频道上否则目标写再好也是墙上画饼。另外还有一个细节为什么不直接让大模型生成完整长文再用LLM-as-a-judge循环修改作者在related work里隐晦地怼了这类方法核心论点是“全局评估的反馈噪声太大”。一篇文章有几十个点可能写得不够好你让judge模型打分它给你一句“内容不够深入”这反馈根本没法指导局部修正。校验层把反馈粒度切到子目标级之后模型才能知道具体是哪一句、哪个段落出了问题。这个思路跟我在实际工程里的经验完全一致——粒度太粗的反馈等于没有反馈。2. 核心机制拆解骨架规划、块级解码和过程奖励2.1 骨架规划模块与动态预算分配骨架规划是整个框架的“大脑”也是实现起来最繁琐的部分。论文里的规划器输入是任务描述输出是一个结构化的skeleton序列每个节点包含三部分信息意图类型、参数内容、预算占比。意图类型不是让模型自由发挥的文本而是限制在一个由任务聚类得到的意图集合里。论文里给出了一个例子集合分析、对比、总结、举例、引用、解释、推导、建议。用闭集而不是开放集我当时有点不太理解后来想明白了如果允许模型随便发明意图词skeleton的可计算性就没了。校验层没法判断“执行结果是否符合某个意图”除非意图本身是离散且可枚举的。这个设计牺牲了一点点表达能力换来了整个框架的可训练性值。预算占比的分配是一个很有工程味道的设计。它本质上是在告诉执行层别在前两个节点上把上下文窗口耗尽后面还有重头戏。预算占比的标注来自训练数据构造方法是拿人工高完成度的长文按段落反推每个段落的“相对信息量权重”然后归一化成百分比。论文里给了一个示例写一篇对比分析类文章skeleton可能是“①明确对比维度5%②列举产品A特征25%③列举产品B特征25%④对比差异30%⑤总结建议15%”。执行层遵循这个预算去控制每个块的生成长度就不会出现“前两段写到超长后面草草收尾”的典型长文病。动态预算分配不是死板的执行层有权利“超支”。每个子目标执行完之后校验层会给一个置信分如果当前节点内容质量高但预算已经用完模型允许超支20%方式是从后续节点临时“借调”预算。这种“任务执行中的资源挪用”机制我看了好几遍才确认它的必要性——在真实写作里重要部分多写两句太正常了硬卡预算反而会让内容断裂。2.2 序列级执行与块级解码机制如果说骨架规划是“大脑”块级解码就是整个框架的“手”。传统自回归解码是逐token生成上下文长度一上来早期生成的低质量内容会像雪球一样越滚越大。块级解码的思路是把生成过程切成一串长度可变的块每生成完一个块就触发一次校验校验通过才继续下一个块校验不通过就触发局部重写。具体来说执行器每次生成的不是一个段落而是“一个意图块”。比如skeleton节点是“列举产品A特征”执行器生成的内容块就是围绕产品A展开的3-5句话块之间用特殊分隔符标记。分隔符的设计挺关键论文用的是[SEQ_BLOCK]这种显式标记而不是靠句号断句。显式标记的好处是校验层能精确知道“这一个块从哪里开始、到哪里结束”不需要再去猜边界。这看起来是个简单工程决策但实际影响很大如果靠句号切分遇到缩写、引号、列表格式边界识别错误率会高得离谱。块级解码还涉及一个“块长”的元参数。论文实验了64、128、256 token三种块长最终选择128。块太长校验频率太低错误积累问题又回来了块太短校验频率高计算开销翻倍而且模型生成意图连贯内容的空间被压缩段落显得太碎。128是个实测下来的甜点值我在自己的场景里测过长代码生成任务里64更好使因为代码的语句单元比自然语言段落短这个差异论文里没提属于实操中的补充经验。块级解码另一个优势是可以做“并行预判”。校验层在评估第k个块的时候执行器已经可以pre-compute第k1个块的候选了评估完成后直接无缝切换。论文里的实现是用双stream流水线把校验延迟隐藏在执行生成后面实测下来校验层几乎不成为吞吐瓶颈。这一点对工程落地很重要很多人一听说“每生成一块就校验一次”第一反应是“那生成速度得慢多少倍”实际上用流水线压住延迟之后端到端速度只慢了大概40%换来的是长文本质量的大幅提升这个交换非常划算。2.3 过程奖励模型与前瞻性自适应停止过程奖励模型的输入是“当前已生成的全部内容 当前skeleton节点 剩余skeleton节点”输出是一个标量分数。打分维度前面提过有两个局部忠实度和前瞻贡献度。局部忠实度比较好理解就是有没有跑题前瞻贡献度才是亮点它衡量当前块对后续节点的“铺垫价值”。怎么让模型学到“前瞻贡献度”论文用了一个很巧妙的监督信号构造方式。在构建训练数据的时候作者拿完整的长文做样本然后把后半部分遮住让标注模型判断“只看前半部分能不能合理推断出后面大概要讲什么”。如果能前半部分的各个块就获得额外的前瞻奖励。这个操作的本质是用“可预测性”代理“连贯性”——一个让读者能预判后续内容的长文必然是结构紧凑、逻辑连贯的。我当时看到这个设计的时候想这比让人工一句一句标“这句话为下一段埋了伏笔”靠谱多了成本也降了几个数量级。自适应停止机制是另一个容易被忽略的细节。骨架规划阶段已经给每个节点分配了预算但执行过程中校验层会持续评估“当前节点目标是否已达成”。当分数超过一个阈值的上升区间后执行器会提前结束当前块哪怕预算还没用完转入下一个节点。反过来如果分数一直上不去执行器会就地重写最多三次还不达标就直接“放弃节点”并推动到skeleton的下一个环节。这个“带止损的执行策略”非常现实因为实际任务里某个子目标就是可能做不好死磕它只会把全局节奏拖垮。不过要提醒一点早期版本的自适应停止过于激进经常出现“模型觉得这一节写得差不多了但实际内容长度明显不足”的情况。论文在实验部分也给了数据纯靠阈值停止时输出平均长度比设定预算短了22%内容信息密度不够。后来他们在奖励函数里加了“长度完整性”约束项惩罚“提前收工”才算把长度拉回正常区间。我自己的经验是阈值不要设成固定值最好按任务类型分别调信息密度高的任务阈值可以设高一些允许提前结束低密度任务就得把阈值压低强制模型写满预算。3. 训练流程与复现要点3.1 数据构造高质量的“方案-执行”三元组要复现SequenceO1数据关是第一道坎。论文里没有用现成的公开数据而是基于一个“长格式指令数据集”做的二次加工加工产物叫“方案-执行三元组”输入任务、skeleton方案、分块执行结果。第一步是生成skeleton。论文用的方法是拿GPT-4级别的模型对任务描述做“逆向规划”先不给任务答案只给任务和目标让模型输出“如果你要完成这个任务你会分成哪几个子目标各自占比多少”。这里有一个提示词技巧不要让模型看到“最终成品”看到成品之后的规划会带严重的“结果导向偏差”规划出来的子目标里会藏着成品的关键信息这对训练是毒药。训练时模型的输入只有一个任务描述如果skeleton里出现了“只有看了结果才能知道”的细节训练会严重过拟合到“瞎猜结果”上。第二步是生成分块执行结果。基于skeleton逐节点指令base模型生成对应块生成时强制要求用[SEQ_BLOCK]分隔。这里论文强调了一个反直觉的操作故意污染一部分样本比如在某一个块里强行插入与节点意图无关的信息然后把污染后的整条序列标记为“低分正例”喂给校验层做难例挖掘。这个操作我一开始觉得没必要后来明白了校验层如果只在“干净样本”上训练它会变得非常苛刻稍微有点内容波动就判低分反而干扰执行层发挥。掺入少量“轻微污染但整体可用”的样本能让校验层的评分更符合真实文本的分布。第三步是反推预算占比。前面提过按段落信息量权重计算具体做法是把每个块喂给一个小模型让它输出“这个块能独立支撑什么结论”再统计每个块被评为“关键支撑”的频率频率归一化后就是预算占比真值。这个方法计算量大但全自动不用人工标注复现可行性很高。我自己走下来的体验是小模型选7B到13B级别就够了不要用太强的模型做标注太强模型会把所有块都评为“关键支撑”区分度反而消失。3.2 两阶段训练策略先对齐再强化训练流程明确分成两个阶段。第一阶段是“监督微调对齐”用三元组数据把规划器、执行器、校验器都初始化到合理水平。规划器的SFT目标是“任务描述 - skeleton”执行器的SFT目标是“skeleton 已生成内容 - 下一个内容块”校验器的SFT目标是“部分内容 skeleton - 分数”。这个阶段的主要目的是让三个模块形成基本的行为能力不追求最优只求“能跑通”。第二阶段是强化学习联合优化。论文选择的是PPO不过不是对“整条轨迹”做一次打分而是把奖励函数分解成三个part规划奖励skeleton与执行结果最终匹配度、执行奖励每个内容块的即时质量、校验奖励校验层输出的PRM分数。三者用权重叠加论文给的默认权重是0.2 / 0.5 / 0.3我在复现时把执行奖励权重提了一点到0.6效果有轻微提升但要注意权重加太多会让模型变得“过度谨慎”生成的文本四平八稳但缺少灵气这个很难量化只能靠人工读sample。RL阶段一个必须注意的细节是skeleton的生成需要可微采样。但skeleton是离散的意图串没法直接走梯度论文用了Gumbel-Softmax做连续近似在执行器那边拿到反馈后再通过straight-through estimator把梯度传回规划器。这块是全文代码实现最复杂的部分我建议复现时先跑通不加RL的“弱基线版”确认链路没问题再上这个trick。否则梯度在离散采样和连续近似之间来回切报错会非常难调。训练数据规模说一下论文最终用了大概12万条三元组其中带污染样本约1.8万条从零训练一个7B级别的模型大致需要相当于1200小时A100的训练量。这个成本对个人复现来说偏高论文里给了个建议可以拿现成的长文本模型做“模块级初始化”即规划器直接用现成的指令模型微调执行器用现成的长文本生成模型初始化校验器单独从PRM出发。这样整体训练时间可以砍到原来的四分之一左右。我自己按这个路子走大概用8张A100训了四天就能跑出一个效果可接受的版本。3.3 推理流程的工程配置推理阶段跟传统生成有本质差异。整体流程是任务输入 - 规划器产出skeleton - 执行器按skeleton逐块生成 - 每块末尾校验层打分 - 不达标触发重写或跳转 - 全部节点完成或预算耗尽 - 拼接最终输出。工程实现上的核心是“流水线并行”。前面说过执行器生成第k1块时校验器同步评估第k块双stream并发。我用vLLM做底层推理框架但vLLM原生不支持“生成到一半插入一次外部评估再决定继续还是回头”所以需要自己封装。我的做法是把skeleton生成、块生成、PRM打分都拆成独立的HTTP服务中间用一个调度器管理状态机。状态机需要维护的变量不少当前节点索引、当前块编号、剩余预算、重写次数、历史内容buffer。调度器手册级别地设计了7个状态包括“评估中”“重写中”“跳转中”“完成”状态转换逻辑有几十行判断写的时候一定要先画清楚状态表再动手否则后面调试会让你怀疑人生。另一个推理配置是“重写策略”。论文里默认是局部重写即只重生成当前块不改变之前的内容。我调研的时候试过“重写当前块后续块重新规划”效果没有显著提升但推理时间暴增果断放弃。局部重写在大多数情况够用了因为校验层设计的初衷就是“早发现早止损”一个块写坏了不至于拖垮整篇文章。模型推理时的KV cache管理也要专门处理。块级重写会改变当前块的KV cache但之前的块保持不变所以要支持“KV cache的定点截断和追加”。好在vLLM的前缀缓存机制可以复用已有前缀的KV重写时只需要释放当前块的cache、保留前缀cache再重新生成。这块如果不处理重写一次就要全序列重新计算长文本场景下延迟直接翻倍必须用前缀缓存压住。4. 实测对比与常见问题排查4.1 跟普通CoT和长思维链的对比为了验证这套框架是不是真的在“序列规划”层面带来了增量我拿同一批测试任务做了三个对照基线是普通指令模型直接长文生成方案A是“先让模型写长CoT草稿再基于草稿生成正文”OpenAI O1-style较常见的复制版思路方案B是SequenceO1完整版。任务选了三个类型2000字左右的产品分析报告、包含5个步骤的工具调用长任务、以及一篇带有复杂论点支撑的议论文。评测指标用人工打分重点关注三点结构完整度有没有该写的部分漏掉、局部连贯性段落内部逻辑是否顺畅、资源分配合理性重点部分有没有对应的篇幅。结果差距最明显的是“漏点”这个指标。基线模型在五步工具调用任务里漏掉了两个子步骤比例高达40%长CoT方案好一点漏一个但代价是生成了非常长的“思考草稿”很多思考内容在正式输出里根本用不上信息密度低SequenceO1的完整版只漏了一个子步骤而且这个漏项是“跳转机制”主动放弃的——校验层判断该子任务当前输入下没法达成选择止损。这说明框架不是“更聪明地不漏”而是“更聪明地管理遗漏”这个差别挺本质的。CoT方案在长文档上的另一个明显短板是“前后口径不一致”。前文说产品A定价偏高后文对比里又写成“价格优势明显”这种问题在基线和CoT方案里出现的频率远高于SequenceO1。原因也好解释长CoT本身也是逐token生成的它同样会犯长距离遗忘。SequenceO1有校验层不断检查“当前块是否跟之前的事实一致”实际上等于给长文本加了一个“事实一致性监控器”。整个链路跑下来我的观感是CoT让模型“想得更多”SequenceO1让模型“做事更有章法”二者不在同一个维度上。4.2 复现时容易踩的坑和调参实录先说一个最隐蔽的坑skeleton中的意图词跟执行器生成内容之间的“格式漂移”。规划器输出的是离散意图词但SFT微调后执行器偶尔会把意图词消化进正文导致最终输出里出现“分析产品A”之类的裸意图字句。这个问题的根源是执行器的训练样本里[SEQ_BLOCK]标记和意图词之间的距离太近模型把意图词也当成了要输出的内容。我的解决办法是把意图词从正文流中剥离放到[INTENT]token之后让执行器在生成内容之前先跳过这个区域相当于给模型一个明确的“这个字段是控制信号不是正文”的提示。另一个坑是校验层的分数漂移。训练初期校验层的分数普遍偏低执行器为了“讨好”校验层会倾向于生成四平八稳的模板化文本因为模板文本的“可预测性”高前瞻贡献度得分也高。这跟没加RL之前相比输出多样性反而下降了。我花了很久才定位到这个问题一开始以为是训练率过大导致的坍塌后来把校验层的前瞻贡献奖励权重调低之后才缓解。这件事给我的教训是RL训练中多目标之间的权重真的需要动态调整固定权重的结果就是模型找到“局部最优的捷径”不是我们真正想要的目标。还有一个工程上的坑预算占比的“比例分配”跟实际token数的对应关系。骨架规划的预算占比是百分比但执行器实际消耗的token数还受文本密度影响。同一段字数如果内容里充满代码token数可能翻倍。如果只是简单按百分比分配代码密集型的节点会频繁触发“超支借调”借到最后整个预算体系形同虚设。我最后的处理是让每个节点的预算对外暴露为“token软上限”由执行器的embedding统计信息实时估计已消耗token占比动态调整“预算压力”。这算是论文框架基础上的一点工程补丁效果显著但论文正文里没有讨论这个细节。4.3 常用问题速查表问题现象可能原因排查方法推荐解法生成的正文里出现“意图词”裸文本控制信号与正文流没有彻底分离检查样本里[SEQ_BLOCK]和意图词位置引入[INTENT]标记与其他内容隔离输出风格变得过度模板化校验层前瞻奖励权重过高看生成样本的多样性指标降低前瞻奖励权重或加入多样性正则某节点反复重写但分数不上涨当前节点目标不可能达成检查该节点所依赖的外部信息调高“放弃阈值”尽早跳转止损生成内容长度普遍偏短自适应停止阈值设置过高统计平均输出长度/预算比加入长度完整性约束项执行层经常“超支借调”文本密度差异太大观察不同节点的token消耗分布用预估token数替代百分比做分配多机分布式训练时损耗严重强化学习小batch导致通信占比过高nvidia-smi监控GPU利用率增大batch或把RL的rollout与update分离部署表格里的后两条属于工程扩展内容论文没直接讲但都是实操中必然遇到的问题。我在这张表上花的时间不少每一条都是拿真实训练日志和生成样本反复对比才定位到的自己复现的话建议把这页截图留着当排查地图。5. 我的一些经验性总结论文读到这里最大的感受是SequenceO1真正的贡献不只是把O1的思路搬到序列场景里而是它完整回答了“如何在任意抽象层级上引入推理时计算”的问题。O1在token层思考SequenceO1在意图层思考未来可能还会有人做“篇章级思考”把多个段落进一步抽象成模块。这个方向一旦走通推理时才真正算是“有结构”的而不是“更多算力”的堆料。多说一句实操里的小技巧如果你暂时没有资源完整复现这篇文章可以只拿走两样东西用在自己的项目里。第一样是“块级解码 局部校验”这套组合可以直接挂在任何长文本生成模型外面工程改动不大却能显著降低长文跑题率。第二样是“预算占比预分配”哪怕不用复杂的三模块框架只在prompt里让模型“按每个段落的重要程度分配篇幅”生成结果的结构感都能上一个台阶。这两招是性价比最高的“偷师”姿势。最后再分享一个我们团队后续准备做的扩展把SequenceO1的骨架规划能力跟搜索引擎串起来让每个skeleton节点动态触发一次检索把外部知识按节点粒度注入执行层。等于把“先规划再写”升级成“边检索边写”很多纯靠模型内部知识会写糊的内容理论上可以被外部证据支撑住。这个方向目前还在原型期跑通了再回来填坑。