一、从一个常见现象说起

你一定遇到过这样的场景：跟一个 AI 聊了很久，聊到第几十轮时，它突然"忘了"你开头说过的话；或者你把一份几十页的 PDF 丢给它，它只读到了前几页就开始回答。这不是模型"变笨"了，而是它撞上了一堵墙——上下文窗口（Context Window）。

本文就来聊清楚：上下文窗口到底是什么、它如何影响我们使用大模型、以及当需求超出窗口时，工程师们用哪些代码手段来突破它。

二、什么是上下文窗口

上下文窗口（Context Window），指的是大模型在"一次推理"中能够同时读取并记住的文本长度上限，通常以 token 为单位。你可以把它理解成模型的"短期记忆容量"：在一次对话/一次补全中，所有输入(prompt) + 所有已生成的输出(completion) 加起来的 token 数，不能超过这个上限。

图 1：上下文窗口就像是模型一次能"框住"的文本范围

一个关键但常被忽视的点：窗口是"输入+输出共享"的。比如一个 8K token 的模型，你塞了 7K 的 prompt 进去，它最多只能再生成 1K token 的回答，再多就会被截断或报错。这也是为什么长 prompt 会"挤压"模型的回答空间。

三、为什么单位是 token 而不是"字"

大模型不直接读字符，而是先把文本切成"token"——一种介于字符和词之间的子词单元。一个汉字可能占 1~2 个 token，一个英文单词通常 1~3 个 token。所以"8000 token"既不等于 8000 个汉字，也不等于 8000 个英文单词。

图 2：文本被切成 token 序列后送入模型

用 OpenAI 的 tiktoken 库可以直观感受同一段话在不同编码器下的 token 数：

import tiktoken

 

# GPT-4o 使用的编码器

enc = tiktoken.encoding_for_model("gpt-4o")

 

zh = "上下文窗口是模型的短期记忆容量"

en = "The context window is the model's short-term memory capacity."

 

print("中文 token 数:", len(enc.encode(zh)))

print("英文 token 数:", len(enc.encode(en)))

print("中文 token 序列:", enc.encode(zh))

 

# 输出示例：

# 中文 token 数: 12

# 英文 token 数: 9

# 中文 token 序列: [60831, 106434, 494915, ...]

可以看到，仅 15 个汉字就消耗了 12 个 token。这意味着当我们讨论"4K/8K/128K 上下文"时，换算成自然语言字数往往要打不少折扣，这也是工程上必须用 token 计量的原因。

四、主流大模型的上下文窗口对比

最近两年，模型的上下文窗口呈数量级增长。下表是几个有代表性的模型：

从 4K 到 2M，三年内窗口扩大了约 500 倍。但窗口越大，推理成本和延迟也越高——上下文窗口从来不是"越大越好"，而是要根据任务权衡。

五、上下文窗口为什么重要

它直接决定了模型能做什么样的任务：

短窗口（≤8K）：只能做多轮问答、单篇短文摘要；

中窗口（32K~128K）：可以"整本"读取一份 PDF、做长文档摘要、代码库级别的问答；

长窗口（200K~2M）：能一次性吃下整本书、整段视频字幕、整个代码仓库，做跨文档推理。

但要注意："能装下"不等于"能用好"。研究表明，当关键信息出现在超长上下文的中间位置时，模型的检索准确率会显著下降，这被称为"Lost in the Middle"现象。所以工程实践中，我们仍倾向于用 RAG 等手段，而不是盲目堆 prompt。

六、当需求超出窗口：RAG 的工程解法

假设我们有一份 50 万字的企业知识库，远超任何模型的单次窗口。最主流的解决方案是 RAG（Retrieval-Augmented Generation，检索增强生成）：把文档切块、向量化、按需检索最相关的几块塞进 prompt。下面是一个最小可运行示例：

import numpy as np

 

# 1) 模拟一份长文档，按句子切成 chunk

doc = "上下文窗口是模型的短期记忆。它以 token 为单位。"

doc += "当文档超长时需要 RAG。RAG 先检索再生成。"

doc += "向量检索用embedding。embedding把文本映射成向量。"

chunks = [doc[i:i+12] for i in range(0, len(doc), 12)]

print("分块数:", len(chunks))

 

# 2) 假装有一个 embedding 函数，把每个 chunk 变成 8 维向量

def embed(text: str) -> np.ndarray:

    rng = np.random.default_rng(abs(hash(text)) % (2**32))

    return rng.normal(size=8)

 

db = np.vstack([embed(c) for c in chunks])  # 向量库

 

# 3) 用户提问，检索最相似的 top-2 chunk

query = "RAG 是什么？"

q_vec = embed(query)

scores = db @ q_vec / (np.linalg.norm(db, axis=1) * np.linalg.norm(q_vec))

top_idx = np.argsort(scores)[::-1][:2]

retrieved = [chunks[i] for i in top_idx]

 

# 4) 只把检索到的片段塞进 prompt（远小于窗口）

prompt = "已知信息：\n" + "\n".join(retrieved) + "\n\n问题：" + query

print("最终 prompt 长度(字符):", len(prompt))

print("prompt:", prompt)

运行后你会发现，虽然原始文档很长，但真正送进模型的 prompt 只有几十个字。这就是 RAG 的核心价值：用"检索"把"无限长"的文档压缩到"窗口内"。除了 RAG，常见的还有 Map-Reduce 摘要、滑动窗口记忆、分层摘要等策略，思路都是同一类——用工程手段绕开窗口的物理上限。

七、总结

上下文窗口 = 大模型一次推理中能同时读写的 token 上限，是输入与输出共享的。它决定了模型能处理多长的文本、能记住多少轮对话，但"装得下"不等于"用得好"，长上下文还伴随 Lost in the Middle、成本与延迟上升等问题。理解它，能帮你在选型、Prompt 设计和工程架构（如 RAG）上做出更合理的决策。

下次再遇到 AI"失忆"或"读不完文档"，你就知道：这不是它笨，而是上下文窗口到顶了——该上 RAG 了。