开发人员认为，生成人工智能驱动的工具正在动态改进——从错误中学习，完善他们的知识，适应。但这不是它的运作方式。大型语言模型（LLM）在设计上是无状态的。除非外部系统提供先前的上下文，否则每个请求都会单独处理。
这意味着“内存”实际上并没有内置在模型中——它被分层在顶部，通常是不完美的。如果您使用ChatGPT很长时间，您可能已经注意到：
它在会议之间记住了一些事情，但完全忘记了其他事情。
即使您多次更正，它也会固定在过时的假设上。
它有时会在会话中“忘记”，丢掉关键细节。
这些不是模型的失败，而是内存管理的失败。
内存如何在LLM应用程序中工作
LLM没有持久内存。感觉像“内存”实际上是上下文重建，其中相关历史记录被手动重新加载到每个请求中。在实践中，像ChatGPT这样的应用程序在核心模型的顶部分层多个内存组件：
上下文窗口：每个会话都保留过去消息的滚动缓冲区。GPT-4o支持高达128K的代币，而其他型号有自己的限制（例如Claude支持20万个代币）。
长期记忆：一些高级细节在会话中持续存在，但保留不一致。
系统消息：隐形提示塑造了模型的响应。长期记忆通常以这种方式传递到会话中。
执行上下文：临时状态，如Python变量，仅在会话重置之前存在。
如果没有外部内存支架，LLM应用程序仍然是无状态的。每个API调用都是独立的，这意味着为了连续性，必须明确重新加载之前的交互。
为什么LLM默认是无状态的
在基于API的LLM集成中，模型在请求之间不保留任何内存。除非您手动传递之前的消息，否则每个提示都会被隔离解释。这是一个API调用OpenAI的GPT-4o的简单示例：
如果需要上下文连续性，每个请求都必须明确包含过去的消息。如果对话历史变得太长，您必须设计一个内存系统来管理它——否则可能会截断关键细节或坚持过时的上下文。
这就是为什么LLM应用程序中的内存经常感觉不一致的原因。如果过去的上下文没有正确重建，模型要么会坚持无关的细节，要么会丢失关键信息。
当LLM申请无法放手时
一些LLM应用程序存在相反的问题——不是忘记太多，而是记住错误的东西。你有没有告诉过ChatGPT“忽略最后一部分”，反正它以后才提出来？这就是我所说的“创伤记忆”——当LLM顽固地坚持过时或无关的细节，积极降低其有用性时。
例如，我曾经为一个项目测试过一个Python库，发现它没有用处，并告诉ChatGPT我删除了它。它承认了这一点——然后继续建议使用相同的弃用库的代码片段。这不是人工智能幻觉问题。这是糟糕的记忆检索。
人类学的克劳德提供了及时的缓存和持久的记忆，朝着正确的方向前进。Claude允许开发人员使用预先验证的标识符传递缓存的提示片段以提高效率——从而降低请求之间的重复，并使会话结构更加明确。
但是，虽然缓存提高了连续性，但它仍然留下了更广泛的挑战未解决：应用程序必须管理哪些工作内存中保持活动，哪些内容降级到长期存储，以及哪些内容完全丢弃。Claude的工具很有帮助，但它们只是开发人员需要构建的控制系统的一部分。
真正的挑战不仅仅是增加记忆力——而是设计更好的遗忘。
更聪明的记忆需要更好的遗忘
人类的记忆不仅仅是关于记忆——它是选择性的。我们根据相关性过滤细节，将正确的信息移动到工作内存中，同时丢弃噪音。LLM应用程序缺乏这种能力，除非我们明确地为它设计。目前，LLM的内存系统分为两类有缺陷的类别：
- 无状态人工智能：除非手动重新加载，否则完全忘记过去的交互。
- 内存增强人工智能：保留一些信息，但在没有优先级概念的情況下修剪错误的细节。
- 为了构建更好的LLM内存，应用程序需要：
- 上下文工作记忆：通过消息总结和选择性调用主动管理会话上下文，以防止令牌溢出。
- 持久记忆系统：长期存储，根据相关性检索，而不是原始转录。许多团队使用基于矢量的搜索（例如，过去消息的语义相似性），但相关性过滤仍然很弱。
- 注意力记忆控制：一个优先考虑有用信息，同时淡化过时细节的系统。如果没有这个，模型要么会坚持旧数据，要么会忘记必要的更正。
示例：编码助手在多次更正后应停止建议弃用的依赖项。
目前的人工智能工具无法通过，因为它们要么：
- 忘记一切，迫使用户重新提供上下文，或者
- 保留太多，浮出水面无关或过时的信息。
缺失的一块不是更大的记忆——而是更聪明的遗忘。
GenAI内存必须变得更智能，而不是更大
仅仅增加上下文窗口大小并不能解决内存问题。LLM申请需要：
- 选择性保留：仅存储高相关性知识，而不是整个对话记录。
- 注意力检索：优先考虑重要细节，同时淡化旧的、无关的细节。
- 遗忘机制：过时或低值的细节应该会随着时间的推移而衰减。
下一代人工智能工具不会是能记住一切的工具。他们会知道要忘记什么。构建LLM应用程序的开发人员应该从塑造工作记忆开始。在上下文层设计相关性，即使持久内存会随着时间的推移而扩展。
