RAG 知识库怎么做版本管理和回滚？
面试怎么回答
知识库的文档内容、解析和切分逻辑、Embedding 模型、索引配置都会变，都要可追溯可回滚。文档层面每份文档有 ID、版本和内容哈希，原始文件保留历史版本，Chunk 记录来自哪个文档版本和处理配置版本。大变更用蓝绿切换：新建索引全量构建，在评测集上对比通过后用别名切换，旧索引保留一段时间用于回滚。日常增量更新做入库前质量检查，记录每批更新清单以便按批次撤回，更新后跑冒烟评测。如果 Chunk 和向量存在支持快照的表格式里，还可以用时间旅行回到之前的快照。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
一次批量更新，把一批格式错误的文档导进了知识库，或者换了新的切分策略，结果线上回答质量明显下降。这时候能不能快速回到上一个好的状态？面试官问知识库的版本管理，其实是在问你有没有把知识库当成一个需要发布管理的数据产品。
哪些东西会变
- 文档内容：新增、修改、删除；
- 处理逻辑：解析器、切分策略、上下文补充方式；
- Embedding 模型：换模型后所有向量都变了；
- 索引配置：索引类型和参数、元数据字段。
每一种变化都可能影响检索效果，都需要可追溯、可回滚。
文档层面的版本
- 每份文档有唯一 ID 和版本号，记录内容哈希、来源、更新时间；
- 原始文件保留历史版本（对象存储开启版本控制）；
- Chunk 记录它来自哪个文档的哪个版本，以及用的处理配置版本。
这样能回答「这个回答是基于哪个版本的文档」。
索引层面的版本：蓝绿切换
大的变更（换 Embedding 模型、换切分策略、大批量导入）不要直接改线上索引：
- 新建一个索引（或集合），用新配置全量构建；
- 在评测集上对比新旧索引的召回率和回答质量；
- 通过后，把查询服务指向新索引（别名切换）；
- 旧索引保留一段时间，出问题时切回别名即可回滚。
这和数仓里「新表跑完校验通过再切换」的思路完全一样。
日常增量更新
小的增量更新直接写线上索引，但要：
- 有入库前的质量检查：解析是否成功、字符数是否异常、是否重复；
- 记录每批更新的内容清单，出问题时能按批次撤回（删除这批新增的 Chunk、恢复被修改文档的旧版本 Chunk）；
- 更新后跑冒烟评测。
数据湖里的做法
如果 Chunk 和向量也存在 Iceberg、Lance 这类支持快照的表格式里，可以利用它们的时间旅行能力回到之前的快照，再重建或同步到在线检索服务。