上下文窗口
上下文窗口 = 模型一次能看到的 token 上限。面试主线：为什么有限、怎么变长、长上下文和 RAG 怎么选。
上下文是什么
- 上下文 = 输入给模型的所有 token（系统提示 + 历史 + 检索内容 + 用户输入）
- 窗口从 2K（GPT-3）到 200K+（GPT-4 Turbo、Claude 等），国产模型也到 128K-1M
- 输入全都要过注意力：窗口越大，单请求计算和 KV cache 显存越大（见注意力优化篇）
为什么上下文有限
| 限制 | 原因 |
|---|---|
| 计算 | 注意力 O(n²)（优化后仍是 O(n²) 量级） |
| 显存 | KV cache 随长度线性增长（主要瓶颈） |
| 训练 | 训练数据长度有限，模型没见过超长序列 |
| 质量 | 超长输入下“大海捞针”能力下降（中间信息丢失） |
面试点：上下文窗口是工程约束，不是纯能力指标。标称 200K 不代表 200K 用得好。
长上下文技术
| 技术 | 机制 |
|---|---|
| 位置编码外推 | RoPE 的 θ 缩放（NTK-aware），训练短窗口推理长窗口 |
| 滑动窗口注意力 | 只注意局部（Mistral），质量取舍 |
| 稀疏/分层注意力 | 全局 token + 局部窗口（Longformer） |
| 训练加长 | 用长序列数据继续训练（成本高） |
| 压缩/摘要 | 把历史压缩成摘要再进上下文（工程方案） |
长上下文 vs RAG
| 维度 | 长上下文 | RAG |
|---|---|---|
| 输入方式 | 全量塞进去 | 检索后只塞相关片段 |
| 成本 | 随长度线性涨 | 固定（片段大小） |
| 准确性 | 长输入信息密度低 | 精准片段 |
| 适用 | 单文档深读、代码库 | 大知识库、实时数据 |
面试话术：长上下文适合“少量但全”（一本书、一个仓库），RAG 适合“海量但精”（知识库）。生产常用组合：RAG 检索 + 长上下文精读。
工程实践
- 控制输入长度：只放必要的（见 context-engineering 篇）
- 监控 token 消耗：超长对话要摘要/裁剪（见 LangChain 记忆篇）
- 按场景选模型：短任务用短窗口模型省钱，长文档用长窗口模型
面试追问
- 上下文窗口为什么有限？ KV cache 显存 + 计算成本随长度涨。训练数据长度也限制
- 长上下文和 RAG 怎么选？ 少量全量用长上下文，海量精准用 RAG。可组合
- 标称 200K 能用满吗？ 不能：长输入质量下降（大海捞针），成本也高。要留余量
- 怎么让模型处理超长内容？ 摘要、分层检索、滑动窗口。工程手段优先
- 长上下文贵在哪？ KV cache 显存线性增长 + 计算增长。token 计费也线性涨