Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

第3章：逐字存储的经济学

定位：本章用硬数据证明"存储一切"在经济上完全可行，将问题焦点从"存不存"转移到"怎么组织"，为后续章节引入解决方案做铺垫。

一个被搞反的等式

在上两章中，我们建立了两个论点：

  1. 每天有数百万 token 的决策记录在 AI 对话中蒸发（第 1 章）。
  2. 让 LLM 决定什么值得记住是根本性错误（第 2 章）。

这两个论点的逻辑交汇点指向一个看似激进的结论：存储一切。 不做提取，不做压缩，不做筛选——把每一次对话的每一个 token 都原封不动地保留下来。

大多数人对这个方案的第一反应是："这太贵了"或"这不现实"。

这个反应是错误的。它来自一个被搞反的等式：人们高估了存储的成本，低估了检索的难度。

让我们用数字说话。

存储成本：接近于零

先建立基准。我们在第 1 章中估算了一个中等强度 AI 用户 6 个月产生的数据量：

180 天 x 3 小时/天 x 10,000 token/小时 = 约 1950 万 token

1950 万 token 转换为原始文本，大约是多少？

一个 token 平均约 4 个字符（英文）或 1.5 个字符（中文混合场景）。取保守估计，1950 万 token 约等于 6000 万字符，即 60MB 的纯文本。加上元数据（时间戳、会话 ID、项目标签），大约 100MB。

100MB。半年的全部 AI 对话记录，100MB。

这个数字在 2026 年意味着什么？

  • 本地存储：一块 1TB SSD 售价约 ￥400。100MB 占 0.01%。你的手机里一张照片可能比这更大。
  • 云存储：AWS S3 标准存储的价格是 $0.023/GB/月。100MB 一年的存储成本是 $0.028——不到 3 美分。

存储成本，在任何合理的讨论中，都可以四舍五入为零。

但这只是原始文本的存储。AI 记忆系统通常还需要向量索引来支持语义检索。向量索引的存储开销大约是原始文本的 3-5 倍（取决于向量维度和索引结构）。即便如此，500MB 的向量数据库在本地运行完全没有问题——ChromaDB 在这个量级下的查询延迟在毫秒级别。

所以第一个结论是明确的："存不起"是一个伪问题。 完整存储所有 AI 对话的成本低到可以忽略。

真正的成本：不在存储，在使用

存储便宜，但使用不便宜。具体来说，当你需要把记忆加载到 LLM 的上下文窗口中时，每个 token 都是有成本的——因为 LLM 的 API 按 token 收费。

这才是真正的经济决策点。让我们比较四种方案的使用成本。

方案一：全量粘贴

最天真的方案：把所有历史对话一次性塞进 LLM 的上下文。

Token 消耗：19,500,000 token

这个方案在物理上就不可行。截至 2026 年初，商用 LLM 的最大上下文窗口约为 200K-1M token。1950 万 token 超出任何现有模型的上下文窗口。即使未来上下文窗口扩展到千万级别，加载成本也是天文数字。

结论：不可能。

方案二：LLM 摘要

这是 Mem0、Zep 等系统采用的方案。用 LLM 把 1950 万 token 的原始对话压缩为摘要，在需要时加载摘要。

假设压缩比为 30:1（这已经是较高的压缩比了），摘要总量约 65 万 token。

每次会话需要加载多少摘要？这取决于场景，但一个合理的估计是：每次会话加载约 5,000-10,000 token 的相关记忆。

每次会话加载：~7,500 token（摘要）
每日会话数：~5 次
年度 token 消耗：7,500 x 5 x 365 = 13,687,500 token

以 Claude Sonnet 的输入价格 $3/百万 token（2026 年初参考价格）计算：

年度成本 = 13,687,500 x $3 / 1,000,000 = ~$41

但这只是加载成本。摘要本身的生成也需要 LLM 调用——你需要用 LLM 处理 1950 万 token 的原始对话来产生摘要。以输入价格计算：

摘要生成成本 = 19,500,000 x $3 / 1,000,000 = $58.5（一次性）

加上持续的增量更新（每天新对话需要被摘要化），实际年度总成本约在 $200-500 之间，取决于使用强度和模型选择。

我们取一个中间估计：~$507/年。

