模型、Prompt、数据和索引如何统一版本化并支持回滚？

面试时怎么答

制品版本化要先纠正“模型版本就是系统版本”的误区：一次响应还依赖 Tokenizer、Prompt、检索语料、Embedding、索引、代码和推理参数。随后说明不可变 ID、Manifest 依赖图与 production 别名如何配合发布和回滚，并交代敏感数据快照的隐私代价。

可以这样答：

LLM 响应不是一个 Git Commit 决定的，而是模型、Tokenizer、Prompt、检索语料、Embedding、索引、代码和推理参数共同决定。我会给每个制品不可变 ID，用 Manifest 记录依赖图，再让 production 别名指向已验证快照。代价是保留完整版本会增加存储和隐私成本，所以敏感输入只保留脱敏特征与授权快照。线上每次请求记录 Manifest ID，发布看版本混用率，演练回滚时间，并抽样验证同输入复现率。

核心回答

不要只给“模型”一个版本号，而要为每次发布生成不可变清单，至少绑定模型权重或供应商快照、tokenizer/chat template、适配器、Prompt、工具与输出 Schema、生成参数、安全策略、代码镜像、评测数据版本，以及 RAG 的 embedding、切分配置和索引快照。线上只通过可审计的环境别名（如 candidate、champion）指向清单，Trace 记录实际解析出的不可变 ID。

制品不可变，别名可变；晋级就是在门禁通过后原子切换别名，回滚则切回上一份完整清单。这样可以避免“模型回去了，Prompt 或索引却没回去”的半回滚。

展开说明

版本治理需要处理依赖而不只是存文件：

内容寻址：对自有制品保存 digest；托管模型记录供应商实际返回的模型标识与调用日期，不能假设营销名称永远不变。
数据血缘：训练、评测和索引数据保存来源、查询或快照时间、Schema、清洗代码和 digest，才能解释结果差异。
兼容矩阵：模型与 tokenizer、LoRA 基座、工具 Schema 和索引 embedding 需声明兼容关系，部署前自动检查。
数据迁移：会话或任务跨版本时采用双读、双写或显式迁移；回滚前确认旧代码仍能读取新数据格式。
审批与保留：高风险发布保存评测报告、审批人和变更原因；清理旧制品不能破坏审计或回滚窗口。

工程实践

CI 负责构建清单、计算 digest、运行兼容与回归门禁，再注册候选；CD 只部署已注册的不可变 ID。给每个线上响应附内部 release ID，并能从它反查全部依赖、评测和日志。定期做“从清单重建环境”和“切回上一版本”的演练，防止注册表里有记录但底层权重、数据或容器已经无法获取。

常见追问

Git 版本为什么不足以完整复现一次 LLM 响应？ Git 通常只覆盖代码和文本配置，不包含远端模型版本、索引快照、随机种子、推理后端与运行时参数。
可变别名和不可变模型版本分别承担什么职责？ 不可变版本负责审计与复现，可变别名负责灰度切流和快速回滚；请求日志应最终解析到不可变 ID。
RAG 的 Embedding 模型升级时，怎样避免新旧向量混用？ 建立新索引命名空间并双写或离线重建，检索端按版本成套切换，验证后再回收旧索引。

一句话复习

把模型、Prompt、数据、索引和运行参数绑定成不可变发布清单，用可审计别名晋级和原子回滚。

参考资料

面试题来源：AI Engineering Interview Questions 的 Prompt/模型版本与回滚题
官方依据：MLflow Model Registry、MLflow Dataset Tracking