揭秘 LLM 上下文窗口：AI 记忆如何工作以及为什么会失效

一位开发者在 Dev.to 上发表文章，深入探讨了大语言模型（LLM）的上下文窗口（Context Window）的工作原理，以及为什么它经常会"忘记"之前的信息。文章以一个常见的场景开场：让 AI 编程助手帮忙重构一个复杂应用，起初它给出准确的回答，但 20 条消息之后，它突然忘记了你之前设定的架构规则。这背后的原因，就藏在上下文窗口的工作机制中。

背景：上下文窗口的重要性

什么是上下文窗口

上下文窗口是 LLM 能够"看到"和"记住"的最大 token 数量。它包括：

• 系统提示词（System Prompt）：定义 AI 角色和行为的指令
• 对话历史（Conversation History）：之前的用户消息和 AI 回复
• 当前输入（Current Input）：用户最新的消息
• 生成的输出（Generated Output）：AI 正在生成的回复

所有这些内容加起来的 token 数量，不能超过模型的上下文窗口限制。

为什么上下文窗口重要

上下文窗口直接决定了 AI 的能力：

• 记忆能力：更大的上下文窗口意味着 AI 能记住更多的对话历史
• 文档理解：更大的窗口可以处理更长的文档（整本书、大型代码库）
• 复杂推理：更多的上下文支持更复杂的多步推理
• 少样本学习：更多的示例可以帮助 AI 更好地理解任务

近年来，上下文窗口的大小快速增长：从 GPT-3 的 2K，到 GPT-4 的 8K/32K，再到 Claude 的 100K/200K，甚至有些模型宣称支持 1M+ 的上下文窗口。

但正如文章指出的，更大的上下文窗口并不等于更好的记忆能力。

上下文窗口的工作原理

1. Token 化（Tokenization）

在理解上下文窗口之前，需要先理解 token：

• 什么是 token：token 是 LLM 处理文本的基本单位，可以是一个词、一个词的一部分、一个标点符号
• Token 化过程：输入文本被分词器（Tokenizer）分割成 token 序列
• Token 数量：1 个英文单词大约是 1.3 个 token，1 个中文字符大约是 1-2 个 token
• 上下文窗口限制：上下文窗口的大小是以 token 数量计算的，不是字符数或词数

示例：
输入文本："Hello, how are you?"
Token 化后：["Hello", ",", " how", " are", " you", "?"]
Token 数量：6

2. 注意力机制（Attention）

LLM 的核心是注意力机制，它决定了模型在生成每个 token 时，应该关注上下文中的哪些部分：

• 自注意力（Self-Attention）：模型计算上下文中每个 token 与其他所有 token 的关联度
• 注意力权重：每个 token 都有一组注意力权重，表示它对其他 token 的"关注程度"
• 上下文窗口的作用：注意力机制只能在上下文窗口内的 token 之间计算关联度
• 计算复杂度：注意力的计算复杂度是 O(n²)，其中 n 是 token 数量。这就是为什么更大的上下文窗口需要更多的计算资源

3. 位置编码（Positional Encoding）

由于注意力机制本身不区分 token 的顺序，LLM 需要位置编码来告诉模型每个 token 在序列中的位置：

• 绝对位置编码：为每个位置分配一个唯一的编码
• 相对位置编码：编码 token 之间的相对位置关系
• 旋转位置编码（RoPE）：现代模型常用的位置编码方式，通过旋转矩阵编码位置
• 外推问题：当输入序列超过训练时的最大长度时，位置编码的效果会下降，导致模型性能降低

4. KV 缓存（KV Cache）

为了加速推理，LLM 使用 KV 缓存来存储之前计算的键（Key）和值（Value）：

• 什么是 KV 缓存：在生成每个新 token 时，不需要重新计算之前所有 token 的 K 和 V，而是缓存起来复用
• 内存占用：KV 缓存的内存占用与上下文长度成正比，长上下文需要大量显存
• 缓存限制：KV 缓存的大小限制了实际可用的上下文长度
• 缓存管理：当上下文超过限制时，需要策略来管理缓存（如滑动窗口、摘要压缩）

为什么上下文窗口会"失效"

虽然模型宣称支持很大的上下文窗口，但在实际使用中，AI 经常会"忘记"之前的信息。文章分析了以下几个原因：

1. 中间迷失（Lost in the Middle）

这是最著名的上下文窗口问题：

• 现象：模型对上下文开头和结尾的信息记忆很好，但对中间的信息记忆较差
• 研究发现：多项研究表明，当相关信息位于上下文中间时，模型的性能显著下降
• 原因：注意力机制在处理长序列时，中间位置的注意力权重被稀释
• 影响：在长对话中，早期的重要信息（如架构规则、用户偏好）可能被"遗忘"

