上下文窗口详解
什么是上下文窗口
上下文窗口是指模型在单次请求中能处理的最大 token 数量，包括输入（Prompt）和输出（Response）。
┌─────────────────────────────────────────────────────────────────┐
│ 上下文窗口示意图 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────┐ ┌───────────────────┐ │
│ │ 输入 Prompt │ │ 输出 Response │ │
│ └────────┬────────┘ └─────────┬─────────┘ │
│ │ │ │
│ └───────────────┬─────────────────┘ │
│ │ │
│ ┌──────┴──────┐ │
│ │ 上下文窗口 │ │
│ │ (最大 Token) │ │
│ └──────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘主流模型上下文窗口
GPT 系列
| 模型 | 上下文窗口 | 说明 |
|---|---|---|
| GPT-4o | 128K | 128,000 tokens |
| GPT-4o-mini | 128K | 128,000 tokens |
| GPT-4 Turbo | 128K | 128,000 tokens |
| GPT-3.5 Turbo | 16K | 16,384 tokens |
Claude 系列
| 模型 | 上下文窗口 | 说明 |
|---|---|---|
| Claude 3.5 Sonnet | 200K | 200,000 tokens |
| Claude 3 Opus | 200K | 200,000 tokens |
| Claude 3 Haiku | 200K | 200,000 tokens |
Gemini 系列
| 模型 | 上下文窗口 | 说明 |
|---|---|---|
| Gemini 3 Pro | 1M | 1,000,000 tokens |
| Gemini 3 Flash | 1M | 1,000,000 tokens |
国产模型
| 模型 | 提供商 | 上下文窗口 |
|---|---|---|
| DeepSeek V4 | DeepSeek | 64K |
| GLM-5 | 智谱 | 128K |
| Kimi K2.5 | 月之暗面 | 200K |
| Qwen3.5 | 阿里 | 128K |
上下文对模型的影响
1. 输入长度影响可用输出空间
上下文窗口: 4096 tokens
情况 A: 简单任务
├── 输入: 100 tokens
└── 可用输出: 3996 tokens ✅ 充足
情况 B: 中等任务
├── 输入: 3500 tokens
└── 可用输出: 596 tokens ⚠️ 有限
情况 C: 长文本任务
├── 输入: 4000 tokens
└── 可用输出: 96 tokens ❌ 几乎无法输出2. 注意力衰减现象
随着序列增长，模型对早期内容的注意力会逐渐减弱：
输入: [用户问题] [背景1] [背景2] ... [最新内容]
↑
强注意力 弱注意力可能问题：
- 忽略开头的关键指令
- 遗忘中间部分的背景信息
- 错误引用内容来源
3. 长上下文的理论挑战
| 挑战 | 说明 |
|---|---|
| 计算复杂度 | 自注意力计算量与序列长度的平方成正比 |
| 内存占用 | KV Cache 随序列长度线性增长 |
| 通信开销 | 分布式推理时跨节点传输数据量增大 |
应用场景建议
短上下文场景（≤ 32K）
| 场景 | 推荐理由 |
|---|---|
| 客服对话 | 单轮交互，响应简洁 |
| 简单问答 | 任务单一，无需长背景 |
| 文本补全 | 短文本生成任务 |
| 代码生成 | 函数级代码，片段输出 |
中等上下文场景（64K - 128K）
| 场景 | 推荐理由 |
|---|---|
| 文档分析 | 可分析 10-20 页 PDF |
| 多轮对话 | 保留多轮对话历史 |
| 代码调试 | 包含完整文件上下文 |
| 内容创作 | 中长篇文章写作 |
长上下文场景（> 128K）
| 场景 | 推荐理由 |
|---|---|
| 长篇小说 | 可处理整章内容 |
| 代码库理解 | 整个文件的理解分析 |
| 书籍摘要 | 整本书的总结提炼 |
| 知识库问答 | 大量文档检索增强 |
参数配置建议
max_tokens 参数
控制模型最大输出 token 数：
python
response = client.chat.completions.create(
model="gpt-4o",
messages=[
{"role": "user", "content": "详细解释量子计算"}
],
max_tokens=2000
)场景化配置
| 场景 | 建议 max_tokens | 说明 |
|---|---|---|
| 简短问答 | 300-500 | 简洁回答 |
| 标准问答 | 1000-2000 | 完整回答 |
| 详细解释 | 3000-4000 | 深入分析 |
| 长文写作 | 5000-8000 | 文章输出 |
设置建议
建议公式：
max_tokens = 上下文窗口 × 0.4 ~ 0.5
示例（128K 窗口）：
max_tokens ≈ 50000 ~ 64000
注意：需预留空间给输入，建议不超过窗口的 50%超限处理策略
1. 分段处理 (Chunking)
适用于长文档分析、书籍摘要：
python
def process_long_document(text, chunk_size=4000, overlap=200):
chunks = []
tokens = text.split()
for i in range(0, len(tokens), chunk_size - overlap):
chunk = ' '.join(tokens[i:i + chunk_size])
chunks.append(chunk)
return chunks2. 摘要压缩
适用于多轮对话历史过长：
python
def summarize_conversation(messages, max_tokens=4000):
summary_prompt = f"""将以下对话总结为要点，控制在 {max_tokens} tokens 内：
{messages}
摘要："""
summary = call_llm(summary_prompt)
return [
{"role": "system", "content": "之前对话摘要：" + summary},
messages[-1]
]3. 检索增强 (RAG)
适用于需要处理海量知识的场景：
用户问题 ──→ 检索 ──→ 相关文档 ──→ 构建 Prompt ──→ LLM 推理
↑
只取最相关的片段最佳实践
1. 重要信息放置
- 关键指令放在开头或结尾
- 使用结构化格式突出关键点
2. 根据任务选模型
| 任务类型 | 推荐模型 | 理由 |
|---|---|---|
| 短对话 | GPT-4o-mini | 快速低成本 |
| 文档分析 | Claude 3.5 | 长上下文支持 |
| 超长任务 | Gemini 3 Pro | 百万级上下文 |
3. 监控与优化
python
def estimate_tokens(text):
return len(text.split()) * 1.3
def check_context_usage(prompt, max_tokens, context_window):
estimated = estimate_tokens(prompt)
available = context_window - max_tokens
usage_ratio = estimated / available
if usage_ratio > 0.9:
return "warning"
return "ok"常见问题
Q: 为什么输出被截断？
可能原因：
max_tokens设置过小- 上下文窗口已满
Q: 如何避免"遗忘"问题？
- 将重要信息放在输入开头或结尾
- 使用结构化格式突出关键点
- 超长任务使用分段处理
Q: 上下文窗口越大越好？
不一定。更大上下文带来更高延迟和成本，过长上下文可能导致中间部分注意力减弱。建议根据实际任务选择合适的模型。