前端学 LLM

上下文窗口与模型记忆

开篇问题

你在使用大模型时，很容易产生一种直觉：只要前面聊过，模型就应该记得；只要模型学过，它就应该知道；只要上下文窗口足够大，它就应该能稳定利用里面的所有信息。

这三个直觉都不完全对。

大模型的“知道”和程序里的变量、数据库里的记录、浏览器里的缓存都不一样。它有一部分知识压缩在参数里，有一部分信息来自本次输入的上下文，有一部分中间状态暂存在推理过程的 KV Cache 里。至于我们在产品里说的“记忆”，往往不是模型内部自动保存的记忆，而是应用层选择、压缩、再注入上下文的结果。

本章要回答一个基础问题：模型在生成每一个 token 时，到底能依赖哪些信息？

本章你会理解什么

  • 上下文窗口为什么不是“聊天记录数据库”。
  • 参数知识、输入上下文、模型记忆和 KV Cache 的区别。
  • Transformer 为什么需要把历史 token 保留为可注意的信息。
  • 长上下文为什么不等于稳定记忆。
  • 开发者在理解“模型记得什么”时最容易混淆的几件事。

核心概念

上下文窗口指模型一次推理请求中最多能处理的 token 范围。它包括系统指令、用户输入、历史消息、文件片段、工具结果、格式要求等所有被送入模型的文本或结构化内容。

参数知识指训练后固化在模型权重里的统计规律和知识。模型没有像数据库一样保存一条条事实，而是把语言模式、概念关系、代码习惯和世界知识压缩进大量参数。

模型记忆在不同语境下含义不同。严格从模型原理看，基础模型在一次请求结束后不会自动修改参数，也不会把这次对话写进内部存储。产品层面的“记忆”通常是外部系统保存用户偏好、历史摘要或事实，再在后续请求中放回上下文。

KV Cache是推理时为了加速自回归生成而保存的中间张量。它让模型在生成下一个 token 时不用反复计算前面所有 token 的 Key 和 Value。它是计算缓存，不是长期记忆。

注意力是 Transformer 让当前位置读取前面位置表示的机制。当前 token 不是在一个空白房间里生成的，它会通过注意力从上下文中取信息，但取到什么、取多少、是否取准，并不由开发者直接控制。

机制拆解

一次请求里，模型看到的是 token 序列

从接口上看，你传给模型的是一组消息：

system: 你是一个严谨的技术作者
user: 请解释 KV Cache
assistant: ...

从模型内部看，这些内容会被 tokenizer 切成一串 token。模型处理的不是“消息对象”，也不是“数据库行”，而是一段连续的 token 序列。角色、分隔符、换行、Markdown 标记和自然语言内容，都会以某种形式进入序列。

上下文窗口限制的是这段序列的总长度。超出窗口的内容不会被模型处理。没有进入本次序列的信息，对本次生成就不可见。

这点对开发者很重要：页面上显示的历史，不等于模型本次看到的历史；服务器里存着的消息，不等于模型可以引用的事实；用户曾经说过的话，如果没有被再次放入请求，模型就不能直接依据它。

参数知识是压缩后的可能性，不是可查询表

模型训练时会看大量文本，并通过预测下一个 token 来调整参数。训练结束后，参数里包含了大量语言和知识模式。

但这和数据库有本质区别。

数据库可以保存：

user_id = 42
favorite_editor = "VS Code"

然后通过主键精确查询。模型参数不会以这种方式保存事实。它更像一个巨大的函数：给定当前 token 序列，输出下一个 token 的概率分布。

因此，当模型回答“JavaScript 的事件循环是什么”时，它依赖的是参数中学到的通用概念和语言模式；当它回答“你上周提交的 PR 为什么失败”时，如果上下文里没有这条 PR 的日志，它就只能猜测、泛化或拒绝。

参数知识擅长提供通用背景，不擅长保证某个具体、最新、私有事实正确。

上下文是临时工作区

如果参数知识像编译进程序的能力，上下文更像一次函数调用的入参。

你可以把当前任务需要的信息放进上下文，例如：

  • 当前用户问题。
  • 相关历史消息。
  • 一段代码。
  • 一份错误日志。
  • 一段文档摘录。
  • 输出格式要求。

模型生成时会把这些 token 当作可参考材料。上下文的优势是新鲜、具体、可控；缺点是容量有限、成本随长度上升，并且会在请求结束后消失。

这也是为什么“把信息放进上下文”和“让模型学会”是两件事。前者是本次请求临时可见，后者需要训练或微调改变参数。大多数应用开发里的“让模型知道某事”，其实只是“把某事放进本次上下文”。

Transformer 如何利用上下文

Transformer 的核心机制之一是自注意力。可以用一个简化说法理解：当模型处理当前位置时，它会为上下文中的其他位置分配不同注意力权重，从而决定哪些 token 对当前位置更重要。

例如这句话：

小林把书放进背包，因为它太重了。

模型要理解“它”更可能指“书”，需要参考前面的 token。注意力机制让当前位置可以读取前文表示。

在大语言模型生成时，每产生一个新 token，模型都会基于已有序列重新形成对上下文的读取。它不是逐字照抄上下文，而是在许多层注意力和前馈网络中不断变换表示，最后得到下一个 token 的概率分布。

所以，上下文不是一块模型会精确检索的硬盘。它更像一张临时摊开的材料桌：材料在桌上，但模型是否关注到关键行、是否把远处信息和当前问题正确关联，仍然取决于模型能力、位置、干扰信息和任务形式。

KV Cache 是推理缓存，不是记忆系统

自回归生成有一个特点：模型一次生成一个 token。生成第 1001 个 token 时，前面 1000 个 token 都会影响它。

