上下文窗口指模型在一次请求中能处理的最大 Token 数，包括输入的提示、文档、历史对话以及模型生成的输出。过去几年，这个数字增长得非常快，很多模型都宣传能“一次读完一本书”。但在实际项目中，上下文越长，并不意味着效果线性变好。理解其中的边界，才能决定什么时候直接塞长文本，什么时候应该换用检索等方案。

长上下文的技术代价

标准自注意力的计算量随序列长度大致呈平方增长，推理时还需要为每个 Token 保存键值缓存。上下文越长：

  • 首 Token 延迟越高：模型需要先把整段输入处理一遍才能开始输出；
  • 显存与成本越高：服务商通常对超长输入单独定价，或者按 Token 线性收费，长请求的账单很可观；
  • 并发能力下降：同样的硬件能同时服务的请求变少。

所以即使模型支持超长上下文，也要问一句：这些内容真的都需要吗？关于推理侧的显存问题，可参考 KV Cache 详解。

“能读到”不等于“能用好”

研究社区和工程实践中反复观察到一个现象：模型对放在开头和结尾的信息利用得较好，而对埋在长文本中间的信息更容易忽略，这常被称为“中间遗忘”（lost in the middle）。新一代模型在这方面有明显改进，但在信息密集、干扰项多的真实文档中，问题并没有完全消失。

常见的“大海捞针”测试，往往是在无关文本中插入一句明显不同的话，检测模型能否找到它。这类测试通过，只能说明模型具备基础的定位能力，并不代表它能在几百页合同里正确综合多处条款、发现彼此矛盾的地方。

什么时候适合用长上下文

长上下文更适合以下场景：

  1. 整体性理解任务：总结一份完整报告、梳理一本书的结构、分析一次长会议的讨论脉络，需要看到全貌；
  2. 跨段落关联：比如对比合同前后条款、找出代码中多个文件之间的调用关系；
  3. 一次性分析：文档只用一次，没必要专门建索引。

而对于需要反复查询的大型知识库、频繁更新的资料、或者成本敏感的高并发服务，检索增强生成通常更合适。两者的取舍可以参考 RAG 还是长上下文。

用好长上下文的技巧

把问题放在合适的位置

很多实践表明，把文档放在前面、把具体问题和指令放在最后，效果通常更稳定。对于特别长的输入，可以在开头简述任务、在结尾再重申一次关键要求。

给文档加结构

用清晰的分隔符和标题标出每份文档的来源、日期和编号，并要求模型回答时注明依据来自哪一段。这既能提升准确率，也方便人工核查。

先抽取再推理

面对很长的材料，可以分两步：先让模型逐段抽取与问题相关的原文片段，再基于这些片段作答。这种“先找证据、后下结论”的方式能减少遗漏和编造。

控制对话历史

多轮对话中，历史会不断累积占用上下文。可以定期把早期对话压缩成摘要，只保留关键事实和决定，相关思路在 AI Agent 记忆设计中有更详细的讨论。

小结

长上下文是一项真实且有用的能力，但它有成本、有盲区。把它当作工具箱里的一种选择，而不是万能方案：需要全局理解时用它，需要高频精准查询时配合检索，同时通过结构化输入和分步推理来提升可靠性。