主题
第 13 章 删除与遗忘的四层语义
上一章末尾留下一个矛盾：哈希链证明记录未被篡改，却无法证明记录所描述的事实已经不存在。它给出的恰恰是反方向的答案——一条永久的墓碑。
这个矛盾在真实场景里出现得非常具体。2026 年 4 月，一家消费金融公司收到用户行使删除权的请求，要求清除其"收入水平"相关记忆。运维执行了删除，接口返回成功，检索确认已查不到。三个月后合规抽查发现：该用户的会话摘要里仍有一句"月收入约 2 万"，依赖该记忆生成的推荐策略仍在使用旧参数，检索缓存里还留着上一次召回的命中列表。系统删除了第一层，另外三层原封不动。
问题不在实现有 bug，而在"删除"这个词本身没有被定义清楚。在记忆系统里，它至少指四件不同的事：标记一条记录失效、把正文换成占位符、让依赖它的派生结论一起失效、从存储中物理抹除。四件事的代价、可逆性、适用场景完全不同，而它们经常被同一个"删除"按钮笼统承诺。
本章先拆解删除为什么是多义的，再给出四层语义的对照与各自的实现要求，然后讨论预览机制为什么是必需项而非可选项，接着处理掩码与删除的取舍，最后正面回答那个行业性难题——删除的可验证性，以及为什么本书不声称它已被解决。
13.1 删除为什么是多义词
13.1.1 一条记忆的四个下游
一条记忆写入之后，会在四个地方留下痕迹。
源记录本身，存于主表，含正文、元数据、置信度、时间轴。
派生结论，由这条记忆推导出的更高层判断。例如"月收入约 2 万"会推导出"属于中高收入客群"，后者可能已作为独立条目存入库中。
检索缓存，上一次召回的结果集。缓存的存在是为了避免重复计算，它保存的是记忆的引用或快照。
依赖摘要，会话摘要、主题摘要这类聚合产物。它们把多条记忆压缩成一段叙述，其中可能包含该记忆的内容。
只删源记录，另外三个下游会继续以"已经不存在的事实的影子"形式影响系统行为。这就是 13 开头那家金融公司的处境：源记录删了，摘要还在引用，策略还在用旧参数。
13.1.2 删除的三种动机
动机不同，需要的层数也不同。
用户要求"别记这个"。用户通常不是要求物理抹除，而是要求"别再用它影响我"。此时掩码或标记删除就够，物理删除反而破坏了上下文连续性。
用户行使法定删除权。这要求物理删除，且需要证据——不是"我们删了"的口头承诺，而是可交付给监管方的处理记录。
系统自我清理。低价值记忆降级、过期条目归档、重复条目合并。这类操作不需要销毁证据，需要的是可逆与可追溯。
三种动机对应三种强度，用同一套机制处理，必然在某一侧出问题：对"别记这个"做物理删除，会破坏对话连续性；对法定删除权做标记删除，会在审计时被发现。
13.1.3 删除与遗忘的区别
这两个词经常混用，但它们的指向不同。
删除是数据操作，结果是记录不再存在或不再可读。
遗忘是效果描述，结果是系统不再受该信息影响。
一个系统可以删除了记录但仍然"记得"——因为派生结论还在、缓存还在、摘要还在。反过来，一个系统可以保留记录但"遗忘"了——因为它把该记录降级到冷层、降低了召回权重、标记为 superseded。后者对用户体验而言等同于遗忘，且成本更低、可逆。
因此正确的问法是：我要的是删除还是遗忘。多数产品需求要的是遗忘，多数合规需求要的是删除，而工程实现经常把两者做成同一个接口。
13.2 四层语义与实现要求
13.2.1 四层的定义与对照
| 操作 | 效果 | 可逆 | 存储变化 | 适用场景 |
|---|---|---|---|---|
| 标记删除 | 记录保留，状态置为已删除，检索默认排除 | 可（可恢复状态） | 无 | 常规遗忘、误删找回 |
| 掩码 | 正文替换为占位符，骨架与元数据保留 | 可（撤销掩码） | 正文被替换 | 用户说"别记这个"但需保留上下文长度 |
| 级联软删 | 源记录软删 + 派生结论失效 + 缓存清除 + 依赖摘要标陈旧 | 部分（需重建派生） | 多表状态变更 | 删除一条有依赖关系的记忆 |
| 物理删除 | 记录与索引从存储中抹除 | 不可逆 | 实际释放 | 合规要求的彻底删除 |
表 13-1 删除的四层语义
这张表的第四列容易被忽略，但它决定了成本。前两层不动存储，第三层动多张表，第四层才真正释放空间。一个只会做第四层的系统，在处理"别记这个"这类请求时会过度销毁；一个只会做第一层的系统，在合规场景下不达标。
13.2.2 标记删除的实现要点
标记删除的核心是默认排除而非默认包含。检索路径必须在没有显式要求时排除已删除记录，否则"删了还能搜到"会成为反复出现的缺陷。
这条要求听起来简单，实际容易破。检索有五路信号，每一路都要加排除条件；任何一路漏掉，就会出现"向量检索查不到、关键词检索查得到"的诡异现象。这也是物理隔离之外，逻辑过滤最需要测试的地方。
第二个要点是可恢复。标记删除的价值在于误删可救，因此需要保留足够的元数据来重建状态。代价是存储不释放，对高频删除的场景需要定期压缩。
13.2.3 掩码的实现要点
掩码把正文替换为占位符，但保留记录骨架：ID、时间、类型、来源、指针关系都不变。
这个设计的直接收益是不破坏上下文长度与前缀。在依赖 KV-Cache 复用的推理架构里，前缀一旦变化，缓存全失效。掩码让"别记这个"这个操作不会引发一次全量重算。
代价有两处。第一，存储中仍保留骨架与元数据，合规场景下这不等于删除——元数据本身可能构成个人信息。第二，掩码后的记录在检索时仍占位，如果检索逻辑没有把占位符排除，会出现"召回到一条空记忆"的情况。
撤销掩码需要当初保留了原文。这是一个必须在设计时确定的开关：保留原文可撤销但增加了泄露面，不保留则掩码接近不可逆。多数实现选择保留，因为撤销的需求比预想中频繁。
13.2.4 级联删除的实现要点
级联删除是最复杂的一层，它的前提是派生关系必须存在。
派生关系指：哪些结论由这条记忆推导而来、哪些摘要引用了它、哪些缓存条目对应它。这层关系如果不在写入时建立，删除时只能靠扫描全文推断，准确率无法保证——你会删掉不该删的，也会漏掉该删的。
因此级联删除的第一个工程要求不是删除逻辑，而是写入时记录依赖。这条要求经常被推迟到"以后再加"，结果是级联删除永远做不实。
第二个要求是分阶段执行。四个步骤（源软删、派生失效、缓存清除、摘要标陈旧）不应在一个事务里完成，因为摘要重建可能耗时很长。合理做法是先标记、再异步重建，并在重建完成前把相关摘要置为不可用状态。
13.2.5 物理删除的实现要点
物理删除要求覆盖所有副本：主表、索引、缓存、备份策略允许范围内的快照。
这里有一个必须说清的边界：物理删除通常无法覆盖已经导出的副本。防删除导出（deliberation-proof export）作为审计证据存在时，它与删除权天然冲突。解决方式不是技术，而是策略：明确哪些副本在删除范围内、哪些作为法定留存被隔离，并把隔离的事实记录进审计。
代价是这类策略需要法务参与，不能由工程单方面决定。
13.3 预览机制为什么是必需项
13.3.1 爆炸半径
一条被删除的用户偏好可能已经影响了三次对话的推荐结果。在电商场景里，它可能改变了首页排序；在医疗随访场景里，它可能改变了下一次提醒的内容；在金融场景里，它可能改变了一个风控评分。
这些影响在删除之后仍然存在——因为它们已经被写进了派生结论、摘要、甚至下游系统。
因此删除操作的真正风险不是"删错了一条"，而是"删对了但不知道影响面"。预览机制的作用就是把影响面在执行前暴露出来。
13.3.2 预览应该给出什么
一个可用的预览至少包含四项：
受影响的派生条目数与清单。不是"3 条"，而是哪 3 条、内容摘要是什么。
受影响的摘要。会话摘要、主题摘要中引用了该记忆的部分。
受影响的缓存条目。哪些查询的缓存会失效。
不可逆程度。这次操作里哪些步骤可回滚、哪些不可。
只给数量不给清单的预览没有实际价值，因为决策者无法判断"3 条"是无关紧要还是核心资产。
13.3.3 预览与审批的配合
预览的价值在于支撑决策，因此它必须出现在审批之前，而不是执行之后作为报告。
一个可落地的流程是：请求删除 → 生成预览 → 人工确认影响面 → 执行 → 输出处理记录 → 归档。中间的人工确认步骤在高频场景下会成为瓶颈，因此需要分级：低风险删除（无派生依赖）自动执行，高风险删除（有派生依赖或跨作用域）强制确认。
13.3.4 为什么要在预发环境验证
预览的输出依赖数据形态。开发环境的数据通常干净、依赖少，预览会给出"无影响"的结论；生产环境的数据有历史遗留、有跨作用域引用、有未预期的依赖，预览会给出完全不同的结果。
因此级联删除必须在预发环境用真实数据规模验证。这条纪律不是流程洁癖，而是因为预览本身也是一个需要测试的功能——它的准确率只有在真实数据上才能被检验。
13.4 掩码与删除的取舍
13.4.1 产品视角与合规视角的分歧
产品团队倾向掩码，因为它保留了上下文连续性，用户不会感到"系统突然失忆"。合规团队倾向删除，因为"保留骨架"在审查时会被追问"骨架里有什么"。
这个分歧没有统一答案，但可以被结构化：把"用户可见的效果"与"存储中的事实"分开处理。
用户可见层面，掩码后该记忆不再出现在任何回答中，效果等同于遗忘。存储层面，骨架仍在，需在合规文档中明确声明并说明保留理由（例如保留指针关系以维持审计链完整性）。
如果监管方不接受任何形式保留，则必须物理删除，并接受审计链断裂的代价——这是一个真实的取舍，不是可以两全的问题。
13.4.2 一个判断准则
按请求来源分流：
用户主动说"别记这个"：默认掩码。理由是可逆、不破坏连续性、成本低。
用户行使法定删除权：物理删除 + 处理记录。理由是合规优先于连续性。
系统内部清理：标记删除或降级。理由是可追溯比彻底更重要。
安全事件处置（如发现被投毒的记忆）：级联删除 + 强制重建派生。理由是污染可能已扩散到派生结论。
四条分流规则覆盖了多数场景，剩下的边缘情况需要个案判断——但有个案判断的框架，比每次从零讨论要好。
13.5 删除的可验证性难题
13.5.1 为什么这是行业性难题
删除权的核心诉求是"被遗忘"，而"被遗忘"的证明需要回答一个否定命题：某条信息已经不存在于系统中的任何位置。
否定命题的证明在计算上极其困难。你需要穷举所有可能存放位置——主表、索引、缓存、日志、备份、导出副本、下游系统的副本——并证明每一处都不存在。任何一个遗漏，证明就不成立。
更麻烦的是，证明本身会留下痕迹。如果为了证明"已删除"而保留一份删除记录，这份记录本身就包含了"曾经存在过某条信息"这一事实，可能构成新的个人信息。
13.5.2 现有手段能做到什么
哈希链能证明"记录未被篡改"，能定位到具体哪一条被改。它不能证明"记录已不存在"。
级联删除能处理四个层次，能输出处理记录。它不能证明"备份与导出副本也已清除"。
隔离能保证默认路径下数据不交叉。它不能证明"配置错误时也不交叉"。
因此当前能给出的最强承诺是：在明确的范围内，按明确的步骤，完成了可复核的处理，并留下了处理记录。这不是"已彻底清除"的证明，而是"已按约定流程处理"的证据。
把这两者混为一谈，是合规沟通中最常见的过度承诺。
13.5.3 一个可能的方向
可跨系统交换的删除审计格式是一个有价值的方向：它不试图证明"不存在"，而是记录"在哪些位置、由谁、在什么时间、执行了何种处理"，并允许第三方复核这些处理是否覆盖了其已知的所有位置。
这个思路把否定命题转化成了可核查的清单比对，难度大幅下降。截至 2026 年 10 月，还没有形成标准，各家自定义格式。
13.6 删除的工程纪律
四条，按重要性排序。
第一，派生关系必须在写入时建立。 这是级联删除能否做实的唯一前提，事后补救的成本高于重建整个存储。
第二，预览必须在执行前，且给出清单而非数量。 只给数量的预览无法支撑决策。
第三，级联删除在预发环境用真实数据规模验证。 预览本身是功能，需要被测试。
第四，把预览输出纳入变更管理。 一次高风险删除应当像一次发布一样有审批、有记录、有回滚预案。
13.7 本章小结
本章确立了四条判断。
第一，"删除"在记忆系统里是四层语义，不是单一操作。 标记删除、掩码、级联软删、物理删除对应四种动机，用同一套机制处理必然在某一侧出问题：对"别记这个"做物理删除会破坏连续性，对法定删除权做标记删除会在审计时被发现。
第二，删除与遗忘是两件事。 删除是数据操作，遗忘是效果描述。系统可以删除了记录但仍然受其影响（派生结论、缓存、摘要仍在），也可以保留记录但已不受影响（降级、降权、标记失效）。产品需求多要遗忘，合规需求多要删除，混用会导致过度销毁或删除不实。
第三，级联删除的前提是派生关系存在，而不是删除逻辑写得好。 这层关系必须在写入时建立，事后靠扫描推断的准确率无法保证。同时预览必须给出清单而非数量，且必须在执行前出现。
第四，删除的可验证性仍是未解问题，本书不声称它已被解决。 当前最强承诺是"在明确范围内按明确步骤完成可复核的处理并留下记录"，而不是"已彻底清除"。把这个区别讲清楚，比宣称解决更有价值。
这四条判断有一个共同前提：删除操作本身是可信的。而如果写入路径上就已经混入了不该记的内容——凭据、注入指令、被伪造的事实——那么删除只是在清理一个本不该发生的问题。第 14 章转向写入前的那道关口。