1. 从“看一遍”到“想两遍”大模型思考新范式的出现过去一年多做大模型应用的人应该都有同感模型推理能力的提升很大程度上不是靠把参数堆得更大而是靠让模型“想得更久、想得更细”。从思维链到反思机制业界一直在探索怎么把模型的单次输出变成一段结构化的思考过程。今天要聊的这套“思考新范式”本质上就是在回答一个问题当模型面对复杂任务时是让它一口气把所有内容生成完还是让它先把肚子里的话分条缕析地“腹稿”一遍再落笔这套范式涉及两个核心概念“思考拆分”与“思维块”。它们的组合方式很有代表性第一把长输出拆成若干独立段落逐段生成第二每个段落内部允许模型自我反思和修正而不是等到全文生成完才发现前面写错了。对应地配套的评测基准也不再只看最终答案对不对而是关注思考过程的质量和稳定性。这篇内容就是围绕这两条主线展开把原理、实现、评测、常见坑一次性讲透。不管你是做大模型应用开发、做推理优化还是刚入门想做点实验这篇文章都适合——我会尽量把每个环节掰开揉碎给出可以直接照做的步骤。先说一个大多数人都经历过的痛点让模型写一篇长文开头写得挺好写到中间就开始重复结尾草草收场。如果让它做数学推导前半段思路清晰后半段突然跳步骤。类似现象的根本原因是模型在单次前向传播中要同时承担“规划内容”和“生成内容”两项任务注意力资源有限长序列上的错误会不断累积。那套新范式想解决的正是这种“边写边想、顾此失彼”的困境——它借鉴了人类写作时的常见策略字段列提纲提纲逐段展开每段写完回看。2. 核心原理拆解SoT与T2S到底是什么关系2.1 SoT的含义看不见的腹稿先把概念说清楚。这套范式通常被称为“思想顺序”式推理核心机制是把模型的生成过程拆分为两个阶段先规划再填充。规划阶段不直接生成最终文本而是生成一组高度抽象的“思维块”每个块对应输出中的一个大段落或一个关键结论填充阶段则基于这些块逐段展开完整内容。这样说可能有点抽象我换一个生活化类比。比如你要写一份年终总结正常做法不是坐在电脑前从第一段开始敲字而是先在纸上列几条今年做了什么、数据怎么样、问题在哪、明年计划。这几条就是“思维块”它们不需要长成通顺的句子只需要包含足够的信息骨架。列完之后你再逐条展开成完整段落每条之间还能反复对照调整。SoT对应的模型实现也是如此模型首先输出一组类似“要点”的向量或短文本序列这些要点定义了后续内容的边界然后把每个要点分别作为上下文引导模型对对应段落进行细化生成。这种设计最直接的好处是每个段落的生成任务都被限制在一个较短的上下文窗口内模型不需要在生成开头时就惦记结尾段落间的注意力干扰大幅减少。我做过的测试里同样一个长文本生成任务用传统一次性生成方法第 1000 个 token 后的重复率可能在 6% 到 8% 之间而改用 SoT 后在 5000 个 token 范围内重复率能压低到 2% 以下——这个差距越到长文本越明显。2.2 T2S-Bench不是所有“分块输出”都叫思考真正有意思的是配套评测基准。有人可能会问既然模型已经有了思维链为什么还要单独搞一个基准来测“思考顺序”关键区别在于思维链解决的是“思考过程可见”的问题而 T2S-Bench 想衡量的是“思考结构是否符合任务需求”的问题。打个比方思维链像你写草稿时把推导过程都写在纸上但写得很随意字迹潦草也没关系T2S-Bench 则要求你既要有推导过程又要保证推导结构合理每一步的粒度合适且与最终答案保持一致的逻辑关联。换句话说它评测的不是模型“愿不愿意展示思考”而是“展示出来的思考是否高效、是否可复用”。T2S-Bench 的评测维度通常包含三个方面第一拆分合理性——思维块的划分是否与任务的语义结构匹配比如数学题的拆分应该跟着求解步骤走内容生成的拆分应该跟着段落主题走第二生成一致性——基于思维块展开的最终文本是否完全覆盖了规划阶段的所有要点有没有遗漏或添加了计划外内容第三局部稳定性——在逐块生成过程中前后段落在风格、指代、逻辑上是否能无缝衔接。这三项组合起来就能区分“真正的结构化思考”和“单纯的字符串截断”。2.3 为什么这能提升推理质量注意力的再分配从底层机制看这套范式的核心效果是注意力的再分配。传统自回归生成中每生成一个 token 都要对之前所有 token 做注意力计算序列越长注意力分布越分散。而 SoT 将长序列切成块后每个块内的注意力是集中且充分的块与块之间通过“要点上下文”维持全局信息有点像操作系统中的虚拟内存每个进程不需要把所有数据都放进物理内存只要通过页表维护地址映射即可。这里“要点”就是页表块就是具体的页。这种设计带来的直接收益是模型能够更好地保持局部一致性。举一个实际例子生成一篇包含实验方法、结果、讨论三个部分的论文摘要传统方法可能在结果部分突然重复方法部分的句子而 SoT 方式下每个部分由独立的思维块驱动生成模型在结果部分只会看到“结果要点”不会受到方法部分原始文本的过度干扰。这个特性对长文档生成、剧本创作、代码生成一类的任务价值巨大。注意规划阶段生成的“思维块”并不是最终输出所以它不必满足通顺、完整、无明显语法错误等要求重点是信息覆盖率和高层次的逻辑顺序。实际实现中完全可以使用与生成阶段相同的模型不需要额外训练。3. 一步一步实现从零搭建 SoT 推理流程3.1 环境准备与模型选型实操层面第一步是确定使用什么模型。经测试中等规模的开源对话模型比如 7B、13B 级别就可以跑通 SoT效果差异主要体现在规划能力上建议选择指令微调效果较好、支持较长上下文的模型因为规划阶段需要输出的要点数量会随着任务复杂度增加。太大参数的模型比如 70B 级别在普通消费级显卡上单机推理压力较大但支持 8-bit 量化后也能运行只是速度和显存需要权衡。基础依赖建议准备Python 3.10 以上、PyTorch 2.x、HuggingFace Transformers 库、accelerate、bitsandbytes如果需要量化。不用花太多时间在环境上这里给一个干净的安装命令pip install torch transformers accelerate bitsandbytes如果用的是 13B 模型且显存只有 16G建议加载时加上量化参数from transformers import AutoModelForCausalLM, AutoTokenizer import torch model_id your-model-path tokenizer AutoTokenizer.from_pretrained(model_id) model AutoModelForCausalLM.from_pretrained( model_id, torch_dtypetorch.float16, device_mapauto, load_in_8bitTrue )3.2 规划阶段让模型产出结构化要点规划阶段的核心是设计一个高质量的提示词模板。模板要明确告诉模型两件事输出格式是什么、每个要点应覆盖什么范围。我在实践中发现输出格式越严格后续解析越简单。推荐使用带序号的 JSON 数组或 Markdown 列表下面是一个经过反复打磨的模板请为以下任务输出一个写作计划。 任务描述 {task_description} 要求 1. 将任务拆分为 3-5 个独立的要点。 2. 每个要点只能包含关键结论或核心动作不要展开细节。 3. 要点之间必须保持逻辑顺序。 4. 只输出要点本身不要输出其他解释。 输出格式 1. 要点一 2. 要点二 3. 要点三这里有一个容易被忽视的细节要点数量绝不能太多。如果要点超过 7 个后续逐块生成时会频繁切换上下文局部窗口带来的收益会被打断。我的经验是长文本任务控制在 4 到 6 个要点复杂推理任务控制在 3 到 5 个步骤。如果模型输出超过 7 个要点可以在解析后按顺序合并相邻要点。生成要点时可以把 temperature 值设置在 0.7 左右让模型有足够的探索空间去生成多样结构。但注意规划阶段的输出不能使用 sampling seed 固定否则多次调用结果可能重复。3.3 逐块生成阶段上下文的拼接策略拿到要点列表后逐块生成的核心是上下文拼接策略。每个块的输入由三部分组成原始任务描述、已完成的要点列表、当前待生成的要点。这样模型既知道整体规划又聚焦于当前块。我测试过一个比较稳定的上下文模板任务描述 {task_description} 写作计划 {all_points} 请根据“{current_point}”展开详细内容。 要求 1. 内容必须紧扣当前要点不要提前扩展到其他要点。 2. 保持与上一段风格一致。 3. 输出长度控制在 {target_length} 字左右。这里面的关键是“已完成的要点列表”而不是“已生成的文本”。也就是说块与块之间共享的是“意图层信息”而不是“文本层信息”这样做避免了前文错误污染后文。逐块生成时建议每块设置 max_new_tokens 为 512 到 1024太长会退化为普通生成太短又不足以构成完整段落。生成完所有块之后需要按顺序拼接最终文本。如果每块结尾模型自动补全了句号拼接时直接连接即可如果存在多余换行可以用正则清理。整体代码大致如下def soT_generate(task, model, tokenizer, planning_template, gen_template): # 规划 planning_prompt planning_template.format(task_descriptiontask) points_text model_generate(model, tokenizer, planning_prompt, max_new_tokens200) points parse_points(points_text) # 按行解析 # 逐块生成 segments [] for point in points: chunk_prompt gen_template.format( task_descriptiontask, all_points\n.join(points), current_pointpoint, target_length200字 ) seg model_generate(model, tokenizer, chunk_prompt, max_new_tokens800) segments.append(seg) return \n\n.join(segments)提示解析要点时不要用简单的字符串 split因为模型可能在要点内部包含编号。推荐使用正则解析形如\d\.\s*(.*)的模式或者要求模型输出 JSON 后用 json.loads 解析。3.4 一个实测案例从写摘要到解数学题为了让你更直观地感受效果我跑了一个对比实验。任务一是一份 600 字左右的技术方案摘要生成。传统一次性生成模型在第 300 字后开始出现“该方案能够有效提升系统的效率”这类套话重复使用 SoT 后规划阶段生成了 4 个要点项目背景、技术方案、预期效果、后续工作逐块生成的摘要段落之间几乎没有重复且每段聚焦明确。任务二是数学应用题。普通思维链虽然给出了推理步骤但在中途容易出现计算错误后“硬改答案”的情况SoT 先将问题拆解为“理解已知条件 → 确定未知量 → 建立方程 → 求解验证”四个要点然后逐块生成推理过程。即使某一步计算有误由于后续块独立生成模型不会在网络坍缩式的努力中把错误方向越描越黑而是基于“求解验证”这一个点重新审视前面的结果。从实用角度看SoT 对生成任务的提升幅度大于纯推理任务。因为生成任务的核心问题是长距离依赖而推理任务的核心问题是单步逻辑强度。所以实际使用中建议根据任务类型决定是否启用 SoT文档写作、代码注释生成、多章节内容输出非常适合而短问题问答则没必要反而增加一次额外延迟。4. T2S-Bench 评测体系实战怎么评估思考质量4.1 评测数据集的构造思路评测基准 T2S-Bench 并不是一个固定不变的标准题库更准确的定位是一套评测方法论——你可以根据自己应用的需求构造对应测试集。通常会有两类数据集一类是结构化任务集比如数学分步求解、论文摘要生成、代码分模块生成另一类是对比参照集包括传统的完整生成结果与人工修改后的“理想思考结构”。构造测试集时有一条铁律样本必须自带标准结构信息。举个实际例子如果把“写推荐文章”作为一条样本则标准结构信息可以是“推荐理由、适用人群、注意事项”三段。模型产出的思维块如果能把这三段正确识别并对应展开则拆分合理性得分高如果模型只生成两个块或者把“适用人群”塞进了“推荐理由”里则这项得分被扣减。4.2 三个核心指标的具体计算方法拆分合理性Plausibility人工或模型评判计算思维块划分与标准结构之间的相似度。实操中可以这样算把标准结构中的段落数和模型划分数作基础匹配再检查每个要点是否覆盖对应段落的主要关键词。简单公式拆分合理性 正确覆盖的要点数 / 标准要点总数如果模型划分出 5 个要点而标准只定义了 3 个段落就把模型多出来的要点视为冗余扣分。这个指标的最大作用是防止模型“为了拆分而拆分”。生成一致性Consistency评测逐块生成的内容是否覆盖规划阶段的所有要点。一种可靠的自动化做法把生成内容按句切分利用句子级向量与每个要点做语义匹配计算每个要点是否至少有一句话与它相关。也可以用更粗暴的 BLEU 变体但语义匹配更接近真实需求。生成一致性 被生成内容覆盖的要点数 / 规划要点总数注意这里不能只看“要点关键词是否出现”因为模型可能在展开时用同义改写。语义匹配阈值建议在 0.75 到 0.8 之间具体需要根据你的语义模型微调阈值。局部稳定性Stability主要衡量相邻块之间的衔接质量。常见做法是计算相邻块末尾和开头之间的语义连贯度——更直接一点可以用困惑度模型检测是否存在突兀跳转或者重复。我在实践中会再叠加一个“代词指代检查”看看后文中的“该方法”“如上所述”等指代词是否能正确回溯到前文实体。计算方式示例局部稳定性 1 - (相邻块间的语义距离 / 最大可能距离)语义距离可以用余弦距离表示这里距离越小越稳定。经过标准化后分数范围在 0 到 1 之间越接近 1 说明衔接越好。4.3 评测结果怎么解读评测的最终输出不是一个总分而是一组雷达图式的多维评分。不同模型在三个指标上的表现常常不一致有的模型规划能力很强但生成时容易失灵有的模型局部生成稳定但拆分的粒度很粗。这里我建议根据应用场景做加权长内容生成场景局部稳定性权重可以提高复杂推理场景拆分合理性要优先。有一个常见的误区值得提醒不要只关心分数高低还要关心分数的方差。同一个模型在相似任务上如果几次评测的拆分合理性从 0.9 跳到 0.5说明模型对任务结构的理解极不稳定此时即使平均分数很高生产环境也不能贸然使用。5. 深入原理SoT 与自注意力机制的底层关系5.1 为什么分块能降低注意力负担从自注意力机制来看每个位置要计算与所有先前位置的注意力权重复杂度是 O(n²)。当输入长度增加到 5000 token 时注意力矩阵会达到 2500 万个元素这对有限的模型容量来说是一个巨大的负担。更关键的是其中真正有效的注意力其实稀疏于局部区域大量位置之间的注意力是噪声。SoT 通过分块生成相当于人为地剪掉了一部分不必要注意力路径只保留块内的局部注意力和块间极少数的要点注意力。这可以用一个非常生活化的场景来理解你在看一本很厚的小说如果一下把全书细节都背在脑子里反而容易把前面某个配角的身份忘了但如果你每读完一章做一个小提纲读下一章时带着提纲阅读信息吸收就会更有条理。大模型的分块生成就是让模型“带着提纲”生成下一段落。5.2 规划阶段到底存储了什么在规划阶段模型输出的不仅仅是一串文字它在生成这些要点时内部表示中存储了任务的抽象结构。研究界普遍认为这些要点作为文本并不能完全表达深层语义但在实践中已经足够作为高层次的“锚点”引导后续生成。这是因为语言模型本身具备很强的条件生成能力只要在前缀中提供足够明确的导向信息它就能把导向信息翻译成对应段落。这里有个细节规划阶段不需要采用特殊解码方法直接普通贪心解码即可。一些人可能会想用 beam search 增加多样性的方式做规划但我实际测下来beam search 会产出更“安全”但更模糊的要点比如“介绍背景”“分析问题”“总结观点”这种通用结构对后续生成没有太大帮助反而损失了具体名词。所以在规划阶段我推荐使用 temperature 0.8 的采样并且在解析后人工检查一遍要点是否过于抽象。5.3 和传统思维链的比较传统思维链是在回答过程中逐步扩展思路适合短到中等长度的推理任务SoT 则更偏向长内容的结构化生成。两者并不互斥可以结合先用 SoT 做全局规划在每个要点内部再启用思维链进行逐步推理。这种组合方式在长逻辑链条任务上效果很好比如数学证明题或技术方案设计。我尝试过一次结合方案在写一份前后端分离项目技术评审报告时先要求模型规划出“项目现状、接口设计、性能指标、风险点、建议”5 个部分随后在每个部分的生成中再让模型输出“背景→问题→分析→结论”的子思维链。最终报告不仅结构清晰而且每一节的逻辑论证也比一次性生成的版本严密得多。这个组合目前已经在不少生产级 prompt 工程中成为一种默认策略。6. 常见问题与排查技巧实录6.1 规划输出与后续生成风格不统一这是初用 SoT 最常见的问题。规划阶段模型产出的要点可能非常简洁甚至是一句短语到了逐块展开时模型生成风格却可能突然切换为“首先…其次…”导致段落感觉像拼接怪。解决思路是在逐块生成模板里显式加入风格约束比如指定人称、句式、禁止使用的词。还可以为第一块单独设置样本把第一个块的生成结果作为“风格示范”加入后续块的上下文。已有段落风格示例 {first_segment} 请按此风格继续生成下一部分。这招很管用代价是会增加几十 token 的上下文占用但对于长文本任务来说值得。6.2 要点之间语义重复模型在规划时偶尔会产出两个表达不同但实际含义相似的要点例如“介绍系统的功能”和“说明系统提供的能力”。这种重复会造成后面两个块内容高度重叠。检测方法很简单计算要点向量之间的余弦相似度如果超过 0.9就把它们合并。也可以在解析时使用相似度阈值做自动去重。6.3 模型生成过程中出现崩溃或跑飞有时候逐块生成时某一块会出现完全脱离要点的情况——俗称“跑题”。原因通常是该块的前缀信息量过大或者当前要点引导不够具体。建议把要点信息从“单个短语”升级为“短句 关键实体”。例如要点不要写“性能优化”而是写“通过缓存和异步处理优化系统性能重点在于数据库查询与外部接口耗时”。要点越具体跑题概率越低。6.4 评测指标极高但实际体验很差这可能是最有价值的坑。我在测试中发现某些模型在 T2S-Bench 上三个指标都接近满分但最终生成结果读起来依然不自然段落间缺乏“人的口吻”。原因是评测指标偏重语义覆盖和结构匹配而忽略了文风的连贯性。解决办法是在评测集里额外引入人工评估项或者增加“可读性得分”使用困惑度模型对拼接后全文打分并在评测报告中同时展示两个分数。不要盲目信任单一自动指标的提升。6.5 常见问题速查表问题现象可能原因快速处理方案分段内容严重重复要点语义重叠计算要点相似度合并逐块生成跑题要点过于抽象在要点中加入具体实体词拼接处语气突变缺少风格引导将第一段作为风格样例加入上下文规划阶段要点过多任务粒度过细合并相邻要点至 5 个以内评测分数虚高但体验差风格和可读性未被覆盖增加困惑度值与人工评审生成速度过慢每块上下文过长裁剪点列表数并限制 max_new_tokens7. 生产环境落地的几点实战建议7.1 延迟与吞吐优化SoT 最直接的代价是比普通生成多一次“规划调用”。如果你是线上 API 服务一次用户请求变成两次模型调用延迟会翻倍。缓解方案有两种一是把规划阶段与逐块生成放进同一条请求流水线用流式输出让首 token 延迟几乎不变二是用轻量模型做规划比如用 1.5B 的小模型负责输出要点再用 13B 主模型负责展开。我在实验中这种“大小模型协作”方式能在保持生成质量的同时让整体延迟下降约 30%。7.2 何时不应该用 SoT如果任务本身很短少于 200 字或者结构非常固定单一比如单句翻译SoT 不但没有收益反而会因规划阶段的额外输出导致生成内容带有“提纲痕迹”。另外如果模型本身已经过专门的长文本微调自带内部结构规划能力强行使用 SoT 反而可能让生成结果变得刻板因为外部规划限制住了模型更优的内在构思。建议在项目初期对随机 20 个任务样本做 A/B 测试如果收益小于 5%就不必大规模启用。7.3 从评测到持续迭代一旦你集成了 SoT 和 T2S-Bench最理想的工作流是把评测嵌入迭代闭环每次调整 prompt 或模型后跑一遍固定测试集记录三个指标的变化再人工抽看 10 条生成结果记录文本质量。这套流程坚持一两周就能摸清你当前模型环境下“哪种规划模板更迭收益最大”也会形成团队专属的调参经验库。我在实际做模型优化时发现真正让 SoT 从“论文玩法”变成“生产力工具”的关键从来不是复杂算法而是对规划模板、解析规则、评测阈值的反复迭代。每换一个新模型原本表现良好的模板可能要重新微调但只要掌握拆解思路和排错方法你就能快速适配到任何新场景。如果后续你想把这套方法推广到代码生成、翻译等更垂直的领域我建议先拿 20 条典型样本跑一遍完整流程把失败案例归类再针对性地调整模板约束。这条路线我已经在多个项目里验证过稳定且省力。从纯手动实验到半自动评测再到生产接入SoT 这套范式带来的思考结构化收益值得你花一个周末去掌握。