索引更新与维护
知识库是活的。文档新增、修改、下架都要反映到索引里，索引更新的设计决定知识的新鲜度和系统的一致性。
更新策略
| 策略 | 做法 | 适用 |
|---|---|---|
| 全量重建 | 全部文档重新解析、分块、嵌入、入库 | 数据量小、一次性导入、嵌入模型升级 |
| 增量更新 | 只处理变更的文档 | 生产常态，文档持续变化 |
| 定期全量校准 | 定时全量重建兜底 | 修正增量管道积累的错误 |
嵌入模型升级必须全量重建，不同模型的向量空间不可比，这是硬约束。
异步更新管道
索引更新管道
生产环境用消息驱动：文档平台发变更事件，管道消费事件做解析、分块、嵌入、入库。要点：
- 幂等：同一事件重放不产生重复块，靠文档 ID 加版本号去重
- 版本化：文档带版本号，旧版本失效自动标记，回答引用能指向当时版本
- 批量嵌入：变更多时批量调嵌入接口，控制成本和限流
删除合规
内容删除（合规要求、文档下架、版权）在 RAG 里比想象中麻烦：文档删了，块还在向量库里。必须按文档 ID 级联删除所有块，并有定期扫描确认没有孤儿块。这也是“私有数据不进权重”的延伸优势：RAG 能删，微调不能。
一致性
- 更新期间的读一致性：正在重建的文档，旧块可能被检索到。按版本号过滤或原子切换
- 索引与源文档的一致性：定期对账，源变了索引没跟上就是脏数据
- 监控指标：索引新鲜度（最老未更新文档的时长）、管道失败率、孤儿块数量
面试追问
- 增量更新还是全量重建？ 生产常态是增量更新，嵌入模型升级时全量重建。数据量小也可以直接全量
- 为什么换嵌入模型必须重建？ 不同模型的向量空间不可比，混合使用检索结果混乱
- 删除文档怎么处理？ 按文档 ID 级联删除所有块，定期扫描孤儿块。这是 RAG 相对微调的优势，能删
- 更新期间检索到旧数据怎么办？ 文档版本号加原子切换，旧版本标记失效
- 怎么监控索引健康？ 新鲜度、管道失败率、孤儿块数量。源变了索引没跟上就是脏数据