样本和标注不断修订后，团队需要知道每次实验用了哪版数据，后续才能复用和比较。将确认过的数据保存为明确版本，可以减少重复准备和核对。深信服aStor统一存储为适用的对象数据集提供分支与提交能力，帮助研发团队保留实验输入并管理变更。

如何保留每次实验使用的数据

一个数据集经过确认后，可以形成固定提交，并把提交标识写入实验记录。下次修改产生新的提交，团队能够比较两次输入的差别，也能继续使用历史版本开展回归测试。

模型实验会反复补充样本、修订标注和调整清洗规则。持续覆盖同一目录，或用“最终版”“最终版2”区分文件，很难说明一次实验实际读取了什么。保留确定的数据提交后，团队才方便区分结果变化来自数据修改，还是代码、环境与参数调整。

数据版本需要明确范围、发布人和提交标识。任务引用确定的提交时，后续追加数据不会改变它已经选用的输入。分支名便于协作，提交标识则用于实验追溯，并由平台写入任务记录。

统一治理全域数据

版本不能脱离数据来源和使用规则。数据负责人应确认样本来源、使用许可、标签规则和发布范围；平台团队维护数据目录与任务记录；存储侧负责可访问的数据状态及相关操作。谁能创建候选版本、谁可以审核合并、谁负责保留策略，也应在流程中约定。

对分散在多个系统中的数据，先通过统一视图发现候选目录和对象，再决定哪些数据进入版本管理范围。深信服aStor统一存储支持异构数据纳管与跨异构设备的桶、目录逻辑聚合及多维元数据检索，可协助团队定位数据源。检索结果并不自动表示数据已获得授权、已完成质量检查或适合加入某一训练集；这些判断仍由数据责任方和业务平台完成。

版本边界也不宜无限扩大。可以按数据集、业务线或明确的发布单元组织版本，避免把无关团队的临时文件都纳入同一管理单元。数据集内若有部分内容来自不同许可或保留周期，也应先拆分管理范围，或由平台在发布时执行对应规则。

源端继续产生的新数据，应按新批次准备到候选分支。已经提交的Commit保持不变，实验任务引用该提交读取；候选分支仍可继续写入，并在下一次提交时形成新的状态。源端更新、可写分支和固定提交由此各有明确职责，任务不会因为后续追加而失去输入依据。

使用分支分别修改数据

深信服aStor统一存储支持基于Git式机制管理数据分支。团队可以从一个已知数据状态创建候选分支，在其中追加样本、修订标注或测试数据处理结果，再将候选状态与基准进行差异比较。实验修改与正式发布状态分开，有利于避免未经审核的变化直接进入后续任务。

一条建议的实验流程是：数据工程师从已发布版本创建候选分支；在候选分支上执行数据补充或加工；平台记录处理程序版本和输入来源；质量负责人检查差异清单、抽样结果及业务规则；审核通过后提交版本，进入后续发布或合并步骤。未通过审核的修改可以继续留在候选分支中补充，不必覆盖当前训练基线。

差异审阅应围绕变更内容进行。数据负责人查看新增、删除和覆盖范围，再结合抽样检查确认标签口径与许可范围。系统提供差异和合并机制，团队根据审核结果决定哪些修改进入正式基线，使存储操作与业务质量检查衔接。

深信服aStor统一存储的数据分支管理适用于受支持的普通对象桶和普通目录桶。建设时，将原始数据接入空间与版本发布空间分别规划：把获准数据准备到创建时已启用分支管理的独立普通桶，再开展分支与提交。版本空间单独配置版本保留和保护流程，源端纳管与长期保存由相应数据空间承担。

数据提交合并与实验使用

候选分支经过检查后，团队可将当前状态提交为不可变Commit。提交后的候选分支仍可继续写入，新的变更进入后续提交；实验任务则通过指定提交读取固定状态。提交以零拷贝方式保留未变化的数据引用，避免为每个版本复制整份数据集，从而控制版本积累带来的存储开销。实验平台把该提交与代码和运行结果关联，形成可追溯记录。

