拆解大模型的“工作记忆”：上下文窗口从4K到1M的进化之路

还是奇怪

222人浏览 · 2026-06-02 10:59:19

还是奇怪 · 2026-06-02 10:59:19 发布

文章目录

1. “上下文窗口”到底是什么
2. 发展简史：从“金鱼记忆”到“过目不忘”的军备竞赛
3. 技术解密：模型是如何“看见”更长的上下文的？
4. 长上下文的三大核心挑战
5. 如何用好上下文窗口？
6. 上下文窗口的尽头是什么？

2024年，大模型的上下文窗口已经卷到了惊人的100万Token，足以一口气吞下《三体》全集。似乎“记忆力”问题已被彻底解决。但一个讽刺的发现是：模型能“看到”全文，却经常忽略你藏在中间的关键指令——这被称为“迷失在中间”现象。

长的上下文窗口，真的直接等同于更好的理解和推理能力吗？答案远比你想象的复杂。事实上，上下文窗口的进化史，就是一部在算力、记忆与理解力之间反复平衡的技术军备竞赛史。要真正用好大模型，我们必须先读懂它的 “工作记忆”。

1. “上下文窗口”到底是什么

那么，这个让大模型时而“失忆”、时而又能通读巨著的“上下文窗口”，到底是什么？

核心定义一句话：

上下文窗口（Context Window）是大模型在生成每一个词时，一次性能“看到”并作为推理依据的文本令牌（Token）的最大数量。它本质上就是模型单次处理信息的“工作记忆”容量上限。

为了让这个定义真正落地，我们用三层递进来吃透它。

第一层：把它想象成“桌面的面积”

你坐在图书馆里研究一个课题。每次你只能从书架上抱来一摞书和资料，摊在面前的桌子上。

如果桌子很小（比如只有 4K Token），你一次只能摆开几张纸，写出的分析注定只能基于极其有限的信息。
如果桌子很大（比如 100K 甚至 1M Token），你能同时摊开一整本《三体》、几十篇论文，甚至一整部代码库，在它们之间建立关联，给出跨文档的洞察。

这个“桌面”的面积，就是上下文窗口。桌子越大，你单次能同时参考的资料就越多，推理的上限也就越高。

第二层：理解它的计量单位——Token（令牌）

上下文窗口的大小不是用“字”或“词”来算的，而是用 Token。

在大模型的世界里，Token 是文本被切分后的最小处理单元。英文中，一个单词大约等于 1-2 个 Token；中文里，一个汉字通常也是 1-2 个 Token。
一个 4K（即 4,096 Token）的窗口，大约能容纳一篇 3000 字左右的短文章。
一个 128K 的窗口，可以一口气吞下约 10 万字的内容，相当于一本中篇小说。
像 Gemini 1.5 Pro 的 1M（100万）Token 窗口，则能直接处理数小时的视频、音频，或一整部《战争与和平》级别的长篇小说。

第三层：分清两个容易混淆的概念——“窗口” vs “记忆”

上下文窗口是单次请求中模型能“看见”的文本上限，它是一次性的、硬性的工作区。
模型的长期记忆（如训练时学到的知识、或通过外部向量数据库实现的知识）则不在这个窗口之内。窗口关闭，本次对话的历史就会被“清空”。
换句话说，上下文窗口是模型处理当前任务时的 “瞬时工作记忆” ，而它训练完成时固化的世界知识，是它的 “长期知识库” 。

所以，当你觉得 ChatGPT“失忆”了，不是它忘了你这个人，而是你的关键信息已经从它的上下文窗口中滑出去了——就像你桌面上被拿走的资料，无法再被用于当前的分析。

一句话总结：

“上下文窗口，就是大模型在说下一句话之前，最多能‘回想’起的前文总量。”

2. 发展简史：从“金鱼记忆”到“过目不忘”的军备竞赛

如果要用一句话概括上下文窗口的进化史，那就是：人类对AI“记忆力”的贪婪，驱动了一场不到五年就将窗口扩大了一万倍的技术竞速。让我们回到起点，看这场竞赛如何一步步把大模型从“金鱼”变成了能通读巨著的“速记员”。

1. 阶段一：石器时代 —— 1K-2K Token（2018-2019）

一切要从GPT-1和BERT说起。2018年，GPT-1的上下文窗口只有 512 Token，连一篇稍长的新闻报道都塞不下。随后GPT-2扩展到 1024 Token，BERT则是 512 Token。