这个成本不算高——对于专业用户来说完全可接受。但问题不在于成本，而在于质量：上一章已经论证了，这些摘要的准确率约为 85%。你每年花 $507 买到的是一个 85% 准确的记忆系统。

方案三：MemPalace 唤醒

MemPalace 的设计采用了完全不同的策略。它不在每次会话时加载大量记忆摘要，而是加载一个极小的"身份层"——你是谁、你的团队是谁、你的项目是什么——然后只在需要时做精确检索。

按当前源码口径，唤醒（wake-up）加载的是 L0（身份）和 L1（关键故事）两层，总量通常在 ~600-900 token。README 中常见的 ~170 token / ~$0.70，则对应另一条更激进的目标路径：把 L1 进一步改写为 AAAK 后再用于唤醒。

每次会话加载：~600-900 token
每日会话数：~5 次
年度 token 消耗：600-900 x 5 x 365 = 1,095,000-1,642,500 token
年度成本 = ~$3.3-$4.9

仍然只是个位数美元。~$3-$5/年。README 中引用的 $0.70 属于 AAAK 化之后的下一阶段口径；就当前默认 CLI 来说，正确的量级是"几美元"，而不是"几百美元"。

$5。不是 $500，不是 $50，而是个位数美元。一年。

但公平地说，600-900 token 只包含你的身份和最关键的故事层——它不包含所有具体历史决策。当你需要查找"为什么选了 Postgres"时，你仍然需要做检索。

方案四：MemPalace 唤醒 + 按需检索

在实际使用中，MemPalace 的工作流程是：先加载 600-900 token 的唤醒信息，然后根据对话需要做语义检索。每次检索返回约 2,500 token 的相关内容（包含原始对话片段）。

假设每次会话平均做 5 次检索：

每次会话加载：600-900 + (5 x 2,500) = 13,100-13,400 token
每日会话数：~5 次
年度 token 消耗：23,907,500-24,455,000 token
年度成本 = ~$72-$73

等一下——这个数字看起来比摘要方案还高？让我们修正一下计算。

实际上，5 次检索/会话是一个较高的估计。大多数会话只需要 0-2 次检索——只有当对话涉及历史决策时才需要查询记忆。更合理的估计是平均每次会话 1 次检索：

每次会话加载：600-900 + (1 x 2,500) = 3,100-3,400 token
每日会话数：~5 次
年度 token 消耗：5,657,500-6,205,000 token
年度成本 = ~$17-$19

而 README 中给出的更低标定值，仍然对应 AAAK 化后的目标路径。关键点不在于精确数字，而在于数量级：当前默认实现下，MemPalace 的年度使用成本大致在 $3-$20（常见 0-1 次检索/会话）到 $70+（高强度 5 次检索/会话）的范围内，而摘要方案在 $200-$500 的范围内。

成本对比总表

方案每次加载 token年度成本准确率
全量粘贴19,500,000（超出上下文窗口）不可能N/A
LLM 摘要~7,500~$507/年~85%
MemPalace 唤醒~600-900~$3-$5/年N/A（仅身份层）
MemPalace + 按需检索~3,100-13,400~$17-$73/年96.6%

最后一列是关键：MemPalace 不仅显著更便宜，而且准确率高 12 个百分点。这不是一个"便宜但差一点"的方案——它在两个维度上都优于摘要方案。若未来切到 README 所描述的 AAAK wake-up 路径，成本还会进一步下降。

检索为什么难

到这里，你可能会想：如果存储便宜、使用成本也低，那问题就解决了？

没有。上面的计算有一个隐含前提：检索必须准确。 如果检索返回的不是你要找的内容，那么无论成本多低都没有意义——你花了 token 加载了一堆无关信息。

检索的难度来自三个层面。

语义鸿沟

用户的查询和记忆的内容之间存在语义鸿沟。

用户问："为什么选了 Clerk？" 原始对话中的表述可能是："OAuth 提供商的评估结论——Auth0 的企业版定价在 1 万 MAU 之后跳了三倍，Clerk 的定价更线性，而且 Next.js SDK 开箱即用。"

"Clerk"这个词在两边都出现了，但"选了"和"评估结论"之间的语义对应、"为什么"和定价/SDK 对比之间的因果对应，都需要语义理解才能建立。

