考察点
这道题出自小米 AI 大模型开发二面，属于 RAG 工程落地里很实际的一环，考的是你有没有真的运维过一个活着的知识库。面试官想听的不是「更新一下就行」，而是一套完整的增量更新机制：怎么感知变更、怎么定向更新向量库、删除和修改怎么处理、一致性怎么保证。追问可能往「向量库支持删除吗」「更新期间用户搜到旧版本怎么办」走。
参考答案
先明确：全量重建是最后手段，不是日常手段
确实不能每次全量重建。一个几十万 chunk 的知识库，全量重建要重新跑 embedding 推理加重建索引，几十分钟到几小时，期间还要考虑索引可用性。日常更新必须是增量的，全量重建只留给换 embedding 模型、改切分策略这种结构性变更。
增量更新的核心：文档级版本管理
方案的地基是在文档和 chunk 两个层级都维护标识和版本：
每个文档有 doc_id 和版本号（或内容 hash），每个 chunk 记录它所属的 doc_id。文档发生变更时，处理逻辑是：按 doc_id 删掉向量库里该文档的所有旧 chunk，对重新切分后的新 chunk 算 embedding 写入。主流向量库都支持这个操作——Milvus、Qdrant、Elasticsearch 都可以按 metadata 条件删除，不需要动索引里其他文档。
这里的关键设计是「删旧插新」而不是「就地更新」：文档内容变了，切分结果通常也变了，chunk 的数量和边界都对不上，逐 chunk 对比 diff 得不偿失。以文档为原子单位整批替换，简单且不会留下孤儿 chunk。
怎么感知变更
三种机制按场景组合：
- 源系统推送：文档系统（Confluence、语雀、Git 仓库）有 webhook 或事件通知，文档保存/删除时触发更新管道，实时性最好，是首选；
- 定时轮询比对：对不支持事件的源，定期拉取文档列表，比对更新时间戳或内容 hash，发现差异进入更新队列；
- 消息队列削峰：变更事件进队列，消费者批量处理，避免高峰期大量文档同时变更打爆 embedding 服务。
删除操作容易漏但很重要：源文档删了，向量库里的 chunk 不删，RAG 就会召回一个已经不存在的文档，轻则答案引用失效，重则泄露已下线的内容。所以删除事件要和更新事件走同一条管道。
更新链路里的工程细节
一是异步化和失败重试。embedding 推理和向量库写入都可能失败，更新任务要有状态记录和重试机制，失败的任务告警人工介入，不能静默丢掉——丢一次更新就是一个长期的脏数据。
二是更新期间的读写一致性。删旧插新之间有个时间窗，用户可能搜到空或搜到新旧混合。简单场景可以接受（秒级窗口）；要求高的话可以用版本标记：新 chunk 先以新版本号写入，全部写完后切一个「当前版本」指针，再删旧版本，实现原子切换。这和搜索引擎索引的 segment 切换是一个思路。
三是成本。增量更新一次的代价只是变更文档的 embedding 推理，相比全量重建是几个数量级的差别。hash 比对保证没变的文档完全不碰。
容易被追问的一个坑：embedding 模型升级怎么办
这是增量机制解决不了的情况——换 embedding 模型意味着新旧向量不在同一个语义空间，不能混存。做法是影子索引：新模型离线建一个全新的集合（collection），建完后切流量，旧集合保留观察一段时间再下线。Milvus、Qdrant 都支持多 collection，切换成本很低。切分策略变更同理。
收尾
一句话总结方案：文档级版本管理 + 事件驱动的增量管道 + 删旧插新的原子替换，覆盖日常更新；全量重建降级为结构性变更（换模型、改切分）的专用流程。再补一句监控：更新延迟（文档变更到可被检索的耗时）和失败率要进监控看板，不然知识库悄悄过期没人发现。
可能的追问
- chunk 内容里引用了其他文档的信息，被引用的文档更新了呢？ 答：这是 chunk 间依赖问题，实践上不做跨文档追踪（复杂度爆炸），靠切分时让 chunk 尽量自包含、以及定期全量校验兜底。
- 向量库删除是真删吗？ 答：多数是逻辑删除标记，空间在 compaction 时回收；频繁增删的库要关注存储膨胀，定期 compact。
- 怎么验证增量更新的正确性？ 答：离线抽查——随机取变更过的文档，检索其新内容能召回、旧内容召不回；再跑一个固定的回归评测集确认整体召回指标没有退化。