大模型的记忆和上下文有什么区别？为什么不能把历史一直塞进窗口？

简化版

上下文是本次推理可见的 token；记忆通常是系统在外部存储中保存、检索并注入的历史信息。一直塞历史会增加成本、稀释注意力、带来隐私风险，也可能让旧信息覆盖新指令。

详细版

• 模型权重里的知识不是用户会话记忆，推理时不会自动保存新事实。
• 短期上下文适合当前任务，长期记忆适合偏好、身份、项目事实等可复用信息。
• 长期记忆需要写入策略、检索策略、过期机制和用户可控性。
• 历史消息应摘要、筛选或检索，而不是无限追加。
• 敏感数据要有权限、脱敏和删除能力。

完整版教学

这道题考察候选人是否能区分模型能力、上下文管理和产品记忆系统。

一、这题真正考什么

这道题考察候选人是否能区分模型能力、上下文管理和产品记忆系统。

上下文是本次推理真正送进模型的 token；记忆是应用在请求之外保存、检索并决定是否写回上下文的信息。模型 API 本身通常无状态，所谓“记住用户”来自外部存储与拼装链路。

二、核心机制怎么工作

LLM 每次生成只基于当前输入上下文和模型参数。产品里说的“记忆”通常是数据库、向量库或用户画像，在下一次请求前被检索出来放回上下文。它提升连续性，但也引入召回错误、隐私合规和冲突处理问题。

短期历史可直接保留，长历史要摘要，跨会话偏好需结构化存储并设置来源、置信度和过期时间。读取记忆前做权限与相关性过滤，写入前区分稳定事实和一次性表达，用户纠正时建立新版本而非悄悄覆盖审计记录。

三、带数字的拆解

一个客服会话积累了 60000 token 历史，但当前模型有效预算只有 16000 token。系统可以保留最近 3000 token、检索 5 条相关长期记忆、再加一段 800 token 摘要，而不是原样塞入全部对话。

可用上下文 = 窗口上限 - 系统提示 - 工具描述 - 当前问题 - 输出预算
记忆命中率 = 被正确检索的有用记忆数 / 应被使用的记忆数
历史压缩率 = 摘要 token 数 / 原始历史 token 数

四、流程图和工程落点

可以把它拆成下面这条链路来讲：

用户新请求
   |
读取短期对话
   |
检索长期记忆
   |
冲突与权限过滤
   |
拼装上下文
   |
模型回答并按策略写回记忆

五、和相近方案怎么区分

概念	存放位置	生命周期
上下文	本次请求 token	一次推理
权重知识	模型参数	训练后长期存在
长期记忆	外部存储	按产品策略保留
摘要历史	会话状态	随对话更新

六、上线或训练时最容易踩的坑

• 旧记忆可能过期，使用前要允许新信息覆盖旧信息。

• 不要把敏感信息默认写入长期记忆，尤其是身份、财务和健康数据。

• 把模型生成的推测写成用户事实会形成自我强化错误，写入必须要求明确证据或用户确认。

• 多租户检索键缺少 tenant/user 约束会造成跨用户记忆泄露，这是数据隔离问题而非 Prompt 问题。

七、常见误区与追问

• 误区：模型聊过一次就会永久记住。 若应用没有把历史保存并在下次请求重新注入，模型不会跨 API 请求保留这段会话。
• 误区：把所有历史塞进上下文最可靠。 长历史会挤占预算、引入过期冲突并触发 lost-in-the-middle；应保留近期对话并检索相关记忆。
• 误区：向量检索出来的记忆一定相关。 相似度只表示表征接近，还要检查用户归属、时间有效性、事实来源与当前意图。
• 追问：长期记忆应该什么时候写入？ 只写稳定、未来可复用且有明确来源的信息；临时情绪、模型猜测和敏感数据默认不自动持久化。
• 追问：如何处理用户要求删除记忆？ 删除主存、向量索引和派生缓存，记录合规审计事件，并验证后续检索确实不再返回。
• 追问：记忆和 RAG 知识库有什么区别？ 记忆通常面向用户或会话且可变，知识库面向组织事实和文档；二者都需检索，但权限、生命周期和权威性不同。

八、加强记忆

记住“上下文是桌面，记忆是档案柜”。回答前从档案柜取必要材料放到桌面，桌面大小有限，档案也要能更新和清理。

上下文是“这次模型看见什么”，记忆是“应用长期保存什么、何时再给模型看”。答题时沿写入、存储、检索、冲突、删除五个环节说明责任边界。