这个时代，模型的“工作桌面”也就一张便签纸大小。你让它写一段文字，它只能参考紧挨着的前文。只要稍微多聊两句，它就像一个永远在“断片”边缘的人，每一句都可能是重新开始。

2. 阶段二：GPT-3 时代 —— 4K Token（2020-2021）

2020年，GPT-3横空出世，将上下文窗口拉到 2048 Token，后续版本扩展到 4096 Token。一下子，模型的“桌面”从便签纸变成了一页A4纸。

这意味着什么？你可以给它一段相对完整的背景说明，它能在整个回答中保持主题一致性。开发者开始能用它来总结短文档、写中等篇幅的文章。但你想让它读完一本小册子？抱歉，窗口还是太小。这个时期，AI能处理的任务，天然被限制在“短文本”的牢笼里。

3. 阶段三：长窗口爆发前夜 —— 8K-32K Token（2022-2023）

真正的军备竞赛，从这时悄然打响。

2022年，Anthropic推出Claude，率先支持 100K Token，震惊业界。你能把《了不起的盖茨比》整本塞进去，让它分析人物和情节。这不再是“读一段回一句”，而是“读一整本再回你”。

OpenAI紧追不放。2023年底，GPT-4 Turbo带着 128K Token 窗口登场，可以一口气吞下约300页书的内容。一夜之间，长文档问答、法律合同审查、代码库级别的理解，从“不可能”变成了“标配”。

这时候，核心矛盾开始显现：能塞进去 ≠ 能看清。

4. 阶段四：百万Token时代的到来 —— 1M-2M Token（2024）

如果说之前是量变，2024年就是质变。

Google推出Gemini 1.5 Pro，直接亮出 1M（100万）Token 的杀手锏，后续甚至扩展到 2M Token。这相当于什么？它能一口气处理：

超过 11小时 的音频
超过 1小时 的视频
整个 《三体》 三部曲的体量

Anthropic的Claude 3系列也支持到 200K Token，在长文本理解和准确率上与之对垒。

窗口的大小竞赛，此时已进入了一个“超现实”阶段。单论容量，几部小说、一整天的会议录音、几万行代码库，都已是桌上一角。

5. 阶段五：反思与回归理性 —— “更大”不等于“更好”（2025至今）

当数字的狂欢趋于冷静，一个更本质的问题浮现：给它一个图书馆，它真的会认真读完每一本书吗？

研究揭示了一个现象，叫 “迷失在中间”（Lost in the Middle）——模型对开头和结尾的信息吸收最好，中间部分却被天然忽略，仿佛从未存在过。你把最重要的指令藏在几千页报告的中间段落，它大概率“看”不到。

同时，长窗口是“烧”出来的。注意力计算的复杂度与序列长度呈 平方关系，窗口翻倍，计算量翻四倍。这直接带来了首字延迟的飙升和API成本的暴涨——为了那可能被“忽略”的中间部分，你支付了真金白银。

于是，竞赛的方向开始从单纯的 “能塞下多少”，微妙地转向 “能真正理解多少”，以及 “用什么样的代价来理解”。

小时间线速览表

为了让这段历史一目了然，这里有一份速览：

时间	标志性模型	上下文窗口	约等于能处理的文本量
2018	GPT-1 / BERT	512	半页纸
2019	GPT-2	1024	一页纸
2020	GPT-3	2048-4096	一篇短文
2022	Claude (初代)	100K	一本小说
2023	GPT-4 Turbo	128K	约300页书
2024	Gemini 1.5 Pro	1M-2M	多部小说 / 数小时视频
2025-2026	o1 / o3 / Claude 3.5 系列等	128K-200K (重在强化推理与深层理解)	理性回归，发展出“思考/推理时间”，重在深度而非一味追求容量

3. 技术解密：模型是如何“看见”更长的上下文的？

读到这里，你可能会有一个疑问：既然注意力计算的复杂度随长度平方级增长，那从4K到128K甚至1M Token，模型岂不是要算到天荒地老？这笔“算力账”到底是怎么被抹平的？

简单说，为了让模型“看见”更长的上下文，研究者们在三个关键战场上同时打了三场硬仗：位置编码、注意力机制、以及数据与微调策略。每一场都贡献了不可或缺的突破。

第一战场：位置编码的革命 —— 让模型知道“谁在哪”