上下文位置与记忆效果的关系：

高 ┤  ★                                          ★
   │  ★★                                        ★★
   │  ★★★         记忆效果较差的中间区域        ★★★
   │  ★★★★                                    ★★★★
低 └──┬──────────────────────────────────────────┬──→
     开头                                        结尾
     位置

2. 注意力稀释（Attention Dilution）

随着上下文长度增加，注意力被稀释：

• 注意力预算有限：模型在生成每个 token 时，总的"注意力"是有限的
• 更多的 token = 更少的关注：上下文越长，每个 token 获得的平均注意力越少
• 重要信息被淹没：重要的信息可能被大量不重要的信息淹没
• 信噪比下降：随着上下文增长，信号（重要信息）与噪声（无关信息）的比例下降

3. 位置编码外推（Positional Encoding Extrapolation）

当实际使用的上下文长度超过训练时的长度时：

• 训练分布外：模型在训练时没有见过这么长的序列，位置编码超出了训练分布
• 性能下降：外推会导致模型性能显著下降，特别是在需要精确位置信息的任务上
• 宣称 vs 实际：很多模型宣称的上下文窗口大小是通过外推实现的，实际性能在超过一定长度后会急剧下降
• 有效上下文：模型的"有效上下文"（实际能有效利用的长度）通常小于宣称的上下文窗口

4. KV 缓存管理策略

当上下文超过 KV 缓存限制时，需要使用管理策略：

• 滑动窗口（Sliding Window）：只保留最近的 N 个 token，更早的信息被丢弃
• 摘要压缩（Summarization）：将早期的对话压缩成摘要，节省空间
• 分层缓存（Hierarchical Caching）：不同层级使用不同的缓存策略
• 信息丢失：无论使用哪种策略，都会丢失一些原始信息，导致"遗忘"

5. 训练数据的影响

模型的训练数据也影响上下文窗口的效果：

• 训练序列长度：模型在训练时使用的序列长度决定了它对长上下文的适应能力
• 长文档训练：如果训练数据中长文档较少，模型对长上下文的处理能力就较差
• 任务类型：训练时的任务类型影响模型对上下文的利用方式
• 预训练 vs 微调：预训练和微调阶段的上下文长度可能不同，影响最终效果

6. 提示词工程的影响

用户的提示词方式也会影响记忆效果：

• 信息放置位置：重要信息放在开头或结尾效果更好，放在中间容易被遗忘
• 重复强调：重要信息多次重复可以增强记忆
• 结构化提示：使用清晰的结构（如标题、列表）帮助模型组织信息
• 上下文污染：无关的信息会干扰模型，降低对重要信息的记忆

实际场景中的表现

1. 长对话中的遗忘

这是最常见的场景：

• 早期设定被遗忘：对话开始时设定的角色、规则、偏好，在长对话后被遗忘
• 上下文切换：话题切换后，之前的上下文可能干扰当前的回答
• 累积错误：早期的小错误在长对话中被放大和累积
• 身份漂移：AI 的行为逐渐偏离最初设定的角色

2. 长文档处理

处理长文档时的问题：

• 中间内容遗漏：文档中间的重要信息可能被遗漏
• 跨页推理困难：需要跨越多段内容进行推理时，性能下降
• 细节丢失：长文档中的细节信息容易丢失
• 摘要偏好：模型倾向于生成摘要，而不是精确引用原文

3. 代码库分析

分析大型代码库时的问题：

• 文件间关系遗忘：多个文件之间的依赖关系和调用关系容易被遗忘
• 架构规则丢失：项目的架构规则和编码规范在长上下文中丢失
• 跨文件修改困难：需要同时修改多个文件时，容易遗漏某些文件
• 上下文溢出：大型代码库的内容很容易超过上下文窗口限制

如何改善上下文窗口的效果

1. 提示词优化

• 重要信息前置：将最重要的信息放在上下文开头
• 结尾重申：在提示词结尾重申关键要求
• 结构化组织：使用清晰的标题、列表、分隔符组织信息
• 减少噪声：移除无关的信息，提高信噪比
• 显式引用：要求 AI 在回答时显式引用之前的信息

优化前：
"请帮我重构这个应用。之前我们讨论过要使用微服务架构，
每个服务有独立的数据库，API 网关统一入口，服务间用 gRPC 通信。
另外要注意错误处理和日志规范..."

优化后：
"【核心架构规则 - 必须遵守】
1. 微服务架构，每个服务独立数据库
2. API 网关统一入口
3. 服务间通信使用 gRPC
4. 统一错误处理格式
5. 结构化日志，包含 trace_id

