LLM记忆：写入正确只是起点，使用阶段才是成败关键

在开发基于大模型（LLM）的 Agent、RAG 或对话应用时，几乎所有人都会遇到“记忆”这个话题。早期做记忆模块，大家最关心的是怎么把用户偏好、历史对话、领域知识写进向量库，只要写入成功就会觉得大功告成。但真正上线跑一段时间后你会发现，最隐蔽、最头疼的问题往往不是“写入时报错”，而是写入时一切正常，到了后续检索、注入、生成阶段才突然暴露问题。本文就从 LLM memory 系统的完整链路出发，结合一个最小可运行的 Python 项目，复盘这类“之后才出错”的典型场景，并给出可落地的排查思路和工程建议。

1. 背景与核心概念

1.1 LLM memory 到底是什么

大模型的上下文窗口是有限的，模型本身也不具备跨会话的持久记忆能力。每次请求结束后，模型并不会“记得”上一次对话的内容。为了让 LLM 应用更像一个长期陪伴的助手，我们就需要在模型外部搭建一套记忆系统。

用计算机体系结构来类比会更直观。缓存（Cache）负责短期高频数据，内存（DRAM）负责当前进程的运行数据，磁盘负责长期持久化。LLM memory 也是类似的思路：

• 短期记忆：当前会话内的上下文，放在 Prompt 中或会话缓存中。
• 中期记忆：当前任务中的中间状态，例如 Agent 的工具调用结果、子任务上下文。
• 长期记忆：跨会话的用户画像、业务知识、历史偏好，通常会落到向量数据库、关系型数据库或知识图谱中。

我们通常说的“给 LLM 加记忆”，重点是指长期记忆部分：从对话或业务数据中抽取信息，保存到外部存储，并在合适的时机把相关信息重新注入 Prompt。

1.2 一套完整记忆系统的通用链路

一个生产可用的 LLM memory 模块，至少包含以下环节：

1. 提取（Extract）：从用户消息、助手回复或工具结果中，抽取出值得记住的信息。
2. 存储（Store）：将提取出的信息做向量化，写入向量库，同时保存时间戳、来源、置信度等元数据。
3. 检索（Retrieve）：在后续对话中，根据当前 Query 从向量库中召回相关记忆。
4. 注入（Inject）：将召回结果拼接进 Prompt，作为模型生成的上下文。
5. 更新（Update）：当旧记忆被新信息覆盖时，需要做更新或标记过期。
6. 遗忘（Forget）：对长期未使用、已失效或敏感的记忆，需要归档或清理。

很多人开发记忆模块时，把 80% 的精力放在第 1、2 步，也就是“写入”这一侧。但真正影响线上效果的，往往是第 3 到第 6 步，也就是“使用”这一侧。

1.3 本文核心观点：写入正确只是起点

标题“LLM memory doesn't only get written wrong, it goes wrong later”想表达的就是：记忆系统的问题不只发生在写入阶段，大量故障是在写入成功之后，因为检索条件变化、记忆冲突、上下文污染、存储规模膨胀等原因才爆发出来的。

本文会用一个非常轻量的演示项目，把“写入时看似没问题，使用阶段却出现问题”的场景完整复现出来，方便后续系统性地排查和规避。

2. 为什么“写入没问题，使用阶段才出问题”

2.1 写入侧与使用侧的判断标准不一样

写入阶段，系统判断的是“这条文本是否符合格式、能否写入向量库”。只要 embedding 成功、数据库写入成功，就算完成。

使用阶段，系统判断的是“这条记忆是否能在合适时机被合适地召回，并在注入 Prompt 后帮助模型生成正确结果”。这涉及向量检索的命中率、记忆之间的优先级、Prompt 的容错能力等。

这两套标准天然存在偏差。写入时你觉得“内容已经存进去了”，但使用时不代表能查得到、查得准、用得上。

2.2 五大典型故障模式

结合我在 LLM 应用开发中看到的常见问题，可以把“写入之后才出错”归纳为五类：

下面分别展开说明。

2.2.1 语义鸿沟

向量检索的核心思想是“语义相似”。但 embedding 模型对措辞非常敏感。用户写入时说“我喜欢使用 Vim 编辑器”，后续检索时问“我适合用什么工具写 Python？”，这两句话在语义上有一定关联，但向量距离可能并不近。

