核心问题
本地 LLM 能继续对话，是因为：
- 运行时保持活跃上下文
- KV Cache 让模型复用已做的工作
但这不等于学习知识、数据库、或长期个人记忆。
四个常被混淆的概念
| 概念 | 本质 | 是否持久 | 是否人类可读 |
|---|---|---|---|
| Context | 模型当前能看到的 token | 临时 | 是 |
| Chat History | 之前的消息文本 | 由 App 存储 | 是 |
| KV Cache | 之前 token 的内部注意力数据 | 运行时临时 | 否 |
| Long-term Memory | 外部系统存储和检索 | 持久 | 是 |
关键澄清
模型本身不在聊天中学习
正常推理期间，模型不会从你的对话中学习。它只是把对话当作活跃上下文使用。
告诉模型你的名字，它能在会话中使用，是因为名字还在上下文里。不是因为模型永久存储了这个事实。
KV Cache 不是记忆数据库
KV Cache 存储的是：
Tokens: [The] [cat] [sat] [on] [the] [mat]
模型计算的注意力数据：
K/V data for "The"
K/V data for "cat"
...
不是：
用户喜欢小模型
用户偏好短回答
用户在 Linux 上工作
KV Cache 是速度优化，不是记忆数据库。你不能打开它读出一行"用户偏好 Python"。
为什么长上下文贵
更大的上下文窗口意味着：
- 更多 token 要处理
- 更多注意力状态要存储
- 更多内存压力
- 可能更慢的提示词摄入
- 更大的会话状态
KV Cache 用内存换速度。
模型何时会"忘记"
- 聊天超过上下文窗口
- 旧消息被丢弃
- 摘要删除了重要细节
- 新会话没有加载旧聊天
- App 没有重载之前的状态
- 信息一开始就没被包含
这不是模型在闹情绪。这是上下文管理问题。
四层记忆框架
1. Weights — 学到的记忆
- 语言模式、通用事实、代码语法
- 正常聊天不更新
2. Context — 活跃记忆
- 当前消息、 earlier 聊天轮次、粘贴的文档
- 临时，受窗口限制
3. KV Cache — 计算记忆
- 已处理 token 的 key/value 状态
- 加速生成，非人类可读
4. External Memory — 存储记忆
- 笔记、数据库、向量存储、Agent 记忆系统
- 必须检索并插入上下文才能使用
常见初学者错误
| 错误 | 真相 |
|---|---|
| 聊天更新模型 | 正常推理不训练模型 |
| KV Cache 存储事实 | KV Cache 存储注意力数据，不是语义记忆 |
| 更大上下文 = 完美记忆 | 更大上下文有帮助但不解决一切，且更贵 |
| 保存聊天 = 自动包含 | 保存的历史必须重载/摘要/检索后才能使用 |
| 模型忘了 = 模型坏了 | 通常是前端行为，不是模型问题 |
验证实验
- 新建聊天
- 告诉模型："我的项目代号是 Blue Lantern"
- 问："我的项目代号是什么？" → 应正确回答
- 继续长聊或粘贴大文档
- 再问："我的项目代号是什么？"
如果原始细节仍在上下文 → 正确回答。 如果掉出上下文/被摘要/会话重置 → 可能忘记。
一句话总结
- Weights 是模型学到的
- Context 是模型当前能看到的
- KV Cache 是运行时避免重复工作的
- External Memory 是另一个系统存储和检索的
不要把这些都叫"记忆"。它们行为不同、失败方式不同、消耗不同资源。