MemPalace 解读
一个应该让你停下滚动的数字：
96.6%
我的观点：这些数字看起来好得令人难以置信……但话说回来，让我们继续，因为这个故事也有好的方面。
这是MemPalace在LongMemEval上的Recall@5得分。LongMemEval是一个包含500个问题的基准测试，旨在检验记忆系统能否在海量历史会话中找到正确的对话。原始逐字文本。ChromaDB嵌入。检索循环中没有语言模型。没有云端调用。没有API密钥。
作为对比：Mastra得分94.87%。Hindsight达到91.4%。生产环境中的Supermemory约为85%。大多数人实际使用的Mem0系统呢？在包含75,000多个问答对的ConvoMem上，它的表现只有30%到45%。
这些差距不小。在检索领域，85%和96.6%之间的差异就是"有时有用"和"我真的可以依赖这个"之间的差异。实际意义是：85%意味着大约七分之一的查询会遗漏。96.6%意味着每50个问题可能只有一两次遗漏。
但关键在于：数字甚至不是最有趣的部分。产生这个数字的架构才是。
1、原始文本论点：为什么保留一切能赢
MemPalace的核心赌注简单得令人尴尬。 不要总结。不要压缩。不要蒸馏。只需存储原始对话的逐字文本，让现代嵌入模型处理检索。
这不是通常的渐进式优化。这与整个AI记忆行业一直在构建的方向背道而驰。Mem0、Zep，每个基于LLM的记忆系统都假设你需要在存储之前提取、总结和压缩对话。理由似乎显而易见：原始对话很混乱，充满填充内容，大规模搜索成本高昂。
MemPalace说这种推理是错误的。
而96.6%的R@5、零提取的成绩表明他们可能是对的。
这种洞察微妙但深刻。每次你总结对话时，你都会丢失信息。也许是用户表达偏好时的细微差别。也许是顺便提到的特定工具名称。也许是讨论时的时间背景。总结是应用于自然语言的有损压缩，而这些压缩伪影会在下游表现为检索失败。
这样想：你是一名技术主管，同时使用Claude Code、ChatGPT和Cursor管理三个项目。六个月后，你已经积累了数千个会话。
在第二个月的某个时候，你与AI助手讨论了一个数据库架构决策。具体的推理、你权衡的取舍、你选择的具体迁移方法——都在那次对话中。
基于总结的系统会将其提炼为："用户决定在后端使用PostgreSQL。"
技术上正确，但除此之外毫无用处
当你需要记住为什么，或者被拒绝的替代方案是什么，或者你担心的边界情况时，这完全没用。
MemPalace保留了整个对话。原始。逐字。每个词。六个月后当你搜索时，嵌入模型能找到它，因为完整的信号仍然在那里。
原始逐字存储保留了一切。嵌入模型处理语义匹配。ChromaDB处理向量搜索。而且因为你从未丢弃原始信号，检索有更多可用信息。
这就是论点：带有良好嵌入的原始文本是比你意识到的更强的基线，因为它不会丢失信息。
2、宫殿内部：AI记忆的空间架构
这个比喻很迷人，但实现才是关键。MemPalace将你的对话历史组织成一个空间层次结构，灵感来自古老的记忆宫殿技术：
翼楼（Wings）
是顶级类别：你正在进行的项目、你合作的人、你正在学习的领域。将它们视为命名空间。
房间（Rooms）
位于翼楼内部。每个房间代表一个特定主题。例如，你的"后端"翼楼中有一个"Python迁移"房间。房间检测器使用room_detector_local.py中的模式匹配来自动分类传入的对话。
抽屉（Drawers）
保存实际内容——你的原始逐字对话文件。每次对话都进入一个抽屉，未经修改。检索就在这里发生。
壁橱（Closets）
壁橱保存指向抽屉的摘要。它们用于快速人工扫描和导航，而非检索准确性。检索引擎直接访问抽屉。
大厅（Halls）
连接同一翼楼内的相关房间。如果你的"Python迁移"房间和"数据库架构"房间共享上下文，大厅会连接它们，这样palace_graph.py中的BFS遍历就能找到多跳连接。**隧道（Tunnels）**跨翼楼做同样的事情——比如将合作者翼楼中的"API设计"房间链接到你的后端翼楼中的"数据库架构"房间。
这种层次结构服务于导航，而非检索准确性。作者对此一直很坦诚：宫殿结构帮助你浏览1950万token的对话历史。检索准确性来自对抽屉内容的原始嵌入。
知识图谱层
宫殿下方是一个基于SQLite的知识图谱，具有时间实体关系。与Zep基于云的Neo4j方法不同，MemPalace将所有内容保留在本地，成本为零。
entity_detector.py模块从对话中提取实体——人员、工具、项目——knowledge_graph.py使用有效期窗口跟踪它们之间的关系。一月份成立的实体关系可能在四月份不再成立。时间维度很重要。
entity_registry.py模块将实体映射到短代码（下文AAAK部分会详细介绍），并处理谁在你的整个对话语料库中知道什么关于谁的管理工作。
偏好翼楼
一个更 clever 的功能：MemPalace在摄取时维护一个专门的偏好翼楼。general_extractor.py中的16个正则表达式模式扫描传入对话中的偏好表达并生成合成文档。"用户提到：更喜欢TypeScript而非JavaScript；对花生过敏；使用vim绑定。"
这些合成偏好文档成为ChromaDB中的一流可搜索实体。当未来的查询涉及偏好时，系统可以针对这些集中信号进行匹配，而不是寄希望于嵌入能找到埋藏在2000字对话中的正确句子。
3、五阶段混合检索管道
MemPalace真正 clever 的地方是混合检索模式。该管道经历了五个有文档记录的版本，每个版本都为特定类别的检索失败添加了针对性修复。进展记录在HYBRID_MODE.md中，读起来像实时工程事后分析。
阶段1：扩大漏斗（基线）
原始模式检索ChromaDB的前10个结果。混合管道首先将其扩大到前50个候选。更多候选意味着更高的召回率，代价是精确度；后续阶段处理精确度问题。
仅这个基线就达到了96.6%的R@5。实际意义是：500个测试问题中有483个在前五个结果中返回了正确的对话。17次遗漏。
阶段2：关键词重叠重排序（v1，+1.2pp）
语义搜索很强大，但有一个已知的盲点：它可能错过精确的关键词匹配。如果你问"关于GraphQL我说了什么？"而相关对话使用了确切的"GraphQL"这个词12次，纯嵌入搜索仍可能将语义相似但不同的对话排名更高。
混合v1用一个简单的融合距离公式修复了这个问题：
fused_dist = dist × (1.0 − 0.30 × overlap)
系统从查询中提取非停用词（过滤掉40多个停用词，如"what"、"when"、"where"、"how"），计算与每个候选文档的关键词重叠，并相应降低距离分数。对于强关键词匹配，距离最多可降低30%。
结果：97.8% R@5。
六个更多问题回答正确。六个本会丢失的对话被找到。
阶段3：时间日期增强（v2，+0.6pp）
这里有一个只在真实世界使用中出现的失败模式：基于时间的问题。"几天前我们讨论了什么？""上周的那个东西是什么？"
混合v2使用正则表达式解析时间引用，匹配"N天前"、"几天前"、"上周"、"N个月前"和"最近"等模式。它计算目标日期窗口并增强落在其中的文档。对于时间上相关的结果，距离最多可降低40%。
这也引入了关于AI助手之前说了什么的问题的两遍检索。当查询包含"你建议"、"你告诉我"或"你推荐"等触发词时，第一遍搜索仅用户轮次的索引，第二遍使用完整对话文本（用户+助手轮次）重新索引前5个结果。
结果：98.4% R@5。仅时间增强一项就恢复了语义搜索无法找到的对话，因为嵌入本身并不编码"三天前"。
阶段4：偏好提取（v3，+0.6pp）
偏好翼楼在这里发挥作用。在摄取时，16个正则表达式模式提取偏好表达并创建合成文档。在查询时，重排序候选池从前10个扩大到前20个，给偏好匹配留出浮现空间。
结果：无需LLM重排序即可达到98.4% R@5。使用Haiku重排序，每次查询约0.001美元，这推升至99.4% R@5。500个问题中遗漏3个。
阶段5：LLM重排序（可选，+1.0pp）
最后阶段是可选的，也是唯一需要花钱的阶段。Claude Haiku接收前20个候选并做出语义相关性判断。每次查询约0.001美元，它将分数从98.4%推升至99.4%。
这个阶段的分类细分很有启发性：知识更新问题达到100%（n=78）。多会话问题达到100%（n=133）。单会话用户问题达到100%（n=70）。时间推理达到99.2%（n=133）。最弱的是单会话偏好，为96.7%（n=30），可能是因为基于正则的偏好提取无法捕捉每种表达风格。
4、AAAK：尚未成功的压缩实验
MemPalace提供了一个有损符号总结格式，称为AAAK（名字故意不作解释；README说"别问，这本身就是一个完整的故事"）。
值得理解AAAK实际做了什么，因为其雄心与当前结果之间的差距恰好说明了为什么原始文本论点很重要。
AAAK通过提取五个组件来压缩文本：
实体（Entities）
实体被映射到3字符大写代码。"Alice"变成"ALC"。"Bob"变成"BOB"。这些代码来自可配置的实体注册表。
主题（Topics）
这些是过滤150多个停用词后频率最高的内容词，专有名词和驼峰命名技术术语有额外增强。
关键句子（A key sentence）
这些通过决策关键词和长度评分（系统偏好40-80字符片段），然后截断至最多55字符。
情感（Emotions）
情感通过关键词信号检测并映射到30多种情感的3-4字符代码："vul"表示脆弱，"determ"表示决心，"convict"表示信念。
标记（Flags）
标记就像标记重要性的标签：ORIGIN、CORE、SENSITIVE、PIVOT、GENESIS、DECISION、TECHNICAL。
句子输出看起来像这样：
ALC+BOB|GraphQL_REST|"chose GraphQL instead"|0.85|determ+convict|DECISION
任何LLM都可以原生读取。无需解码器。理论是，在大规模时，当实体代码如"ALC"在语料库中替换"Alice"数百次时，token节省会累积。
但这里是诚实的结果。
在LongMemEval上，AAAK模式得分84.2% R@5，而原始模式为96.6%。这是12.4个百分点的倒退。总结过程中丢失的信息对检索的伤害超过了token节省带来的好处。而且在小规模时，该格式实际上增加了token：README自己的例子将66个英文token压缩成73个AAAK token。
AAAK实验即使失败也很有价值。
它为原始文本论点提供了实证证据：当你的压缩是有损的，你就会丢失检索准确性。AAAK的实体代码方法在真正大规模（数百万重复实体引用）时是否值得的问题仍然开放。Issue #95对哈希碰撞保真度在法律和医疗RAG等高精度领域提出了深思熟虑的担忧。这是一个研究方向，而非生产功能。
5、经济性：每年0.70美元对比507美元
这里有一个没有受到足够关注的数字。
MemPalace计算了六个月日常使用AI记忆的成本，假设有1950万token的对话历史。使用基于LLM的总结（行业标准方法），你每年大约需要507美元。Zep收取订阅费。Mem0有云套餐。
MemPalace的唤醒成本？
每年0.70美元。
不是每月。每年。
每天增加五次搜索，你每年大约10美元。添加可选的Haiku重排序，每次查询0.001美元，你仍低于15美元。
成本差异不是边际的。这是两个数量级。而且它来自推动检索准确性的相同架构决策：不要在不需要的地方使用LLM。存储原始文本。使用嵌入进行搜索。仅在最后3%的准确性上调用LLM。
对于构建个人知识管理系统的人，或运行AI辅助开发的小团队来说，这就是"负担得起"和"免费"之间的差异。
6、如果你正在构建产品，这意味着什么
假设你正在运行一个10人工程团队，每天都使用Claude Code或Cursor。六个月后，你有了数万个会话。技术决策、调试方法、架构讨论——所有内容都在这些会话中，一旦上下文窗口滚动过去就会丢失。
MemPalace将这些会话挖掘成可搜索的语料库。
一名新工程师加入并问"我们如何决定数据库架构的？"答案就在某个抽屉中，逐字记录，以96.6%的准确率可检索。
没有人必须写文档。没有人必须维护wiki。对话就是文档。
19工具MCP服务器让这变得实用。一个命令：claude mcp add mempalace -- python -m mempalace.mcp_server。你的AI助手现在可以访问你的整个对话历史。你正在调试生产问题，依稀记得三个月前解决过类似的问题。无需通过grep搜索聊天记录导出，你的AI查询MemPalace，逐字检索相关对话，并准确从你离开的地方继续。
对于那些负担不起Mem0或Zep云套餐订阅费的人来说，这就是持久AI记忆的整个价值主张，在本地运行，免费。
这是我的观点。你应该做你觉得舒服的事。另外，这是我第一次使用MemPalace。我对术语有点反感。我认为实现非常原始。
但如果它有效，它就有效。我将认真尝试使用OpenPDFLoader作为我的核心管道。
7、社区发现了什么
MemPalace的GitHub issues页面读起来像协作同行评审。社区不仅提交了bug；他们压力测试假设，独立复现基准测试，并提供建设性分析，改进文档和代码。
值得注意的几个亮点：
他们没有计算真实的东西
用户panuhorsmalahti（Issue #43）通过OpenAI的实际tokenizer运行AAAK压缩示例，发现README的token估计使用了len(text)//3启发式而非真实tokenizer。社区标记了它，作者立即承认，修正被纳入README更新。
LoCoMo地面实况包含错误
用户dial481（Issue #29）对基准声明进行了详细的方法论审查，指出LoCoMo地面实况包含错误，一些代码补丁针对特定测试问题，而且ConvoMem比较混合了不同的评估指标。这些方法论观察让公布的数字值得信赖。
原始文本本身就96%准确
这让我既高兴又难过。对我来说太高了，我无法相信原始文本实际上96%有效。
用户gizmax（Issue #39）在M2 Ultra Mac Studio上独立运行了完整基准测试套件。原始96.6%完全复现。
由于AAAK导致的较低压缩率
不到五分钟。在独立硬件上。但gizmax也确认AAAK压缩率低于声称，房间检测需要改进。一次独立复现既验证了核心结果又确定了改进领域——这就是科学正确运作的方式。
许多其他社区贡献正在活跃
其他贡献包括.mempalace-ignore功能请求（Issue #102）、Gemini CLI集成（Issue #107）、多跳遍历路径（Issue #101），以及用Zig重写的提案以实现单二进制部署（Issue #30）。还有关于与Sara Brain项目架构相似性的 thoughtful 讨论（Issue #104），触及AI记忆系统中趋同设计的更广泛问题。
8、Milla、Ben和纠正航向的正确方式
2026年4月7日，Milla Jovovich和Ben Sigman在README中直接发布了更正说明。不是埋在发布说明中。就在顶部。
他们澄清token计数使用了粗略启发式，96.6%的标题来自原始模式（而非AAAK），"+34%宫殿增强"是标准ChromaDB元数据过滤，矛盾检测尚未连接到知识图谱管道。
他们的结束语："我们宁愿正确而非令人印象深刻。"❤
就是这样。没有粉饰。
这就是开源应该运作的方式。作者发布了雄心勃勃的东西，社区提供了严格反馈，回应是透明和即时的。没有人试图摧毁任何东西。每个人都试图让它变得更好。
panuhorsmalahti提交Issue #43不是为了攻击MemPalace。他们提交它是因为想要准确的文档。dial481写了八条方法论观察，因为严格的基准测试让整个领域更值得信赖。gizmax花时间在独立复现上，因为可验证的结果很重要。
这是开源社区的真正形态：开放尝试、测试、包容、改进和贡献。
这是协作智能。作者带来愿景和代码。社区带来审查和边界情况。项目比任何闭源替代方案发展得更快、更诚实。最后，剩下的是一个按原样存储你的对话、用现代嵌入索引它们、以96.6%的准确率检索它们、零成本的系统。
那是一个凭自身实力立足的记忆系统。
原文链接: MemPalace By Mila Jovovich: 96.6% Recall With Zero API Calls (Too Good To Be True?)
汇智网翻译整理，转载请标明出处