如果检索阈值设得比较高，或者 Top-K 设置得比较小，这条记忆很可能根本不会被召回。问题不是写入错误，而是使用阶段的 Query 与写入文本存在表达差异。

2.2.2 记忆冲突

很多记忆系统在写入新记忆时，并不会主动删除或覆盖旧记忆。用户某天说“我喜欢使用 Vim 编辑器”，过几天又说“我现在改用 VS Code 了”。如果系统只是不断追加，没有做实体级别的更新，那么这两条记忆会同时存在于向量库中。

当后续 Query 是“用户最近喜欢用什么编辑器”时，两条记忆都会被召回。如果 Prompt 没有设计冲突消解机制，LLM 就不知道该信哪一条，最终可能给出模棱两可或错误的回答。

2.2.3 上下文污染

比检索不到更隐蔽的问题是“检索到了不该检索的东西”。如果 min_score 阈值过低，任何擦边内容都会被注入 Prompt。模型会把不相关的历史信息当成事实背景，从而生成看似合理、实则错误的回答。

2.2.4 记忆膨胀

长期运行的系统如果没有遗忘机制，记忆会无限增长。每一次检索都涉及向量计算，注入时也会占用越来越长的 Token 窗口。注意力机制在超长上下文中会退化，真正重要的信息可能被大量无关记忆淹没。

2.2.5 版本漂移

embedding 模型升级、向量库索引参数调整、ChromaDB 或 Milvus 版本变更，都可能导致同样的文本在不同环境下生成不同向量，或距离分布发生变化。写入时一切正常，升级后查询结果却变了。这属于比较隐蔽的工程问题。

3. 一个最小可运行的 LLM Memory 项目

为了直观复现上面的问题，我们用 Python + ChromaDB 做一个极简的记忆引擎。ChromaDB 是轻量级向量数据库，支持持久化存储，默认带 embedding 功能，非常适合快速验证思路。

3.1 项目结构

llm-memory-demo/ ├── requirements.txt ├── memory_engine.py └── demo.py

3.2 依赖准备

创建requirements.txt：

chromadb>=0.4.0

安装依赖：

pip install -r requirements.txt

说明：ChromaDB 会自动下载默认的 embedding 模型，第一次运行会拉取模型文件，需要保持网络畅通。

3.3 记忆引擎代码

创建memory_engine.py，实现一个简化版记忆引擎，包含写入、存储、检索、上下文构建四个核心方法。

