LLM 上下文窗口的工作原理与实用边界

什么是上下文窗口

每次调用 LLM 时，都会向其发送一个文本块——系统指令、迄今为止的对话、任何检索到的文档，以及新的问题。整个文本块必须塞进一个有限的窗口里，按 token 计数。模型每次调用都会从头读取全部内容。它不会"记住"上一轮对话；上一轮是作为输入的一部分重新发送的。

这是关键的认知转换：模型是无状态的。 聊天中感觉像记忆的东西，不过是每次消息时将整个对话重新喂入。窗口用尽时，最旧的内容必须被丢弃——模型不会优雅地遗忘，它只是根本看不到被截断的部分。

更大的窗口不是免费的午餐

上下文窗口已经大幅扩展，很容易认为可以把所有东西都塞进去。但有两个问题：

成本和延迟随发送量增长。 按 token 付费，按 token 等待。每次调用都带上巨大的上下文，费用会很高，速度会很慢。

"迷失在中间"。 模型能可靠地关注长上下文的开头和结尾，对中间部分则比较模糊。如果把关键事实埋在 100,000 个 token 的中间，模型可能真的会漏掉它。更多的上下文可能意味着更差的答案，因为它稀释了信号。

所以技能不是填充窗口——而是筛选。把正确的信息放在正确的位置，其余的丢弃。这是一个我在构建 AI 系统时依赖的准则。

这就是 RAG 存在的原因

如果模型无法将其整个知识库放入窗口——它确实做不到——就需要在查询时只获取相关片段，并将其放入上下文。这是一句话描述的检索增强生成：不要扩展记忆，而是筛选进入它的内容。上下文窗口的限制是检索成为一种架构而非事后思考的全部原因。

与窗口协同工作，而非对抗

• 不要逐字携带旧对话，而是做摘要，这样长对话不会超出预算。
• 把最重要的指令和事实放在边缘位置——开头和结尾——那里注意力最强。
• 检索，不要倾倒。 给模型喂少量重要的段落，而不是你拥有的所有东西。
• 像在受限系统中追踪内存一样追踪你的 token 预算，因为它本质上就是这样的。

把上下文窗口视为一种稀缺、需要精心管理的资源，模型就会变得更锐利。把它视为无限的，它就会变慢、变贵、变模糊。更多关于我是如何管理它的内容，请访问 www.divyakush.com。

RAG 正确解释：检索如何让 LLM 保持诚实——一种完全围绕这一限制构建的架构。

Divyakush Punjabi · 全栈与 AI 工程师作品集 · GitHub · LinkedIn