> For the complete documentation index, see [llms.txt](https://yeasy.gitbook.io/context_engineering_guide/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://yeasy.gitbook.io/context_engineering_guide/di-yi-bu-fen-ren-shi-shang-xia-wen-gong-cheng/02_llm_basics/2.2_context_window.md).

# 2.2 上下文窗口的本质

## 2.2.1 什么是上下文窗口

**上下文窗口**（Context Window）是大语言模型一次能够处理的最大 Token 序列长度。它包括输入的提示词、对话历史、检索到的文档等所有信息，以及模型生成的输出。

可以将上下文窗口类比为模型的“工作记忆”：

* 它有固定的容量上限
* 超出容量的内容无法被处理
* 窗口内的所有信息相互可见、相互影响

```mermaid
graph TB
    subgraph "上下文窗口结构"
        A["系统提示词"]
        B["用户消息"]
        C["对话历史"]
        D["检索内容"]
        E["模型输出"]

        A --> F["上下文窗口"]
        B --> F
        C --> F
        D --> F
        F --> E
    end
```

图 2-1：上下文窗口结构

## 2.2.2 输入与输出的关系

上下文窗口容量需要同时容纳输入和输出：

$$上下文窗口容量 = 输入 Token 数 + 输出 Token 数$$

例如，一个 8K 窗口的模型：

* 如果输入占用 6K Token
* 则输出最多只剩 2K Token 的空间

这意味着在实际应用中，需要谨慎规划输入内容的规模，为输出留出足够空间。

## 2.2.3 上下文窗口的技术实现

从技术角度看，上下文窗口的限制来自多个层面：

* **位置编码**：Transformer 使用位置编码（Positional Encoding）让模型感知 Token 的位置。传统的绝对位置编码难以泛化到训练时未见过的长度。现代模型采用改进方案如 **RoPE**（旋转位置编码）和 **ALiBi**（注意力线性偏置）
* **KV 缓存**：在生成过程中，模型需要缓存之前所有 Token 的 Key 和 Value 向量。KV 缓存大小与上下文长度成正比——一个 70B 参数模型的 128K 上下文可能需要数十 GB 显存
* **注意力计算**：自注意力的 $O(n^2)$ 复杂度使得超长上下文的计算成本极高，虽然有各种优化技术但基本瓶颈依然存在

## 2.2.4 长上下文的挑战

随着上下文窗口不断扩大，新的挑战也随之出现：

* **“中段迷失”（Lost in the Middle）问题**：一些模型在长上下文中可能出现位置偏置，即对开头和结尾的信息更敏感，而对中间部分的关键信息利用不足（注意与下文用于评测的“大海捞针”测试相区分）。新一代模型与评测方法在持续改进这一现象，但在极端长度、强干扰噪声或复杂检索任务下仍需通过结构化、检索与显式提示来降低风险。

  ```mermaid
  graph TB
      subgraph "U型注意力分布 (Lost in the Middle)"
      direction LR
      S[开头: 关注度高] --- M[中间: 关注度低] --- E[结尾: 关注度高]
      style S fill:#d4f1f4,stroke:#333
      style M fill:#f8d7da,stroke:#333,stroke-dasharray: 5 5
      style E fill:#d4f1f4,stroke:#333
      end
  ```

  图 2-2：U 型注意力分布 (Lost in the Middle)
* **注意力稀释**：上下文越长，噪声、冲突证据和位置偏置的暴露面越大，重要信息更可能被干扰；这是一种工程风险描述，不是平均注意力必然按长度线性下降。
* **成本与延迟**：更长的上下文意味着更高的计算成本和更长的响应延迟，直接影响用户体验。
* **质量与长度的权衡**：精心筛选的短上下文往往比冗长的长上下文效果更好，信息质量比数量更重要。

## 2.2.5 有效上下文长度

需要区分两个概念：

* **声称上下文长度**：模型官方宣称支持的最大长度
* **有效上下文长度**：模型能够真正有效利用的长度

许多模型在接近最大上下文长度时，性能会显著下降。一个声称支持 128K 的模型，有效长度可能只有 64K 甚至更短。

评估有效上下文长度的常用方法是“大海捞针”测试（Needle in a Haystack）：将一条关键信息放置在上下文的不同位置，测试模型能否准确检索。

## 2.2.6 上下文窗口的发展趋势

上下文窗口正在快速扩展：

| 阶段      | 常见量级（示意） | 备注                |
| ------- | -------- | ----------------- |
| 早期商用阶段  | 2K–8K    | 适合短对话与简单问答        |
| 中等上下文阶段 | 16K–128K | 适合文档问答、代码片段审阅     |
| 长上下文阶段  | 200K–1M  | 适合长文档、跨多文档汇总      |
| 超长上下文探索 | 多百万级     | 对成本、延迟与信息组织提出更高要求 |

然而，更大的上下文窗口并不意味着可以忽视上下文工程。事实上，超大上下文窗口让上下文管理变得更加重要——如何在巨大的可用空间中高效组织信息、避免噪声干扰、确保关键信息被正确利用，这些都是上下文工程需要解决的问题。