简单的关键词匹配会遗漏这个对应。向量检索（语义相似度）可以捕获一部分，但在大型记忆库中，语义相似但不相关的结果（假阳性）会显著增加。

规模困境

1950 万 token 的记忆库，切分为对话片段后约有数万到数十万个文档块。在这个规模下，向量检索的 top-5 或 top-10 结果中混入不相关内容的概率很高。

这是一个典型的信息检索问题：当语料库变大时，精确率（precision）和召回率（recall）很难同时保持高水平。提高召回率（不遗漏相关结果）会降低精确率（混入更多不相关结果），反之亦然。

上下文缺失

纯向量检索缺乏结构性上下文。它知道"这个文档块和查询在语义上相似"，但不知道"这个文档块属于哪个项目、涉及哪些人、是在什么项目阶段产生的"。

没有这些结构性上下文，检索系统无法回答类似这样的查询：

  • "Kai 关于数据库的建议"——需要知道 Kai 是谁，以及哪些对话涉及 Kai。
  • "Driftwood 项目上个月的决策"——需要知道 Driftwood 是哪个项目，以及时间过滤。
  • "我们在 auth 迁移中踩过的坑"——需要知道 auth 迁移是一个跨多次对话的主题。

什么使检索可行

检索的三个难题——语义鸿沟、规模困境、上下文缺失——不是无解的。它们各自有已知的解法，只是这些解法需要被组合在一起。

解法一：缩小搜索空间

规模困境的最有效对策不是更好的搜索算法，而是更小的搜索空间。

如果你能在搜索之前就知道答案大概在哪个区域，你就可以把搜索范围从数万个文档块缩小到数百个。精确率和召回率在小规模语料上都容易保持高水平。

但"知道答案在哪个区域"需要记忆库有结构。不是扁平的向量数据库，而是有层级、有分类、有关联的组织体系。

这个观察本身并不新鲜——图书馆学已经研究了几百年。杜威十进制分类法的核心洞察就是：先分类，再搜索。分类将 O(N) 的搜索问题降维为 O(N/K) 的搜索问题，其中 K 是分类的数量。

对于 AI 记忆来说，分类的维度可以是：

  • 谁——哪个人或团队的记忆？
  • 什么项目——属于哪个项目？
  • 什么类型——是决策、是事件、是偏好、还是建议？
  • 什么主题——具体是关于 auth、数据库、部署、还是前端？

如果一个查询可以被路由到正确的分类组合（例如"Driftwood 项目的数据库决策"），搜索空间可以从数万缩小到数十——精确率和召回率都会大幅提升。

数据可以量化这个效果。在 22,000+ 条记忆的测试集上，仅通过按"谁"、"类型"、"主题"逐步缩小搜索范围，R@10 从 60.9% 提升到 94.8%——结构本身带来了 34 个百分点的检索提升，不需要更好的向量模型，不需要 LLM 重排序，不需要任何额外的计算成本。纯粹是数据组织方式的改变（详见第 7 章的逐层基准测试数据）。

这是一个深刻的结果。它说明检索效率的最大杠杆不在于算法层面（更好的 embedding、更精确的相似度计算），而在于数据组织层面——如何将信息放进正确的抽屉。

解法二：分层加载

并非所有记忆都需要在每次会话中被加载。人类的记忆也是分层的——你的名字、你的工作、你的团队，这些是"始终在线"的记忆；上周二的午餐吃了什么，这是"按需检索"的记忆。

AI 记忆可以采用同样的分层策略：

层内容大小加载时机
L0身份——这个 AI 是谁~100 token始终加载
L1关键故事——高权重 / 最近记忆~500-800 token始终加载
L2主题记忆——最近的会话、当前项目按需话题出现时
L3深度检索——全量语义搜索按需明确需要时

L0 + L1 在当前实现中合计约 600-900 token。README 中更激进的 170 token 口径，属于把 L1 进一步 AAAK 化后的下一阶段目标。即便按当前实现，这部分上下文开销仍然很小，但更重要的是：它让 AI 知道你是谁、你的团队结构是什么、你最近在做什么项目，从而可以正确理解后续提问，并在需要时发起正确的 L2/L3 检索。

解法三：压缩而非摘要