# 文件路径：llm-memory-demo/memory_engine.py import re import time import uuid from enum import Enum from typing import Any, Callable, Dict, List, Optional import chromadb def default_llm_callback(prompt: str) -> str: """ 默认的 LLM 回调函数。 实际项目中可以替换成任意兼容 OpenAI 协议的调用，例如： from openai import OpenAI client = OpenAI() def llm_callback(prompt: str) -> str: resp = client.chat.completions.create( model="gpt-4o-mini", messages=[{"role": "user", "content": prompt}] ) return resp.choices[0].message.content 本文示例为了可运行，默认返回空字符串。 """ return "" class MemoryStatus(str, Enum): ACTIVE = "active" PENDING = "pending" ARCHIVED = "archived" class MemoryRecord: """单条记忆的记录结构""" def __init__( self, content: str, source: str, created_at: float, updated_at: float, status: MemoryStatus = MemoryStatus.ACTIVE, confidence: float = 0.8, extra: Optional[Dict[str, Any]] = None, ): self.id = str(uuid.uuid4()) self.content = content self.source = source self.created_at = created_at self.updated_at = updated_at self.status = status self.confidence = confidence self.extra = extra or {} def to_dict(self) -> Dict[str, Any]: return { "id": self.id, "content": self.content, "source": self.source, "created_at": self.created_at, "updated_at": self.updated_at, "status": self.status.value, "confidence": self.confidence, "extra": self.extra, } class MemoryEngine: """ 一个带向量存储的简化记忆引擎。 它负责写入（extract + store）与读取（retrieve + inject）。 """ def __init__( self, collection_name: str = "llm_memory", persist_directory: str = "./chroma_memory_db", llm_callback: Optional[Callable[[str], str]] = None, ): self.client = chromadb.PersistentClient(path=persist_directory) self.collection = self.client.get_or_create_collection( name=collection_name, metadata={"hnsw:space": "cosine"}, ) self.llm_callback = llm_callback or default_llm_callback # ---------- 写入侧 ---------- def extract_memory(self, user_message: str, assistant_message: str) -> List[MemoryRecord]: """ 从一段对话中提取结构化记忆。 真实项目中应使用 LLM + Prompt 完成。 这里提供基于规则的简化实现，方便演示流程。 """ records = [] user_text = user_message.strip() # 规则：提取“我喜欢使用 XXX”这类偏好 pref_match = re.search(r"我喜欢(?:使用|用)?\s*([\u4e00-\u9fa5A-Za-z0-9]+)", user_text) if pref_match: item = pref_match.group(1) content = f"用户的偏好：喜欢使用 {item}" records.append( MemoryRecord( content=content, source="rule_extract", created_at=time.time(), updated_at=time.time(), confidence=0.7, ) ) return records def store_memory(self, records: List[MemoryRecord]) -> List[str]: """ 将记忆写入向量库。 这里直接写入文本和元数据，ChromaDB 负责生成向量。 """ ids = [] docs = [] metadatas = [] for rec in records: ids.append(rec.id) docs.append(rec.content) metadatas.append(rec.to_dict()) if not ids: return [] self.collection.upsert( ids=ids, documents=docs, metadatas=metadatas, ) return ids def add_conversation(self, user_message: str, assistant_message: str) -> List[str]: """ 完整写入流程：对话 -> 提取记忆 -> 向量化存储。 """ records = self.extract_memory(user_message, assistant_message) return self.store_memory(records) # ---------- 读取侧 ---------- def retrieve_memory( self, query: str, top_k: int = 3, min_score: float = 0.5, include_archived: bool = False, ) -> List[Dict[str, Any]]: """ 检索记忆。 注意：ChromaDB 默认使用 cosine 距离，distance 越小表示越相似。 这里用 score = 1 - distance 换算成“得分”，便于理解阈值。 score 越高表示越相似。 """ result = self.collection.query( query_texts=[query], n_results=top_k, ) retrieved = [] for i in range(len(result["ids"][0])): doc_id = str(result["ids"][0][i]) doc = str(result["documents"][0][i]) distance = float(result["distances"][0][i]) meta = result.get("metadatas") meta = meta[0][i] if meta else {} # distance 越小越相似，转成得分 score = 1 - distance if score < min_score: continue if not include_archived and meta.get("status") == "archived": continue retrieved.append( { "id": doc_id, "content": doc, "score": round(score, 4), "created_at": meta.get("created_at"), "updated_at": meta.get("updated_at"), "confidence": meta.get("confidence"), } ) return retrieved def build_context(self, query: str, top_k: int = 3) -> str: """ 将检索到的记忆拼接成 Prompt 上下文片段。 """ memories = self.retrieve_memory(query=query, top_k=top_k) if not memories: return "" parts = [] for m in memories: parts.append(f"- {m['content']} (相关度 {m['score']}, 更新时间 {m['updated_at']})") return "\n".join(parts)

3.4 演示脚本代码

创建demo.py，用来模拟“写入成功、使用阶段出问题”的几个典型场景。

