（来源：网易科技）
长程任务需要执行许多步骤，长输入任务需要处理大量材料，但这是否意味着模型必须始终保留长上下文？
英伟达新研究发现，完成所谓的长上下文任务，并不需要长上下文。
论文链接：https://arxiv.org/abs/2611.05306
研究团队通过频繁压缩历史和选择性读取输入，检验模型能否在短上下文中完成长程与长输入任务，并据此提出语义状态空间模型（Semantic State Space Models，SSSMs）的概念。根据他们给出的结果，在所测试的多种任务中，保持短上下文带来的准确率损失很小，或者没有损失。即使每段上下文最多执行一次动作，模型在长程软件工程任务中的表现也没有崩溃。
他们关注的首先是长上下文的实际开销。对于研究讨论的主流注意力架构，生成一个 token 所需的计算量随其在上下文中的位置增加而增长，位置靠后的 token 比位置靠前的 token 生成成本更高。在前沿开放权重模型上，这种成本差异最高可达 7 倍。所以，上下文越长，输出 token 的生成开销越高。不过，云端服务通常按固定的每百万 token 单价收费，用户未必能够直接察觉这种成本差异。
一方面，长上下文会增加生成开销。另一方面，模型的上下文窗口持续扩大，能够容纳的文本规模已经超过许多长篇作品。这促使他们追问，完成通常被归入长上下文的任务，是否确实需要长上下文？
他们将上下文变长的原因分为两类。一类是长程任务，模型需要采取多次动作才能完成目标，交互历史随着任务推进不断积累。另一类是长输入任务，任务本身附带大量信息，直接输入便会形成长上下文。
但执行过程长，不代表模型每一步都必须重新考虑全部历史。输入材料多，也不代表模型必须始终读取全部内容。他们指出，如果将长输入保存为资源，再为模型提供选择性读取工具，长输入任务就可以转化为需要多次行动的长程任务。
围绕这两类任务，他们提出三个研究问题，RQ1 考察长程任务能否在没有长上下文的情况下完成。RQ2 考察长输入任务能否在没有长上下文的情况下完成。RQ3 则进一步考察，当每段上下文最多执行一次动作时，模型能否完成长程任务。
图｜本研究考察的三种上下文管理策略
针对 RQ1，他们采用对话末尾压缩，比较压缩历史与保留完整历史时的任务准确率。他们发现，即使采用这种简单的压缩方式，准确率通常也能达到或略高于完整历史基线。在其余设置中，准确率损失较小。这表明，在这些测试中，模型无须持续保留全部交互记录，也能维持接近原有水平的任务表现。
图｜长程任务结果随总上下文上限的变化
RQ2 将考察对象转向长输入。模型面对的材料总量并未减少，改变的是访问方式。他们采用选择性读取，并在需要时使用上下文压缩作为后备措施，使模型能够处理长材料，同时保持较短的实时上下文。这种方式在几乎所有测试情形中都能达到或超过一次性输入完整材料的基线，部分情形下改善幅度较大。对于这些任务，输入材料很长，并不要求模型始终将全部内容放在当前上下文中。
图｜长输入任务结果随总上下文上限的变化
前两组问题分别考察了历史压缩与选择性读取，RQ3 则进一步考察动作之间需要传递多少历史。他们测试单动作压缩，每段上下文最多执行一次动作，动作之间只传递紧凑的语义状态。单动作压缩能够大致保持基线准确率，或者取得更高的准确率。在这一条件下，模型在长程软件工程任务中的表现没有崩溃。
图｜SAC 与 FHA、EoCC 的比较
SSSMs 正是基于这些发现提出的模型概念。通过紧凑的语义状态衔接连续动作，是他们在单动作压缩实验中考察的执行方式，也是这一概念的出发点。
由此，长程任务可以通过压缩减少历史积累，长输入任务可以通过选择性读取控制当前上下文，单动作压缩则进一步检验了紧凑状态能否支持连续执行。
三个研究问题最终回到同一个核心问题，任务很长，是否就意味着上下文必须很长？他们据此认为，在所测试的设置中，长输入和长交互过程本身，都不足以构成长上下文必不可少的理由。通过有组织的状态维护与选择性访问，模型能够保持较短的上下文，同时维持接近或更高的任务准确率。
更多技术细节，详见原论文。
作者：张佳怡