这里需要做一个关键的区分：压缩和摘要不是同一件事。

摘要是有损的——它丢弃"不重要的"信息（但谁来定义"不重要"？）。 压缩是无损的（或接近无损的）——它用更紧凑的表示保留所有信息。

文本的无损压缩通常被认为是有极限的——自然语言的冗余度是有限的。但如果压缩的目标不是让人类阅读，而是让 AI 阅读呢？

AI 和人类对文本的处理方式不同。人类需要完整的语法、标点、连接词来理解句意。AI 可以从高度压缩的结构化文本中恢复完整语义。

一个面向 AI 的压缩方言可以实现 30 倍的压缩比，同时保留所有语义信息。例如：

原文（~1000 token）：

Priya 管理 Driftwood 团队。团队成员包括：Kai（后端开发，3 年经验）、
Soren（前端开发）、Maya（基础设施）、Leo（初级开发者，上个月入职）。
他们正在开发一个 SaaS 分析平台。当前 sprint 的任务是将认证系统迁移到 Clerk。
Kai 基于定价和开发者体验，推荐 Clerk 而非 Auth0。

压缩后（~120 token）：

TEAM: PRI(lead) | KAI(backend,3yr) SOR(frontend) MAY(infra) LEO(junior,new)
PROJ: DRIFTWOOD(saas.analytics) | SPRINT: auth.migration→clerk
DECISION: KAI.rec:clerk>auth0(pricing+dx)

8 倍的压缩，零信息损失。AI 可以完美地从压缩形式恢复原始语义。

这种压缩方式与 LLM 摘要的本质区别在于：它不做任何"什么重要"的判断。它保留了所有事实，只改变了表达方式。这就像 gzip 之于 JPEG——前者无损，后者有损；前者可以完美还原，后者不能。

被颠倒的等式，被纠正

让我们回到本章开头的等式。

传统思维是：存储是昂贵的，所以需要压缩（通过摘要）来降低存储和使用成本。

现实是：存储是免费的，使用成本取决于检索效率，检索效率取决于数据组织方式。

这个等式的纠正意味着：

  1. 不要在存储端优化。 存储所有原始数据的成本接近零。任何在存储端做的"优化"（如摘要提取）都只是在增加风险（丢失信息）而不是在降低成本。

  2. 在检索端优化。 真正的成本节约来自加载更少但更准确的 token 到 LLM 上下文中。当前 600-900 token 的唤醒 vs 7,500 token 的摘要，已经体现了这种优势；如果未来再切到 AAAK 版 wake-up，这个差距还会继续扩大。

  3. 在组织端投资。 34% 的检索提升来自数据的组织方式——这是整个方案中投入产出比最高的环节。好的数据组织可以使简单的检索算法达到复杂算法在无组织数据上的效果。

过渡：从"为什么"到"怎么"

三章走到这里，我们完成了问题空间的全部描述：

  • 第 1 章回答了"发生了什么"——技术决策迁移到了 AI 对话中，每天产生大量不可替代的知识资产，在会话结束后蒸发。
  • 第 2 章回答了"为什么现有方案不行"——让 LLM 提取关键信息的假设在根本层面上是错误的，它产生的错误记忆比没有记忆更危险。
  • 第 3 章回答了"正确的方向是什么"——存储一切（接近零成本），然后通过数据组织使检索高效（34% 提升来自结构）。

读者现在应该对以下几点有清晰的理解：

  • 问题是真实且紧迫的。
  • 现有的主流方案（LLM 提取）在根本假设上有缺陷。
  • 正确的方向是"完整存储 + 结构化检索"，而非"智能提取 + 扁平存储"。
  • 存储不是瓶颈，组织方式才是关键。

但我们还没有回答具体的"怎么做"：

  • 怎样的数据组织结构可以带来那 34% 的检索提升？
  • 当前 ~600-900 token 的唤醒信息具体包含什么？README 中 ~170 token 的目标路径又意味着什么？
  • 按需检索的语义搜索是如何工作的？
  • 30 倍的无损压缩是如何实现的？

这些问题将在本书的第二部分——解决方案空间——中逐一展开。在那里，我们将看到一个古老的记忆术——记忆宫殿——如何被重新发明为 AI 时代的知识架构。