标准回答
为什么重要
ML 的产出不只由代码决定，还由数据、超参、环境共同决定。只版本化代码无法复现结果——同一脚本喂不同数据集会得到完全不同的模型。版本管理解决三件事：可复现（精确重跑历史实验）、可审计（追溯模型由哪批数据训练，满足合规）、可回滚（线上出问题快速退回已知良好版本）。
数据版本化
大数据集不适合直接进 Git。DVC 用内容哈希把数据指针存进 Git、实体存对象存储；lakeFS / Delta Lake 给数据湖提供类 Git 的分支、提交、回滚能力，支持「时间旅行」回看任意历史快照。
模型与实验管理
Model Registry（如 MLflow、Weights & Biases）登记模型版本，标注 staging/production 阶段，记录指标、超参与数据血缘，支持审批晋升与回滚。实验追踪工具把每次跑的参数、指标、产物自动归档，便于横向对比。
参见 MLOps 版本管理实战 与流水线设计。
常见误区
⚠️ 常见踩坑
别把大数据集直接塞进 Git（仓库膨胀、克隆缓慢）——应用 DVC/lakeFS 存指针。也别只存模型权重却不记数据与超参血缘：没有「这版模型用了哪批数据、什么参数」就既无法复现也无法审计。
追问
追问 1：DVC 是怎么工作的？
DVC 对数据文件计算内容哈希，在 Git 里只提交 .dvc 指针文件（含哈希与远端位置），真实数据推到对象存储（S3/GCS）。git checkout 切到某版本时，dvc pull 按指针拉回对应数据，从而让数据与代码版本对齐、可复现。
追问 2：模型注册表（Model Registry）解决什么问题？
集中管理模型生命周期：登记版本、标注阶段（staging/production/archived）、记录指标与数据血缘、控制晋升审批与回滚。让「线上跑的是哪一版、谁批准、用什么数据训的」可查可控，是模型治理与合规的核心组件。
追问 3：怎样保证一次训练完全可复现？
钉死四要素：代码（Git commit）、数据（DVC/lakeFS 版本）、超参与随机种子、环境（容器镜像+依赖锁定）。再固定库版本与确定性算子（如关闭非确定 CUDA kernel）。把这些元数据随实验一并记录，才能精确重跑。
🔗 相似问题
同一考点的不同问法，换着练更稳
没找到想看的面试题？把你想看的告诉我们 →
延伸学习
按主题分类的相关资源，便于系统复习
