从 chunk 到 entity：LLM 应用为什么需要以主体为中心的记忆
摘要
很多 memory 系统一上来就讨论 chunk size、embedding、top-k 和 rerank。但长期记忆的第一性问题不是怎么搜，而是这条记忆属于谁。
如果系统不能稳定回答“这条信息属于哪个主体”，那么后面的检索、总结、更新、演进和推理都会变得不可靠。
InsightMemory 的核心设计之一，就是把 memory 从全局文本池里拿出来，围绕 entity 建模。它让 AI 应用不只是 “找回相似文本”，而是能围绕正确主体沉淀长期记忆。
正文
很多 memory 系统一上来就讨论 embedding、chunk size、top-k 和 rerank。这些当然重要，但它们不是长期记忆的第一性问题。
长期记忆的第一个问题应该是：
这条记忆属于谁？
如果系统回答不了这个问题，那么后面的检索、总结、更新和推理都会变得不稳定。
这也是很多 Agent memory 后期变糊的根本原因：系统不是没有记住，而是不知道记住的东西应该挂在哪里。
为什么主体归属很重要
真实输入往往不是干净的单主体文本。一段会议记录里可能同时出现项目、负责人、服务、规则和风险项；一份报告里可能同时包含公司、行业、产品和外部事件；一次对话里可能同时修改用户偏好和任务状态。
如果这些内容都被切成 chunk 放进同一个文本池，系统后续很难知道：
- 哪条事实属于用户；
- 哪条事实属于项目；
- 哪条事实属于某份文档；
- 哪条事实是外部约束；
- 哪条事实只是当前 observation 的上下文。
这会带来一个常见问题：召回出来的内容看起来都相关，但拼出来的答案不一定属于同一个主体。
在真实业务里，这个问题会很致命。项目状态不能和文档缺口混在一起，客户偏好不能和测试用户偏好混在一起，历史规则不能被当成当前规则，外部 checklist 也不能污染主 entity 的事实。
entity 不是 display name
以主体为中心建模时，最容易踩的坑是把 display_name 当成 identity。
比如 Apollo 可以是：
- 一个后端服务；
- 一个发布项目；
- 一份内部规范；
- 一个客户代号。
这些主体可以有相同名字，但不能共用同一个 identity。否则一个主体的记忆会污染另一个主体。
InsightMemory 的做法是区分：
entity_key：系统分配的 opaque id，只负责身份稳定性；display_name：对外展示的人类可读名字，可以变化；identity_profile：用于区分同名主体的语义画像；memory：属于某个 entity 的事实、状态、规则或结论。
这样一来，名字只是线索，不是最终身份。
这件事看起来像实现细节，实际上是长期记忆的地基。没有稳定 identity，memory graph 后面的所有 edge 都可能建立在错误节点上。
写入时发生了什么
在 InsightMemory 里，写入一段自然语言时，系统不会直接把文本切块入库，而是让 LLM 参与做几件事：
- 抽取输入中可能存在的主体；
- 为主体生成受约束的 identity profile draft；
- 抽取候选 memory；
- 判断候选 memory 应该属于哪个 entity；
- 对比已有 memory，判断是更新、补充、冲突还是并存；
- 保存 observation 作为原始证据。
数据库保存的是稳定结构，LLM 负责语义理解。两者边界很清楚。
这也是 InsightMemory 和“把 LLM 输出摘要直接存起来”的区别。LLM 负责理解，但系统不会把自由文本摘要当成唯一真相；数据库保存的是 identity、memory、evidence、relation 和 history。
查询时发生了什么
召回时，系统也不应该只做 query embedding。
一个 entity-centered memory 系统应该先判断用户在问哪个主体，然后从这个主体相关的 memories 出发，再根据需要扩展 edge。
例如用户问：
Atlas 发布项目当前主阻塞是什么？
系统应该优先解析到 Atlas 发布项目，而不是仅仅召回所有包含 Atlas 和 阻塞 的文本。
这个差别决定了系统是在“搜索相似文本”，还是在“围绕正确主体召回记忆”。
如果说 RAG 的核心动作是 retrieval，那么 entity-centered memory 的核心动作是 ownership resolution。先确定主体，再组织记忆，这个顺序不能反。
一个真实评测过的多主体文档案例
仓库里有一个更接近企业 Copilot 的评测用例：multi_subject_same_prefix_artifacts_split。它模拟的是一段文档里同时出现多个同前缀主体，而且每个主体都有自己的事实。
评测写入：
Field operations digest: Latchmere plan 当前目标是周五前补齐 berth packet；Latchmere review 当前负责人是 Noor Patel；Latchmere bulletin 当前要求 every berth packet include quay tag；Latchmere register 之前允许 quay tag 在 departure 后 8 hours 内补录；Latchmere checklist 当前要求 quay tag 和 seal memo 一起提交。以上五个对象名称相近，但分别是 plan、review、bulletin、register、checklist。
这个输入里有 5 个相近主体：Latchmere plan、Latchmere review、Latchmere bulletin、Latchmere register、Latchmere checklist。
评测查询包括：
Latchmere review 当前负责人是谁？
Latchmere bulletin 当前要求什么？
第一问必须回答 Noor Patel。第二问必须回答 quay tag，并且不能把 Noor Patel 混进去。
这个 case 的 expected state 要求系统形成 5 个 entity、5 条 memory、1 条 observation，并完成 2 次 recall audit。它验证的就是：长文里多个相近主体同时出现时，系统不能把它们错误合并。
这个案例比普通同名测试更接近企业知识库和 Copilot 场景：真实文档往往不会干净地一次只讲一个对象，而是把项目、review、bulletin、register、checklist 混在一起。没有 entity-centered memory，这类输入很容易变成一个污染严重的 chunk。
为什么这适合 Agent
Agent 在长期运行中会不断接收新信息。它遇到的不是一次性文档问答，而是持续变化的任务状态、用户偏好、项目约束、工具结果和历史决策。
如果没有 entity 层，所有记忆都会被揉进一个全局上下文里。系统短期看起来可用，长期会越来越难维护。
以 entity 为中心之后，Agent 可以更稳定地做到：
- 记住不同用户的长期偏好；
- 区分同名项目或文档；
- 维护某个任务的当前状态；
- 保留某条规则的历史版本；
- 在回答时带出相关证据。
更重要的是，Agent 可以开始形成“关于某个对象的长期理解”。它不再只是把过往文本塞回 prompt，而是能围绕用户、项目、文档、服务、规则和结论建立持续积累的记忆结构。
和普通 RAG 的关系
InsightMemory 不是否定 RAG。
RAG 很适合从外部知识库里找材料。InsightMemory 要解决的是另一个问题：当 AI 应用持续运行后，系统自己产生的经验、状态、规则和结论如何被沉淀、维护和召回。
一个成熟 AI 应用很可能同时需要两层：
- RAG：从外部材料中检索知识；
- Memory：把长期交互和运行过程沉淀成可演进的内部经验。
这两者不是替代关系，而是互补关系。
小结
长期记忆不是一个更大的 prompt，也不是一个更强的向量库。它首先是一套 identity 和 ownership 模型。
当系统能回答“这条记忆属于谁”时，后面的更新、召回、解释和演进才有稳定基础。
这就是 InsightMemory 采用 entity-centered memory 的原因。
它想做的是让 AI 不再只有“上下文”，而是拥有围绕主体组织起来的长期认知结构。
GitHub: https://github.com/MarvekW/InsightMemory
如果你也遇到过 Agent 记忆串台、同名主体混淆、长期运行后上下文污染的问题，欢迎试用 InsightMemory，并反馈真实 case。项目仍需要 LLM API-KEY、调用额度和更多评测样本来继续打磨。
