# 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  | 适合长文档、跨多文档汇总      |
| 超长上下文探索 | 多百万级     | 对成本、延迟与信息组织提出更高要求 |

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


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET 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?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.