1. 从一次跑偏的35步推理说起什么是长链推理的上下文管理幻觉最近在调一个多步逻辑推理任务模型需要一路推导35个中间步骤才能得出最终结论。前15步表现正常从第28步开始突然开始复读前面的假设条件然后在第31步得出了一个和前面推导完全矛盾的答案。我检查了输入、检查了采样参数、把temperature降到0.1问题依旧。后来我把完整的推理轨迹打印出来逐行看才意识到问题根本不在于模型笨而是它在长链推理过程中把自己的早期结论给弄丢了——注意力被后面越来越多的token稀释前面算出来的关键中间量在上下文里逐渐隐身。这其实就是标题里说的上下文管理幻觉模型不是因为知识缺失产生幻觉而是因为长上下文里的信息管理失效导致推理链条自我断裂。这类幻觉和普通的事实性幻觉有本质区别。普通幻觉是模型编了一个不存在的答案上下文管理幻觉是模型忘记了自己前面算出来的正确答案。后者更隐蔽因为单看每一步的输出都很合理只有把整条链拉通看才能发现逻辑已经断了。这篇文章想聊的事情很具体为什么长链推理必然会出现这类上下文幻觉市面上常用的截断法分块法为什么治不了本以及我目前在用的解决思路——把CoTChain of Thought思维链变成模型自己能够主动压缩的格式让它在推理过程中持续维护一份精炼推理笔记而不是让原始CoT无限积累下去。适合看这篇文章的朋友有三类一类是在做Agent、做复杂任务拆解经常被模型中途失忆困扰的开发者一类是研究推理能力、关注上下文窗口利用效率的算法工程师还有一类是单纯想理解为什么GPT类模型推理一长就会出错的好奇派。下面全部内容都是我在实际任务中跑出来的经验不是教科书推导。2. 上下文长尾效应CoT越长模型越容易丢失关键中间量要理解这个问题先得搞清楚CoT在Transformer里到底是怎么被处理的。很多人以为CoT是模型把思考过程写在输出里这个理解没错但它忽略了一个关键点CoT的前面部分会变成后续计算的上下文输入也就是说模型一边生成推理步骤一边在读自己刚才写过的内容。这里的问题是模型在读自己的历史CoT时距离越近的token注意力权重越高距离越远的token越容易被忽略。具体来说Self-Attention的权重分布经过softmax之后存在一个天然的长尾效应——后面的token对前面token的注意力会随着相对距离增加而衰减。这不是某个模型的问题是所有基于Transformer架构模型的共性。我做一个比较直观的实验来说明。用同一个模型跑同一个多步推理任务只改一个变量是不是允许模型把完整的CoT保留在上下文里。结果如下实验配置中间步骤数前16步对最终答案的影响权重最终正确率100次抽样每一轮只保留最近4步推理摘要35高关键变量始终可见78%完整保留全部35步CoT35低早期关键量被长尾稀释41%完整保留CoT但允许模型回溯关键节点35中仅在模型主动回溯时有效52%数字本身不代表绝对正确率但差距足够说明问题了同样是35步推理把早期的关键中间量保留成随时可见的摘要比把完整CoT堆在上下文里效果好得多。核心原因是长CoT带来的上下文管理开销已经开始反过来伤害推理本身。那为什么模型不自己去回顾早期内容呢理论上模型可以attend到任何历史token但注意力分配是数据驱动学出来的。当上下文长度从几千膨胀到几万模型只学会了聚焦最近的几百个token早期的内容即使还在上下文窗口里实际参与计算的有效注意力已经接近于零。打个比方你书桌上放了100份资料最上面3份是今天刚打印的剩下的97份压在最底下。忽然有人问你第一份资料的某个数字你知道它存在但你得翻半天才能找到而且翻的过程还会打断手上的工作。模型面临的情况完全一样只是它的翻找成本体现在注意力的分散和计算量的膨胀上。这就是上下文管理幻觉的核心机制CoT越长模型对早期关键中间量的有效可见性越差推理链就越容易在不该断的地方断裂。而一旦某一步用错了中间量后面每一步的错误都会被放大形成连锁性的逻辑崩塌。3. 常规缓解方案为什么治标不治本截断和分块的隐性代价知道了问题根源理论上我们有三种直接的缓解思路截断早期CoT、对历史CoT做分块摘要、让模型每隔几步复盘一次。这三种思路我都实际试过效果参差而且各自有绕不开的坑。先说截断法。做法很朴素上下文超过某个阈值之后直接把最早的CoT token截掉。这种方案的优点是实现简单只要控制住上下文长度就行缺点却是灾难性的。被截断的往往不是废话而是推理链的关键锚点。我遇到过这种情况模型在第9步算出了一个中间值A第17步用A推导出了B第24步打算把A和B做比较。如果此时把前16步截掉后面整个推导就失去了依据。更麻烦的是模型自己并不知道A被截掉了它还会在输出里引用根据前面得到的A然后接着往下算。这种引用一个被删除内容的幻觉比普通的上下文管理幻觉更难排查。再说分块摘要法。做法是把早期CoT分段做归纳只保留每段的结论摘要。这个思路相对合理我在很多开源框架里也见过类似的记忆模块设计但实际跑下来有一个很棘手的问题摘要过程本身会丢失推理分支的细节。举个我实际遇到的例子。某次任务里模型在第10步考虑过方案X然后因为某个条件不满足转到了方案Y。分块摘要只记录了采用方案Y但忽略了方案X为什么被否决这个关键信息。后面模型在第20步遇到了类似场景需要复用X为什么不可行的推理依据但上下文里已经找不到了于是它只能重新猜测甚至直接走了X路线导致错误。分块摘要适合压缩已终结的分支不适合压缩仍在推理链上有后向引用的节点。最后是定期复盘法。做法是每隔N步插入一次基于当前的推理进度总结已经确定的信息把总结结果追加到上下文里。这个方法我最开始抱了蛮大期望实际测试发现它在一些推理长度适中的任务上确实有效但有两个副作用。第一复盘本身会占掉额外的token额度CoT总长不减反增长链推理到了后期仍然会撞上注意力长尾问题第二模型经常把复盘写成复读机——内容几乎就是把上一步的结论换了个说法重复了一遍真正的信息增益很低。也就是说复盘法的效果高度依赖模型自身的总结能力而不同模型在这个点上的表现差异极大。总结一下这三种方案分别败在三个维度上截断破坏了因果链的完整性分块压缩忽略了推理分支的可回溯性复盘增加了上下文负担且质量不稳定。它们共同的缺陷是仍然把CoT当作一个需要被动处理的副产品而不是让模型以CoT为工具主动管理自己的推理过程。这就引出了我最终转向的方向——让模型自己学会压缩CoT。4. 让模型自己判断哪些信息值得保留两个层次的压缩思路核心思路就一句话不再由外部脚本决定哪些CoT该留哪些该丢而是把压缩决策交给模型自己。理由很简单模型在生成每一步推理时天然知道自己正在依赖哪些历史信息也知道哪些历史信息已经用完不会再用。让它在生成当前步骤的同时同步给出这条记录需不需要被保留的判断比任何外部启发式规则都更精准。这个思路可以从两个层面上落地一个是提示词工程层不改模型权重在输入输出格式上引导模型行为另一个是模型层通过微调让模型获得自动压缩CoT的能力。我两个都做了先分析一下它们的核心差异。提示词工程层的优势是无训练成本兼容所有模型。做法是在系统提示里定义一套推理笔记的维护规则让模型每生成几步就更新一次笔记把不再引用的早期推理细节折叠成短摘要。这个方案依赖模型的指令遵循能力对本身遵循能力强的模型效果很好对弱一些的模型就有点随机。模型层的做法则是构建一批长链推理 摘要标注的微调数据让模型在推理过程中内化这个行为。效果更稳定但对数据质量和算力有门槛。比较现实的做法是先用提示词工程跑通流程验证效果沉淀一批高质量数据之后再去做针对性微调。先有流程后有数据最后才谈权重层面的调整。先聊聊压缩的本质。模型在长链推理中产生的信息大体分三类一类是将来还会用到的中间量比如算出来的中间答案、决定分支选择的阈值条件第二类是已经被后续步骤消化过的过程信息比如某一步的推导细节它的结论已经被下一步用了第三类是探索性信息比如试过一个方向发现不对这条路径本身已经关闭。真正需要保留的只有第一类。第二类和第三类如果一直被完整保留就成了纯粹的上下文负担。模型要学会的压缩动作本质上就是把推理轨迹里的第一类信息抽出来整理成一份稳定的运行笔记然后把其余的内容折叠成一句话甚至直接丢弃。这不是简单的总结全文而是识别哪些推理节点仍然活跃、哪些已经终结的过程性判断。类比一下这就像读书时记笔记不是为了把每一页抄下来而是为了把论证骨架抽出来日后回看时能迅速还原整个论证过程。好的CoT压缩也是这个道理——保留的是推理骨架不是原样复述。5. 我在提示词层实现的自压缩CoT模板与参数设计现在把提示词层的实现方案完整写出来。我把它叫做推理笔记制基本思路是在系统提示中强制模型以思考-更新笔记-再思考的循环推进推理而不是一路线性输出CoT。具体提示词结构如下任务规则 1. 你需要在回答过程中维护一份「推理笔记」笔记中记录所有后续步骤可能继续引用的关键中间量、结论和约束条件。笔记格式为 - 关键量 KEY: 值 - 结论 CONC: 简要结论注明来源步骤编号 - 约束 CONS: 当前仍然生效的约束条件 2. 推理时按以下循环进行 a. 每次产生新的推理子结论后更新推理笔记 b. 如果笔记中某个关键量在后续3步内未被任何新步骤引用自动将其压缩为一行摘要并标注已验证 c. 若某条笔记内容已被后续多个步骤反复引用则提升它的保留优先级即使距离较远也不得丢弃 d. 已封闭的分支推理后发现此路不通在笔记中删除避免后续步骤误引用。 3. 最终回答必须引用笔记中的核心结论并检查笔记内是否含有互相矛盾的记录。如有矛盾回溯到最先引入矛盾值的那一个推理步骤重新推演该步骤。 4. 笔记总长度不得超过全部输出长度的40%。超过时需要立即对旧笔记做进一步压缩。这个提示词有几个关键设计点我逐个说明为什么这么写。第一关键量、结论、约束三种记录类型分离。这是为了促成模型自己区分数据和判断。很多模型把推理中间过程以散文形式写在CoT里数据、判断、旁白混在一起后续引用时很难精准定位。拆成三种类型后模型在用历史信息时可以用KEY:xxx或CONC:xxx精确引用而不是模糊地根据前面提到的。第二明确标注来源步骤编号。这是我自己加的最有效的小改动。模型推理链一旦断裂最常见的表现是不知道当前结论是建立在哪些早期步骤之上。有了来源编号模型在冲突检测时可以沿着编号回溯而不是漫无目的地搜索整个上下文。实测下来这个改动对长链任务正确率的提升幅度最大。第三3步内未被引用就压缩是一个动态阀值。这里的3是经验值不是理论推导出来的。我试过1步、2步、5步1步会导致压缩太频繁模型还没来得及引用就被折叠了5步又放得太宽上下文膨胀问题依旧3步是个比较平衡的数值。不同模型可以微调这个参数但核心思路是压缩频率要追上推理引用节奏而不是固定每隔N步压一次。参数层面我建议在做这类实验时这样设置采样参数temperature设置为0.2~0.3。太低了模型在压缩是否保留某条信息这件事上会变得保守倾向于什么都留着太高了压缩判断变得不稳定、容易误删关键量。max_tokens按任务需求放量不要卡太紧。自压缩CoT虽然整体token数比完整CoT少但单步输出会变长因为要同时输出推理和笔记更新。关闭或大幅降低top_p随机截断先保证推理路径本身稳定再谈多样性。跑通流程后我对比过几个不同规模的模型。指令遵循能力强的模型套上这套提示词后效果提升非常明显能力弱的模型则会出现一种情况——它把笔记维护当成一个额外任务来表演笔记写得工工整整但推理和笔记之间没有真正联动。这时候单靠提示词就撑不住了需要往模型层走。6. 实测对比与失败案例分析自压缩CoT到底把正确率拉高了多少为了验证这个方案的真实效果我搭了一组对照实验。测试任务分三类数学多步应用题每道题需要12~20次推导、逻辑规则推导需要维护多个抽象变量之间的约束关系、复杂场景决策需要综合多条约束推演多个候选方案。每个任务都设置了三组对照基线组完整CoT不加压缩、外部摘要组用脚本对历史CoT做定期摘要、自压缩组用上面的推理笔记制提示词。跑完一百多组数据结果汇总如下任务类型基线组正确率外部摘要组正确率自压缩组正确率数学多步应用53%61%76%逻辑规则推导47%55%72%复杂场景决策38%49%68%注意这些数字是在一个未微调的通用模型上加提示词得出的不是上限但趋势已经很清楚了自压缩方案在所有任务上都明显优于外部摘要。尤其复杂场景决策任务这个任务的特点是上下文里经常出现互相约束的多条规则推理步骤又多基线组到了后期几乎等于在猜。自压缩组因为强制维护当前仍然生效的约束条件相当于给模型上了一根约束不变量扶手帮助它始终记得自己还在哪些条件的限制下做推理。不过这只是平均效果真正有信息量的是失败案例。我复盘了自压缩组里所有做错的题发现失败模式高度集中在两个场景里。第一个失败场景模型把结论压缩这一步本身写错了。举个例子一次数学推理里模型在第9步算出一个中间值X37笔记里写的却是X73。这种错误发生后后续所有引用这条笔记的推理全部跟着错而且因为笔记本身看起来很整洁模型在检查时也没有发现异常。这是压缩引入的错误——在上下文管理上降了负担却增加了单点信息错误的风险。针对这个场景我在提示词里加了一条规定关键量写入笔记时必须同时记录它是由哪些前序步骤推导出来的。比如KEY:X37 (由步骤7、8推导)。这样当系统检测到X被后续步骤引用时可以回溯验证来源而不必信任笔记中的唯一值。第二个失败场景模型判断这个分支已经封闭的时机靠后了。在逻辑规则推导任务中模型常常先走一条分支走到一半发现矛盾然后退回。但它在发现矛盾和在笔记中标记该分支封闭之间隔了太多步骤导致笔记里仍然残留着已经废弃的中间结论。后续推理一旦引用了这个残留结论就又把封闭分支的错误路径重新激活了。这个场景我目前没有完美的解法只在提示词里强调了一旦确认分支不可行立即在笔记中删除该分支下所有记录不要等待本轮推理结尾。实测能缓解一部分但模型的自我监控能力仍然不足以完全杜绝这类错误。如果你的任务也频繁涉及分支回退建议配合外部逻辑检查器做二次验证不要把希望全放在模型自觉上。还有一类失败让我意识到自压缩CoT不是万能的。当任务本身需要推理多个并行分支然后综合对比时这个方案的表现会明显下降。原因是并行分支会在笔记里产生多条同时活跃的记录模型维护起来容易顾此失彼。对这类任务我现在的做法是显式要求模型先逐分支分别完成推理笔记最后再建立一个综合笔记对比各分支结论相当于把并行推理拆成了多个串行子任务。从结果来看这个改动效果还不错。7. 逃不过的token支出问题自压缩CoT并没有真的减少总长度坦率地说这个方案在减少早期上下文被长尾稀释这件事上有效但它不是免费的午餐。我统计过完整CoT和自压缩CoT的总token数结果可能会让你意外在某些任务上自压缩CoT的总token数反而比完整CoT更多。原因在于模型每更新一次笔记都要把新的笔记内容写入上下文。如果任务本身推理节点非常多笔记本身就会膨胀成一个第二上下文。再加上模型还需要在推理和笔记之间反复切换输出节奏变得更长总token数自然就上去了。这里的分界线是任务复杂度。任务推理步数在10步以内时自压缩CoT的token开销反而高于直接输出完整CoT但正确率没明显差异——属于纯粹的浪费。突破20步以上之后完整CoT的上下文膨胀会让模型早先的结论丢失自压缩CoT的正确率优势才开始显现虽然token数仍然略高但至少推理是连贯的。到了40步以上的长链任务自压缩CoT反而开始省token了因为早期的大量过程性推理被压缩成了寥寥几笔笔记上下文增长速度远低于完整CoT。所以我的建议是给这个方案加一个仅在需要时启用的开关。如果你在跑短链路任务直接用完整CoT就够了只有当步骤数预计超过十五步、且后续步骤会反复引用早期中间量时再切换到推理笔记制。可以先把推理步数上限写在系统提示里让模型自己判断是否需要进入笔记模式。我在实际项目里就是这么做的——低复杂度任务保持原来的输出习惯只在长链任务中启用笔记维护既控制了token消耗也保证了正确率。另外还有一个成本容易被忽略解析成本。自压缩CoT的输出格式是半结构化的如果你想自动追踪模型是否在笔记中保持了约束不变这类横切性质就需要写额外的解析逻辑来读取笔记内容、检查互斥项。我在自己的项目里用了一段脚本做笔记一致性检查解析规则比直接读完整CoT要复杂得多。这是一个隐藏的开发成本做工程落地前要有心理准备。8. 数据沉淀与微调方向怎么把提示词里的行为内化成模型本能提示词工程方案的局限很明显每一次推理都要重复携带那套长指令token开销固定存在而且模型遵守规则的稳定性参差不齐状态差的时候会把笔记写得像流水账。想要根治最好还是把这些规则内化成模型自身的行为偏好。我做微调数据沉淀时采用的是先提示词后蒸馏的路线先把推理笔记制提示词跑在强模型上收集一批高质量的长链推理轨迹然后清洗这些轨迹作为训练数据用弱模型去学习。这个方法本质上是在做行为蒸馏——让弱模型直接学会强模型在提示词约束下的推理习惯但不再依赖于那套长指令文本。数据格式上我处理成类似这样的对话结构{ conversation: [ { role: user, content: 给定以下约束条件和目标请完成推理过程...描述任务 }, { role: assistant, content: 【推理笔记】\nKEY: X... (由步骤a、b推导)\nCONC: 候选方案A不可行原因是...\n\n【推理步骤】\n基于当前笔记接下来验证候选方案B...逐步推理并继续更新笔记 } ], metadata: { max_steps: 30, requires_branching: false } }这个格式给模型传递的信息是输出推理过程时可以先写当前笔记再基于笔记做下一步推理而且笔记和推理必须交错出现。训练的时候我特意把先笔记后推理这个顺序固定下来因为实测发现顺序一致时模型学得更快。数据清洗环节有几个细节值得提。第一长度筛选我只保留推理步骤数在15步以上的样本让模型在统计上有足够的压缩压力短样本没有学习的价值。第二分支封闭标注训练数据里特意加入了一批推理到一半发现此路不通退回修正笔记的样本这部分数据量不多但对于学会封闭分支这个行为至关重要。第三格式规范所有训练样本必须严格遵循同一套笔记记录格式不允许出现散文式笔记。格式的单调性直接影响模型能不能稳定输出结构化内容。做了数据蒸馏之后弱模型在长链推理上的表现确实比纯提示词方案要稳定得多。最明显的改动是模型不再需要读一遍几百字的长指令才行动而是在面对多步推理问题时自动开启笔记模式。而且整个推理输出的总token数也会下降因为长指令和解释规则遵守情况的旁白都消失了。这里必须给大家泼一盆冷水微调不是一劳永逸的。模型在训练分布内的任务上表现很好一旦遇到训练数据里没有覆盖的任务类型比如全新的推理格式、陌生的约束表达方式笔记维护的稳定性会明显下降。如果你打算做这个方向建议把微调后的模型继续配合一层轻量级外部检查而不是完全卸载掉可观测性。9. 蒸馏数据与笔记维护中的取舍什么该保留什么该丢弃聊完了微调我想把压缩什么这个问题单独拉出来展开一次。因为不管是用提示词还是微调最终效果都取决于模型在每一个压缩决策点上是否做了正确的取舍。这部分内容是我在日常实验中逐步形成的经验集合写出来供参考。先说该保留的东西。第一优先级是仍然活跃的中间量也就是后面的推理节点还会引用的数值、条件、结论。判断活跃性最简单的方式是看它最近几轮是否还在被引用。第二优先级是约束条件。很多长链推理任务最终答案是在若干约束下寻找可行解如果模型在中途忘了某个约束先前的整个搜索空间都会被污染。在笔记里单列CONS类记录就是为了让约束条件始终处于可检查的显式状态。第三优先级是分支选择的原因。这点容易被忽略——模型转到一个新分支时通常会忘记记录为什么上一个分支不行而后续如果遇到类似场景这个原因恰恰是防止再次走入死胡同的关键。那什么该被压缩甚至丢弃我归纳为这三类已经消化过的推理细节、语气词和重复性表达、以及封闭分支中的全部中间结论。很多模型在CoT里会写一些嗯这样的话X应该等于……之类的自然语言填充这部分在长链推理中没有任何信息价值压缩掉不影响任何逻辑。麻烦的是封闭分支的中间结论——如果模型记不住这个分支已经封闭后续可能会被自己之前忽略的路径重新吸引过去。所以压缩的正确做法不是简单删掉而是要在笔记里保留一行分支X已验证不可行的标记同时删除该分支下的详细推理过程。怎么判断一条记录已经可以被丢弃我现在使用的规则是后向引用稀疏化探测当某条记录在过去N步之内没有被任何新推理节点引用、且当前所有活跃约束也不依赖它时就可以压缩。实现上我会维护一个最近引用时序表每追加一步推理就更新一次。这个表本身可以放在上下文之外用代码逻辑维护定期把已不再活跃的记录物理清掉。这么做相当于给模型配了一个自动化的记忆管家。最后分享一个关于压缩粒度的经验。压缩并不是越激进越好。我一开始设定的目标是笔记不超过总输出长度的30%后来发现压得太狠时模型会把一些尚未确认终结的推理节点也折叠掉导致后续还得重新推导。最终我调整成了40%并把笔记压缩动作本身也写进输出让模型在每次压缩时明确标注我移除了哪些内容因为它们已被后续步骤消化。这个标注过程能强制模型做一个显式的因果check压缩的准确性因此提高不少。10. 踩坑记录与可复用的检查清单这一节写一下我在实现和调优过程中踩过的坑以及我沉淀下来的一套检查清单。第一个坑是模型把笔记写成了文本摘要。推理笔记制的核心是结构化数据但模型在早期经常把笔记写成散文段落看起来像总结实际上丢了精确性。后来我放弃了自然语言式约束改为在提示词里直接给出笔记模板并用JSON区块约束输出结构。模型一旦输出非JSON格式就触发重试。这个改动让笔记内容可以精确解析质量也可以程序化检验。第二个坑是浅拷贝式笔记。模型有时会直接把上一步的完整输出复制到笔记里美其名曰维护记录实际完全没有压缩。后续步骤读到这种笔记等于还是面对一整段原始CoT。对策是限制笔记容量当笔记总token超过阈值时不允许继续追加强制模型在旧记录上做删减或压缩后才能写入新内容。这个容量受限机制是整个方案里最接近物理有效的一环——没有上限模型就不会真正学会取舍。第三个坑是笔记和推理脱节。我在测试中发现模型偶尔会通篇维护笔记但推理时却完全不在笔记里读取历史信息——笔记只是摆设。后来复查发现是训练数据里基于笔记进行推理的样本比例不够。解决办法是把数据里的推理步骤改成显式引用形式比如根据笔记KEY:X现在计算Y让模型把查阅笔记这个动作变成推理步骤的一部分。加了这条之后脱节现象明显减少。除了这三点另一个值得注意的工程坑是迭代次数失控。模型在发现笔记内容矛盾后会主动回溯推理。这是好事但如果不限制回溯次数模型可能陷入回溯-重推-矛盾-再回溯的死循环。我在系统提示里加了最多回溯两次第二次回溯后仍未解决矛盾时放弃该分支并选择另一个方向。这个约束虽然看起来有点暴力但它避免了很多无谓的token消耗。做自压缩CoT的过程中我养成了一个检查清单每次调整方案后都照着过一遍笔记是否保持结构化格式且可以直接程序化解析关键中间量是否明确标注了推导来源步骤已被后续引用的记录是否提高了保留优先级封闭分支的详细推理过程是否已删除只保留了结论标记笔记总长度是否控制在输出长度的40%以内模型推理时是否显式引用了笔记内容而不是只用最近的上下文迭代回溯次数是否有上限输出里是否包含压缩了什么、为什么压缩的显式标注这个清单我每次跑长链任务都会过一遍哪怕没做任何改动也至少能快速定位问题是出在压缩决策、引用机制还是回溯逻辑上。你如果照着这套方案去试建议也先把这个清单沉淀成自己的固定检查流程。它比任何单一的技术技巧都更能帮你避坑。