RAG 索引为什么会召回已删内容：增量更新与删除传播

RAG 的向量索引本质上是源数据的一份缓存。源文档更新或删除后如果索引没有同步检索仍会返回旧内容而且通常不会报错。用户看到的是一条看似正常的答案系统却可能引用了已经失效的事实。一、最容易漏掉的是删除传播很多实现只处理新增新文档嵌入后写入向量库却没有为更新和删除建立对称流程。结果是源系统里的文档已经删除索引中的向量仍能被召回形成“孤儿向量”。文档重新分块时也有同样的问题如果只写入新分块而不清理旧分块新旧版本会同时进入候选集。可靠的做法是给文档和分块分配稳定 ID。新增时 add更新时按同一 ID upsert删除时按 ID delete重新分块时先定位并清理旧 chunk再写入新版本。删除不是增量同步的附属项而是必须单独验证的路径。二、增量同步与全量重建各管一件事增量同步负责新鲜度。可以通过 CDC、版本号或更新时间识别变化只处理新增、更新和删除的文档。全量重建负责纠正长期积累的漂移重新分块、重新嵌入、建立新索引验证完成后再原子切换。两者不是二选一更稳妥的组合是高频增量保新鲜低频全量做校准。在设计同步机制时可以用生产就绪自查表核对索引新鲜度、删除传播和回滚边界避免只验证新增路径。三、上线前固定四个运行约束1. 为每个文档和分块保存稳定 ID以及来源版本。2. 明确索引新鲜度 SLA避免“多久同步一次”无人负责。3. 定期比对源系统与索引识别孤儿向量和旧版本。4. 全量重建使用新旧索引切换保留可验证的回滚窗口。RAG 的答案质量不只取决于召回算法也取决于索引维护是否可审计、可删除、可回滚。把索引当作会过期的生产缓存来治理才能避免系统在没有报错的情况下持续引用旧事实。