Transformer模型架构本身并没有内置“位置”的概念。对它来说，“我爱你”和“你爱我”只是三个相同的词。为了让模型理解词序，我们需要给每个词“打上位置的标签”——这就是位置编码。

1. 绝对位置编码：每人一个固定座位号
最直觉的做法，是给第一个词标“1号”，第二个词标“2号”……以此类推。这就像教室里每人一个固定座位。简单，但有个致命缺陷：一旦训练时只见过512个座位，推理时突然出现第513号座位，模型就懵了。它不知道怎么处理“没学过”的位置编号。所以，绝对位置编码天然不具备外推性，无法处理比训练时更长的序列。

2. RoPE（旋转位置编码）：给每个词一个“角度”
RoPE的思路完全不一样。它不标座位号，而是给每个词分配一个旋转角度。想象每个词的向量都在一个圆上，第一个词的角度小，越往后角度越大。当模型计算两个词之间的“注意力”时，它不看它们的绝对角度，而只看它们的相对角度差。

这就带来了一个绝妙的性质：无论序列有多长，词与词之间的相对位置关系始终是被良好定义的。因为角度是可以连续旋转的，所以理论上可以外推到训练时从未见过的长度。今天几乎所有主流开源模型（LLaMA系列、Qwen、DeepSeek等）都采用RoPE，它是长上下文扩展最核心的基石。

3. ALiBi：直接告诉模型“越远越不重要”
另一种更简单暴力的思路来自ALiBi。它不学习任何位置编码，而是直接给注意力分数加一个偏置：两个词离得越远，惩罚就越大。这等于直接给模型植入了一个先验——“优先看近的词，远词的影响自然衰减”。因为没有任何需要学习的参数，ALiBi的外推能力极强，训练时4K的模型，推理时直接拉到16K也往往表现不错。

第二战场：注意力机制的瘦身 —— 解决“算不动”的问题

位置编码解决了“知道谁在哪”，但还有一个更根本的问题：序列变长后，注意力矩阵的尺寸会平方级爆炸。一个100万Token的序列，其原始注意力矩阵有1万亿个元素——没有任何硬件能算。于是，研究者开始给注意力机制“减肥”。

1. 稀疏注意力：不需要每个词都看所有词
核心洞察是：并非所有词之间都需要建立连接。当前词往往最关心它的邻居，以及少数全局关键词。于是，人们设计了各种“稀疏模式”：

滑动窗口注意力：每个词只关注它前后一个固定窗口内的词。就像你读书时，当前段落和前后几段最相关，远处的章节暂不调用。
全局+局部注意力：少数特殊词（如句首的CLS Token或Prompt中标记的关键位置）可以与所有词互相关注，而普通词仍然只看局部窗口。这样既保留了跨距离的信息通道，又大幅压低了计算量。

2. Ring Attention（环形注意力）：把长序列“切块”分给多个GPU
当序列实在太长，单张GPU的显存连存下注意力矩阵的一行都困难时，Ring Attention出场了。它的思路是：把长序列切成多块，分配给排成一个环的多张GPU。每张GPU负责计算自己那块的自注意力，同时把当前块传给下一个邻居。通过这种环状接力，整个长序列的注意力计算被分摊到了所有GPU上。这本质上是一个分布式计算策略，用多卡并行换取了单卡永远无法企及的窗口长度。

第三战场：上下文扩展微调 —— 用“拉伸”而非“重训”

有了位置编码和高效注意力的理论支撑，工程上还有一个问题：怎么让一个已经训练好的模型，适应比它训练时长得多的窗口？从头训练成本太高，于是“微调拉伸”技术应运而生。

1. 位置插值（Position Interpolation）
最直觉的做法。假设模型训练时窗口是4K，现在想扩展到32K。我们可以把新序列中的所有位置编号按比例“压缩”回4K范围内。原来每4个Token的位置，现在8个Token共享一个编号区间。这种简单缩放在初期很有效，但会损失一定精度，因为模型被迫在更细的粒度上分辨位置。

2. NTK-Aware 插值
这是对位置插值的改进，借鉴了信号处理中的Nyquist-Shannon采样定理思想。简单说，它不是均匀压缩所有频率的位置信息，而是重点压缩高频部分（近处的位置分辨），保留低频部分（远处的位置分辨）。这使得扩展后的模型既能顾好近处，也不至于对远处完全失去分辨力，效果比均匀插值提升显著。

