拆解LLM的"记忆"机制：本质只是上下文投喂

一个反直觉的真相：大模型根本没有记忆

很多人在使用 ChatGPT、Claude 等大语言模型时，都有一个隐含的假设：模型"记得"我们之前聊过什么。但真相恰恰相反——LLM 本身没有任何记忆能力。

你有没有注意到，AI 似乎能记住你上一条消息，但只要开一个新窗口，它就把一切都忘光了？这个现象揭示了一个关键事实：对模型来说，每一次回复都像是第一次见到你。它既不知道你是谁，也不记得刚才发生了什么。

这篇文章基于一位正在学习 LLM 应用开发的开发者在 Reddit 上分享的学习笔记，用通俗的方式拆解了"记忆"这个概念的本质，并给出了工程实践中的解决思路。

reddit source

两种记忆类型：LLM有一种，缺一种

要理解为什么 LLM "没有记忆"，需要先区分两种截然不同的记忆类型。

参数记忆：训练阶段固化的静态知识

参数记忆（Parametric Memory）是在训练阶段就固化进模型权重里的知识。比如"巴黎是法国的首都"、"水的化学式是 H₂O"这类通用事实。模型确实拥有这类记忆，它们被编码在数十亿甚至上万亿的参数当中。

从技术本质来看，参数记忆的底层机制是神经网络的权重矩阵。在训练过程中，模型通过反向传播算法不断调整这些浮点数参数，将海量文本中的统计规律编码为权重值。这个过程类似于人类通过反复学习将知识内化为长期记忆。以 GPT-4 为例，其参数量据估计超过万亿级别，训练数据覆盖了截止日期之前的大量互联网文本、书籍和学术论文。

但要注意，参数记忆是静态的、只读的。训练完成后，这些知识就不会因为你和它的对话而更新——除非进行微调（Fine-tuning）或持续预训练（Continual Pre-training），而这两者都需要额外的训练流程和计算资源。这也是为什么模型会有"知识截止日期"的原因。

情景记忆：LLM完全不具备的能力

情景记忆（Episodic Memory）是指记住"你刚才说你叫王"这类当下发生的具体事件。而这恰恰是 LLM 完全不具备的能力。

每一次 API 调用都是独立且失忆的（independent and amnesiac）。模型之所以能"接着聊"，唯一的原因是：你每次都把过去的对话作为"小抄"重新递给了它。换句话说，所谓的对话记忆，本质上是应用层不断地把历史上下文重新喂给模型。

对话记忆的三个工程演进阶段

原作者用一个循序渐进的"小抄"比喻，清晰地展示了如何在工程上构建对话记忆。

阶段 0：零记忆状态——没有任何上下文

llm.invoke("What's my name?")
# → "I don't know."

即便你上一秒才说了自己的名字，模型也答不出来——因为在两次独立调用之间，没有任何信息被携带。这就是 LLM 的"出厂默认状态"。

阶段 1：发送全部历史——朴素但有效的做法

messages = [
    HumanMessage("My name is Wang"),
    AIMessage("Hi Wang!"),
    HumanMessage("What's my name?")
]
llm.invoke(messages)
# → "Your name is Wang."

这下能用了！但问题也随之而来：对话越长，小抄越厚。这带来三个直接后果——调用成本更高、响应速度更慢，并且最终会超出模型的上下文窗口限制（context limit）。

这里有必要解释一下上下文窗口的技术背景。上下文窗口（Context Window）是指模型在一次推理中能处理的最大 token 数量。Token 是模型处理文本的最小单位，一个英文单词通常对应 1-2 个 token，一个中文字通常对应 1-2 个 token。早期的 GPT-3.5 上下文窗口仅有 4096 个 token（约 3000 个英文单词），而 GPT-4 Turbo 扩展到了 128K token，Claude 3 则达到了 200K token。上下文窗口受限于 Transformer 架构中自注意力机制的计算复杂度——标准自注意力的计算量与序列长度的平方成正比，这意味着上下文翻倍，计算成本大约增长四倍。此外，API 调用通常按 token 数量计费，上下文越长意味着每次调用的成本越高。

对于一个真实的生产级应用来说，这种朴素做法显然无法长期维持。

阶段 2：上下文压缩——真正的工程智慧

真正的工程智慧在于：如何在不丢失关键信息的前提下压缩上下文。原作者给出了三种常见的上下文压缩策略：

1. 裁剪（Trim）——只保留最近的若干条消息：

trim_messages(messages, max_tokens=100, strategy="last")

