上下文窗口详解：大模型的'记忆力'

上下文窗口决定了大模型一次能”记住”多少信息，是选择模型时的关键指标。

一、什么是上下文窗口？

1.1 定义

上下文窗口（Context Window）= 模型一次能处理的最大 Token 数量

包括：

• 系统提示词（System Prompt）
• 用户输入（Input）
• 对话历史（History）
• 模型输出（Output）

1.2 通俗理解

用一个比喻：

• 上下文窗口 = 人的”工作记忆”
• 窗口越大，能同时处理的信息越多

小上下文窗口（4K Tokens）：
就像只能记住最近说的 5 句话
对话长了就忘记前面说的什么

大上下文窗口（200K Tokens）：
就像能记住整本书的内容
可以基于全文进行分析和回答

1.3 上下文窗口的组成

┌─────────────────────────────────────────────────────────────────┐
│                    上下文窗口组成                                │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  ┌─────────────────┐                                           │
│  │  System Prompt  │ 系统指令（如"你是一位助手"）                │
│  │     ~100 Tokens │                                           │
│  └─────────────────┘                                           │
│  ┌─────────────────┐                                           │
│  │  对话历史        │ 之前的多轮对话                              │
│  │     ~2000 Tokens│                                           │
│  └─────────────────┘                                           │
│  ┌─────────────────┐                                           │
│  │  当前输入        │ 用户当前的问题                              │
│  │     ~500 Tokens │                                           │
│  └─────────────────┘                                           │
│  ┌─────────────────┐                                           │
│  │  模型输出        │ 生成的回答                                  │
│  │     ~1000 Tokens│                                           │
│  └─────────────────┘                                           │
│                                                                 │
│  总计：~3600 Tokens（在 4K 窗口内）                              │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

二、主流模型的上下文窗口

2.1 上下文窗口演进史

2.2 当前主流模型对比（2026 年 3 月）

2.3 上下文窗口与实际页数

换算关系（估算）：
1 页 A4 纸 ≈ 500 汉字 ≈ 600-800 Tokens

窗口大小与实际页数：
┌──────────────┬──────────────┬─────────────────┐
│   Tokens     │    汉字      │     A4 页数      │
├──────────────┼──────────────┼─────────────────┤
│    4K        │   ~3000 字   │     6 页        │
│    8K        │   ~6000 字   │     12 页       │
│   32K        │   ~24000 字  │     48 页       │
│  128K        │   ~96000 字  │     192 页      │
│  200K        │   ~150000 字 │     300 页      │
│    1M        │   ~750000 字 │     1500 页     │
└──────────────┴──────────────┴─────────────────┘

实际例子：
• 一篇本科毕业论文 ≈ 30-50 页 ≈ 25K Tokens
• 一本小说（10 万字）≈ 200 页 ≈ 128K Tokens
• 一份技术文档合集 ≈ 500 页 ≈ 200K Tokens

三、上下文窗口的技术实现

3.1 Attention 机制与上下文

核心挑战：

传统 Attention 的计算复杂度是 O(n²)
n = Token 数量

上下文窗口扩大 10 倍 → 计算量增加 100 倍！

解决方案：

3.2 位置编码

问题： Transformer 本身不知道 Token 的顺序

解决方案：

3.3 KV Cache

原理：

自回归生成时，前面的 Token 的 Key/Value 可以缓存
避免重复计算

好处：
• 推理速度提升 5-10 倍
• 显存占用增加（需要存储缓存）

挑战：
• 长上下文时缓存很大
• 需要显存优化技术

四、上下文窗口的实际应用

4.1 适合长上下文的场景

4.2 场景对比：小窗口 vs 大窗口

场景：分析一份 100 页的产品需求文档

❌ 小窗口（4K Tokens，约 6 页）：
• 只能一次读 6 页
• 需要分 17 次读完
• 每次只能理解局部
• 无法把握整体结构
• 可能遗漏跨章节的关联

✅ 大窗口（128K Tokens，约 200 页）：
• 一次读完 100 页
• 理解整体结构
• 发现跨章节关联
• 回答基于全文
• 效率更高，效果更好

4.3 实际案例：法律合同审查

任务：审查一份 50 页的采购合同

使用 Claude 3.5（200K 窗口）：

Prompt：
"请审查这份采购合同，找出：
1. 对买方不利的条款
2. 缺失的关键条款
3. 潜在的法律风险
4. 修改建议

[附上完整 50 页合同]"