3. YaRN（Yet another RoPE extensioN method）
YaRN在NTK-Aware的基础上再进一步，结合了插值策略和温度调节，是目前RoPE扩展最主流且效果最好的方法之一。很多开源模型的128K长上下文版本，都是用YaRN或类似方案，仅需几百步微调、极少的长文本数据，就能将原本4K的模型安全地“拉伸”到128K。

小结

三场战争打完，技术路线也清晰了：

RoPE/ALiBi 让位置信息不再成为瓶颈。
稀疏注意力 / Ring Attention 让算力和显存不再成为瓶颈。
插值微调 / YaRN 让“拉伸旧模型”的成本不再成为瓶颈。

正是这三重突破叠加在一起，才让上下文窗口从4K到1M的跨越成为可能。

4. 长上下文的三大核心挑战

技术上的突破让模型“看见”了更长的上下文，但一个令人不安的事实随后浮出水面：窗口容量只是“准入证”，远不是“理解力”的保证书。就像给你一间图书馆，不代表你会认真读完每一本书。长上下文窗口面临三个核心挑战，每一个都直指当前技术的软肋。

挑战一：“迷失在中间”（Lost in the Middle）—— 最致命的信息盲区

这是长上下文研究中最具冲击力的发现，也是每一位开发者都必须刻在脑中的现象。

现象是什么？
当研究者把一段关键信息分别放在长文档的开头、中间和末尾，然后测试模型能否准确回答基于该信息的问题，结果令人震惊：无论文档有多长、无论模型的窗口有多大，模型对开头和末尾的信息抓取最好，而对中间部分的信息提取准确率断崖式下跌——如同被腰斩一般。

换句话说，你如果把最重要的指令、最核心的业务规则藏在Prompt的中间段落，模型大概率会“视而不见”。

为什么会这样？
这并非Bug，而更像是 Transformer架构的某种“天性”。一种解释是，自注意力机制在处理序列时，位置靠前的信息有更多机会在逐层传递中被“反复回顾”而巩固；位置靠后的信息因距离输出层最近而天然被“关注”；唯有中间部分，既缺乏开头的先发优势，又没有末尾的临近优势，在多层的传递中被逐渐“稀释”掉了。

对实际使用的冲击有多大？

你做合同审查，把关键条款放在上传文档的中间，模型可能漏审。
你写了一个很长的Few-shot Prompt，例子都放在中间，模型可能根本没学到。
你做 RAG（检索增强生成），召回了10段相关文本，把最相关的那段放在中间位置，模型可能恰恰忽略了它。

理解“迷失在中间”，是驾驭长上下文窗口的第一课。

挑战二：“大海捞针”的虚荣陷阱 —— 检索≠理解

你可能听说过一个风靡行业的测试叫 “大海捞针”（Needle in a Haystack）：在长文档的任意位置藏一句完全无关的“针”（比如“匹萨的配料是菠萝”），然后问模型这句话是什么。很多长上下文模型都通过了这项测试，准确率极高。

但这恰恰是一个虚荣指标。

它的局限在哪？

“大海捞针”测的是单点检索能力——从一堆信息中准确地找到那一句原话。但真实世界的任务远比这复杂：

多点关联：关键信息分散在不同的段落，需要综合推理。模型能把分散的线索串起来吗？
逻辑推理：不是找原话，而是基于全文得出一个没有明说的结论。
时序因果：事件A在章节2，事件B在章节7，二者有因果关系，模型能从时间线中推断出来吗？

这些才是“理解”的本质，而单纯通过“大海捞针”只能证明模型有足够大的“寻址空间”，不能证明它有真正的长程推理能力。找到一根针，和读懂一本书的谋篇布局，是截然不同的能力层级。

更值得关注的评估方式是 “大海捞针多针版”（Multi-Needle） 或 长文本问答基准（如L-Eval、LongBench），这些测试开始关注多条信息的综合与推理，但目前还远未成为行业标配。

挑战三：成本与延迟的隐形代价 —— “烧钱”的长窗口

即便模型能在某种程度上克服前两个挑战，第三个挑战也没有技术上的完美解：长上下文窗口很贵，而且会一直贵下去。

首Token延迟的剧增
大模型是“读完再回答”的，你给的上下文越长，模型处理Prompt的时间就越久。这种等待被称为“首Token延迟”。用户体验的铁律是：超过2秒的等待，用户就会开始焦虑；超过5秒，用户可能直接关掉页面。对于需要实时交互的场景（如语音对话、AI搜索），首Token延迟是致命的。

