RAG 知识库更新，为什么推荐「先删后增」而不是局部更新？

先这样答

推荐先删后增，因为文档和向量是一对多关系。一份文档会被切成多个 chunk。文档内容一变，chunk 的数量可能变化，边界也可能变化，具体内容还可能变化。

这时，旧 chunk 和新 chunk 没法稳定地一一对应。工程上如果强行做局部更新，就要先判断哪些旧 chunk 对应哪些新 chunk。这个对应关系本身不可靠，也会让更新逻辑变复杂。

更简单的做法是，先删掉该文档对应的全部旧 chunk，再按当前规则重新切割文档，最后把新 chunk 重新入库。这样不需要维护旧新 chunk 的对应关系，结果也更容易确认。局部更新只有在切分策略完全稳定时理论上可行，生产环境不应该押这个前提。

面试官会怎么追问

• 「为什么文档内容只改了一小段，也不能只更新受影响的 chunk？」 因为这一小段内容可能改变 chunk 的边界。后面的 chunk 也可能随切分结果发生变化。旧 chunk 和新 chunk 仍然不能稳定对应，所以直接删掉该文档的全部旧 chunk，再重新切分更可靠。

• 「先删后增的核心收益是什么？」 核心是把复杂的对应关系变成一次完整重建。系统只需要识别文档，删除它的旧 chunk，再写入重新切分后的结果。这样流程简单，结果也更容易检查。

• 「什么情况下可以考虑局部更新？」 只有切分策略完全稳定时，局部更新才有理论可行性。此时还需要保证旧 chunk 和新 chunk 能够可靠对应。生产环境不应该把这个前提当成默认条件。

回答的坑

• 把文档和向量说成一对一，忽略一份文档会对应多个 chunk。
• 只盯着修改的文字，忽略内容变化可能影响 chunk 数量、边界和整体内容。