【当前任务】
请重构以下代码，遵守上述架构规则：
[代码内容]

【再次提醒】请确保重构后的代码符合上述 5 条架构规则。"

2. 上下文管理策略

• 定期摘要：定期将对话历史压缩成摘要，释放上下文空间
• 滑动窗口：只保留最近的 N 轮对话，更早的内容摘要化
• 分层记忆：将信息分为短期记忆（最近对话）和长期记忆（摘要、关键信息）
• 主动检索：使用 RAG（检索增强生成）在需要时检索相关信息，而不是将所有信息都放在上下文中

3. RAG（检索增强生成）

RAG 是解决长上下文问题的有效方法：

• 外部存储：将大量信息存储在外部数据库（向量数据库）中
• 按需检索：在需要时检索相关信息，而不是全部放入上下文
• 相关性排序：检索结果按相关性排序，只将最相关的信息放入上下文
• 更新方便：外部存储的信息可以独立更新，不需要重新训练模型

RAG 工作流程：

用户问题 → 检索相关文档 → 将相关文档加入上下文 → LLM 生成回答
     ↑                                                        │
     └──────────── 向量数据库存储所有文档 ←──────────────────┘

4. 微调（Fine-tuning）

对于特定场景，可以通过微调改善上下文利用：

• 长上下文微调：在长序列数据上微调模型，提高对长上下文的适应能力
• 任务特定微调：在特定任务上微调，让模型学会更好地利用上下文
• 位置编码微调：调整位置编码，改善外推性能
• 注意：微调成本高：微调需要大量数据和计算资源，不是所有场景都适用

5. 选择合适的模型

不同模型的上下文窗口效果差异很大：

• 关注有效上下文：不要只看宣称的上下文窗口大小，更要关注"有效上下文"（实际能有效利用的长度）
• 参考基准测试：参考长上下文基准测试（如 LongBench、RULER）的结果
• 测试实际场景：在自己的实际场景中测试模型的长上下文表现
• 考虑成本：更大的上下文窗口通常意味着更高的推理成本

未来发展方向

上下文窗口技术正在快速发展，未来的方向包括：

1. 无限上下文

• 目标：实现理论上无限的上下文长度
• 技术路径：改进注意力机制（如线性注意力、状态空间模型）、优化 KV 缓存、分层记忆
• 挑战：计算效率、记忆准确性、位置编码

2. 更智能的记忆管理

• 主动记忆：模型主动决定什么信息需要记住、什么可以遗忘
• 记忆巩固：类似人类的记忆巩固过程，将重要信息转化为长期记忆
• 元记忆：模型知道自己记住了什么、忘记了什么，可以主动查询

3. 外部记忆集成

• 持久记忆：将模型的记忆持久化到外部存储，跨会话保持
• 个性化记忆：为每个用户维护独立的记忆，实现个性化交互
• 记忆编辑：支持编辑和删除模型的记忆，保护隐私

4. 混合架构

• 短时 + 长时记忆：类似人类的记忆系统，短时记忆处理当前任务，长时记忆存储知识
• 符号 + 神经：结合符号推理和神经网络，互补优势
• 检索 + 生成：RAG 成为标配，检索和生成深度融合

总结

LLM 的上下文窗口是一个复杂而精妙的系统，它的工作原理涉及 token 化、注意力机制、位置编码、KV 缓存等多个方面。虽然模型宣称的上下文窗口越来越大，但在实际使用中，"遗忘"是一个常见的问题。

核心要点：

1. 工作原理：上下文窗口通过 token 化、注意力机制、位置编码、KV 缓存协同工作
2. 失效原因：中间迷失、注意力稀释、位置编码外推、KV 缓存管理、训练数据影响、提示词工程影响
3. 实际表现：长对话中的遗忘、长文档处理困难、代码库分析挑战
4. 改善方法：提示词优化、上下文管理策略、RAG、微调、选择合适的模型
5. 未来方向：无限上下文、智能记忆管理、外部记忆集成、混合架构

对于使用 LLM 的开发者来说，理解上下文窗口的工作原理和局限性，可以帮助我们更好地设计提示词、构建应用、选择模型。不要盲目相信模型宣称的上下文窗口大小，而要在实际场景中测试其有效上下文长度，并采用合适的策略（如 RAG、摘要、分层记忆）来弥补局限性。

正如文章所暗示的，AI 的"记忆"不是一个简单的容量问题，而是一个涉及注意力、位置、编码、检索等多个方面的复杂系统。理解这个系统，才能真正发挥 LLM 的潜力。

原文链接：https://dev.to/iar01/demystifying-llm-context-windows-how-ai-memory-works-and-why-it-fails-khd