注意力计算的平方级增长
我们再回到那个核心公式：自注意力的计算复杂度是O(n²)。这意味着什么？直观来看：

窗口大小	相对计算量（与4K比较）
4K	1x
32K	64x
128K	1024x
1M	约 62,500x

即便有稀疏注意力和分布式计算的优化，这个增长趋势是无法彻底消除的物理约束。每一次把窗口扩大，背后都意味着更多的GPU、更高的电费、更贵的API调用。

API定价的直观感受
你可以打开各家的API定价表对比一下：同等能力层级的模型，长上下文版本的单价往往是标准版的数倍甚至十数倍。如果你在一个Agent系统中反复调用长上下文模型，每轮循环都携带完整的对话历史，账单会以肉眼可见的速度飙升。

这倒逼我们思考：把一切都扔进上下文窗口，真的是最优解吗？还是说，我们应该更聪明地选择哪些信息值得进入窗口，哪些应该被过滤、摘要或存储在外部的记忆中？

5. 如何用好上下文窗口？

理论说了这么多，最终还是要落到代码和产品里。不管你是在构建一个Agent、一个知识库问答系统，还是一个陪伴式对话应用，下面这四套策略，或许都能帮你一二。

策略一：动态上下文管理

大多数对话式应用最朴素的实现，就是把整个对话历史无脑塞进API。这在短对话时毫无问题，但一旦聊上几十轮，窗口迅速被旧消息淹没，剩下的空间寥寥无几，成本却一路飙升。

核心思路：上下文窗口不是垃圾场，不要什么都往里扔。你需要一个“记忆管理器”。

实操方案：

滑动窗口 + 摘要（Sliding Window with Summary）
保留最近N轮对话的完整消息（N根据你预估的每轮Token用量和总预算设定），而对更早的历史，调用模型自己生成一份阶段性摘要。每一轮请求，都带上这份摘要作为“背景”，再附上最近的详细对话。这样，模型既能把握全局脉络，又不丢失当下的细节。
```
[系统提示词]
[长期记忆摘要：用户偏好、关键决策、前期结论]
[最近10轮完整对话]
[用户最新输入]
```
分层记忆架构
如果你在做一个长期陪伴型Agent，可以引入三层记忆：
- 即时上下文：当前窗口内的完整信息。
- 短期记忆：近期对话摘要或关键事件，定时刷新。
- 长期记忆：与用户相关的稳定信息（如姓名、喜好、历史大事），存入外部数据库，每次会话开始时检索注入。这样每次只需占用极少的Token。
对话截断的艺术
当窗口逼近上限时，不要简单地从头部粗暴删除。优先删除“已被模型充分响应且不再被后续逻辑依赖”的旧轮次。可以给每条历史消息打一个“重要性”评分（可以用另一条便宜的小模型来打分），淘汰时优先丢弃低价值信息。

策略二：关键信息前置与结构化

上文提到，“迷失在中间”是长上下文的头号杀手。你的第一道防线，就是主动设计Prompt的结构，把最重要的信息放在模型注意力最集中的地方。

核心原则：重要的放两头，不重要的放中间；全局指令放开头，即时任务放结尾。

实操方案：

采用“三明治”结构
```
[开头：角色设定、全局规则、核心约束]
[中间：参考文档、例子、数据（大量内容）]
[结尾：当前具体问题、要求输出格式]
```
开头部分用来框定模型的行为边界和背景知识，结尾部分精确下达本次任务指令。即使中间信息被稀释，模型依然能在规则和任务的双重锚定下，给出基本可用的回复。对于极其关键的中间信息，可以适当在结尾处“复述”一句提醒。
用XML/标记语言明确划分区域
别指望模型光凭自然段就理解你的意图。直接用标签把不同职能的内容包裹起来：
```
 <system>
你是一个严谨的法律顾问...
</system>

<context>
[粘贴的合同原文、法条等]
</context>

<question>
[具体要分析的问题]
</question>
```
研究显示，明确的标签能帮助模型在内部注意力路由时建立清晰的边界，提升对特定区域的关注度。某些模型甚至已经在训练中对特定标签做过优化。
关键指令二次曝光
对于绝对不能忽略的规则，可以在system prompt里说一次，然后在用户消息的末尾再以“请记住：…”的形式重复一次。这不是啰嗦，而是确保它出现在模型注意力最强的“末尾区”。

策略三：RAG 与长窗口的黄金搭档

