怎么考「知识库更新了，向量索引怎么增量更新？删除的文档怎么办？」

怎么知道哪些文档需要更新？

期望

上游变更检测——文件哈希/mtime 比对、业务系统的变更事件（CDC、消息队列）、定时全量扫描做兜底对账。理想是事件驱动 + 定期对账双保险，因为事件可能丢。

信号

只说「定时全量重跑」的，没做过成本优化；能提「事件驱动 + 对账兜底」的，是做过数据同步的。

一个文档改了一句话，要重算整个文档的向量吗？

期望

不用——做 chunk 级哈希对比，只重算内容变化的 chunk。但要注意边界效应：如果分块是按语义或滑动窗口切的，改一句话可能导致后续所有 chunk 的边界偏移，那就只能整篇重切。按结构（标题）切分的文档在这方面稳定得多，这是结构感知切分的一个隐藏好处。

信号

能想到「边界偏移」这个细节的，是真做过增量更新。

软删除积累多了具体会怎样？怎么监控？

期望

图连通性劣化 → 召回率下降、查询变慢；存储不释放。监控手段：跟踪软删除占比（比如超过 20–30% 触发告警）、定期在评测集上跑 recall 看有没有缓慢下滑。处理：定期 compact 或在低峰期重建。关键是这种劣化是渐进无声的，不主动监控发现不了。

信号

能说出「渐进劣化、需要主动监控」的，运维过真实系统。

更新过程中用户正好在查询，会读到不一致的数据吗？

期望

会——比如新 chunk 写了一半，用户检索到了新旧混合的内容。解法：版本号过滤（用户只看到完整的某一版本）；或者用别名/指针切换（新版本全部就绪后原子切换指针）；pgvector 这类支持事务的库可以直接用事务保证。这也是 pgvector 的一个真实优势场景。

信号

能把这题连回「向量库选型时事务一致性为什么重要」的，知识成体系。

客户要求「文档删除后 5 分钟内不能再被检索到」，你怎么保证？

期望

分层设计——① 检索层用元数据黑名单立即过滤（不依赖向量库的物理删除，秒级生效）；② 缓存层同步失效（语义缓存、答案缓存都要清）；③ 物理删除异步执行；④ 加一条验证机制：删除后自动跑一次针对该文档的检索测试，确认返回为空，并记录审计日志。给出可验证的保证，而不只是「我们会删掉」。

信号

只答「调用删除接口」的，不理解软删除的存在；能提出「元数据黑名单立即生效 + 缓存失效 + 删除后验证」的，是能扛合规要求的方案。