# 文件路径：llm-memory-demo/demo.py from memory_engine import MemoryEngine def main(): engine = MemoryEngine() # ---------- 第 1 轮：正常写入 ---------- print("=" * 60) print("[第 1 轮] 用户告知偏好：我喜欢使用 Vim 编辑器") print("=" * 60) ids = engine.add_conversation( user_message="我喜欢使用 Vim 编辑器", assistant_message="好的，已记录你的编辑器偏好。", ) print(f"写入成功，记忆 ID: {ids}") print() # 直接用几乎相同的话 Query，看是否能检索到 same_query = "用户的编辑器偏好是什么？" memories = engine.retrieve_memory(query=same_query, top_k=5, min_score=0.2) print(f"使用高度相似的 Query「{same_query}」检索：") if memories: for m in memories: print(f" -> {m['content']} (score={m['score']})") else: print(" -> 没有检索到任何记忆") print() # ---------- 第 2 轮：换一种问法 ---------- print("=" * 60) print("[第 2 轮] 几天后，用户询问：我适合用什么工具写 Python？") print("=" * 60) query2 = "我适合用什么工具写 Python？" memories2 = engine.retrieve_memory(query=query2, top_k=5, min_score=0.3) print(f"使用 Query「{query2}」检索：") if memories2: for m in memories2: print(f" -> {m['content']} (score={m['score']})") else: print(" -> 没有检索到任何记忆。") print(" 原因：Query 与已存记忆的向量距离较远，被阈值过滤掉了。") print() # ---------- 第 3 轮：新增一条冲突记忆 ---------- print("=" * 60) print("[第 3 轮] 用户又告知：我现在改用 VS Code 了") print("=" * 60) engine.add_conversation( user_message="我现在改用 VS Code 了", assistant_message="明白，已更新你的工具偏好。", ) print("已写入新记忆。注意：旧记忆没有被删除。") print() query3 = "用户的编辑器偏好是什么？" memories3 = engine.retrieve_memory(query=query3, top_k=10, min_score=0.2) print(f"使用 Query「{query3}」再次检索：") for m in memories3: print(f" -> {m['content']} (score={m['score']}, updated_at={m['updated_at']})") print("问题：新旧两条记忆同时被召回，如果 Prompt 不处理冲突，LLM 会困惑。") print() # ---------- 第 4 轮：把检索结果注入 Prompt ---------- print("=" * 60) print("[第 4 轮] 观察注入后的 Prompt 上下文") print("=" * 60) context = engine.build_context(query="用户喜欢什么编辑器", top_k=10) print("构建出的上下文片段：") print(context if context else "（空）") print() print("=" * 60) print("复盘：写入阶段全部成功，问题全部出现在后续检索/使用阶段。") print("=" * 60) if __name__ == "__main__": main()

4. 运行演示：复现“之后才出错”

4.1 运行步骤

在llm-memory-demo目录下执行：

python demo.py

第一次运行会下载默认的 embedding 模型，需要等待片刻。之后每次运行会复用本地模型文件和 ChromaDB 持久化数据。

4.2 预期现象：第一阶段正常

第 1 轮中，系统从“我喜欢使用 Vim 编辑器”中提取出“用户的偏好：喜欢使用 Vim”，并成功写入向量库。用“用户的编辑器偏好是什么？”这种高度相似的 Query 去检索，能够正常召回。

这个阶段看起来一切正常，很多开发者在本地验证到这里就认为记忆模块已经没问题了。

4.3 预期现象：换一种问法，检索失败

第 2 轮是关键。用户真实场景中不一定会用与存储文本高度相似的措辞，而是会问“我适合用什么工具写 Python？”。

这时检索结果可能为空。原因不是写入失败，而是：

• Query 与记忆文本的语义距离较远；
• min_score 阈值把低分结果过滤掉了；
• Top-K 不足，或者 embedding 模型没有把“编辑器”和“写 Python 工具”识别为强相关。

这就是典型的“写入正确，使用才出错”。真实业务中，用户问法千变万化，如果只依赖单轮向量检索，召回率会非常不稳定。

4.4 预期现象：冲突记忆同时被召回

第 3 轮模拟了用户更换偏好的场景。系统把“喜欢使用 Vim”和“改用 VS Code”两条记忆都写入了向量库，但没有做覆盖或过期处理。

当再次检索“用户的编辑器偏好是什么？”时，两条记忆会同时出现。此时如果直接把两条记忆都塞进 Prompt，LLM 无法判断哪一条是用户当前的真实偏好，轻则回答模棱两可，重则给出过时信息。

4.5 预期现象：上下文被无效或冲突信息填充

第 4 轮把检索结果拼成上下文片段。你会发现：

• 召回的条目越多，上下文越长；
• 冲突条目越多，模型越难判断；
• 低相关度条目进入上下文后，还会带来噪声。

这提醒我们：记忆不是“存得越多越好”，而是“用得越准越好”。

5. 常见问题与排查清单

排查顺序建议：

