知识库更新策略怎么选?

这道题其实问的不是单纯的“怎么把数据灌进去”，它本质是在问：在一个实时性、一致性和检索质量三方博弈的系统里，你怎么做工程取舍。如果只让我说一句话，那就是：没有万能的更新策略，只有按场景配比的方案。

先说策略的边界。全量重建，就是每天或每周把整个知识库重新[[分块]]、重新生成 [[Embedding]]，再全量替换。好处是数据一致性最强，能彻底清理脏数据，坏处是成本高、耗时长，适合数据量小或者变更不频繁的场景，比如企业内部的合规文档，半年更新一次，你全量重建完全没问题。但如果是电商的实时库存，或者金融的实时价格，全量重建根本来不及，这时候就要上增量更新。增量更新只处理变更的数据，新增、修改、删除分别走不同的逻辑。真正落地的时候，很少只用一种策略，往往是全量加增量混用。比如白天跑增量，凌晨低峰期跑一次全量做对账修复。

具体到增量更新的实时性方案，我一般会分几层。最底层是数据源变更捕获，比如监听数据库的 binlog 或者业务的消息队列。如果业务系统本身就发变更事件到 Kafka，那就直接消费。如果没有，就需要自己搭 CDC 组件。拿到变更之后，不能直接写[[向量库]]，因为向量库的索引对高频写入很敏感。我的做法是：新增数据直接插入，修改数据拆成“旧版本软删除加新版本新增”，删除数据不原地动索引，而是维护一个删除标记列表，后台异步重建索引。这里有个坑：千万不要在 [[HNSW]] 或 [[IVF]] 这种图索引/聚类索引上直接做删除操作，否则检索质量会崩。

一致性保障是另一个难点。说白了，你要保证业务数据库和向量库最终一致。我常用的手段是：消费端做幂等处理，每条记录带版本号或时间戳，写向量库时做 upsert 语义。检索的时候，带版本过滤，只取最新版本。这还不够，我会加一个定期对账任务，比如每小时比对源库和向量库的记录数、计算 hash，发现不一致就自动补发。上线前还要做灰度，新索引先在小流量上跑，对比召回率，达标了再全量切换。

还有一个容易被忽视的点：更新对检索质量的影响不只是数据对不对，还有向量空间的漂移。比如你新增了一批文档，它们的 embedding 分布可能跟旧数据有偏移，导致召回率下降。这个怎么监控和修复，其实比单纯的数据同步更复杂。

所以我的整体判断是：知识库更新不能只当成数据管道来做，要当成一个带质量门禁的系统。我更倾向按变更类型分类处理，低频重要数据用全量加双写事务，高频海量数据用增量加异步对账。每轮更新上线前，必须用固定 query 集回放，对比 Recall@K 和延迟，通过才原子切换，不通过就回滚。