很多人曾以为，一旦模型支持1M窗口，RAG（检索增强生成）就要退出历史舞台了。但现实恰恰相反：长上下文窗口和RAG不是互相替代，而是彼此成就。

为什么不能只用长窗口？
将整个知识库塞进窗口，代价极高（见挑战三），而且引入大量噪声。模型在信息海洋里被打捞的，往往是你最需要的那几条，其余的全是干扰。RAG就是那个精准的“过滤器”。

最佳组合模式：

检索 + 长窗口 = 高质量回答
用RAG从你的海量知识库中，精确检索出与当前问题最相关的若干段落（比如Top 20段）。然后，利用长窗口的优势，将这些检索结果连同它们周边的上下文一并送入模型。过去受限于窗口太小，你只能给检索出来的那几句话；现在有了更长的窗口，你可以放心地给模型更完整的段落甚至整个章节，让它在更丰富的语境中理解和推理，答案质量自然飞跃。
长窗口作为“精读器”
在一些需要深度分析的场景里，可以先用RAG快速定位相关文档，然后用长窗口一次加载整篇文档，要求模型进行跨段落推理、矛盾检测或整体总结。这相当于先用索引找到书，再把整本书铺在“桌面”上细读。
成本控制视角：永远记得，将整个库全量传进去的Token费用，是检索式注入的成百上千倍。RAG帮你把预算花在刀刃上。

策略四：流式输出与感知性能优化 —— 让等待“消失”

长Prompt带来的首Token延迟无法物理消除，但可以心理消除。

实操方案：

始终启用流式输出（Streaming）
不要等模型想完整个答案再返回。边想边发，哪怕首Token延迟有3秒，一旦第一个字出现，用户的等待焦虑就会大幅下降。前端UI上立刻显示一个打字光标，然后逐字渲染。
预生成占位符
在模型真正开始推理前，可以先向客户端发送一条“准备中”的状态消息或一个进度骨架。这能填满那几秒的空白。
异步任务队列
对于非实时场景，比如批量文档分析、报告生成，直接走异步任务。用户提交后告知“预计需要30秒”，然后去做别的事。把“等待”从交互环节中剥离。
尽量缩短Prompt本身（老生常谈但永远有效）
每次发请求前，用程序自动扫描一下Prompt，去掉多余的空格、无意义的礼貌用语（对模型而言），压缩真正消耗Token的文本。对于参考材料，如果模型没要求全文，你可以先用一小段摘要来评估是否真有必要传入全文。

6. 上下文窗口的尽头是什么？

当我们看完上下文窗口的进化、挑战与实战策略，一个更大的问题自然浮现：这场军备竞赛的终点在哪里？上下文窗口的未来，究竟是无限扩张，还是彻底消失？

答案或许比“更大窗口”更激动人心，来让我们预言一波。

终局一：从“平方”到“线性” —— 架构范式的潜在颠覆

今天长上下文的一切挣扎，根源都在 Transformer 的 O(n²) 复杂度。只要这个平方诅咒还在，窗口扩张就是一场与算力成本的无尽消耗战。但已经有一批探索者，试图从架构本身解除这个诅咒。

状态空间模型（State Space Models, SSM） 正是其中最亮的火种。代表架构如 Mamba、RWKV、RetNet，它们用另一种数学框架来处理序列：不再让每个词去关注所有词，而是维持一个持续更新的“隐藏状态”，像一个压缩的摘要，一边读入新词一边更新这个摘要状态。这让计算复杂度从平方降到了 O(n)——线性。

线性复杂度意味着什么？理论上，处理百万级序列的计算量不再爆炸，首Token延迟也不再随长度剧烈增长。Mamba-2 等模型已经在长序列任务上展现出与 Transformer 可比的性能，同时推理速度数倍于同量级的注意力模型。这不是修修补补的优化，而是对底层运算逻辑的重新定义。

如果线性架构在未来 3-5 年成为主流，上下文窗口的物理极限将大大松绑，“一次性读完整个知识库”可能不再是疯狂的成本黑洞。

终局二：从“窗口”到“记忆系统” —— 工作记忆与长期记忆的分离

今天我们把一切都粗暴地塞进上下文窗口，是因为窗口就是模型唯一的“记忆体”。但人脑不是这样工作的。我们有工作记忆（短期、有限容量）和长期记忆（几乎无限的存储，需要检索提取）。

大模型的架构也在朝这个方向演进：