大模型的上下文窗口是什么意思

一、从一个常见现象说起你一定遇到过这样的场景跟一个 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 models 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 万字的企业知识库远超任何模型的单次窗口。最主流的解决方案是 RAGRetrieval-Augmented Generation检索增强生成把文档切块、向量化、按需检索最相关的几块塞进 prompt。下面是一个最小可运行示例import numpy as np# 1) 模拟一份长文档按句子切成 chunkdoc 上下文窗口是模型的短期记忆。它以 token 为单位。doc 当文档超长时需要 RAG。RAG 先检索再生成。doc 向量检索用embedding。embedding把文本映射成向量。chunks [doc[i:i12] 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(size8)db np.vstack([embed(c) for c in chunks]) # 向量库# 3) 用户提问检索最相似的 top-2 chunkquery RAG 是什么q_vec embed(query)scores db q_vec / (np.linalg.norm(db, axis1) * 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问题 queryprint(最终 prompt 长度(字符):, len(prompt))print(prompt:, prompt)运行后你会发现虽然原始文档很长但真正送进模型的 prompt 只有几十个字。这就是 RAG 的核心价值用检索把无限长的文档压缩到窗口内。除了 RAG常见的还有 Map-Reduce 摘要、滑动窗口记忆、分层摘要等策略思路都是同一类——用工程手段绕开窗口的物理上限。七、总结上下文窗口 大模型一次推理中能同时读写的 token 上限是输入与输出共享的。它决定了模型能处理多长的文本、能记住多少轮对话但装得下不等于用得好长上下文还伴随 Lost in the Middle、成本与延迟上升等问题。理解它能帮你在选型、Prompt 设计和工程架构如 RAG上做出更合理的决策。下次再遇到 AI失忆或读不完文档你就知道这不是它笨而是上下文窗口到顶了——该上 RAG 了。