直接给结论：政策类、文档类知识库频繁更新，千万别每次都全量重建向量库。又慢又费，还容易在重建窗口里查不到。这篇讲怎么做增量。

我们维护一个政策问答库，几百份文件，平均每周改个十来份——发个补充通知、改两个条款。最早图省事，每次更新就全量删了重灌。结果两个问题：一是慢，几百份重新切片、重新embedding,跑一次小半小时；二是重建那段时间库是空的或半残的，用户来查命中不了，业务投诉过来。

增量怎么做，分几块：

一、给每份文档算个指纹。 我用文件内容的哈希当版本标识，存一份"文档→哈希"的映射表。每次同步先比对，哈希没变的直接跳过，连切片都不做。这一步就把工作量砍到只剩真正变了的那几份。

二、变了的文档，先删旧块再插新块。 关键是删干净。每个向量块要带上来源文档ID,更新某份文档时，先按文档ID把它的旧向量全删掉，再把新内容切片灌进去。漏删旧块是最常见的坑——会导致旧政策和新政策同时被召回，用户拿到过期答案，比查不到还糟。

三、删除的文档要能同步删。 文件被下架了，对应向量也得清掉。我在映射表里做了个"本轮没出现的文档ID",收尾时统一删除其向量。不做这步，库里会残留幽灵文档。

四、更新做成定时任务，别手动。 我挂了个每天凌晨跑一次的同步，扫源目录、比哈希、增量更新，全自动。手动同步迟早会忘。

讲个真实的坑：政策文档常有"附件3见正文"这种跨文件引用，按单文件切片会把上下文切断，召回回来是半句话。这个增量更新本身解决不了，得在切片策略上单独处理（我把强关联的附件和正文合并成一个逻辑文档再切）。所以增量更新省的是"重复劳动",切片质量该花的功夫一分不能少。

落地我用的是一个零代码搭智能体、带场景化知识库的平台，知识库支持按文档增量管理、配定时同步，不用自己写向量库的增删改脚本。但有个取舍：它的切片粒度是几个预设档，特别刁钻的文档结构（比如复杂表格嵌套）自动切的效果一般，得自己拆好再传。

一句话：增量更新的本质是"只动该动的",指纹比对+精准删插+定时调度，三件事做到位就稳了。

（嵌入和问答模型我都接的讯飞 MaaS,现成调，没自己跑GPU。）