上下文窗口是什么？模型一次能“记住”多少内容

上下文窗口（Context Window）是大模型单次请求里能处理的 token 总量上限，你写的提示词、之前的对话历史、上传的文档、工具调用的返回结果，再加上模型自己吐出来的回答，全都要挤进这个额度里。超出部分要么被截掉，要么请求直接报错。打个比方，它像一张办公桌的桌面：桌子越大，能同时摊开的资料越多，但桌面之外的东西模型是看不见的。

窗口大小用 token 计

窗口的单位是 token，不是字数。英文里一个 token 大约是四分之三个单词，中文因分词器不同差别很大，常见的情况是一个汉字对应一到两个 token。所以同样标着 128K 的窗口，装英文和装中文能放下的“字数”并不一样。看厂商的规格表时还要分清两个数：上下文窗口是输入加输出的总量，最大输出是单次回答的上限，后者通常小得多。

窗口为什么越做越大

早期的 GPT-3 只有 2K 左右的窗口，塞一篇长文章都费劲。后来位置编码的改进（比如 RoPE 外推）、注意力计算的优化（FlashAttention 一类的实现）和训练数据里长文本比例的提高，让窗口一路涨到 128K、百万级。窗口大了，整本合同、一个代码仓库、几小时的会议记录都能一次喂进去，很多原来要切块处理的活变成了一步完成。

窗口大不等于记得牢

这是最容易踩的坑。很多测试发现，模型对放在开头和结尾的信息记得最清楚，中间那段容易被忽略，业内把这叫“迷失在中间”（Lost in the Middle）。“大海捞针”这类测试能说明模型找得到单个事实，但要它把散落在几十万字里的线索串起来推理，表现往往会明显下降。另外窗口越满，单次调用越慢、越贵，因为大多数 API 是按输入 token 计费的。

实际用起来怎么取舍

资料不多时，直接塞进窗口最省事，效果通常也比检索好。资料成千上万份、还经常更新时，更现实的做法是检索增强生成（RAG）：先检索出最相关的几段，再交给模型。写长提示词时，把最关键的指令放在开头或结尾，长文档前面加个目录式的说明，都能让模型少漏东西。有些厂商还提供提示词缓存，重复的长上下文第二次调用能便宜不少，做多轮对话的应用很值得打开。

在 AI 主线看来，挑模型时上下文窗口只是一个门槛指标：先确认它够装下你的典型任务，再去比长文本场景下的真实表现，别只盯着规格表上那个最大的数字。