源文件删了，chunk 还在，回答仍会引用它。

先讲

四个身份要一起走。文档 id 是业务对象，例如 doc:travel-cn，换文件名也不该换这个号。内容哈希是这一版字节的指纹，哈希变了就是新版本，不要靠最后修改时间独断。chunk 记下 parent：从哪份文档、哪一版切出来。tombstone 是盖在文档 id 上的「已删除」章。检索、缓存、重放摄取，都要先看这枚章。

业务说删，第一步盖 tombstone，让检索立刻滤掉这个 id。第二步删该 id 下全部 chunk。第三步按 doc_id 对账，计数应为 0。源文件可以从对象存储里收，但它不是开关。只删磁盘文件再重建索引：窗口以小时计，重建期间旧段落仍回答。只删 chunk 不盖章，队列重放会把旧段落写回来。

v1 已在、v2 到了：先算 v2 的哈希。若与 v1 相同，什么都别动。若不同，写入带 parent 和 version=2 的新 chunk，再删 version=1 的孩子。只加不删，索引里两版同时可被命中，模型会把作废条款和现行条款拼在一段回答里。

乱序事件常见。更旧的更新晚到，不能靠「谁最后写入谁赢」。比较版本号，旧的那条丢弃。同一 (doc_id, content_hash, chunk_i) 写两次仍是一条。删除 SLA 用分钟说清：tombstone 后 30 秒内检索应看不到。全库 120 万截重建要 4 小时，日常删除等不起。

对账用数说话。docA 在 v1 切出 17 截。tombstone 之后，按 parent 计数应为 0。若仍是 3，那 3 截就是活引用：客服问住宿，450 还会从已死文件里出来。盖章之后 30 秒内检索应看不到这个 id。缓存键里要有文档 id，带这个 doc 的回答键全部 miss。一页 PDF 解析崩了，不要拖死整批。日常删除走短路径，等不起四小时重建。