2. 过滤（Filter）——丢弃无关或噪声消息，只留下有价值的内容。

3. 摘要（Summarize）——把久远的对话压缩成一句话：

def should_continue(state):
    if len(state["messages"]) > 6:
        return "summarize"
    return END

通过摘要，几十轮对话可以被压缩成"用户叫王，正在咨询退货问题"这样一张便利贴，而不再是一整本书。结果就是：更便宜，同时依然记得住关键信息。

这三种压缩策略各有适用场景，值得深入理解。裁剪策略最简单直接，适合闲聊类场景，因为最近的对话通常最相关；但在需要引用早期关键信息的场景（如法律咨询中开头提到的案件编号）就会丢失重要上下文。过滤策略需要设计判断标准来区分"有价值"和"噪声"消息，可以基于规则（如过滤掉纯寒暄语句）或基于语义相似度来实现。摘要策略最为智能，它本身就利用 LLM 来生成对话摘要，但这引入了额外的 API 调用成本和延迟，而且摘要过程本身也可能丢失细节。在实际生产中，工程师往往会组合使用这三种策略——比如对最近 5 轮保留原文，对更早的对话生成摘要，对寒暄内容直接过滤。LangChain、LlamaIndex 等主流 LLM 应用框架都内置了这些记忆管理组件。

记忆不是模型能力，而是上下文管理的工程问题

这个视角对 LLM 应用开发者极具启发性。它把"记忆"从一个模糊的"模型是否智能"的问题，转化为一个清晰的上下文管理工程问题。

一旦理解了这一点，很多产品设计上的困惑就迎刃而解了：

为什么长对话会突然"忘记"开头说过的话？——因为超出上下文窗口后，早期消息被裁剪掉了。
为什么同样的问题在新会话里得到完全不同的回答？——因为新会话没有任何"小抄"。
为什么有些 AI 产品需要精心设计"系统提示词"？——因为这是模型每次都能看到的"永久小抄"。

真正的技术难点，从来不是让模型"拥有记忆"，而是在有限的上下文预算内，决定哪些信息值得保留、如何高效压缩。这也是 RAG（检索增强生成）、向量数据库等技术流行的底层逻辑——它们本质上都是更智能的"小抄管理系统"。

RAG（Retrieval-Augmented Generation，检索增强生成）是 2020 年由 Facebook AI Research 提出的架构范式，其核心思想是：不把所有知识都塞进上下文，而是在需要时从外部知识库中检索最相关的片段，再注入到提示词中。这个过程依赖向量数据库（如 Pinecone、Weaviate、Milvus 等）来实现高效的语义检索。具体流程是：首先将文档切片并通过嵌入模型（Embedding Model）转化为高维向量存储在向量数据库中；当用户提问时，将问题同样转化为向量，通过近似最近邻搜索（ANN）找到语义最相关的文档片段；最后将这些片段拼接到提示词中供模型参考。这种方式既解决了上下文窗口有限的问题，也解决了参数记忆无法更新的问题——只需更新向量数据库中的文档即可。

下一步挑战：跨会话的长期记忆方案

本文讨论的都是单次会话内的短期记忆管理。而更进一步的挑战是长期记忆：如何让 AI 在不同的会话之间也能记住你？

这就需要引入外部存储机制——比如将用户画像、历史偏好持久化到数据库，并在合适的时机检索出来注入到上下文中。这正是当前诸多 AI 助手产品竞相攻克的方向。

目前跨会话长期记忆的主流技术方案包括三大类。第一类是用户画像持久化，将对话中提取的用户偏好、基本信息等结构化数据存入关系型数据库或键值存储中。第二类是记忆向量化，将重要的对话片段转化为向量存储在向量数据库中，在新会话开始时通过语义检索注入相关历史记忆。第三类是知识图谱方式，将对话中的实体和关系提取出来构建图谱，实现更精确的记忆检索。OpenAI 在 2024 年为 ChatGPT 引入的 Memory 功能、Google Gemini 的记忆系统，以及开源框架 Mem0 等，都在探索这个方向。核心挑战在于：如何自动判断哪些信息值得长期记忆、如何处理记忆冲突（例如用户更新了个人信息）、以及如何在隐私保护和个性化服务之间取得平衡。

结语

模型没有记忆，所谓的"记忆"只是我们喂给它的上下文。 放任不管，它就会溢出；因此真正的技能，是在不丢失关键信息的前提下压缩这张小抄。

对于每一位 LLM 应用开发者而言，把"记忆"理解为可控的工程变量，而非黑盒里的神秘能力，是构建可靠 AI 应用的第一步。