1. 先确认写入是否真的成功：查询向量库中是否包含该条记录。
2. 再确认检索能否命中：用原始写入文本作为 Query 测试。
3. 然后换多种同义问法测试，观察召回分数变化。
4. 最后检查注入的 Prompt 中实际拼入了哪些记忆，判断上下文是否被污染。

6. 工程最佳实践

6.1 记忆写入时就要为“未来使用”设计

写入时不能只存一段孤立的文本，要尽量保存元数据：

• 创建时间、更新时间；
• 来源会话 ID、来源用户 ID；
• 置信度；
• 实体 ID（例如用户 ID、偏好主题 ID）；
• 记忆状态（active / pending / archived）。

有了实体 ID 和更新时间，后续更新和冲突消解才有依据。

6.2 使用状态机管理记忆更新

不要把“更新”简单理解成 upsert。更可靠的做法是为每条记忆维护一个状态机：

pending（待确认） -> active（生效） -> archived（归档）

当新信息覆盖旧信息时，不是直接删除旧记忆，而是把旧记忆标记为 archived，写入新的 active 记忆。检索时优先返回 active 记忆，只有用户确认后才展示历史记录。这样既保留历史可追溯性，又避免冲突信息同时干扰模型。

6.3 检索侧要设计多路召回与排序

单靠向量检索远远不够。推荐的检索链路是：

1. 多路召回：向量检索 + 关键词检索（BM25）+ 规则召回（例如用户 ID 精确匹配）。
2. 分数融合：对多路召回结果做分数归一化。
3. 二次排序：用轻量 Rerank 模型或规则，对候选记忆做相关性重排。
4. 阈值控制：严格按照业务场景调整 min_score，避免引入过多噪声。

6.4 Prompt 注入侧要做防护

即使检索结果不完美，Prompt 侧也要留好后路：

• 在上下文片段中标注每条记忆的时间和置信度；
• 告诉模型“以下历史信息仅供参考，以用户最新表达为准”；
• 当检索结果为空或分数过低时，允许模型明确回答“我不知道”。

例如：

以下是该用户的历史记忆，可能已过时，仅供回答参考： - 用户偏好：喜欢使用 Vim（更新时间：2024-01-01） - 用户偏好：改用 VS Code（更新时间：2024-03-01） 如果历史记忆与用户当前表达冲突，请以用户当前表达为准。

6.5 建立记忆生命周期管理

记忆不是永久有效的资产，需要设置生命周期：

• 短期偏好类记忆：例如用户临时选择的工具，保存几天即可。
• 长期画像类记忆：例如用户的固定身份信息，可以长期保存。
• 敏感信息类记忆：需要定期清理或脱敏。

可以用定时任务扫描 archived 状态、超过 TTL 的记录，定期归档或删除。

6.6 增加可观测性与用户纠错机制

给记忆系统加日志和可视化界面，至少能回答以下问题：

• 当前用户有多少条记忆？
• 每次请求实际召回了哪些记忆？
• 召回分数是多少？
• 最后更新时间是什么时候？

同时提供“记忆管理”入口，让用户能查看、删除或修改系统记住的信息。这不仅是体验问题，也关系到数据合规。

7. 具备生产心智后再动手

LLM memory 绝不是一个“向量库 + 一个 upsert”就能解决的问题。写一条记忆只需要几行代码，但让记忆在正确的时间、以正确的形式、帮助模型生成正确的结果，才是真正的挑战。

如果你接下来要接手或设计 LLM 记忆模块，建议按这个顺序推进：

1. 先理清业务需要“记什么”，不要什么信息都往向量库里塞。
2. 设计好元数据 Schema，从第一天就带上时间和状态字段。
3. 把检索结果沉淀成日志，观察线上真实的召回命中率。
4. 逐步引入多路召回、冲突消解、遗忘机制。

每次遇到“写入成功但结果不对”的问题，不要急着改 embedding 模型，先确认检索和注入阶段是否有问题。大部分“后来才出错”的 bug，根源都在使用侧。

如果这篇文章对你有帮助，可以收藏备用。接下来可以继续关注 LLM Agent 编排、RAG 混合检索、以及面向生产环境的记忆评估方案，这几个方向结合记忆系统会非常有意思。