在 RAG 系统中，知识库不是一次性建好就永远不变的，它需要像活的文档系统一样被持续维护。实际业务中，政策会修订、产品会下架、旧公告会过时。如果知识库不能准确反映当前的信息状态，再好的检索和生成能力也无从发挥。因此，增量更新、版本管理、删除同步 构成了知识库运维的三个核心环节，确保系统始终 “言之有据，且据为最新”。
增量更新：只动有变化的部分，不动整体
全量重建索引固然简单，但当知识库体量大、更新频繁时，重跑所有文档的嵌入和入库既耗时又浪费资源。增量更新就是在不重新处理所有内容的情况下，只对新增或修改的部分进行处理。
- 新增知识：新文档或新章节到来后，只对这部分内容进行切块、向量化，然后作为新记录插入向量数据库，已有的索引完全不用触动。
- 修改知识：文档的某个章节内容发生变化，只需重新处理该章节对应的切片，生成新向量，并用新版本替换掉数据库中代表旧内容的向量记录。其他未改动的切片维持原样。
- 合并更新：在实际操作中，可以设计成支持批量增量更新的轻量脚本或服务。比如每晚定时扫描知识库的文件修改时间，仅对当天有变动的文件重新索引。
实践要点：为了支持增量更新，建议在入库时为每个切片分配唯一的 ID（例如基于文件名+段落编号的哈希），并在更新时用相同的 ID 覆盖写入。这样既能避免重复，又能精准定位需要替换的内容。
版本管理：让每次修改都可追溯、可回滚
知识更新并非总是单向正确的。新版政策可能被撤回，产品参数可能回滚到上一版。如果更新仅仅是覆盖，一旦出错就很难恢复。版本管理就是对知识库内容的变化进行记录，使系统能够在必要时退回到任何一个历史状态。
- 保留变更历史：可以用两种常见方式实现：一是在向量数据库的元数据中标记每条向量所属的文档版本号，更新时不直接删除旧向量，而是将其标记为 “过期”，同时写入新版本向量。二是配合外部文档管理系统（如 Git 或对象存储的版本能力），将知识库的每次全量或增量更新作为一个版本快照保存。
- 快速回滚：一旦发现新上线的内容有误，只需回退到上一个版本：可以是在数据库中批量停用当前版本向量并恢复到上一版本，也可以是切换检索服务指向的索引别名到旧版本快照。
- 审计与调试：当某个回答引用的片段被质疑时，通过版本历史可以快速定位该片段是在什么时候、由谁、基于哪份文档版本入库的，方便责任认定。
简化的版本管理实践：在元数据中加入 version 字段（如 “v20250620”），检索时过滤 status = active 且 version = current_version。更新流程变为：写入新版本片段 → 将旧版本片段 status 设为 archived → 更新 current_version 指针。回滚就是反向操作。
删除同步：确保“不再存在的信息”立刻不再出现
知识库中最危险的错误，往往不是答得不全，而是提供了已失效、不应再引用的信息。比如旧的报销标准、下架的产品规格。删除同步要求当某份文档或其部分内容被判定为不再有效时，能迅速从检索结果中消失。
- 逻辑删除优先：通常不建议直接从向量数据库销毁数据，而是将其标记为删除状态（如
status = deleted），并确保检索过滤条件排除所有非活跃状态。这样做既可以快速生效，又保留追溯可能。 - 删除粒度对齐：如果删除的是整个文档，需要一次性将该文档关联的所有切片标记失效。如果只是删除了文中的一段（如修订掉了一条规定），则应对应地停用该段所对应的切片，并要求增量流程为修改后的文档重新生成新切片。
- 删除时效：在安全要求高的场景（如个人隐私信息被要求清除），可能需要物理删除向量，不能仅做标记。这时要确保向量数据库支持真正删除操作，并在删除后立即不可检索。
- 联动外部系统：当知识库源文档来自 CMS 或网盘，文档的删除事件应自动触发删除同步接口，避免人工遗漏。同时，如果系统提供答案引用，要注意已生成的历史回答可能仍带有已删除片段的缓存，处理不当会形成“引用失效”。一种做法是定期剪除或标记历史记录中指向已删除内容的引用。
一个接地气的流程示例：运营人员将过时的《差旅标准 2023》移至归档目录，系统监听到文件移除事件后，自动查找以该文件为来源的所有切片，将其状态更新为 deleted，并记入操作日志。下一条用户查询就不会再检索到这些内容。
增量更新、版本管理和删除同步，三者合力使 RAG 的知识库具备了企业级信息系统的可靠性。它们不只是一次性搭建时的考量，而是系统长期运行中必须内建的基础能力，直接决定了知识库能否持续可信。