如果每生成一个 token 都从头计算前面所有 token 的注意力表示，成本会很高。KV Cache 的作用是保存已经计算好的 Key 和 Value。下一步生成时，新 token 只需要计算自己的部分，再读取之前缓存的 Key 和 Value。

可以把它类比为一次请求内部的计算缓存：

输入 token -> 计算 K/V -> 存入 KV Cache
生成新 token -> 复用旧 K/V -> 只追加新 K/V

它带来的主要收益是降低重复计算、提升生成速度。它不会让模型跨会话记住用户，也不会把新知识写入参数。请求结束、缓存释放后，这些中间状态通常就不存在了。

KV Cache 也解释了为什么长上下文推理会消耗更多显存或内存：模型需要为上下文中许多 token 保存中间表示。上下文越长，缓存越大，推理成本越高。

长上下文不是无限记忆

上下文窗口变大是一件重要的事。它让模型可以一次读取更长文档、更长代码、更完整对话。

但长上下文有三个边界。

第一，能放进去不等于能稳定用好。窗口里的信息可能相互冲突、位置很远、措辞相似，模型未必总能抓住最关键的证据。

第二，长上下文会增加成本和延迟。每次请求都要处理更多 token，KV Cache 也更大。

第三，长上下文仍然是临时的。它不会自动变成长期记忆。你可以把 100 页材料放进一次请求，但下一次请求如果不再放入，模型就看不到。

因此，开发者应该把长上下文理解为更大的工作区，而不是更可靠的大脑。

产品里的“记忆”通常是外部回填

当一个 AI 产品说“我记住了你喜欢简洁回答”，背后通常不是模型参数立即改变，而是系统把这条偏好保存到外部存储里。下次请求时，应用把它作为上下文的一部分放入模型输入：

已知用户偏好：
- 喜欢简洁回答。
- 代码示例优先使用 TypeScript。

这类记忆的关键不在模型内部，而在外部系统如何选择：

  • 什么值得保存。
  • 什么已经过期。
  • 什么和当前任务相关。
  • 什么不该暴露给模型。
  • 多条记忆冲突时如何处理。

从原理上说，模型仍然只是读取本次上下文并生成下一个 token。所谓“记得”，是系统把过去的信息重新摆到了它面前。

开发者常见误解

误解一：模型会自动记住本次对话。

多数 API 调用是无状态的。模型不会因为你上一轮调用过它，就在下一轮自动拥有上一轮内容。能否延续对话，取决于应用是否把必要历史重新传入。

误解二：上下文窗口越大，答案越可靠。

更大的窗口提高了可见信息上限，但也可能带来更多噪声。可靠性来自相关、清晰、少冲突的上下文，而不是单纯堆长度。

误解三：KV Cache 可以当长期记忆用。

KV Cache 是推理时的性能机制，不是用户画像、知识库或会话存档。它保存的是中间计算结果，不是可解释、可检索、可治理的事实记录。

误解四：模型参数里的知识等于事实库。

参数知识可以支持通用问答，但不能保证最新、私有、精确事实。尤其是公司内部数据、今天的版本变化、用户账户状态，都不应该从参数里期待。

误解五：模型没提到某段上下文，说明它没看到。

不一定。它可能看到了，但认为无关；也可能被其他内容干扰；还可能在生成中没有把这段信息转化为输出。上下文可见性和输出引用之间没有一一对应关系。

小实验 / 思考实验

实验一：同一事实，放入和不放入上下文

准备一句虚构事实：

在本书中，“蓝色门槛”指模型不能从参数中可靠获得的私有事实边界。

先直接问模型：

“蓝色门槛”是什么意思？

再把定义放在问题前面，重新提问。观察两次回答的差异。

这个实验能帮助你区分参数知识和上下文知识。第一次模型没有理由知道这个私有定义；第二次它可以基于上下文作答。

实验二：远距离信息是否被稳定使用

构造一段很长的文本，把关键约束放在开头：

重要约束：最终答案只能输出数字 17。

中间加入大量无关段落，最后问：

请给出最终答案。

改变文本长度、干扰信息数量和约束位置，观察模型是否始终遵守。你会发现“信息在窗口内”和“信息被稳定利用”不是同一件事。

实验三：把“记忆”拆成存储和回填

想象你要实现一个偏好记忆：

用户喜欢 Python 示例，不喜欢太长解释。

如果你只把它写进数据库，但下次请求没有放进上下文，模型能知道吗？如果每次都放进去，但当前任务是写 TypeScript 类型定义，它还应该服从这条偏好吗？

这个思考实验说明：记忆不是单纯保存，而是保存、选择、冲突处理和上下文注入的组合。

本章小结

大模型在一次生成中主要依赖三类信息：参数中压缩的通用知识、本次请求提供的上下文，以及推理过程中用于加速的 KV Cache。参数知识不是数据库，上下文不是永久记忆，KV Cache 也不是用户记忆系统。

开发者理解模型边界时，要把“存在哪里”和“本次是否可见”分开。模型只能直接利用本次进入上下文窗口的信息；产品里的长期记忆通常由外部系统保存，再在需要时注入上下文。

长上下文扩展了模型的工作区，但没有取消信息选择、噪声控制和边界判断。真正成熟的理解不是问“模型能记多少”，而是问“本次生成中，哪些信息以什么形式对模型可见”。

自测题

  1. 为什么说上下文窗口不是聊天记录数据库？
  2. 参数知识和上下文知识的区别是什么？各自适合提供什么信息？
  3. KV Cache 为什么能提升推理速度？为什么它不是长期记忆？
  4. 长上下文为什么可能同时带来更强能力和更多干扰？
  5. 如果一个产品说“模型记住了用户偏好”，从原理上通常发生了什么？