RAG 如何动态且不停服地更新知识库？

核心回答

把知识更新与在线查询解耦：日常变更做增量处理，模型或切分迁移做后台重建，校验后切换可查询版本。在线请求持续读取一个完整有效版本，不能先删空旧库，再等待新索引生成。

同时维护文档ID、版本、处理状态和派生片段关系，新增、修改、删除与权限变化都进入更新链路。服务不停不代表数据瞬时最新，应明确业务能接受的同步延迟和紧急撤回要求。

日常增量怎样处理

用事件通知、CDC或轮询发现变化，记录来源版本及处理水位，进入持久队列。处理器解析、清洗、切分、Embedding并更新索引，按文档ID和版本幂等；较旧任务迟到时不能覆盖新版本。

修改后新片段数量可能变化，需要识别并撤销旧版残留。删除通过文档到片段的映射覆盖全文、向量、摘要与缓存；不能只删原文件却让索引继续返回。处理失败保留可查询状态与重试记录，定期与源系统对账防漏更。

全量重建怎样不停服

从快照或确定水位建立新版本，旧版本继续服务；重建期间继续记录变更，并在切换前追平增量。用固定查询检查证据、权限、版本和成本，确认新索引能够正常读取，再切换统一入口。保留旧版本供回退，等在途请求结束后再清理。

Qdrant等系统支持原子切换集合别名，但这只保证相关别名操作，不会自动原子更新外部数据库、全文索引和缓存。多检索通道可以共同绑定一个发布版本清单，请求开始时固定版本；切换方案需覆盖全部消费者。

全量迁移可以按下面几个阶段推进，构建期间仍由旧版本持续服务：

flowchart TB
  A["v1 服务，v2 后台构建"] --> B["追平增量并校验 v2"]
  B --> C["发布完整 v2 版本清单"]
  C --> D["新请求固定读取 v2"]
  D --> E["保留 v1 供在途请求与回退"]
  E --> F["条件满足后清理 v1"]

图中 v1 和 v2 是完整检索版本。涉及新 Embedding 时，文档向量与查询编码器一起配套；别名原子切换的保证范围不自动覆盖外部索引或缓存。

更换Embedding有什么特殊点

新旧模型即使维度相同，也可能处于不同空间。为新模型重建文档向量，并让查询编码器随检索版本配套切换，不能把新query向量直接查旧库。灰度或双读对照时分别走各自完整链路，再比较结果。

权限与故障怎样控制

权限收紧或紧急撤回不能只等低优先级重建，可在查询访问层先做即时禁止，再清理索引与缓存；派生内容也继承限制。普通更新的旧版可用策略与敏感撤回要分开。

监控源变化到可检索的延迟、队列积压、失败与残留旧块，并在发布前后跑关键回归。更新崩溃、重复事件、乱序和回退都要测试，才能证明不停服同时没有静默丢知识。

参考资料