知识库更新最容易被低估。产品同学说“补几份最新文档”，研发把文档切分、向量化、入库，第二天用户问答效果反而变差：旧问题答偏了，新问题引用不稳定，有些答案混着新旧口径。表面上只是上传资料，实际改动的是 RAG 的整条检索链路。
这类经历放到面试里，比单纯介绍向量数据库更有价值。因为它说明你知道 RAG 不是静态功能，而是一个持续更新的线上系统。
文档变了，切分结果也会变
知识库更新不只是多了几段文本。标题层级、段落长度、表格格式、版本说明都会影响切分。如果切分策略稍微变化，同一份文档可能生成完全不同的片段。片段变了，向量表示变了，召回结果也会跟着变。
所以不能只问“文档有没有入库成功”。更应该看：新增片段数量是否异常，平均片段长度是否变化，重复片段是否增多，旧文档是否被新版本正确替换。RAG 里的很多坏答案，源头不是模型，而是检索材料本身变形了。
灰度要从问题集开始
知识库灰度不一定像服务发布那样按机器分流。更适合 RAG 的做法，是先用一批固定问题集验证新索引：高频问题、长尾问题、无答案问题、版本敏感问题、容易误召回的问题都要覆盖。
如果新索引只在新文档相关问题上变好，却让大量旧问题变差，就不能直接全量。一个有用的指标不是“新文档命中率上升”，而是“旧问题没有明显退化，新问题有稳定提升，错误引用没有增加”。
新旧索引最好能并存一段时间
如果条件允许，知识库更新不要直接覆盖旧索引。保留索引版本，可以让同一个问题分别跑旧版和新版，对比召回片段、重排结果和最终答案。出现问题时，也能快速回滚到旧版本。
这里还要注意缓存。很多 RAG 系统会缓存问题、召回结果或最终答案。索引更新后，如果缓存没有带版本，用户可能继续拿到旧答案；如果全部清空缓存，又可能造成短时间成本和延迟上升。比较稳的做法是把知识库版本纳入缓存键或失效策略。
引用错误比召回失败更难发现
召回不到资料，答案可能会空；召回到相似但不正确的资料，答案反而会显得很完整。这就是知识库更新后最危险的地方：模型拿到了看似相关的片段，生成了流畅但口径错误的回答。
因此灰度验证里要看引用是否真的支撑结论。特别是政策、价格、接口字段、权限规则这类版本敏感内容，不能只看答案像不像，还要检查证据是不是来自正确版本。
面试里可以把它讲成发布流程
如果被问到 RAG 知识库怎么维护，可以不要只说“定期更新 embedding”。更像工程项目的回答是：新文档先进入待发布版本，经过切分质量检查和固定问题集评测；通过后小范围启用新索引，并记录索引版本、召回片段和引用；观察坏例和用户反馈；确认没有退化后再扩大范围；出现问题时可以回滚索引和缓存。
RAG 的上线对象不只是代码，还有知识。知识也会引入回归，也需要灰度、评测和回滚。能讲清这一点，说明你理解的是 AI 应用工程，而不是只会接一个检索接口。
项目里还可以补一句权限边界：知识库灰度不能让用户看到本来无权访问的新资料。新索引、新缓存、新引用展示都要继续走权限过滤。否则一次知识更新可能同时带来答案退化和数据泄露风险，这比普通召回错误更严重。