本地RAG知识库刚开始只有几十个文件时，全部重建一次也不麻烦。资料变成几千份以后，每新增一个PDF都重新OCR、切片、做embedding，会浪费大量时间和算力。更实用的方式是做增量更新：只处理新增、修改和删除的内容，同时保证旧索引不会残留过期版本。不要只靠文件名，因为文件会改名或移动目录。稳定ID能让系统知道这是同一份资料的新版本。

保存内容哈希

每次扫描文件时计算哈希，内容没变就跳过。这样可以避免无意义的重复embedding。

新增文件只处理新内容

新文件完成解析、切片、向量化后直接加入索引。不需要触碰其他已有文档。

增量更新不是把新文档不断加入向量库而已，同一价格表改过三次后，旧切片如果仍然活跃，检索很可能同时召回三个版本。应用应根据文件ID、内容哈希或版本记录撤销旧数据。

修改文件要先清旧切片

如果只加入新版本，旧版本仍可能被检索到。先根据文件ID删除旧chunk，再写入新chunk。

删除文件也要更新索引

硬盘上删了PDF，不代表向量库里的旧内容自动消失。删除流程要同步清除向量和元数据。

记录切片版本

如果你改变chunk size或overlap，旧向量和新向量可能不兼容。这种结构性变化通常需要更大范围重建。

嵌入模型升级要单独处理

换embedding模型后，语义空间可能完全不同。不要把两个模型生成的向量直接混在同一索引里。

完整流程可分为新增、变更和删除三条路径。新增文件解析索引；变更文件重建受影响的切片；删除文件同步清除索引、派生摘要和相关缓存。

元数据也要增量更新

标签、权限、日期变化不一定需要重新做向量。可以只更新数据库中的元数据字段。

建立更新队列

文件变化后先进入队列，再由后台逐个处理。这样大量上传不会把系统一次性打满。

失败任务要能重试

某个PDF解析失败，不应该让整个增量任务重新开始。记录每个文件的处理状态和错误原因。

更新后做抽样搜索

新增文件选几个关键词测试，修改文件确认旧答案不再出现。删除文件也要验证搜索不到。

定期做一次完整一致性检查

增量更新跑很久以后，可能出现孤儿向量或状态异常。每月或每季度做一次源文件和索引的对账。备份方面可以参考本地知识库备份指南。增量更新解决日常效率，备份解决真正出故障后的恢复，两者缺一不可。

上线前准备固定的问题集，检查新内容能找到、旧内容不再作为当前依据、未修改的内容仍可检索。这样才真正验证了“增量”没有牺牲正确性。

本地RAG 增量更新的第1轮检查

真正上线前，建议把这个流程固定成可重复的测试：准备一组正常样本、一组容易出错的边界样本，再记录输入条件、模型或工具版本、实际结果和人工修正点。这样下次更换模型、升级软件或修改参数时，就能直接比较前后差异，而不是凭感觉判断“好像变好了”。如果是团队使用，还要把负责更新的人、检查频率和回滚方式写清楚。工具越自动化，越需要知道失败后怎么恢复、哪些数据不能丢、哪些动作必须重新确认。这样才能把一次性的AI技巧变成稳定工作流。

本地RAG 增量更新的第2轮检查