当多个候选分支进入正式数据集时，深信服aStor统一存储通过版本合并处理变更关系，团队根据已确认的差异与审核记录决定发布。重复样本或标签冲突按业务规则处理，合并完成后形成新的提交标识，供后续任务引用。正式基线由此能够持续更新，并保留每次变更的来源。

发布流程要同时维护数据与实验记录。建议在合并审批单或平台任务中保存源版本、目标版本、差异摘要、审核人、变更原因和生效时间。任务调度时引用确定的数据提交标识，而不是引用一个可能继续变化的“最新”路径。这样即使数据集继续迭代，已有任务仍可被追溯到当时选用的状态。

代码与数据应分开版本，再通过实验平台建立关联。数据版本控制不会自动保存脚本仓库、依赖库、驱动、模型权重或容器环境；平台需要明确记录这些对象的版本号或镜像摘要。复现也需要保留数据访问权限、计算环境和必要的外部服务条件，不能只凭一个数据提交点保证整个任务原样重放。

AI业务上线快

模型效果发生变化时，团队需要比较两次实验使用的数据。以已发布版本作为基线，再为新样本或标注修订创建候选分支，可以开展对照评估。团队继续使用已确认的内容，将注意力放在本次修改及其影响上。

实际流程可按“基线版本—候选变更—质量审核—实验任务—结果评估—发布决策”串联。若候选版本指标不符合预期，团队先保留任务记录并分析数据差异；如果确认问题来自某次数据变更，可将数据状态切回合适的历史版本，随后重新运行评估。这里的回退针对数据状态，不会自动撤回模型服务、恢复代码仓库或回滚外部向量索引。相关系统必须各自执行对应操作，并验证相互依赖关系。

版本留存策略应与研发节奏匹配。团队可保留关键基线、正式发布点和仍在评估的提交，通过版本保留策略管理历史状态。已废弃的候选分支按审批流程退出；需要长期保存的发布数据另行安排保护与留存，明确责任人，防止临时版本持续积累。

指标可以帮助团队发现流程是否改善，例如数据准备耗时、候选版本审核周期、可复现任务比例、重复副本数量及回归定位时间。统计口径要先统一，并区分数据处理时间与存储访问时间。版本功能本身不能直接证明训练速度提高或模型质量改善，这些结果需要在具体任务中另行测量。

数据版本管理如何验证

落地时可从一类有稳定来源、更新频率适中且已有审核人的数据开始。先确定对象或目录范围、基准版本、候选分支权限和审批责任，再选一个重复运行的实验任务，记录其数据提交标识、代码版本、环境、参数和评估结果。第一轮重点验证差异是否可读、访问路径是否兼容、候选修改是否隔离，以及任务记录能否关联到正确数据版本。

试点可用一组可识别的变更验证完整主链：从基线创建可写分支，提交为固定状态，由实验记录引用，再完成审核合并。随后在测试环境切回历史提交，核对输入是否与原记录一致；涉及模型或应用恢复时，由相应平台按独立流程处理。演练重点是确认版本操作和任务交接能够连续执行。

AI数据复用应保留明确的实验输入，并能查看后续变更。深信服aStor统一存储在适用的普通对象桶和普通目录桶内提供数据分支、提交、合并与回退能力；实验平台关联数据提交、代码及运行记录，业务团队审核样本含义。按这些分工建立版本流程，团队就能延续已确认的数据基线，比较不同迭代结果。

常见问题

Q：怎么知道每次实验用了哪版数据？

A：通过数据分支、提交与版本回退，为每次实验保留可追溯的数据版本，便于复现与对比。

Q：数据版本会占用大量空间吗？

A：提交以零拷贝保留未变化的数据引用，避免为每个版本复制整份数据集，控制版本积累开销。

Q：版本冲突能自动解决吗？

A：不能。团队根据已确认的差异与审核记录决定发布，业务冲突按规则处理，不自动合并。