先这样答
RAG 的知识库更新，麻烦不在「传新文件」，而在链路上每一层都可能留着旧数据。整条链路是：文档进来、切分成块、向量化、写进向量库，再往下游是检索层和答案缓存。文档改成新版之后，任何一层没跟着更新，检索命中的就还是旧内容，模型照着旧切片回答，用户看到的就是旧答案。
工程上的做法分三步。第一步，给每个切片带上元数据：来源文档、版本号、更新时间，入库和删除都以文档为单位对齐，改一版就把旧版本的切片清掉，不留孤儿切片。第二步，检索之后按元数据过滤，同一篇文档只让最新版本参与召回，避免新旧切片同时命中。第三步，管住缓存：检索结果缓存和答案缓存都要带版本或者设过期时间，文档一更新就失效对应条目，否则前面全做对了，缓存还是会吐旧答案。
更新频率上，数据量小、改动多就全量重建，简单可靠；库大了之后走增量更新，只处理变过的文档，删掉失效切片，写入新切片，平时增量、定期全量校准也是常见组合。上线前用新文档里的关键词实际检索一遍，确认能召回新内容，这一轮更新才算完成。
面试时可以收束为：知识库更新的检查对象是整条链路，切片元数据、检索过滤、缓存失效三处都对齐，旧答案才会真正消失。
面试官会怎么追问
-
「增量更新和全量重建怎么选？」 看数据量和变更比例。文档总量小、变更占比高，全量重建夜里跑一遍就完，最省心；库大了全量重建又贵又慢，走增量：对比文档指纹或更新时间，只处理变过的，并清掉失效切片。混合做法也常见，平时增量，定期用全量重建校准。
-
「用户现在就要新答案，缓存怎么办？」 缓存失效不能只靠过期时间。文档更新事件要主动清掉关联的检索缓存和答案缓存，粒度到文档或切片。做不到事件驱动时，至少把数据版本编进缓存键，版本一变，旧缓存自然失效。
-
「怎么发现线上在用旧数据回答？」 抽检加监控。定期拿最新文档里的关键事实去线上提问并核对答案；同时统计检索命中的切片版本分布，旧版本占比升高就是信号。把「答案引用了哪个版本的切片」记进日志，排查时有据可查。
回答的坑
- 只回答「重新导入一遍文件」。链路上旧切片、旧缓存哪一层会漏一个都说不清，等于没答。
- 只盯着向量库，漏掉检索过滤和缓存层。很多旧答案问题出在缓存，不在向量库。
同系列的题