2.4 上下文窗口与信息处理

上下文窗口是大语言模型的核心概念之一，直接影响着提示词设计的方方面面。理解上下文窗口的特性，有助于更有效地组织和呈现信息。

2.4.1 什么是上下文窗口

上下文窗口是指模型在单次推理中能够“看到”和处理的最大 Token 数量，包括输入（提示词）和输出（生成内容）的总和。

2.4.2 主流模型的上下文限制

不同模型的上下文窗口大小差异显著：

模型	上下文窗口	约等于
GPT-5	400K	约 300,000 词
GPT-5.2	400K	约 300,000 词
Claude Opus 4.6	1M	约 750,000 词
Claude Sonnet 4.6	1M	约 750,000 词
Claude Haiku 4.5	200K	约 150,000 词
Gemini 3 Pro	1M	约 750,000 词
DeepSeek V3	128K	约 96,000 词
Kimi	200K - 2M	约 1,500,000 词
Llama 4 Scout	10M	约 7,500,000 词
Llama 4 Maverick	1M	约 750,000 词

2.4.3 上下文窗口的组成

在典型的 API 调用中，上下文窗口包含以下部分：

系统提示词

设定模型的行为准则、角色定义和全局约束，在整个对话过程中保持不变。

系统提示词示例：
你是一位专业的法律顾问，专注于中国合同法领域。
- 回答时引用相关法条
- 使用专业但易懂的语言
- 对于超出专业范围的问题，建议用户咨询其他专家

对话历史

多轮对话场景中，之前的用户消息和助手回复被包含在上下文中，使模型能够理解对话脉络。

User: 什么是违约责任？
Assistant: 违约责任是指...

User: 那违约金如何计算？
Assistant: [根据上文理解用户是在讨论合同违约]

当前用户输入

用户最新的问题或指令。

附加上下文

通过检索增强或其他方式注入的外部信息，如相关文档片段、数据库查询结果等。

2.4.4 上下文窗口的有效利用

信息优先级排序

并非所有位置的信息都同等重要。研究表明，模型对上下文中不同位置的信息有不同的关注度：

“迷失在中间”现象（Lost in the Middle）：当上下文很长时，中间部分的信息可能被模型忽略或弱化。

应对策略：

• 将最重要的指令和信息放在开头或结尾

• 使用清晰的分隔符突出关键内容

• 将核心指令重复放置在结尾

上下文压缩技术

当需要包含大量信息时，可以采用压缩策略：

摘要替代原文：

原始方式：将 10 页文档完整放入上下文
压缩方式：先让模型生成文档摘要，然后使用摘要进行后续任务

关键信息提取：

原始方式：包含完整的用户数据记录
压缩方式：只提取与当前问题相关的字段

分层处理：

第一层：粗粒度筛选相关内容
第二层：对筛选结果进行精细处理

2.4.5 对话历史管理

在多轮对话中，上下文窗口会被对话历史逐渐填满，需要有效的管理策略。

滑动窗口策略

保留最近的 N 轮对话，丢弃更早的历史：

对话轮次：1 → 2 → 3 → 4 → 5 → 6 → 7
窗口(N=4)：         [4 → 5 → 6 → 7]

优点：简单直接 缺点：可能丢失重要的早期上下文

摘要合并策略

将早期对话压缩成摘要，加上最近的完整对话：

[早期对话摘要] + [最近 3 轮完整对话]

优点：保留关键历史信息 缺点：摘要过程可能丢失细节

重要信息固定

识别并固定对话中的关键信息（如用户名、重要偏好），始终保留在上下文中：

[固定信息：用户偏好 + 核心设定]
+ [动态历史：最近对话]
+ [当前输入]

2.4.6 长上下文的挑战与应对

计算成本

更长的上下文意味着更高的计算成本和 API 费用。需要权衡信息完整性与成本效益。

注意力稀释

上下文越长，每个 Token 获得的“注意力”相对越少，可能影响模型对特定信息的关注。

应对策略：

• 使用结构化格式（标题、列表、分隔符）组织长内容

• 明确指出需要重点关注的部分

• 在提示词末尾重申关键要求

一致性维护

长对话中，模型可能逐渐“忘记”或偏离早期设定的规则。

应对策略：

• 在系统提示词中明确核心规则

• 周期性地在用户提示词中重申重要约束

• 使用 RAG 动态注入相关规则

2.4.7 上下文窗口与提示词设计

理解上下文窗口对提示词设计有直接指导意义：

简洁优先

在不影响效果的前提下，追求更简洁的提示词表达：

冗余写法（约 50 tokens）：
我想请你帮我做一件事情，这件事情是这样的，我需要你
能够帮我把下面这段文字翻译成英文...

简洁写法（约 15 tokens）：
请将以下中文翻译为英文：

结构化组织

用清晰的结构帮助模型理解长提示词：

## 任务背景

[背景信息]

## 具体任务

[任务描述]

## 输出要求

[格式要求]

## 输入内容

[实际内容]

预估与规划

在设计提示词时预估 Token 用量：

系统提示词：~200 tokens
对话历史容量：~2000 tokens
RAG 内容预留：~1000 tokens
用户输入预留：~500 tokens
输出预留：~1000 tokens
────────────────────────
总计：~4700 tokens（在 8K 窗口内安全）

延伸思考

1. 上下文窗口越大就越好吗？更大的窗口可能带来哪些新问题（提示：成本、注意力稀释）？

2. 当你的输入文本超过模型的上下文限制时，你会优先选择“摘要压缩”还是“分块处理”？各有什么利弊？