大模型的“工作记忆”：上下文窗口容量究竟意味着什么？

引言：从千词到千万词

2026年，大型语言模型（LLM）的上下文窗口迎来了里程碑式的突破。Meta的Llama 4 Scout以1000万token的容量创下新纪录，Google Gemini 3 Pro达到200万token，而GPT-5.1、Claude Opus 4.7等主流模型也普遍迈入百万token俱乐部。

上下文窗口，简单来说就是模型在生成回应时能够“同时看到”的最大信息量，相当于它的工作记忆。2022年ChatGPT初代仅能处理约4000个token（约3000个英文单词），对话稍长就会“失忆”或跑题。短短四年间，这个数字增长了2500倍。

但一个关键问题随之浮现：宣称的容量，真的等于有效可用的容量吗？

数字背后的现实含义

100万token究竟意味着什么？这个问题的答案取决于你处理的是什么内容。

在英文场景中，1 token通常约等于0.75个英文词，1M token大致对应75万英文词，约等于《三体》三部曲的总篇幅。在中文环境下，一个汉字通常对应1到2个token，1M token可处理75万到100万汉字——相当于一本极厚的长篇小说。

从文件类型来看，1M token大约可以容纳300-500页的PDF文档、一个中型代码仓库的全部源码，或数十份长篇法律合同。Gemini 1.5 Pro的1M窗口还被报告可同时处理约1小时的音频或3小时的视频内容。

10M token则更是“海量”——相当于数万页文本，足以覆盖一个大型项目的完整文档集。

美丽假设与残酷现实

然而，业界存在一个基本假设：模型应该能均匀地处理上下文中的所有信息——第10万个token应该和第100个token一样可靠。这个假设支撑着整个长上下文叙事。

2025年7月，向量数据库公司Chroma发布了一份震撼业界的报告《Context Rot》，对18款主流LLM进行了系统性评估，揭示了一个扎心的事实：随着输入长度增加，所有模型的性能都会出现显著衰减，即使是最简单的任务也不例外。

研究团队设计了一个极其简单的实验——让模型复制一串重复的单词序列，并在特定位置插入一个独特单词。任务本身毫无难度，但随着单词数量从25增加到10000，所有模型的复制准确率持续下降。Claude Opus 4甚至出现了2.89%的任务拒绝率。

更令人意外的是**“大海结构”实验**：研究人员发现，当“大海”（即填充的无关文本）保持逻辑连贯时，模型表现反而更差；而将句子随机打乱、移除局部连贯性后，模型性能反而提升。这个反直觉的发现暗示，模型并非均匀处理所有输入，输入的结构模式可能严重干扰其注意力机制。

“迷失在中间”与有效上下文

上述现象与一个广为人知的问题密切相关——“迷失在中间”（Lost in the Middle）效应。研究表明，现代LLM对信息的感知存在明显的首因效应和近因效应：它们更关注位于上下文开头或结尾的信息，而对中间部分“视而不见”。

以LLaMA 3.1为例，其宣称窗口为128k token，但在测试中，距离开头超过约64k token的信息几乎不会影响模型回应。对于大多数开源LLM，其实际有效记忆不到宣称窗口的一半。

2026年的评测基准如RULER、LongBench v2显示，多数模型的有效上下文通常比宣称值短30%-60%。一位工程师的诚实总结是：“宣称窗口现在比多跳任务上的有效窗口大4-20倍。”

为什么长上下文如此昂贵？

即便有效利用不足，长上下文本身的成本却是实实在在的。

计算复杂度是首要瓶颈。Transformer的自注意力机制复杂度与序列长度成二次方关系——上下文长度翻倍，内存和计算需求约增加四倍。例如，从1024 token扩展到4096 token，资源消耗理论上增加约16倍。

经济成本同样惊人。商业API通常按输入token计费，一个50万token的提示词，成本约为1万token提示词的50倍，且许多提供商对超过20万token的输入收取“长上下文溢价”。在实际生产中，一个调用6-12个工具的多步代理任务，到第10步时提示词可能已经达到15-18万token。

延迟也随上下文线性增长：一个100万token的提示词，首token延迟可能增加30-60秒。

长上下文的真正解法

面对这些限制，业界并未坐等模型架构突破。目前成熟的应对思路有三条：

第一，RAG（检索增强生成）。与其把百万token全部塞进窗口，不如先通过检索找出最相关的几个片段，再交给模型处理。2026年的生产实践中，3.2万token窗口配合重排序，其成本调整后的忠实度表现优于直接使用100万token窗口。

第二，上下文压缩与管理。MemGPT等项目受操作系统分层内存机制启发，让模型代理动态管理上下文窗口——决定哪些信息保留、哪些压缩、哪些存档。Adaptive Focus Memory（AFM）框架进一步将每条消息分为“完整”、“压缩”或“占位”三级，在保留关键事实的同时将token使用量减少约66%。

第三，递归处理策略。MIT CSAIL团队提出的递归语言模型（RLM）干脆将超长文本处理“外包”给Python环境——模型通过自动编程和递归调用拆解任务，按需处理，将输入长度与上下文窗口彻底解耦。在600万至1100万token规模的多文档推理任务中，RLM方案取得了91.33%的正确率。

结论：容量是前提，利用才是关键

上下文窗口从4K到10M的增长，无疑是LLM能力边界的重大拓展。它让模型能够“看到”更长的对话、更完整的文档、更大的代码库，开辟了文档级问答、跨文档推理、长时程代理等全新应用场景。

但数字本身并不等于能力。宣称的窗口长度是“上限”，有效利用的上下文才是“实际能力”。在真实的复杂任务中，模型往往连宣称容量的一半都无法稳定使用。

对开发者而言，正确的策略或许是：不要只盯着“窗口有多大”，更要关注“如何高效利用窗口”。RAG、上下文压缩、递归拆解——这些工程手段在2026年依然是弥补模型先天局限、控制成本、提升效果的核心工具。正如一位2026年工程师所总结的：“有效上下文是‘在多跳任务上真正可用的那部分’，而宣称窗口只是一个起点。”