长上下文处理#
一句话答案#
上下文窗口是模型一次能”看见”的 token 上限（输入+输出共享），但标称长度 ≠ 有效长度——Lost in the Middle、NIAH/RULER 等评测表明模型对中段信息利用率明显下降；长上下文的代价是注意力 O(n²) 计算、KV Cache 线性增长和成本/TTFT 上升，所以应用侧要在”直接塞全文”与”检索后再塞”之间按成本、准确性、时效性选型，并用裁剪、分块、Prompt Caching、首尾放置等手段榨干窗口价值。
核心要点
1. 上下文窗口是什么#
- 定义：一次请求中模型能处理的最大 token 数，输入（system + 历史 + 文档 + 问题）和输出共享这个预算，输入塞满了就没有空间生成。
- 量级演进：2K/4K（早期）→ 8K/32K → 128K/200K → 1M 级（2026 年头部模型的常见配置：Claude Opus 5 默认 1M、GPT-6 系列约 1.05M、Gemini 3.8 Flash 1M、DeepSeek-V4 1M；开源模型常见原生 128K–256K、用 YaRN 外推到 1M；Llama 4 Scout 宣称 10M）。具体数字随版本变化，以官方模型页为准。128K 大约是一本 300 页英文书；中文 1 个汉字约 1–1.5 token，同样窗口装的汉字更少（见 Tokenizer与分词原理）。
- 不是记忆：窗口是”工作台”，每次请求都要把要用的东西重新摆上去；跨请求的持久记忆靠应用层存储，见 Agent记忆与上下文工程。
2. 标称长度 ≠ 有效长度#
| 现象/评测 | 内容 | 启示 |
|---|---|---|
| Lost in the Middle（Liu 等 2023） | 同一信息放开头/结尾准确率高，放中间显著下降，呈 U 形曲线 | 关键信息放首尾；别把 20 篇检索结果平铺后指望模型都读到 |
| Needle-in-a-Haystack | 在长填充文本任意深度插一句”针”，问模型能否取回，画 深度×长度 热力图 | 通过只是必要条件：单针检索简单，多针/推理/聚合任务更难 |
| RULER、LongBench 等 | 多针、变量追踪、聚合、长文 QA | 不少标称 128K 的模型在复杂任务上有效长度只有标称的 1/4–1/2 |
原因：训练数据里超长依赖样本稀少、位置编码外推后远距离注意力变钝、长文本里无关内容”稀释”注意力。结论：选模型看长文评测，不看宣传数字。
3. 长上下文的代价#
Prefill（读输入）：注意力 O(n²) 计算 → 长序列下 TTFT 随长度近似平方增长（短序列仍由线性的矩阵乘主导；FlashAttention 降 IO 不降 FLOPs）
Decode（逐 token 生成）：每步读全部 KV Cache → 显存 O(n)、每 token 延迟随 n 上升
KV Cache ≈ 2 × layers × kv_heads × head_dim × n × bytes → 上下文越长、并发越少
API 计费：input token 线性计价，每轮把 100K 文档重新塞一遍 = 每轮付 100K模型侧靠 GQA/MLA 压 KV、RoPE 缩放（PI/NTK/YaRN）+ 长文续训/SFT 把窗口从 4K/8K 推到 128K，机制见 注意力机制变体与位置编码；推理框架侧的 PagedAttention、KV 卸载见 LLM推理优化。应用层拿到的是”能塞但贵且会变慢”的窗口，剩下的是怎么用好。
4. 长上下文 vs RAG 的选型#
| 维度 | 直接塞全文（Long Context） | 检索后再塞（RAG） |
|---|---|---|
| 成本 | 每次请求按全文计价，重复前缀可用 Prompt Caching 压 | 只付命中片段，检索链路本身有额外成本 |
| 准确性 | 全局视野，适合跨段推理、总结、比对；但中段信息易丢 | 依赖召回质量，漏召回就答不出；片段聚焦、噪声少 |
| 时效性/规模 | 文档 ≤ 窗口且相对固定；改一处全文重塞 | 语料远超窗口、频繁更新、多租户权限过滤 |
经验法则：单文档/少量文档 + 需要全局理解（合同审阅、代码库级问答、整本书摘要）→ 长上下文；海量语料 + 事实定位 + 需引用来源（企业知识库、客服）→ RAG；生产中常是混合——RAG 先缩小范围到几十 K，再交给长上下文模型做跨片段推理，详见 RAG架构与实现。
5. 榨干窗口的应用侧手段#
- 裁剪与压缩：删掉无关工具输出/冗余格式、旧轮次滚动摘要、对检索结果先做相关性过滤再拼接；目标是”窗口里每个 token 都在干活”。
- 分块处理超长文档：Map-Reduce（并行对每块抽取/摘要再合并，快但丢跨块关系）、Refine（顺序滚动精炼，保上下文但串行慢、受顺序影响）、Map-Rerank（各块独立作答取最高分，适合答案在单块内的问答）。
- Prompt Caching / 上下文缓存：把不变前缀（system prompt、长文档、few-shot）缓存起来，后续请求命中缓存的 input 按基础价的一小部分计费（量级约 0.03–0.5 倍，按厂商和模型不同：Anthropic 缓存读取 0.05–0.25 倍、OpenAI 新模型 0.1 倍、DeepSeek 约 3%；Anthropic 和 OpenAI GPT-5.6 及之后对缓存写入收 1.25 倍，以官方定价页为准），TTFT 也大幅缩短；要求前缀字节级一致且放在最前，动态内容（用户问题）放最后；缓存有 TTL（Anthropic 默认 5 分钟、可选 1 小时；OpenAI 部分新模型可保留到 24 小时，以官方文档为准），多轮对话要保持前缀稳定。
- 放置顺序：长文档放前、问题和指令放最后并重述要点；多文档给编号/标题做结构化分隔；关键约束首尾各提一次。
- 边界：Agent 多轮的三层记忆、Token 预算分配、长期记忆写回属于 Agent记忆与上下文工程，本篇只讲模型层窗口特性与通用策略；成本手段的整体框架见 AI应用成本优化。
面试回答（2分钟版）
上下文窗口是模型一次请求能看见的 token 上限，输入输出共享，头部模型现在普遍是 1M 级，开源模型常见 128K 到 256K 原生窗口。我会强调两点。第一，标称不等于有效：Lost in the Middle 发现信息放中间利用率呈 U 形下降，Needle-in-a-Haystack 只是单针检索的必要条件，RULER 这类多针、聚合评测里不少 128K 模型有效长度只有标称的几分之一，选型要看长文评测。第二，长上下文有代价：prefill 注意力 O(n²)，长序列下首 token 延迟近似平方增长；解码每步读全部 KV Cache，显存线性增长；API 按 input token 计费，每轮重塞 100K 文档就每轮付 100K。模型侧靠 GQA/MLA 压 KV、RoPE 缩放加长文续训把窗口推上去；应用侧先选型：单文档需要全局理解的，比如合同审阅、代码库问答，直接塞全文；语料远超窗口、更新频繁、要引用来源的走 RAG；生产里常是 RAG 先缩范围再交长上下文模型做跨片段推理。然后榨窗口：裁掉无关工具输出、旧轮次滚动摘要；超长文档用 Map-Reduce 或 Refine 分块；不变长前缀用 Prompt Caching，命中部分按基础价的零点几倍计费、TTFT 也降；关键信息放首尾避开中段。
追问与易错
追问方向：
- 有了 1M 窗口，RAG 还有必要吗？ → 有。窗口解决的是”能不能塞”，RAG 解决的是成本（每次不用付全量）、时效（新文档即查即用）、规模（语料 TB 级）和权限过滤（按租户召回）；且长窗口的中段利用率问题并没消失。趋势是两者结合
- Lost in the Middle 怎么在工程上规避？ → 重排：把 rerank 分数最高的片段放最前和最后、次要的放中间；减少塞入数量（top-5 而非 top-20）；问题和指令放文档之后
- Prompt Caching 什么情况命中不了？ → 前缀任何字节变化（时间戳、随机 few-shot 顺序、用户 ID 插在前面）都会失效；缓存有 TTL，长时间不访问要重新写入；不同模型/不同参数的请求不共享
- 为什么长上下文会让 TTFT 明显变长而 token/s 变化相对小？ → TTFT 由 prefill 决定，是 O(n²) 的计算密集型；decode 每步是访存受限的 O(n)，随长度线性变慢但幅度平缓
- Map-Reduce 和 Refine 怎么选？ → 文档各部分相对独立、追求速度用 Map-Reduce 并行；章节间强依赖、要保持叙述连贯用 Refine；都可能丢跨块关系，合并阶段要专门提示”合并冲突信息”
- 长文续训时为什么常先把 RoPE base 调大或用 YaRN 再训？ → 直接在长数据上训原 base 收敛慢且外推差；先把旋转频率缩放到训练长度能覆盖的范围，再用少量长文数据续训，机制见 注意力机制变体与位置编码
易错点：
- ❌ “窗口 128K 就能把 128K 文档的每个细节都记住” → 有效长度常远小于标称，中段信息利用率下降，需评测验证
- ❌ “上下文窗口只限制输入” → 输入+输出共享，输入塞满会导致输出被截断
- ❌ “FlashAttention 让长上下文不再贵” → 它降显存和 IO，prefill FLOPs 仍 O(n²)，API 也仍按 token 计费
- ❌ “长上下文和 RAG 二选一” → 生产中常是 RAG 缩范围 + 长上下文做全局推理的组合