RAG 项目第一次跑通并不难：文档切分、向量化、召回、拼上下文、生成回答。但真正上线后，知识库会不断更新，问题也会变复杂：昨天能回答的问题今天答错了，新文档加进去后旧答案变差，用户看到的依据片段和答案对不上。
这类问题很适合作为面试深挖点，因为它能区分“做过演示”和“考虑过长期维护”。RAG 的质量不是一次性建好索引就结束，而是持续更新中的系统工程。
更新不是覆盖文件那么简单
知识库更新至少涉及文档版本、切分结果、向量索引、元数据、权限和缓存。如果只替换文档文本，却没有同步更新向量和缓存，系统可能仍然召回旧片段。如果新旧版本同时存在，又没有版本过滤，模型可能拿到互相矛盾的资料。
更稳的设计是给文档、段落和索引都带版本。更新时先生成新版本切片和向量，通过灰度或原子切换让检索使用新版本；确认无误后再清理旧版本。对于重要知识库，还要保留回滚能力。
切分变化会影响召回
很多人低估切分策略的影响。同一篇文档，按标题切、按固定长度切、按语义段落切，召回结果可能完全不同。知识库更新后，如果切分边界变化，原来的高质量片段可能被拆散，答案质量就会下降。
这也是为什么 RAG 需要坏例回归。不能只看新文档是否入库成功，还要跑一批典型问题，确认关键答案仍然能召回到正确片段。尤其是规章制度、产品说明、技术文档，版本更新后最怕新旧规则混用。
缓存也会制造旧答案
RAG 系统常常会缓存检索结果、重排结果或最终回答，以降低成本和延迟。但知识库更新后，缓存如果不失效，用户可能继续看到旧答案。更隐蔽的是：检索缓存更新了，回答缓存没更新，最终表现仍然像知识库没变。
文档内容更新：如果没同步处理是向量仍是旧片段，用户看到的现象是回答引用过期信息。切分策略改变：如果没同步处理是召回上下文断裂，用户看到的现象是答案缺关键条件。
- 权限规则变化：如果没同步处理是旧缓存未过滤，用户看到的现象是看到无权限资料。
- 提示词更新：如果没同步处理是回答缓存未失效，用户看到的现象是输出风格或规则不一致。
面试里要讲运维闭环
RAG 上线后，至少要监控召回命中、无答案比例、用户点踩、答案引用片段、知识库版本和缓存命中。出现坏例时，要能定位是资料缺失、切分问题、向量版本问题、权限过滤问题，还是模型没有按证据回答。
一个成熟表达可以是：我会把知识库更新当成一次发布，而不是简单上传文件。更新要有版本、索引构建、缓存失效、灰度验证和坏例回归；如果质量下降，可以回滚到旧版本。这样回答比“我用了向量数据库”更接近真实 RAG 项目。