模型上下文窗口这件事，大多数人的误区在第一步：把「模型宣传的窗口」当成「模型实际能稳定理解的窗口」。这两个差的不是一点。RULER 这类基准早就发现，即便模型在简单检索测试里接近满分，随着上下文变长、任务变复杂，性能照样往下掉。所以问题不是「能不能塞更多」，而是「该让什么进、该把什么挡在门外」。这篇把这几个工程手段一次讲清。
宣传窗口与有效窗口
判断写进第一句：选模型别看宣传的 token 上限，要看它在你这类任务、你需要的上下文长度下，实际还能剩多少准确率。
LongBench 评估的任务范围更广——文档问答、多文档推理、摘要、少样本学习、代码补全。它的结论指向同一个方向：容量（能塞多少）和理解能力（塞进去还能不能找对）是两个属性，别混为一谈。这意味着长上下文有真实价值，但要用在「确实需要整段上下文」的任务上，而不是当默认的垃圾桶。
检索替代全量加载
绝大多数应用根本不需要把整本手册塞给模型。用户问「退货政策是什么」，你要的是手册里那两三段，不是 500 页全文。这就是 RAG 的用武之地——先检索、再只把相关段落放进上下文：
# 检索到相关段落后，只把这几段拼进 prompt，而不是塞全文
chunks = retrieve(query, top_k=3) # 向量检索 + 重排序
context = "
".join(c.text for c in chunks)
prompt = f"依据以下资料回答，资料里没有就明说不知道：
{context}
问题：{query}"
检索质量才是这条路的命门：文档切分要谨慎、多召回几个候选再重排序、拼 prompt 前把无关内容滤掉。ElevenLabs 就曾靠查询改写加并行模型调用，把检索延迟的中位数砍掉一半。
对话历史的三种收法
对话应用最容易被自己喂死：每轮都无脑追加全部历史，token 越滚越多，还把无关的旧细节带进新轮次。成熟的收法是三段式：
# 短期上下文：只保留最近几轮；长期记忆：结构化持久化，用到再查
recent = messages[-6:] # 最近 3 轮问答
if len(messages) > 12:
summary = summarize(messages[:-6]) # 旧对话压成摘要放前面
facts = extract_facts(messages[:-6]) # 持久事实抽成结构化记忆
system = f"用户档案：{facts}
对话摘要：{summary}"
原则一句话：模型马上要用的放短期上下文，以后可能还要用的抽成长期记忆、用到再检索。别指望模型自己从几十轮历史里翻旧账。
缓存与 KV cache
两块缓存容易混，分开说。一块是请求侧的上下文缓存：很多应用反复发同样的系统指令、同样的长文档前缀，命中缓存能省一大笔 token 和延迟；语义缓存更进一步，把「退货政策是什么」和「我有多久能退货」认成同一个问题，直接跳过生成。另一块是推理侧的 KV cache：生成时把之前的 Key/Value 存下来避免重算，超长上下文下它会占几十 GB 显存，MQA 让所有 head 共用一组 KV、GQA 在性能和开销之间折中，主流模型大多用 GQA。这一块是框架和引擎的事，你更该关心的是前者——不变的内容放最前、别乱动前缀，把命中率做上去。
中间迷失与位置摆放
还有一个反直觉的认知坑：关键信息放开头或结尾，模型抓得最准；埋在中间，准确率会显著掉。这是因为训练数据里高质量指令的答案大多集中在首尾。落到实践就是两条：最重要的指令、约束、参考资料放最前或最后；用清晰的分隔（标题、标签）把段落边界标出来，帮模型定位。别把「最关键的那句」随手写在第 17 段中间。
长上下文该用在哪
判断写进第一句：长上下文不是 RAG 的替代品，而是它的互补——海量数据先检索，检索出来的几段再放进长窗口细读。
真正该整段塞进上下文的任务，是那些需要跨段推理、不能被切碎的场景：对比两份长合同的差异、追踪一篇论文从头到尾的论证、总结一整本书。这类任务的价值恰恰在于「完整」，切了反而丢上下文。反过来说，客服问答、政策查询这种「从大文档里找一小段答案」的场景，硬塞全文只是浪费 token。一个实用的混合姿势是：先用检索从千万级语料里筛出 Top-K 相关片段，再把这几个片段放进长上下文窗口做精细分析——检索负责「找对」，长上下文负责「读透」。别把两者当单选题。
常见误区
一是把长上下文当 RAG 的替代品——千万级 token 的海量数据，先检索出 Top-K 再放进长窗口细读，比硬塞靠谱得多。二是宣传窗口当能力，选中模型只看「支持 128K」不看它在 128K 下的实际表现。三是历史无脑追加，宁可堆 token 也不愿做摘要和结构化记忆。四是忽视缓存命中率，前缀天天改，缓存形同虚设。这几条都不玄，省下来的是实打实的成本和延迟。