向量索引如何处理更新和删除？
面试怎么回答
我会先区分 Metadata、内容、Embedding 模型和删除四类变化。更新采用业务主键加版本，新向量验证后再切换 Active Version；删除先用墓碑或状态保证立即不可见，再异步物理清理。墓碑过多时做 Compaction 或影子索引重建，并用变更日志追平增量。最后通过源端与索引的主键、版本、删除和孤儿数据对账，保证可见性一致。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
“更新一条向量，直接覆盖原值不就行了？”
在很多近似索引里，向量不仅是一行数据，还参与图结构、倒排桶或量化编码。覆盖存储并不代表索引结构已经正确更新。
生产方案要把权威数据、索引可见性、墓碑删除和后台重建分开设计，并通过版本与对账保证一致。
先区分四种变化
Metadata 修改，例如权限或状态变化，可能不需要重新计算向量，但必须更新过滤索引；正文修改需要重新切分和 Embedding；模型升级会改变整个向量空间；删除则要求旧对象立即停止召回。
不同变化不能都走“重新 Add 一条”。否则旧 ID、旧模型和旧权限很容易残留。
更新通常采用新版本写入
为对象保存业务主键、向量 ID、内容版本、Embedding 版本和更新时间。新向量先写入并验证，再通过 Active Version 或别名切换可见性。
如果具体索引支持原位更新，也要确认它对图边、倒排桶、量化数据和并发查询的语义。对不支持稳定更新的实现，Delete + Add 或影子索引通常更可控。
这里还要明确读写并发语义：切换前的请求继续读取旧版本，切换后的请求只读取新版本，不能让一次查询在两个版本间漂移。批量更新时可以按租户或分片推进，但每个业务对象的可见版本必须唯一。
删除需要逻辑与物理两阶段
逻辑删除通过状态、墓碑或过滤表让对象快速不可见，优先满足权限和合规；物理删除在后台清理索引节点和存储空间。
墓碑长期累积会增加过滤和搜索成本，因此需要 Compaction 或周期重建。重建时要处理同时发生的新写入，可使用变更日志追平，再原子切换索引版本。
对账比一次写成功更重要
向量库通常不是权威源。定期按业务主键和版本检查源端对象数、Active 数、删除数、Embedding 版本和孤儿向量。
写入接口成功，只能说明请求被接受，不一定代表查询已经可见。监控要区分写入延迟、索引构建延迟和查询可见延迟。
对于权限撤销和合规删除，不能只等待后台重建。应先在查询过滤层阻断，再验证缓存、重排服务和离线副本是否同步失效。
一个典型场景
文档更新后系统用新随机 ID 写入，却没有找到旧 ID 删除。搜索结果开始同时出现两份内容，重排有时还把旧版本排在前面。
后来改为稳定业务键 + 内容版本，查询只读取 Active Version，并对旧版本做墓碑与延迟清理。真正修复的是生命周期，而不是调相似度阈值。