上下文窗口（Context Window）是 LLM 在一次推理中能”同时看到”的最大 token 数，包括系统提示、对话历史、用户输入和模型输出；2024 年主流窗口还在 128K 区间，到 2025 下半年 Gemini 2.5、Claude Sonnet 4 已分别把标准窗口拉到 1M token，GPT-5 也开放了 400K 输入+128K 输出。窗口大小直接决定 RAG、Agent、多轮对话、代码库分析等场景要不要切片、要不要重排、要不要换模型，是应用开发选型时绕不开的硬约束。下文从机制、规模、应用影响三方面系统拆解。
一、上下文窗口到底在算什么
LLM 推理时，每生成一个 token 都要与前序所有 token 做注意力计算；窗口越大，K-V 缓存越大、计算量呈平方级膨胀，但模型能”看到”的上下文也越长。这里面要分清三个常被混用的概念：
- 总窗口（Input + Output）：单次请求允许的总 token 上限；
- 输入窗口：系统提示、检索片段、对话历史能塞多少；
- 输出窗口：模型单次回复最多能生成多少 token。
GPT-5 给的是”400K 输入+128K 输出”组合，意味着它能吃下整本技术书但单次回答可以写一篇博士论文；Gemini 2.5 Pro 是 1M 输入+64K 输出，重在”塞得多”。
二、主流模型窗口规模对比（2025 年下半年）
| 模型 | 输入窗口 | 输出窗口 | 备注 |
|---|---|---|---|
| GPT-4o | 128K | 16K | OpenAI 主力通用模型 |
| GPT-5 / GPT-5.1 | 400K | 128K | 输入输出同步扩张 |
| Claude Sonnet 4（2025-08 升级） | 1M（默认 200K 可开 1M） | 64K | 长文档/代码库分析 |
| Claude Opus 4.5 | 200K（API 可开 1M beta） | 32K | Anthropic 旗舰 |
| Gemini 2.5 Pro | 1M（部分配置 2M） | 64K | 多模态原生支持 |
| Gemini 2.5 Flash | 1M | 64K | 性价比档 |
| Llama 4 Scout（开源） | 10M | — | 实验室级长上下文 |
| Qwen 2.5 | 128K | 8K | 中文开源主力 |
| DeepSeek V3 | 128K | 8K | 极致低成本 |
数字本身只是入场券。实际能不能用足，还要看”中段丢失”和”上下文腐烂”两个问题。
三、两个绕不开的真实问题
广告值和实际可用值之间存在系统性差距。LLM 在长上下文场景下有两类典型问题：
- Lost-in-the-Middle（中段丢失）：模型对开头和结尾的内容回忆最好，处于中间 40% 位置的内容被显著忽略。把关键指令或问题答案埋在长文档中间，是 RAG 链路里最常见的失误。
- Context Rot（上下文腐烂）：可靠性随输入长度下降并不线性，200K 窗口的模型往往在 130K 之后开始断崖式衰减。经验值是按广告窗口的 60%~70% 来规划业务，才留出安全余量。
换句话说，1M 窗口的模型，在 700K 之前可视为健康区；超过之后要么重排顺序、要么改用 RAG 切片，不能盲信”塞得下 = 用得好”。
四、对应用开发的三类核心影响
窗口大小直接影响架构选型。三类典型场景的影响如下：
| 场景 | 小窗口（≤128K）策略 | 大窗口（≥1M）策略 |
|---|---|---|
| RAG 检索 | 强依赖；切片 500~800 token，叠加 rerank | 可弱化；整文档直接喂，仅做精排 |
| Agent 工具调用 | 工具结果必须截断或摘要 | 历史工具结果可长留，简化工程 |
| 多轮对话 | 滚动窗口 + 摘要压缩 + 关键事实抽取 | 多轮历史可保留更多轮次 |
| 代码库分析 | 按文件/模块切块分析 | 整仓库一次提交，跨文件引用更稳 |
| 长文档问答 | 必须先做文档切分与位置标记 | 整本 PDF 直接提问，但要留意中段丢失 |
选型上的反直觉点：很多团队 2024 年还在疯狂做切片，2025 年随着窗口扩张反而要做”减法”——把无关内容主动剔出上下文，让模型少看比多看更准。
五、长上下文应用的五个落地步骤
要把大窗口真正用好，工程上分五步：
- 测量真实有效窗口：用 100~200 条业务样本，在 10%、50%、90% 位置埋关键事实，统计不同窗口长度下的检索准确率，画出”实际可用 vs 广告值”曲线；
- 重排关键内容：把高优先级指令、用户问题、关键事实放到消息开头或结尾，避开中段；
- 选择性注入：长上下文中只保留与本轮强相关的检索片段，无关内容用元数据替代或直接丢弃；
- 预算与告警：在客户端用 tiktoken 类工具预先算 token 数，超过业务设定阈值就触发截断或切片；
- 评估与回退：上线后做 A/B，把”启用大窗口”和”切片+小窗口”两条链路并行跑一段，根据成本与质量决定主备。
下面给出一段在 Python 中用 tiktoken 预算 token、并触发告警的最小化示例：
import tiktoken
def estimate_tokens(messages, model="gpt-5"):
"""预算一段对话的 token 数，超阈值即告警"""
try:
enc = tiktoken.encoding_for_model(model)
except KeyError:
enc = tiktoken.get_encoding("cl100k_base")
total = 0
for msg in messages:
# 经验值：每条消息大约 4 个角色/格式 token
total += 4
total += len(enc.encode(msg.get("content", "")))
total += 2 # 对话整体收尾 token
# 业务阈值取广告窗口的 70%
SAFE_RATIO = 0.7
if model.startswith("gpt-5"):
max_input = 400_000
elif model.startswith("claude"):
max_input = 200_000
elif model.startswith("gemini"):
max_input = 1_000_000
else:
max_input = 128_000
budget = int(max_input * SAFE_RATIO)
if total > budget:
raise ValueError(
f"上下文 {total} token 超出安全预算 {budget}，"
f"请先做切片或重排"
)
return total效果上，把这段校验嵌进请求入口，可以在前置阶段就拦下”塞得下但用不好”的请求；再结合中段重排策略，长文档问答的准确率通常能从 60% 拉到 80% 以上。
六、选型与坑
选大窗口模型时不只看峰值，还要看三件事：单位输入价（百万 token 单价）、TTFT 延迟、上下文腐烂曲线。1M 窗口对应的 K-V 缓存在 GPU 显存里以 GB 计，单请求 TTFT 通常比 128K 慢 2~5 倍；做实时对话时要按延迟预算倒推该选哪家。
最常踩的三个坑：把窗口当”记忆”用、忽视工具结果在长上下文里也会消耗配额、把 RAG 简单替换为”塞整文档”。三者都会让成本与延迟一起失控。
到这里，上下文窗口从机制、规模到应用影响就清楚了：它是 LLM 的”短期记忆容量”，决定架构上要不要切片、要不要重排、要不要换模型；窗口变大的同时，应用的复杂性也在变大。
常见问题（FAQ）
Q1：1M 窗口的模型能直接吃整本书吗？
能塞下，但建议把章节顺序、关键问题放在消息开头或结尾，中段内容仍可能被忽略。
Q2：上下文窗口越大越贵吗？
是的。费用按 input token 计费，1M 窗口的单次请求上限远高于 128K，单位价虽接近，总额会随用量放大。
Q3：是不是用了大窗口就不需要 RAG 了？
不是。大窗口不能解决”中段丢失”和成本问题，关键业务仍建议 RAG 切片+大窗口组合使用。
