面经策

什么是上下文窗口 Context Window？它有什么限制？ ​

  • 标签：Prompt、上下文窗口

🏛 业务架构师 ​

Context Window 是模型单次推理可处理的 token 上限（输入+输出共享额度），2026 年主流 128K~1M。

它的限制（业务视角）：

  1. 物理限制：塞不进的信息模型"不知道"——长文档、全量历史、大代码库必须裁剪或检索；
  2. 经济限制：按 token 计费且长输入梯度加价——塞满是烧钱；输入 token 每轮都在成本表上；
  3. 效果限制："lost in the middle"——窗口中部信息利用率低，塞满不等于用好；长上下文里模型对细节的忠实度也会下降；
  4. 性能限制：注意力计算随长度增长，超长输入首字延迟明显上升。

工程应对（每一项都是架构决策）：

  • RAG：只检索相关内容注入——用"相关性"换"全量"，高频场景的经济最优解；
  • 历史管理：滑动窗口+滚动摘要+关键信息外置（结构化存储）；
  • 工具结果限幅：返回摘要+分页钻取，禁止 50KB 原文直灌；
  • Compaction：逼近上限时整体压缩重写；
  • 预算表：上下文配额化（系统提示/历史/检索/输出各占多少）——超支先裁再进。

我的架构习惯：把"窗口档位"当产品的硬规格管理——不同模型档位对应不同业务能力边界（128K 够单文档问答，1M 才谈代码库通读）；上线前压测"最长会话+最大文档"的真实 token 曲线，别等用户把窗口撑爆了才救火。

🏗 系统架构师 ​

Context Window = 模型单次推理能处理的 token 上限（输入 + 输出共享预算）。限制与工程对策：

限制的四个面：

  • 容量上限：超窗直接报错或静默截断（各模型行为不同——截断最危险，丢失的可能是指令）；
  • 成本线性：输入按 token 计费，长上下文单次调用美元级——循环场景（Agent 每步全量重算）成本乘数放大；
  • 延迟线性：prefill 时间随长度涨（TTFT 变慢），长上下文首 token 秒级~十秒级；
  • 效果衰减（最隐蔽）：lost in the middle——窗口能装 ≠ 都记住，中段信息利用率显著低；有效上下文（可靠利用的长度）常小于标称窗口一半。

工程对策（分层）：

  • 少塞：RAG 精准供给（检索 Top-3 优于全量塞）、工具结果摘要/外置分页加载、输出 max_tokens 预留（防"光输入没输出空间"——输入输出共享预算是常见坑）；
  • 压缩：滚动摘要、Compaction（结构化状态快照）、token 级压缩（LLMLingua）；
  • 分治：长文档 MapReduce（分段处理再归并）、任务分解给子 Agent（各持上下文父级收结论）；
  • 省钱省时：Prompt Cache（稳定前缀命中打 1~2.5 折）、关键信息首尾放置（attention 高地）；
  • 选型：按任务选窗口档位（对话 32K / 文档分析 128K~1M），不为"大窗口"付无谓成本。

一句话：上下文窗口是 LLM 系统的"内存管理问题"——容量、成本、延迟、效果四个约束联动，工程本质是窗口预算分配学。

💻 全栈开发专家 ​

Context Window（上下文窗口）：模型单次推理能处理的 token 总上限——system prompt、对话历史、检索文档、工具结果、正在生成的输出全部计入。

限制的三个层面：

1. 硬限制（物理）：

  • 超限直接 API 报错；部分实现静默截断——更危险，截掉的可能是 system 里的安全规则或对话开头的关键约束；
  • 常见窗口：4k（小模型）~128k（主流旗舰）~1M（Gemini/部分国产）。

2. 质量限制（化学，比硬限制更阴险）：

  • Lost in the middle：长上下文的中段信息召回率显著低于首尾——塞满 128k 不等于用好了 128k；
  • 指令稀释：约束越多/上下文越长，单条指令的服从度越低（30 条规则在 4k 里执行率远高于在 100k 里）；
  • 有效上下文 < 标称上下文是普遍现象。

3. 成本与延迟限制（经济）：

  • 输入成本随长度线性、注意力计算随长度平方（长输入 TTFT 明显恶化）；
  • 多轮 Agent 累积消耗近似平方级增长。

工程对策（预算管理）：

  • 分区配额：system 5% / 任务 5% / 最近对话 30% / 工具结果 40% / 检索 15% / 余量；
  • 裁剪-摘要-外置三件套：最近 N 轮原文、旧历史滚动摘要、大结果落盘留引用；
  • 关键信息放首尾；长文档 RAG 化而非全文塞；
  • 入口预算检查：组装完 prompt 先数 token，超了先压再调。

一句话：窗口是「预算」不是「仓库」，按预算管理思维做应用才稳。