为什么只靠向量检索做不好长期记忆
摘要
过去很多 LLM 应用把 memory 做成了“历史文本切块 + 向量检索 + prompt 拼接”。这套方案可以解决语义搜索，但解决不了长期记忆。
长期记忆真正难的不是“能不能找回相似文本”，而是系统能不能持续判断信息属于谁、能不能把当前事实和历史事实分开、能不能维护更新和冲突关系、能不能在回答时给出证据链。
InsightMemory 的核心判断是：AI 应用的下一层基础设施，不会只是更大的 context window，也不会只是更强的 embedding，而是一套能理解、组织、演进和追溯的 memory layer。
正文
很多 LLM 应用在做 memory 时，第一反应是把历史对话、文档、日志切成 chunk，然后放进向量数据库。查询时再用 embedding 找相似内容，最后把召回片段塞回 prompt。
这套方法很适合语义搜索，但它和“长期记忆”之间还有明显距离。
长期记忆不只是把过去的文本找回来。真正难的是：系统能不能判断一条信息属于谁，能不能知道新事实是在更新旧事实还是补充旧事实，能不能把当前状态和历史状态分开，能不能在回答时说明证据来自哪里。
如果这些问题没有被建模，memory 很容易变成一个越来越大的文本池。
短期看，这样的系统会让人觉得“记住了很多”。长期看，它只是把越来越多的旧事实、过期状态、冲突版本和错误归属一起塞回 prompt。Agent 不是更聪明了，而是被更多噪音包围了。
向量记忆的典型问题
纯向量记忆通常有几个明显短板。
第一，同名主体容易混淆。比如 Atlas 可能是一个发布项目，也可能是一份知识文档。向量检索只看文本相似度时，很容易把两个主体的事实召回到同一个答案里。
第二，当前事实和历史事实容易混在一起。一个规则以前允许 24 小时内补录，后来改成必须先审批。如果系统只保存文本片段，那么查询“现在要求什么”时，历史规则也可能被当成当前答案。
第三，更新关系不可见。新信息到底是覆盖旧信息、补充旧信息、冲突旧信息，还是只是并存事实？如果没有显式关系，系统只能把所有内容都追加进去。
第四，why/how 问题很难回答。用户问“为什么不能切换模板”，答案可能需要同时召回 blocker 和外部 checklist。这不是简单相似度能稳定解决的问题。
第五，证据链不稳定。很多系统能给出一个“像是对的”答案，但很难追溯到原始 observation、历史变化和支持关系。
这五个问题加起来，说明 vector memory 不是“不够好”，而是模型层次不够。它解决的是 retrieval，不是 memory model。真正的长期记忆系统需要把 identity、state、history、relation 和 evidence 都纳入设计。
更大的 context 不能替代 memory
很多人会觉得，既然模型上下文越来越大，长期记忆是不是可以直接靠大窗口解决。
我认为恰恰相反：context 越大，memory 越重要。
大 context 解决的是“能塞进去多少材料”，memory 解决的是“哪些材料应该被组织成长期经验”。没有 memory 层，大 context 只会让系统更容易把无关、过时、冲突的信息一起塞进去。
长期运行的 Agent 不缺材料，它缺的是一套能持续整理材料的认知结构。
长期记忆需要什么
我做 InsightMemory 时，把长期记忆拆成几个稳定对象：
entity：这条记忆属于谁。memory：系统关于这个主体沉淀出的稳定事实、状态、规则或结论。observation：原始输入证据，只追加，不把它当成可变真相。edge：memory 之间的关系，比如 update、support、conflict、derivation。
这意味着写入时不只是“存文本”，而是让 LLM 参与理解：
- 输入里有哪些稳定主体；
- 每条候选记忆应该挂到哪个主体；
- 新旧记忆之间是什么关系；
- 哪些原始 observation 支撑了这条 memory。
召回时也不只是“找相似片段”，而是先解析目标 entity，再从该主体的 memory 和关联 edge 中组织答案。
一个真实评测里的简单例子
写入两条记忆：
Atlas 是发布项目，当前主阻塞是数据库迁移失败。
Atlas 是知识文档，当前缺少回滚说明。
评测查询：
Atlas 发布项目 当前主阻塞是什么？
评测要求答案必须包含 数据库迁移失败，并且不能混入 回滚说明。也就是说，系统必须把 Atlas 发布项目 和 Atlas 知识文档 拆成两个 entity，而不是因为它们都叫 Atlas 就混在一起。
这个 case 在多个评测报告里跑通过，例如 default_matrix_high_concurrency_v1_generic 和 same_name_live_v4。它验证的不是“能不能搜到 Atlas”，而是“能不能在同名主体中保持正确归属”。
InsightMemory 的思路
InsightMemory 的定位不是替代所有 RAG，而是补上长期记忆层。
它把 LLM 用在理解和组织记忆上，把数据库用于持久化 identity、memory、evidence、relation 和 history。这样做的目标是让系统具备几个能力：
- 同名 entity 隔离；
- 当前态和历史态并存；
- 新信息可以更新、补充、冲突或支持已有 memory；
- 召回时可以沿 memory edge 找到相关上下文；
- 答案可以返回 citation 和 observation 证据链。
这也是为什么我认为长期记忆不应该被简化成“向量库加 prompt”。向量检索是重要组件，但它不是完整的 memory model。
更直接地说，InsightMemory 想做的是 AI 应用的持续认知层。它不是把过去的文本临时找回来，而是把长期交互中出现的主体、事实、状态、规则、证据和关系沉淀成可维护的记忆网络。
这层能力一旦稳定，Agent 才有机会从“每次都很聪明”升级为“越用越理解你的世界”。
适合哪些开发者关注
如果你的应用只是一次性文档问答，普通 RAG 可能已经够用。
但如果你在做下面这些系统，长期记忆会很快变成核心问题：
- 需要持续记住用户偏好和任务状态的个人 Agent；
- 需要长期跟踪项目、规则、事故和决策的企业 Copilot；
- 需要区分同名公司、文档、项目和策略的知识系统；
- 需要回答 current、historical、why 和 how 的研究助手；
- 需要给出 citation、支持审计和调试的严肃 AI 应用。
这些场景的共同点是：它们不只是“查资料”，而是在运行过程中不断形成经验。
小结
RAG 解决的是“从材料里找信息”。长期记忆要解决的是“系统如何持续理解、组织、维护和召回自己的经验”。
如果你的 Agent 只需要临时查资料，向量检索可能已经够用。如果你希望它长期记住用户、项目、规则、变化历史和证据链，那么你需要一个更结构化的 memory 层。
InsightMemory 正是在这个方向上的一次开源尝试。
它的野心不是再做一个 memory demo，而是把 LLM 应用里的长期记忆做成一层可独立部署、可评估、可追溯、可扩展的基础设施。
GitHub: https://github.com/MarvekW/InsightMemory
如果你正在做 Agent、Copilot、RAG 或知识系统，欢迎试用、提 issue、贡献评测 case。项目仍在快速迭代中，也欢迎提供 LLM API-KEY、调用额度或真实接入反馈，帮助继续完善评测和长期记忆实验。
