RAG 系统的长期价值，很大程度上取决于知识库能否保持“新鲜”。如果知识库内容陈旧、矛盾或缺失，检索增强的所有优势都会大打折扣。本节聚焦在实际工程中如何建立一套可靠、轻量、可审计的知识库更新机制。
23.1.1 更新的基本单位：文档与切片
在 RAG 系统中，知识库由大量文档及其切片后的向量组成。更新操作的最小粒度通常是切片，但管理上以文档为单元更自然。常见操作有三类：
- 新增：上传新文档，切片后生成向量并插入数据库。
- 修改：对已有的某个文档进行修订。实际操作是删除该文档对应的旧切片，插入修订后的新切片。
- 删除：将指定文档的全部切片从向量数据库中移除。
保持“文档→切片”的映射关系至关重要。建议在入库时记录每一切片的元数据，包括 doc_id、版本号、更新时间等，以便精确替换和回滚。
23.1.2 增量更新与全量重建的选择
根据更新频率和知识库规模，有两种主流策略：
- 增量更新（推荐）
仅对发生变化的文档执行新增/修改/删除操作。优点是响应快、开销小，适合大多数业务场景。例如，运营人员修改了一份产品说明，只需通过脚本把对应切片替换，几秒钟内即可生效。
- 全量重建
当向量数据库升级、切分策略调整（如 chunk 大小、重叠量改变）或嵌入模型更换时，需要对全部文档重新切片和向量化，然后整体替换索引。全量重建通常作为后台批处理任务执行，期间可保持旧索引继续服务，完成后再切换。
实用建议：日常更新走增量流程；每月或每季度安排一次全量重建，以消除长期增量累积带来的碎片和不一致。
23.1.3 更新触发方式
根据企业的运作模式，更新触发可以非常灵活：
- 人工触发：这是最常见的方式。业务人员编辑完内部 wiki 或上传新政策文件后，在管理后台点击“同步更新”。适合文档变更有明确审核、发布流程的场景。
- 定时任务：对数据源稳定、更新频繁的场景（如每日汇率文件、舆情简报），可通过 cron 作业定时拉取最新数据，自动执行切片和入库。
- 事件驱动：通过 webhook 或消息队列，监听 CMS、文档管理系统的内容变更事件，实时触发更新。适合对实时性要求极高的场景（如交易风控规则）。
不管采用哪种方式，都应设计一个简单的审核界面，让管理员可以预览更新后的切片内容，确认无误后再发布。
23.1.4 版本管理与回滚
知识更新难免有失误，例如误删重要条款或上传了未生效的草稿。因此，版本管理不是可选项：
- 保留文档版本历史：在元数据中记录
version字段，每次更新递增。向量数据库中的切片也带有版本标签。 - 软删除机制：删除操作不必物理清除数据，而是标记为
status=inactive，查询时过滤掉。这样回滚时只需重新激活旧版本切片。 - 一键回滚：管理后台提供“回滚到上一个版本”按钮，操作后旧版本切片立即恢复在线，整个过程在秒级完成。
以某保险公司为例，他们的合规助手曾因一次误操作将未审批的条款上线，导致客服回答出现偏差。因为他们保留了版本历史，运维人员在接到通知后两分钟内回滚到前一版本，避免了合规风险。
23.1.5 质量验证与监控
更新完成后，不能假设“入库即正确”。需要配套简单的验证手段：
- 抽样测试：准备一组固定的测试问题（例如 50 个常见问法），在每次更新后自动跑一遍，对比回答是否包含预期关键词、是否引用正确的文档版本。如有异常，告警通知。
- 检索命中率监控：统计新入库切片在后续真实查询中的命中率。如果某个重要政策更新后长期没有被检索到，可能说明切分或索引有问题。
- 人工抽检：定期随机抽取近期更新的文档，输入几个相关问题验证回答质量。这可以由业务专家而非工程师完成。
23.1.6 更新流程示例
下面是一个典型的增量更新操作序列，可作为实现参考：
- 文档作者在内部知识库中修改了《差旅报销标准》，将“住宿费上限 500 元”改为“600 元”。
- 系统监测到文档变更（或作者手动触发更新），调用更新 API。
- 后端根据
doc_id删除该文档的所有旧切片。 - 对修订后的文档重新切分，生成 8 个新切片，向量化后插入数据库。
- 更新元数据：
version: 2, updated_at: 2025-03-15T10:30:00。 - 自动测试集跑过，确认“住宿费上限是多少”的回答已变为 600 元。
- 若测试失败，自动告警，管理员手动回滚至版本 1。
通过上述机制，RAG 系统的知识库可以保持高频率、低风险、可追溯的更新节奏，真正将“知识实时保鲜”从口号变为日常运维能力。