给 RAG 知识库做删除同步时，我会先把墓碑表和索引对账拆出来

最近给一个内部 RAG 知识库补删除同步时，我又踩到一个很隐蔽的坑：文档列表里已经看不到源文件，答案里却还能引用旧 chunk。排查后发现，业务库删除、解析产物删除、向量库删除、缓存刷新分散在几条异步链路里，只要其中一步失败，旧知识就会以低概率继续被召回。后来我把这件事改成一条有墓碑、有版本、有对账的工作流。

RAG 删除同步从源文件变更、墓碑账本、chunk 版本、向量库删除到对账报告的流程图

原创示意图：把 RAG 删除同步拆成源文件变更、墓碑账本、chunk 版本映射、向量点删除、重试队列和对账报告。来源：Codex image generation

问题背景

RAG 的新增链路通常比较受重视，上传、解析、切片、embedding、入库都有进度条。删除链路却很容易被写成一个后台清理动作。LlamaIndex 的文档管理文档把 insert、delete、update、refresh 放在同一类索引管理问题里，这提醒我删除也应有明确契约。Qdrant 的 delete points API 支持按 point id 或 filter 删除向量点，Chroma 的集合 API 也提供按 ids、where 条件删除数据的能力。工具本身给了删除入口，工程上真正难的是知道该删哪些、删到哪一步、失败后怎么补。

关键难点

第一个难点是源文档和 chunk 不再一一对应。一次文档更新可能生成新的 chunkVersion，旧版本还留在向量库里等待清理。如果只拿 docId 删除，很容易误删新版或漏删旧版。

第二个难点是异步失败不显眼。解析服务删除了元数据，向量库删除请求却超时，前端只看到文档消失，线上问答仍可能命中旧 chunk。第三个难点是缓存。召回层、rerank 层和答案侧证据卡如果有短期缓存，删除成功后也要知道哪些缓存需要失效。

解决思路

我把删除同步拆成四张账本。第一张是 tombstone ledger，记录 sourceId、docVersion、deletedAt、operator、reason 和 scope。第二张是 chunk map，记录每个 chunkId 对应的 sourceId、chunkVersion、vectorPointId 和 hash。第三张是 delete job，记录向量库删除、缓存失效、证据卡归档这些动作的执行状态。第四张是 reconcile report，用来定时对比业务库、chunk map 和向量库里还剩哪些点。

这套拆法的核心是先声明删除事实，再异步执行清理。文档被删除时，用户可见状态立即变成已删除，同时写入 tombstone。检索层每次召回后都要用 sourceId 和 chunkVersion 过一遍墓碑检查，只要命中已删除范围，就禁止进入 prompt。这样即使向量库清理晚了一分钟，旧知识也不会继续影响答案。

关键步骤

落地时我先统一 chunk 元数据，要求每个向量点都带 sourceId、docVersion、chunkVersion、contentHash 和 indexedAt。删除请求进入后，不直接拼一个 filter 去删，先从 chunk map 冻结一份待删清单，生成 deleteJobId。随后执行向量库删除，成功后记录 deletedPointCount，失败就把 job 放进重试队列。

接着补对账任务。它每天扫描 tombstone 后的源文档范围，抽样查询向量库里是否还存在同 sourceId 的点。如果发现残留，就生成 reconcile event，并按残留数量决定自动补删或进入人工复核。对于批量删除，我还会限制单个 job 的 point 数量，避免一次清理请求过大导致超时后难以判断完成度。

最后是前端提示。删除操作完成后，界面不只显示成功，还展示清理状态：元数据已标记、向量点清理中、缓存已失效、对账已通过。业务同学看到的是简单状态，研发同学能追到 deleteJobId 和 reconcile report。