优势：
• 一次处理完整合同
• 能发现前后矛盾的条款
• 能检查引用关系
• 输出连贯的审查报告

五、上下文窗口不足怎么办？

5.1 方案对比

5.2 方案 1：滑动窗口截断

保留最近 N 轮对话，丢弃最早的

实现：
messages = messages[-10:]  # 只保留最近 10 轮

优点：简单
缺点：丢失早期重要信息
适用： casual 聊天

5.3 方案 2：对话摘要

定期将历史对话压缩成摘要

实现：
当上下文超过阈值时：
1. 调用模型总结历史对话
2. 用摘要替换原始对话
3. 继续新对话

示例：
原始（10 轮对话，2000 Tokens）：
用户：问题 1 → AI：回答 1
用户：问题 2 → AI：回答 2
...

压缩后（300 Tokens）：
系统：之前讨论了问题 1-5，
      核心结论是 A、B、C
用户：问题 6
AI：回答 6

5.4 方案 3：RAG 检索

适用于有外部知识库的场景

流程：
1. 用户提问
2. 从知识库检索相关片段
3. 只将相关片段放入上下文
4. 模型生成回答

优点：
• 可处理无限知识
• 只提供相关信息
• 减少 Token 消耗

缺点：
• 需要向量数据库
• 检索可能不准确

5.5 方案 4：Map-Reduce

适用于超长文本处理

流程：
1. Map：将文本分块，每块单独处理
2. Reduce：合并各块的结果

示例（长文档总结）：
Map 阶段：
• 总结第 1-10 页 → 摘要 1
• 总结第 11-20 页 → 摘要 2
• ...

Reduce 阶段：
• 合并所有摘要 → 最终总结

优点：可处理任意长度
缺点：多次调用，成本高

六、长上下文的挑战与优化

6.1 “中间丢失”问题

现象：

模型对开头和结尾的信息记忆较好
对中间部分的信息容易遗漏

实验：
在长文本中隐藏一个关键信息
• 放在开头 → 模型能记住
• 放在中间 → 模型经常遗漏
• 放在结尾 → 模型能记住

解决方案：

• 重要信息放在开头或结尾
• 用 RAG 精准检索
• 多次提问不同角度

6.2 推理速度下降

上下文长度与推理时间的关系：

4K Tokens  → 基准速度
32K Tokens → 2-3 倍慢
128K Tokens → 5-8 倍慢
200K Tokens → 10 倍慢

原因：
• Attention 计算量增加
• KV Cache 变大
• 显存带宽瓶颈

优化方案：

• 使用 Flash Attention
• 量化模型
• 批处理请求

6.3 成本考虑

长上下文的成本影响：

GPT-4o 价格：$5/1M Tokens (输入)

场景：每天分析 10 份 50 页文档
• 每份文档 ≈ 40K Tokens
• 每天输入：400K Tokens
• 每月输入：12M Tokens
• 月成本：$60

如果用 200K 窗口一次处理 vs 
用 4K 窗口分 50 次处理：
• 一次处理：40K Tokens × 10 × 30 = 12M Tokens
• 分次处理：额外需要重复系统提示等
• 实际长窗口更省钱

七、选型建议

7.1 根据场景选择窗口大小

7.2 性价比考虑

性价比计算公式：
性价比 = 效果 / 成本

高性价比选择：
• Qwen2.5-72B：128K 窗口，价格低
• DeepSeek-V2.5：128K 窗口，免费额度

高性能选择：
• Claude 3.5：200K 窗口，理解准确
• GPT-4o：128K 窗口，综合能力强

🎯 面试回答版本

面试官问：“什么是上下文窗口？如何处理长文本？“

标准回答（2 分钟）

上下文窗口是模型一次能处理的最大 Token 数量，
可以理解为模型的"工作记忆"。

【主流模型】
GPT-4o 是 128K，Claude 3.5 是 200K，
相当于能一次处理 300-500 页的文档。

【技术挑战】
主要是 Attention 的 O(n²) 复杂度，
通过 Sparse Attention、RoPE 位置编码、
KV Cache 等技术优化。

【长文本处理】
如果文本超过窗口限制，我有几种方案：
1. 截断：只保留最近的内容
2. 摘要：压缩历史对话
3. RAG：检索相关片段
4. Map-Reduce：分块处理再合并

【实际应用】
我在项目中用 RAG 处理了 XX 文档，
将检索精度从 X% 提升到 Y%。

高频追问

相关阅读：

• LLM 大语言模型详解
• Token 机制详解
• RAG 技术详解