这个系列已经写了七篇了主要做了两件事。前四篇建立了 Git4Data 的技术坐标为什么海量数据需要 Git 式版本控制MatrixOne 的 snapshot / branch / diff / merge / cherry-pick / restore 怎么用、为什么快以及它和 DVC、lakeFS、Dolt、Snowflake 等方案分别站在哪一层。第五到第七篇主要介绍了数据运维相关的能力误操作怎么救多人怎么并行改数据ETL 怎么用 Write-Audit-Publish 把坏批次挡在生产门外。从这一篇开始我们进入AI 训练的场景。AI 训练是 Git4Data 这套能力非常核心的应用场景——训练过程中的数据组织、管理、变更和协作都非常频繁MatrixOne 内建的这套能力在这里非常实用。AI 训练本身是一个很大的范畴从传统机器学习到深度学习再到大模型的预训练与精调SFT、RLHF 等每一类的数据形态、规模和组织方式都不一样。本篇先聚焦其中最基础的一类——基于结构化数据的传统机器学习深度学习与大模型相关的数据管理留到系列后续再展开。机器学习是一个环节很多、链条很长的场景。我们先不下钻某一个具体环节而是先把整张地图摊开机器学习从数据进入到模型迭代每一个环节的真实数据难题是什么、分别该用 Git4Data 的哪个能力。要先破除一个常见的误解数据版本控制常被当成训练前的一个准备动作——把数据整理好、存个版本、然后开训。但一个模型从数据接入、清洗、标注、构建到训练、评估、上线再到持续迭代是一条贯穿始终的数据链版本控制是这条链上每一步都在用的底座而不是某一步的一次性操作。真正难管的也常常不是某一次训练而是这一连串问题这个线上模型到底用了哪一版样本、标签和特征它在哪一版验证集上被选中又在哪一版测试 / 评估集上得到最终指标两次训练之间数据究竟变了什么新数据还没通过检查能不能先别让生产样本主线看到两位标注员改了同一批样本哪里一致、哪里冲突新特征带来提升还是那批被修正的标签带来提升模型掉点之后能不能把当时的数据状态完整复原数据只增加了 1%这轮应该增量更新还是必须全量重训这些问题背后其实是同一个缺口机器学习已经有了代码版本、模型版本和实验记录却经常缺少一套真正作用在数据本身之上的版本语义。这正是 MatrixOne 的 Git4Data 能力在机器学习流程里要补上的位置。这一篇先把这张全流程地图建立起来后续各篇再沿着其中几个最典型的节点逐一深入。 本系列配套 SQL 与实验代码见 matrixorigin/git4data-tutorial。本文先建立全流程框架后续各篇会对 SFT 策展、标注协作、RLHF 偏好数据和多模态数据逐一深入。文中代码块为便于阅读有所省略属示意片段配套仓库提供一份已在 MatrixOne4.1.0上端到端跑通、覆盖核心链路接入 → 切分发布 → 模型注册 → 跨版本 DIFF的 companion script文中出现的行数与指标均来自它的实测输出。先纠正一个常见错觉机器学习流程不是流水线而是反馈环教科书里的机器学习流程常被画成一条直线采集数据 → 清洗标注 → 特征工程 → 训练 → 评估 → 部署真实系统却更像一个环每绕一圈至少有四类状态在变化样本在变新增、删除、去重、纠错、合规下架标签在变弱标签变成人工标签争议样本被改判延迟真值终于到达特征在变窗口、口径、填充方式、编码方式被重新定义训练决策在变切分规则、超参、代码、运行环境和模型架构不断迭代。代码的变化可以交给 Git训练运行可以交给 Airflow、Kubeflow 或其他调度系统模型文件可以放在对象存储实验指标可以交给实验跟踪系统。但“某个时刻这几张大表里的哪些行构成了训练数据”并不会自动变成一个可复现、可比较、可合并的版本。把这个缺口补上以后机器学习流程才有一条完整的证据链。一张总图机器学习的每个关键环节分别匹配什么 Git4Data 能力先给结论。MatrixOne 用 Git4Data 这套能力覆盖的是机器学习数据的完整生命周期——从数据接入、清洗与标注、特征构建、数据集发布到训练评估、上线监控与反馈回流每一个环节都有对应的版本能力可用而且它们共用同一套 snapshot / branch / diff / merge 语义可以在同一个库里连成一条完整的证据链。机器学习环节真实问题Git4Data 能力得到的价值数据接入新批次质量未知又不能污染主表DATA BRANCH CREATE、DIFF、MERGE先隔离、后审计、通过才原子发布即 WAP原始数据留档清洗后还想回看原貌CREATE SNAPSHOT、时间旅行给原始池建立低成本、可命名的基线清洗与策展去重、过滤、纠错到底动了什么分支、行级DIFF、RESTORE每一刀都有收据错误清洗可撤回多人标注并行写标签、意见冲突、需要复审每人一条分支、MERGE冲突、PICK分歧自动暴露只把裁决过的行挑回主线特征工程新口径要试验但不能破坏当前训练集分支、跨版本 SQL、DIFF、MERGE在完整数据上隔离试验通过评估再晋升训练 / 验证 / 测试集发布必须冻结训练内容、调参依据和最终评估基准库级快照 切分清单三个集合在同一版本中一致发布成员关系可复现训练与评估模型结果要和数据切分、代码、环境绑定快照 模型注册表建立model → dataset snapshot → split → code/env血缘候选集比较指标变化来自哪批数据快照间 / 分支间DIFF SQL把模型差异缩小到确切的样本与标签变化上线与回滚新版本退化需定位或恢复快照、RESTORE、PITR复原训练现场数据事故可退回确定状态监控与反馈新数据累积何时触发下一轮训练SQL 统计 版本基线 DIFF漂移判断有稳定参照精确取得训练增量持续学习增量还是全量重训DIFF、新快照先知道增/改/删再按模型和数据性质决策这里有一个很重要的分工SQL 负责判断数据是否合格、分布是否变化、指标是否过门槛Git4Data 这套能力负责给这些判断提供隔离的工作区、稳定的版本锚点和可执行的变更集。Git4Data 不会替你定义“异常值是多少”“AUC 至少提升多少”“什么程度算概念漂移”。它解决的是另一层问题让这些规则可以在正确的数据版本上运行让通过规则的改动可控地进入主线让失败的试验可以被丢弃或回退。下面用一个完整案例把这张表跑通。贯穿全文的案例一个每周迭代的交易风控模型假设我们在维护一个交易风险模型。每天有新交易进入部分交易要过几天才知道是否欺诈标注团队会修正旧标签特征团队不断调整统计窗口。模型每周评估一次满足条件才上线。为了把重点放在版本工作流上案例把训练样本简化成一张表CREATEDATABASErisk_ml;USErisk_ml;CREATETABLEsamples(sample_idBIGINTPRIMARYKEY,event_timeDATETIME,amountDECIMAL(12,2),txn_count_7dINT,amount_sum_30dDECIMAL(14,2),labelTINYINT,-- 0正常1欺诈NULL真值尚未回来label_sourceVARCHAR(32),-- rule / reviewer / chargebacksource_batchVARCHAR(32));CREATETABLEdataset_membership(sample_idBIGINTPRIMARYKEY,split_nameVARCHAR(16),-- train / valid / testsplit_ruleVARCHAR(128));CREATETABLEmodel_registry(model_versionVARCHAR(32)PRIMARYKEY,dataset_snapshotVARCHAR(64),code_commitVARCHAR(64),feature_versionVARCHAR(32),image_digestVARCHAR(128),artifact_uriVARCHAR(512),artifact_digestVARCHAR(128),-- 权重内容 hash / 不可变对象版本用于校验产物本身valid_aucDOUBLE,test_aucDOUBLE,statusVARCHAR(16));这三张表承担不同职责samples是会持续演进的数据主线dataset_membership明确记录每条样本属于训练、验证还是测试集model_registry不保存模型二进制只保存模型版本和数据集、切分、代码、特征、运行环境、产物地址与产物内容 hash之间的绑定。一份真正可复现的训练记录至少应该长这样只有数据快照还不等于完整复现。但没有数据快照这个等式一定缺最关键的一项。第一站数据接入——分支先做隔离区星期一凌晨上游送来一批新样本。传统做法是直接写入samples然后再跑质量检查一旦检查失败脏数据已经混进主线。第七篇讲过的 WAP 在这里可以直接复用DATABRANCHCREATETABLEsamples_stageFROMsamples;-- 新批次只进入 staging 分支INSERTINTOsamples_stageVALUES(...);-- 完整性、取值域、重复、参照关系、批次体量等门禁SELECTCOUNT(*)FROMsamples_stageWHEREsource_batch2026w29AND(amount0ORtxn_count_7d0);-- 看清这次发布会新增、修改、删除多少行DATABRANCH DIFF samples_stage AGAINST samples OUTPUT SUMMARY;-- 只有全部门禁通过才发布DATABRANCHMERGEsamples_stageINTOsamples;于是生产样本主线从“数据的入口”变成了“通过质量门禁后的出口”。门禁失败时直接丢弃或保留samples_stage排查即可主线一行没动。这一环节 Git4Data 提供的不是新的质量算法而是质量检查之前的隔离和通过之后的原子晋升。第二站清洗与标注——把修改变成可评审的变更集新数据进入后标注团队收到延迟真值3000 条新交易有了标签同时抽检发现旧数据里有 200 条标签错误。先给清洗前的状态打一个快照CREATESNAPSHOTrisk_before_reviewFORTABLErisk_ml samples;两位标注员可以各自开分支不必在同一张表上互相覆盖DATABRANCHCREATETABLEsamples_aliceFROMsamples;DATABRANCHCREATETABLEsamples_bobFROMsamples;UPDATEsamples_aliceSETlabel...,label_sourcereviewer_aliceWHEREsample_idBETWEEN...;UPDATEsamples_bobSETlabel...,label_sourcereviewer_bobWHEREsample_idBETWEEN...;重叠标注区的一致率直接用 SQL 计算两人意见不同且都改了同一行时三方合并会把它识别为真正的行级冲突DATABRANCHMERGEsamples_aliceINTOsamples;DATABRANCHMERGEsamples_bobINTOsamplesWHENCONFLICT SKIP;SKIP先保留主线已有裁决其余不冲突的标签照常合入。资深评审员在 review 分支上完成改判后只把争议样本挑回主线DATABRANCH PICK samples_reviewINTOsamplesKEYS(SELECTsample_idFROMreview_queue)WHENCONFLICT ACCEPT;这套映射非常自然标注平台仍然负责界面、任务分发、权限和计件底层数据的并行修改、冲突语义和版本证据则由 MatrixOne 的 Git4Data 能力承担。第三站特征工程——不是复制一张大表而是拉一条试验分支特征团队发现txn_count_7d的事件去重口径不够准确想用新口径重算这个 7 天窗口特征。直接重算主表风险太高现有模型和其他训练任务还在读取当前口径复制一张亿级表又慢又贵。更合适的方式是在分支上做完整试验DATABRANCHCREATETABLEsamples_feat_candidateFROMsamples;-- 在分支上重新计算特征主线继续服务现有训练与查询UPDATEsamples_feat_candidateSETtxn_count_7d...;-- 检查影响范围、空值率、分布以及泄漏风险DATABRANCH DIFF samples_feat_candidate AGAINST samples OUTPUT SUMMARY;SELECT...FROMsamples_feat_candidate;候选特征可以在分支上训练并评估。如果没有提升丢掉分支如果提升稳定再把它合回主线或者把这条分支直接作为一个候选数据集版本保留。这里尤其要区分两件事数值重算schema 不变只改变行值适合分支、DIFF、MERGE新增 / 删除特征列属于 schema 演进。MatrixOne 当前要求参与行级 DIFF / MERGE 的两边 schema 完全一致因此应先统一 schema再开分支试验不能让两条分支各自随意改列定义后还期待自动合并。这也是 Git4Data 的边界之一它能很好地管理“同一结构下的数据演进”但 schema 设计本身仍要走受控的迁移流程。第四站训练、验证、测试集发布——不仅要冻结数据还要冻结“谁属于哪一集”数据接入、标签复审和特征验证都完成后才真正到了数据集发布的时刻。这里不能只说“训练集”因为一次可信的模型开发至少有三种不同职责的数据集合用途可以怎样使用最容易犯的错训练集train拟合模型参数反复读取、采样和训练把未来数据或同一实体的近重复样本混进来验证 / 评估集valid / eval选择特征、超参、阈值和候选模型开发期间可以反复评估反复调到最好后却把它的分数当最终泛化能力测试 / 留出集test / holdout候选方案锁定后的最终无偏评估应尽量少看不能继续据此调参测完不满意又回头调测试集事实上变成了验证集有些团队还会维护一份长期稳定的golden evaluation set覆盖关键人群、罕见风险和业务底线用于跨模型版本回归。它可以被看作额外的受控测试集但同样不能被悄悄拿回训练。因此版本化对象不能只有样本内容还必须包括切分成员关系与切分规则。在案例里我们把它显式写进dataset_membership。风控数据通常按时间切分模拟“用过去预测未来”INSERTINTOdataset_membershipSELECTsample_id,CASEWHENevent_time2026-06-01THENtrainWHENevent_time2026-06-15THENvalidWHENevent_time2026-07-01THENtestEND,time_split:v1:2026-06-01/06-15/07-01FROMsamplesWHERElabelISNOTNULLANDevent_time2026-07-01;时间边界只是第一层。实际切分还要同时防止几类泄漏同一用户、设备或商户的高度相关样本跨到 train 和 test导致模型“见过同一个人”同一原始事件的重复记录或增强样本被拆到不同集合在全量数据上先做标准化、目标编码或缺失值拟合再切分——预处理参数已经偷看了验证 / 测试集标签产生时间晚于特征截点却被错误地当作当时可获得的信息。所以切分清单应保存的不只是train / valid / test三个词还应保存时间截点、分组键、去重规则、随机种子或哈希规则。预处理器也只能在 train 上拟合再原样应用到 valid 和 test。现在samples与dataset_membership必须作为一个整体发布。给单表分别打快照可能落在不同时间点这里更适合使用库级快照CREATESNAPSHOTrisk_dataset_v1FORDATABASErisk_ml;训练、验证和最终测试都显式从同一个数据集版本读取只改变split_name-- 训练器读取 trainSELECTs.*FROMsamples {SNAPSHOTrisk_dataset_v1} sJOINdataset_membership {SNAPSHOTrisk_dataset_v1} mONs.sample_idm.sample_idWHEREm.split_nametrain;-- 调参和模型选择读取 valid最终锁定后才读取 testSELECTm.split_name,COUNT(*)FROMdataset_membership {SNAPSHOTrisk_dataset_v1} mGROUPBYm.split_name;这条库级快照不是物理复制整个数据库而是给当时各表的一致状态建立一个命名版本。前面第三篇已经解释过MatrixOne 的不可变对象与元数据目录让快照成本近乎与数据量无关。至此可复现的不只是“有哪些样本”还包括“每条样本在这次实验中扮演什么角色”。如果后来修正了测试标签、加入新的困难样本或调整切分边界应该发布risk_dataset_v2并让新的评估结果明确绑定 v2不能覆盖 v1 后继续沿用旧指标。新版本发布前样本内容和切分成员关系要分别 review-- 样本或标签变了什么DATABRANCH DIFF samples AGAINST samples {SNAPSHOTrisk_dataset_v1} OUTPUT SUMMARY;-- 哪些样本从一个 split 移到了另一个 split或新进入了评估集合DATABRANCH DIFF dataset_membership AGAINST dataset_membership {SNAPSHOTrisk_dataset_v1} OUTPUT SUMMARY;这两个 DIFF 能区分“模型变了”与“尺子变了”如果 test 的成员、标签或评估协议发生变化v2 的测试分数仍然有效但它已经不是和 v1 完全同口径的直接对比。跨版本趋势应优先在未变化的固定测试 / golden set 上比较同时把新时间窗口作为另一条独立指标报告。第五站训练与评估——模型版本必须能反向找到数据版本MatrixOne 不负责替你跑 PyTorch、XGBoost 或 scikit-learn。训练仍发生在训练框架里模型权重仍写到对象存储或模型仓库。但训练完成后应把完整绑定写进注册表INSERTINTOmodel_registryVALUES(risk_m1,risk_dataset_v1,8f31c2...,feature_v7,sha256:4b7...,s3://models/risk_m1/model.bin,sha256:weights-m1...,0.9430,0.9412,candidate);现在“risk_m1 用了什么训练数据”不再是一份可能过期的文档而是一个可以执行的关系risk_m1 ├── dataset risk_dataset_v1 ├── split time_split:v1 ├── code 8f31c2... ├── feature feature_v7 ├── runtime sha256:4b7... (镜像 digest) ├── valid AUC 0.9430 ├── test AUC 0.9412 ├── artifact s3://models/risk_m1/model.bin └── digest sha256:weights-m1... (权重内容 hash / 不可变对象版本)三个月后复现模型时代码从 Git checkout运行环境按镜像 digest 拉起train / valid / test 都从risk_dataset_v1的切分清单读取模型产物再用注册表里的artifact_digest权重内容 hash或对象存储 / lakeFS 侧的不可变对象 / commit 版本校验。Git4Data 补的是这条链上过去最容易丢失的“数据现场与评估现场”。第六站候选评估与上线——先解释差异再讨论指标第二轮模型risk_m2在验证集上胜出锁定特征、超参和阈值之后才允许在测试集上做最终评估测试 AUC 从 0.9412 提升到 0.9470。这个数字仍不能单独回答最重要的问题提升来自哪里如果m1和m2分别绑定risk_dataset_v1、risk_dataset_v2先看两版样本主线DATABRANCH DIFF samples AGAINST samples {SNAPSHOTrisk_dataset_v1} OUTPUT SUMMARY;-- 示例INSERTED 3000 / UPDATED 200 / DELETED 0这样评审者知道这次不是“神秘地换了一份数据”而是新增了 3000 条延迟真值修正了 200 个错误标签其他样本未动。再结合代码 commit、特征版本和超参记录就能判断实验是否只改变了预期变量。上线门禁也不应只有一个总 AUC。风控模型至少还要看时间外测试集、长期 golden set、不同人群切片、召回率、误杀率、校准度和延迟。每个指标必须同时记录数据集快照、split、指标口径和评估代码版本。Git4Data 不定义这些标准但可以让所有评估都指向稳定的候选数据版本并保留“为什么批准上线”的证据。如果测试集结果不理想团队当然可以继续开发但下一轮使用测试反馈调出的模型不能再声称仍在同一个“未见测试集”上做无偏评估。此时应保留旧结果另建新的候选轮次并在条件允许时用新的时间窗口或独立留出集做最终确认。通过门禁后把model_registry.status从candidate改为production。这只是模型发布元数据真正的服务部署仍由模型服务平台完成。第七站上线监控——版本基线让漂移判断不再悬空模型上线后会遇到两种不同的“变化”数据本身被改了新增样本、修正标签、删除记录数据分布变了新流量与训练期相比金额、类别、人群比例等统计特征发生偏移。第一种变化适合用行级 DIFF 回答第二种变化要靠 SQL 或专门的漂移指标比较两个窗口的统计分布。不要把二者混为一谈。-- 数据内容发生了多少增 / 改 / 删DATABRANCH DIFF samples AGAINST samples {SNAPSHOTrisk_dataset_v1} OUTPUT SUMMARY;-- 分布是否漂移示意真实系统可计算 PSI、KS、JS divergence 等指标SELECTsource_batch,COUNT(*)ASn,AVG(amount)ASavg_amount,AVG(txn_count_7d)ASavg_txn_countFROMsamplesGROUPBYsource_batch;Git4Data 在这里的价值是提供稳定基线开发时的训练、验证、测试版本不会随着主表更新而消失监控结果可以明确写成“当前 2026w29 批次相对risk_dataset_v1的变化”而不是相对某份已经被覆盖的临时表。第八站反馈与持续学习——先知道变了什么再决定怎么训一周后主表相对risk_dataset_v1多了 3000 条样本并修正了 200 个标签。现在才轮到持续学习里最常被讨论的核心问题应该只训增量还是全量重训这个决策不能只看“变化行数少”。适合增量训练的情形模型本身支持partial_fit、continued training 或可靠的 warm start新数据主要是同分布下的追加变化占比小、训练频率高全量重训成本确实成为瓶颈老数据没有大规模删除或标签订正。更适合全量重训的情形特征定义、模型架构或超参数变了出现明显概念漂移需要重新采样或重新加权大量旧标签被纠正或旧样本因合规要求被删除模型不支持可靠的增量更新需要消除增量训练的路径依赖得到一个干净、可复现的发布模型。尤其要注意从训练表删除一行并不会自动消除它对已训练模型的影响。这属于 machine unlearning 问题很多场景仍然必须重训。Git4Data 能告诉你哪些行被删了却不会替模型“忘掉”它们。所以更稳妥的工作流是① DIFF 当前数据 AGAINST 上次训练快照 ② 检查变化类型、规模、分布漂移和合规要求 ③ 决定增量更新 / 窗口重训 / 全量重训 ④ 训练完成后再打新快照并绑定新模型版本当增量训练确实适用时原实验的数字依然很有说服力连续 6 轮、每轮新增约 1000 行偶有标签订正全量重训累计处理 21,000 行而只处理每轮变化累计为 6,004 行。随着轮次增加全量方案的累计处理量近似二次增长增量方案近似线性。但这组数字应该放在正确的位置上理解“省算力”是有条件的收益“知道数据变了什么、能复现每轮训练、能定位模型退化”才是普适收益。准备训练risk_m2前要先按 v2 的时间窗口重新生成并审计dataset_membership确认 train / valid / test 的规模、时间边界和实体交叉都符合预期。然后把样本、标签和三份切分清单一起钉成新的数据库版本CREATESNAPSHOTrisk_dataset_v2FORDATABASErisk_ml;INSERTINTOmodel_registryVALUES(risk_m2,risk_dataset_v2,b710aa...,feature_v7,sha256:4b7...,s3://models/risk_m2/model.bin,sha256:weights-m2...,0.9491,0.9470,candidate);模型与数据的演进链就清楚了risk_m1 ← risk_dataset_v1 (train / valid / test v1) │ ├── 3000 新增样本 └── 200 标签修正 ↓ risk_m2 ← risk_dataset_v2 (train / valid / test v2)如果risk_m2上线后退化排查范围不再是整张表而是这条明确的变化集再加上代码、特征和配置的版本差异。把所有原语放回机器学习语境走完案例后再看 Git4Data 的几个原语会发现它们各自承担的是不同职责。Snapshot不是“备份一下”而是发布一个可引用的数据版本快照最有价值的时点不是每条数据写入之后而是语义边界原始批次通过接入门禁一轮清洗或标注完成一版训练 / 验证 / 测试数据集正式发布一个模型被批准上线一次高风险数据迁移之前。快照过密会增加保留成本和命名混乱快照过少又会失去关键现场。正确策略不是“逢写必拍”而是围绕可审计、可复现的发布节点建立版本。Branch不是多存一份数据而是隔离一个尚未被证明正确的假设分支适合承载未经验证的新批次一轮数据清洗一位标注员的结果一套新特征口径一个数据重采样或类别平衡方案一个候选数据集及其切分。这些工作共同的特点是要在完整数据上下文里计算但在通过评审之前不能影响主线。Diff不只是“拿增量”更是模型变化的解释入口DIFF 可以回答这轮清洗删掉了哪些样本新旧标签集差了哪 200 行候选特征表影响了多少用户m2相对m1的训练数据变量是什么线上反馈回流后新增、修改、删除各有多少所以 DIFF 既服务计算优化也服务审计、归因和 review。只把它理解成“增量训练的数据源”会低估它在整个流程里的价值。Merge 与 Pick把“验证通过”变成受控的数据晋升MERGE适合把一整条已审计分支的有效改动原子并回主线PICK适合只晋升一组明确主键例如复审通过的争议标签、人工确认的难例或某批高价值样本。这让训练数据也能形成类似代码 PR 的流程开分支 → 修改 → SQL 检查 → DIFF review → 评估 → MERGE / PICK → 打快照Restore 与 PITR一个恢复“版本”一个恢复“时间点”RESTORE适合回到某个已命名、已知正确的数据集版本PITR 适合处理“我们不知道是哪一笔写坏了但知道大约从星期三下午开始异常”的事故。它们首先是数据恢复能力。在机器学习流程里额外的价值是恢复后可以重新跑训练与评估判断数据事故对模型造成了什么影响。MatrixOne 在 MLOps 技术栈里到底站哪一层一篇完整的文章也必须讲清它不负责什么。更准确的分工如下对象更适合的版本 / 管理方式MatrixOne 的角色训练代码、SQL、特征定义Git在注册表里记录 commit与数据快照绑定结构化样本、标签、特征值MatrixOne Git4Data快照、分支、行级 diff / merge / pick、恢复图片、音频、视频、模型权重等大字节lakeFS、对象存储版本、DVC 等MatrixOne 保存目录、标签、URI、commit/hash不冒充管理字节内容Python / CUDA / 系统依赖容器镜像、lockfile记录 image digest 或环境 hash训练调度与资源Airflow、Kubeflow、Ray、云训练平台等提供稳定的数据版本输入不替代调度器实验指标与模型注册MLflow 或现有实验平台也可落表用dataset_snapshot split metric protocol补全数据与评估血缘在线部署、灰度、回滚模型服务与发布平台保存发布记录与数据版本关联不直接替代模型 serving一句话概括Git 管代码镜像管环境模型仓库管产物调度器管执行MatrixOne 用 Git4Data 能力管的是机器学习过程中不断演进的“结构化数据状态”并把它与其他版本连接起来。这比“用一个工具包办 MLOps”更现实也更容易落地。哪些数据应该进入 MatrixOne哪些不应该MatrixOne 最契合的是满足以下条件的数据以行、表和主键为基本语义会被反复清洗、订正、标注、合并需要在不同版本上直接做 SQL、JOIN、聚合或向量计算需要知道“哪些记录发生了变化”需要与模型、批次、标注员、规则或外部对象建立血缘。典型对象包括样本目录、标签、偏好对、特征值、数据质量结果、数据集切分 manifest、模型注册元数据和反馈记录。而图像、音频、视频、超大语料文件与模型权重等不可解析字节更适合交给对象存储、lakeFS 或 DVC。MatrixOne 的快照会冻结这些 URI / 引用字段当时的取值例如一个 lakeFS commit、对象版本号或 stage 路径但它保存的是“指针”而非字节本身——外部对象若在同一地址下被覆盖数据库快照不会替你留住旧字节。注v4.1.0 的datalink类型只解析file:///hdfs:///stage://并不支持s3://因此 S3 / lakeFS 对象应以 stage 路径或不可变的 object / commit 版本入库而不是指望datalink解析任意 URL。多模态场景要把“字节版本”和“目录版本”一起 pinmodel └── MatrixOne catalog snapshot └── lakeFS commit / object version └── image / audio / video bytes这会是后续多模态篇的主题。落地时最容易踩的八个坑1. 只给模型编号不绑定训练数据model_v17如果只对应一个文件名没有数据集快照、切分清单、代码 commit、特征版本和环境 digest就不是一个可复现版本只是一个标签。2. 训练任务仍然读取不断变化的主表即使训练前打了快照训练器却继续SELECT FROM samples长任务执行期间看到的数据边界仍可能与预期不一致。训练、验证和测试任务都必须显式引用同一个已发布快照及对应 split。3. 把随机切分当成可复现切分快照相同不代表随机切分相同。时间边界、哈希规则或随机种子也必须保存时间序列、风控等场景还要防止未来信息泄漏。4. 把验证集和测试集混成一套“评估集”验证集可以参与模型选择测试集负责选择完成后的最终确认。每看一次测试结果再回头调参都会把测试信息泄漏进开发过程。应分别记录 valid 与 test 指标并把二者绑定到明确的快照和切分版本。5. 把 DIFF 等同于漂移检测DIFF 回答记录发生了哪些增、改、删漂移检测回答统计分布或条件关系是否变化。后者仍需 PSI、KS、JS divergence、性能切片等统计与业务判断。6. 看到变化少就默认可以增量训练200 条标签订正可能比 20 万条同分布新增更值得全量重训。训练策略取决于变化性质、模型能力、遗忘风险和合规要求不只是数量。7. 忘记快照与分支也有保留成本快照和零拷贝分支创建很轻但被它们引用的历史对象不能被 GC。应区分长期保留的上线版本、短期保留的候选版本和任务结束即清理的临时分支。8. 合规删除与长期快照策略互相打架如果个人数据必须被彻底删除仍长期保留包含该数据的历史快照可能不符合要求。数据保留、快照 TTL、访问权限、删除证明和模型重训 / 遗忘策略必须一起设计。Git4Data 提供版本能力但不会自动替组织完成合规判断。一个可以直接采用的最小闭环如果不想一开始就建设一套宏大的 MLOps 平台可以先从下面这个最小闭环开始1. 新批次进入 staging 分支 2. SQL 质量门禁通过后 MERGE 到样本主线 3. 清洗、标注、特征变更都在分支完成DIFF 后再合入 4. 生成并审计 train / valid / test 切分清单用库级 CREATE SNAPSHOT 一起发布 5. 注册模型时强制写入 dataset_snapshot split_rule valid/test 指标 code_commit image_digest 6. 线上反馈回流后DIFF AGAINST 上次数据集快照 7. 根据变化类型和漂移指标决定增量或全量重训 8. 新模型通过门禁后生成新快照并更新模型血缘它不要求一次替换所有已有工具只要求确立三个纪律未经审计的数据不直接进主线没有数据集快照和切分清单的训练不进入模型注册表说不清两版数据与评估基准差异的模型不进入生产。一旦这三个纪律形成快照、分支、DIFF、MERGE 就不再是零散 SQL而会变成机器学习团队共同的工作语言。结语模型的生命周期本质上也是数据状态的生命周期回看整个流程Git4Data 这套能力没有替你训练模型也没有替你判断模型好坏。它做的是更基础的一层数据进入前可以隔离被修改时可以并行、评审和合并被训练时可以冻结并引用模型变化时可以解释数据变量出现事故时可以复原和回退反馈回来时可以精确知道下一轮从哪里开始。所以 Git4Data 对机器学习最大的价值不只是“增量训练省了多少算力”而是把一条原本依靠文件名、时间戳和口头约定维系的流程变成一条可执行、可审计、可复现的数据版本链。这篇建立的是 AI 训练实践篇的总地图。接下来我们会沿着其中几个最典型的节点逐一深入SFT 数据策展几十万条指令数据怎样原地去重、过滤、去污染而且每一刀都有 DIFF 收据标注协作如何把并行标注、分歧发现和资深评审映射成 branch / conflict / cherry-pickRLHF 偏好数据共识、争议、改判和奖励模型版本怎样形成完整谱系多模态训练集lakeFS 管字节MatrixOne 管目录、标签和行级演进两个版本世界怎样拼成一个可复现整体。当这些环节共用同一套版本原语时Git4Data 才真正从一个数据库功能变成 AI 数据工程的工作方式。 可运行 SQLgithub.com/matrixorigin/git4data-tutorial 前七篇文章github.com/matrixorigin/matrixorigin-blog 源码与社区github.com/matrixorigin/matrixone参考资料MLflow — 实验跟踪与模型注册https://mlflow.org/docs/latest/tracking.html、https://mlflow.org/docs/latest/model-registry.htmlApache Airflow — 工作流调度https://airflow.apache.org/docs/scikit-learn — 数据泄漏与常见陷阱https://scikit-learn.org/stable/common_pitfalls.html#data-leakagelakeFS — 对象存储上的数据版本控制https://docs.lakefs.io/Bourtoule 等《Machine Unlearning》IEEE SP 2021https://arxiv.org/abs/1912.03817本文配套可运行脚本已在 MatrixOne 4.1.0 验证08-ml-lifecycle/ml_lifecycle_demo.sql
这个系列已经写了七篇了主要做了两件事。前四篇建立了 Git4Data 的技术坐标为什么海量数据需要 Git 式版本控制MatrixOne 的 snapshot / branch / diff / merge / cherry-pick / restore 怎么用、为什么快以及它和 DVC、lakeFS、Dolt、Snowflake 等方案分别站在哪一层。第五到第七篇主要介绍了数据运维相关的能力误操作怎么救多人怎么并行改数据ETL 怎么用 Write-Audit-Publish 把坏批次挡在生产门外。从这一篇开始我们进入AI 训练的场景。AI 训练是 Git4Data 这套能力非常核心的应用场景——训练过程中的数据组织、管理、变更和协作都非常频繁MatrixOne 内建的这套能力在这里非常实用。AI 训练本身是一个很大的范畴从传统机器学习到深度学习再到大模型的预训练与精调SFT、RLHF 等每一类的数据形态、规模和组织方式都不一样。本篇先聚焦其中最基础的一类——基于结构化数据的传统机器学习深度学习与大模型相关的数据管理留到系列后续再展开。机器学习是一个环节很多、链条很长的场景。我们先不下钻某一个具体环节而是先把整张地图摊开机器学习从数据进入到模型迭代每一个环节的真实数据难题是什么、分别该用 Git4Data 的哪个能力。要先破除一个常见的误解数据版本控制常被当成训练前的一个准备动作——把数据整理好、存个版本、然后开训。但一个模型从数据接入、清洗、标注、构建到训练、评估、上线再到持续迭代是一条贯穿始终的数据链版本控制是这条链上每一步都在用的底座而不是某一步的一次性操作。真正难管的也常常不是某一次训练而是这一连串问题这个线上模型到底用了哪一版样本、标签和特征它在哪一版验证集上被选中又在哪一版测试 / 评估集上得到最终指标两次训练之间数据究竟变了什么新数据还没通过检查能不能先别让生产样本主线看到两位标注员改了同一批样本哪里一致、哪里冲突新特征带来提升还是那批被修正的标签带来提升模型掉点之后能不能把当时的数据状态完整复原数据只增加了 1%这轮应该增量更新还是必须全量重训这些问题背后其实是同一个缺口机器学习已经有了代码版本、模型版本和实验记录却经常缺少一套真正作用在数据本身之上的版本语义。这正是 MatrixOne 的 Git4Data 能力在机器学习流程里要补上的位置。这一篇先把这张全流程地图建立起来后续各篇再沿着其中几个最典型的节点逐一深入。 本系列配套 SQL 与实验代码见 matrixorigin/git4data-tutorial。本文先建立全流程框架后续各篇会对 SFT 策展、标注协作、RLHF 偏好数据和多模态数据逐一深入。文中代码块为便于阅读有所省略属示意片段配套仓库提供一份已在 MatrixOne4.1.0上端到端跑通、覆盖核心链路接入 → 切分发布 → 模型注册 → 跨版本 DIFF的 companion script文中出现的行数与指标均来自它的实测输出。先纠正一个常见错觉机器学习流程不是流水线而是反馈环教科书里的机器学习流程常被画成一条直线采集数据 → 清洗标注 → 特征工程 → 训练 → 评估 → 部署真实系统却更像一个环每绕一圈至少有四类状态在变化样本在变新增、删除、去重、纠错、合规下架标签在变弱标签变成人工标签争议样本被改判延迟真值终于到达特征在变窗口、口径、填充方式、编码方式被重新定义训练决策在变切分规则、超参、代码、运行环境和模型架构不断迭代。代码的变化可以交给 Git训练运行可以交给 Airflow、Kubeflow 或其他调度系统模型文件可以放在对象存储实验指标可以交给实验跟踪系统。但“某个时刻这几张大表里的哪些行构成了训练数据”并不会自动变成一个可复现、可比较、可合并的版本。把这个缺口补上以后机器学习流程才有一条完整的证据链。一张总图机器学习的每个关键环节分别匹配什么 Git4Data 能力先给结论。MatrixOne 用 Git4Data 这套能力覆盖的是机器学习数据的完整生命周期——从数据接入、清洗与标注、特征构建、数据集发布到训练评估、上线监控与反馈回流每一个环节都有对应的版本能力可用而且它们共用同一套 snapshot / branch / diff / merge 语义可以在同一个库里连成一条完整的证据链。机器学习环节真实问题Git4Data 能力得到的价值数据接入新批次质量未知又不能污染主表DATA BRANCH CREATE、DIFF、MERGE先隔离、后审计、通过才原子发布即 WAP原始数据留档清洗后还想回看原貌CREATE SNAPSHOT、时间旅行给原始池建立低成本、可命名的基线清洗与策展去重、过滤、纠错到底动了什么分支、行级DIFF、RESTORE每一刀都有收据错误清洗可撤回多人标注并行写标签、意见冲突、需要复审每人一条分支、MERGE冲突、PICK分歧自动暴露只把裁决过的行挑回主线特征工程新口径要试验但不能破坏当前训练集分支、跨版本 SQL、DIFF、MERGE在完整数据上隔离试验通过评估再晋升训练 / 验证 / 测试集发布必须冻结训练内容、调参依据和最终评估基准库级快照 切分清单三个集合在同一版本中一致发布成员关系可复现训练与评估模型结果要和数据切分、代码、环境绑定快照 模型注册表建立model → dataset snapshot → split → code/env血缘候选集比较指标变化来自哪批数据快照间 / 分支间DIFF SQL把模型差异缩小到确切的样本与标签变化上线与回滚新版本退化需定位或恢复快照、RESTORE、PITR复原训练现场数据事故可退回确定状态监控与反馈新数据累积何时触发下一轮训练SQL 统计 版本基线 DIFF漂移判断有稳定参照精确取得训练增量持续学习增量还是全量重训DIFF、新快照先知道增/改/删再按模型和数据性质决策这里有一个很重要的分工SQL 负责判断数据是否合格、分布是否变化、指标是否过门槛Git4Data 这套能力负责给这些判断提供隔离的工作区、稳定的版本锚点和可执行的变更集。Git4Data 不会替你定义“异常值是多少”“AUC 至少提升多少”“什么程度算概念漂移”。它解决的是另一层问题让这些规则可以在正确的数据版本上运行让通过规则的改动可控地进入主线让失败的试验可以被丢弃或回退。下面用一个完整案例把这张表跑通。贯穿全文的案例一个每周迭代的交易风控模型假设我们在维护一个交易风险模型。每天有新交易进入部分交易要过几天才知道是否欺诈标注团队会修正旧标签特征团队不断调整统计窗口。模型每周评估一次满足条件才上线。为了把重点放在版本工作流上案例把训练样本简化成一张表CREATEDATABASErisk_ml;USErisk_ml;CREATETABLEsamples(sample_idBIGINTPRIMARYKEY,event_timeDATETIME,amountDECIMAL(12,2),txn_count_7dINT,amount_sum_30dDECIMAL(14,2),labelTINYINT,-- 0正常1欺诈NULL真值尚未回来label_sourceVARCHAR(32),-- rule / reviewer / chargebacksource_batchVARCHAR(32));CREATETABLEdataset_membership(sample_idBIGINTPRIMARYKEY,split_nameVARCHAR(16),-- train / valid / testsplit_ruleVARCHAR(128));CREATETABLEmodel_registry(model_versionVARCHAR(32)PRIMARYKEY,dataset_snapshotVARCHAR(64),code_commitVARCHAR(64),feature_versionVARCHAR(32),image_digestVARCHAR(128),artifact_uriVARCHAR(512),artifact_digestVARCHAR(128),-- 权重内容 hash / 不可变对象版本用于校验产物本身valid_aucDOUBLE,test_aucDOUBLE,statusVARCHAR(16));这三张表承担不同职责samples是会持续演进的数据主线dataset_membership明确记录每条样本属于训练、验证还是测试集model_registry不保存模型二进制只保存模型版本和数据集、切分、代码、特征、运行环境、产物地址与产物内容 hash之间的绑定。一份真正可复现的训练记录至少应该长这样只有数据快照还不等于完整复现。但没有数据快照这个等式一定缺最关键的一项。第一站数据接入——分支先做隔离区星期一凌晨上游送来一批新样本。传统做法是直接写入samples然后再跑质量检查一旦检查失败脏数据已经混进主线。第七篇讲过的 WAP 在这里可以直接复用DATABRANCHCREATETABLEsamples_stageFROMsamples;-- 新批次只进入 staging 分支INSERTINTOsamples_stageVALUES(...);-- 完整性、取值域、重复、参照关系、批次体量等门禁SELECTCOUNT(*)FROMsamples_stageWHEREsource_batch2026w29AND(amount0ORtxn_count_7d0);-- 看清这次发布会新增、修改、删除多少行DATABRANCH DIFF samples_stage AGAINST samples OUTPUT SUMMARY;-- 只有全部门禁通过才发布DATABRANCHMERGEsamples_stageINTOsamples;于是生产样本主线从“数据的入口”变成了“通过质量门禁后的出口”。门禁失败时直接丢弃或保留samples_stage排查即可主线一行没动。这一环节 Git4Data 提供的不是新的质量算法而是质量检查之前的隔离和通过之后的原子晋升。第二站清洗与标注——把修改变成可评审的变更集新数据进入后标注团队收到延迟真值3000 条新交易有了标签同时抽检发现旧数据里有 200 条标签错误。先给清洗前的状态打一个快照CREATESNAPSHOTrisk_before_reviewFORTABLErisk_ml samples;两位标注员可以各自开分支不必在同一张表上互相覆盖DATABRANCHCREATETABLEsamples_aliceFROMsamples;DATABRANCHCREATETABLEsamples_bobFROMsamples;UPDATEsamples_aliceSETlabel...,label_sourcereviewer_aliceWHEREsample_idBETWEEN...;UPDATEsamples_bobSETlabel...,label_sourcereviewer_bobWHEREsample_idBETWEEN...;重叠标注区的一致率直接用 SQL 计算两人意见不同且都改了同一行时三方合并会把它识别为真正的行级冲突DATABRANCHMERGEsamples_aliceINTOsamples;DATABRANCHMERGEsamples_bobINTOsamplesWHENCONFLICT SKIP;SKIP先保留主线已有裁决其余不冲突的标签照常合入。资深评审员在 review 分支上完成改判后只把争议样本挑回主线DATABRANCH PICK samples_reviewINTOsamplesKEYS(SELECTsample_idFROMreview_queue)WHENCONFLICT ACCEPT;这套映射非常自然标注平台仍然负责界面、任务分发、权限和计件底层数据的并行修改、冲突语义和版本证据则由 MatrixOne 的 Git4Data 能力承担。第三站特征工程——不是复制一张大表而是拉一条试验分支特征团队发现txn_count_7d的事件去重口径不够准确想用新口径重算这个 7 天窗口特征。直接重算主表风险太高现有模型和其他训练任务还在读取当前口径复制一张亿级表又慢又贵。更合适的方式是在分支上做完整试验DATABRANCHCREATETABLEsamples_feat_candidateFROMsamples;-- 在分支上重新计算特征主线继续服务现有训练与查询UPDATEsamples_feat_candidateSETtxn_count_7d...;-- 检查影响范围、空值率、分布以及泄漏风险DATABRANCH DIFF samples_feat_candidate AGAINST samples OUTPUT SUMMARY;SELECT...FROMsamples_feat_candidate;候选特征可以在分支上训练并评估。如果没有提升丢掉分支如果提升稳定再把它合回主线或者把这条分支直接作为一个候选数据集版本保留。这里尤其要区分两件事数值重算schema 不变只改变行值适合分支、DIFF、MERGE新增 / 删除特征列属于 schema 演进。MatrixOne 当前要求参与行级 DIFF / MERGE 的两边 schema 完全一致因此应先统一 schema再开分支试验不能让两条分支各自随意改列定义后还期待自动合并。这也是 Git4Data 的边界之一它能很好地管理“同一结构下的数据演进”但 schema 设计本身仍要走受控的迁移流程。第四站训练、验证、测试集发布——不仅要冻结数据还要冻结“谁属于哪一集”数据接入、标签复审和特征验证都完成后才真正到了数据集发布的时刻。这里不能只说“训练集”因为一次可信的模型开发至少有三种不同职责的数据集合用途可以怎样使用最容易犯的错训练集train拟合模型参数反复读取、采样和训练把未来数据或同一实体的近重复样本混进来验证 / 评估集valid / eval选择特征、超参、阈值和候选模型开发期间可以反复评估反复调到最好后却把它的分数当最终泛化能力测试 / 留出集test / holdout候选方案锁定后的最终无偏评估应尽量少看不能继续据此调参测完不满意又回头调测试集事实上变成了验证集有些团队还会维护一份长期稳定的golden evaluation set覆盖关键人群、罕见风险和业务底线用于跨模型版本回归。它可以被看作额外的受控测试集但同样不能被悄悄拿回训练。因此版本化对象不能只有样本内容还必须包括切分成员关系与切分规则。在案例里我们把它显式写进dataset_membership。风控数据通常按时间切分模拟“用过去预测未来”INSERTINTOdataset_membershipSELECTsample_id,CASEWHENevent_time2026-06-01THENtrainWHENevent_time2026-06-15THENvalidWHENevent_time2026-07-01THENtestEND,time_split:v1:2026-06-01/06-15/07-01FROMsamplesWHERElabelISNOTNULLANDevent_time2026-07-01;时间边界只是第一层。实际切分还要同时防止几类泄漏同一用户、设备或商户的高度相关样本跨到 train 和 test导致模型“见过同一个人”同一原始事件的重复记录或增强样本被拆到不同集合在全量数据上先做标准化、目标编码或缺失值拟合再切分——预处理参数已经偷看了验证 / 测试集标签产生时间晚于特征截点却被错误地当作当时可获得的信息。所以切分清单应保存的不只是train / valid / test三个词还应保存时间截点、分组键、去重规则、随机种子或哈希规则。预处理器也只能在 train 上拟合再原样应用到 valid 和 test。现在samples与dataset_membership必须作为一个整体发布。给单表分别打快照可能落在不同时间点这里更适合使用库级快照CREATESNAPSHOTrisk_dataset_v1FORDATABASErisk_ml;训练、验证和最终测试都显式从同一个数据集版本读取只改变split_name-- 训练器读取 trainSELECTs.*FROMsamples {SNAPSHOTrisk_dataset_v1} sJOINdataset_membership {SNAPSHOTrisk_dataset_v1} mONs.sample_idm.sample_idWHEREm.split_nametrain;-- 调参和模型选择读取 valid最终锁定后才读取 testSELECTm.split_name,COUNT(*)FROMdataset_membership {SNAPSHOTrisk_dataset_v1} mGROUPBYm.split_name;这条库级快照不是物理复制整个数据库而是给当时各表的一致状态建立一个命名版本。前面第三篇已经解释过MatrixOne 的不可变对象与元数据目录让快照成本近乎与数据量无关。至此可复现的不只是“有哪些样本”还包括“每条样本在这次实验中扮演什么角色”。如果后来修正了测试标签、加入新的困难样本或调整切分边界应该发布risk_dataset_v2并让新的评估结果明确绑定 v2不能覆盖 v1 后继续沿用旧指标。新版本发布前样本内容和切分成员关系要分别 review-- 样本或标签变了什么DATABRANCH DIFF samples AGAINST samples {SNAPSHOTrisk_dataset_v1} OUTPUT SUMMARY;-- 哪些样本从一个 split 移到了另一个 split或新进入了评估集合DATABRANCH DIFF dataset_membership AGAINST dataset_membership {SNAPSHOTrisk_dataset_v1} OUTPUT SUMMARY;这两个 DIFF 能区分“模型变了”与“尺子变了”如果 test 的成员、标签或评估协议发生变化v2 的测试分数仍然有效但它已经不是和 v1 完全同口径的直接对比。跨版本趋势应优先在未变化的固定测试 / golden set 上比较同时把新时间窗口作为另一条独立指标报告。第五站训练与评估——模型版本必须能反向找到数据版本MatrixOne 不负责替你跑 PyTorch、XGBoost 或 scikit-learn。训练仍发生在训练框架里模型权重仍写到对象存储或模型仓库。但训练完成后应把完整绑定写进注册表INSERTINTOmodel_registryVALUES(risk_m1,risk_dataset_v1,8f31c2...,feature_v7,sha256:4b7...,s3://models/risk_m1/model.bin,sha256:weights-m1...,0.9430,0.9412,candidate);现在“risk_m1 用了什么训练数据”不再是一份可能过期的文档而是一个可以执行的关系risk_m1 ├── dataset risk_dataset_v1 ├── split time_split:v1 ├── code 8f31c2... ├── feature feature_v7 ├── runtime sha256:4b7... (镜像 digest) ├── valid AUC 0.9430 ├── test AUC 0.9412 ├── artifact s3://models/risk_m1/model.bin └── digest sha256:weights-m1... (权重内容 hash / 不可变对象版本)三个月后复现模型时代码从 Git checkout运行环境按镜像 digest 拉起train / valid / test 都从risk_dataset_v1的切分清单读取模型产物再用注册表里的artifact_digest权重内容 hash或对象存储 / lakeFS 侧的不可变对象 / commit 版本校验。Git4Data 补的是这条链上过去最容易丢失的“数据现场与评估现场”。第六站候选评估与上线——先解释差异再讨论指标第二轮模型risk_m2在验证集上胜出锁定特征、超参和阈值之后才允许在测试集上做最终评估测试 AUC 从 0.9412 提升到 0.9470。这个数字仍不能单独回答最重要的问题提升来自哪里如果m1和m2分别绑定risk_dataset_v1、risk_dataset_v2先看两版样本主线DATABRANCH DIFF samples AGAINST samples {SNAPSHOTrisk_dataset_v1} OUTPUT SUMMARY;-- 示例INSERTED 3000 / UPDATED 200 / DELETED 0这样评审者知道这次不是“神秘地换了一份数据”而是新增了 3000 条延迟真值修正了 200 个错误标签其他样本未动。再结合代码 commit、特征版本和超参记录就能判断实验是否只改变了预期变量。上线门禁也不应只有一个总 AUC。风控模型至少还要看时间外测试集、长期 golden set、不同人群切片、召回率、误杀率、校准度和延迟。每个指标必须同时记录数据集快照、split、指标口径和评估代码版本。Git4Data 不定义这些标准但可以让所有评估都指向稳定的候选数据版本并保留“为什么批准上线”的证据。如果测试集结果不理想团队当然可以继续开发但下一轮使用测试反馈调出的模型不能再声称仍在同一个“未见测试集”上做无偏评估。此时应保留旧结果另建新的候选轮次并在条件允许时用新的时间窗口或独立留出集做最终确认。通过门禁后把model_registry.status从candidate改为production。这只是模型发布元数据真正的服务部署仍由模型服务平台完成。第七站上线监控——版本基线让漂移判断不再悬空模型上线后会遇到两种不同的“变化”数据本身被改了新增样本、修正标签、删除记录数据分布变了新流量与训练期相比金额、类别、人群比例等统计特征发生偏移。第一种变化适合用行级 DIFF 回答第二种变化要靠 SQL 或专门的漂移指标比较两个窗口的统计分布。不要把二者混为一谈。-- 数据内容发生了多少增 / 改 / 删DATABRANCH DIFF samples AGAINST samples {SNAPSHOTrisk_dataset_v1} OUTPUT SUMMARY;-- 分布是否漂移示意真实系统可计算 PSI、KS、JS divergence 等指标SELECTsource_batch,COUNT(*)ASn,AVG(amount)ASavg_amount,AVG(txn_count_7d)ASavg_txn_countFROMsamplesGROUPBYsource_batch;Git4Data 在这里的价值是提供稳定基线开发时的训练、验证、测试版本不会随着主表更新而消失监控结果可以明确写成“当前 2026w29 批次相对risk_dataset_v1的变化”而不是相对某份已经被覆盖的临时表。第八站反馈与持续学习——先知道变了什么再决定怎么训一周后主表相对risk_dataset_v1多了 3000 条样本并修正了 200 个标签。现在才轮到持续学习里最常被讨论的核心问题应该只训增量还是全量重训这个决策不能只看“变化行数少”。适合增量训练的情形模型本身支持partial_fit、continued training 或可靠的 warm start新数据主要是同分布下的追加变化占比小、训练频率高全量重训成本确实成为瓶颈老数据没有大规模删除或标签订正。更适合全量重训的情形特征定义、模型架构或超参数变了出现明显概念漂移需要重新采样或重新加权大量旧标签被纠正或旧样本因合规要求被删除模型不支持可靠的增量更新需要消除增量训练的路径依赖得到一个干净、可复现的发布模型。尤其要注意从训练表删除一行并不会自动消除它对已训练模型的影响。这属于 machine unlearning 问题很多场景仍然必须重训。Git4Data 能告诉你哪些行被删了却不会替模型“忘掉”它们。所以更稳妥的工作流是① DIFF 当前数据 AGAINST 上次训练快照 ② 检查变化类型、规模、分布漂移和合规要求 ③ 决定增量更新 / 窗口重训 / 全量重训 ④ 训练完成后再打新快照并绑定新模型版本当增量训练确实适用时原实验的数字依然很有说服力连续 6 轮、每轮新增约 1000 行偶有标签订正全量重训累计处理 21,000 行而只处理每轮变化累计为 6,004 行。随着轮次增加全量方案的累计处理量近似二次增长增量方案近似线性。但这组数字应该放在正确的位置上理解“省算力”是有条件的收益“知道数据变了什么、能复现每轮训练、能定位模型退化”才是普适收益。准备训练risk_m2前要先按 v2 的时间窗口重新生成并审计dataset_membership确认 train / valid / test 的规模、时间边界和实体交叉都符合预期。然后把样本、标签和三份切分清单一起钉成新的数据库版本CREATESNAPSHOTrisk_dataset_v2FORDATABASErisk_ml;INSERTINTOmodel_registryVALUES(risk_m2,risk_dataset_v2,b710aa...,feature_v7,sha256:4b7...,s3://models/risk_m2/model.bin,sha256:weights-m2...,0.9491,0.9470,candidate);模型与数据的演进链就清楚了risk_m1 ← risk_dataset_v1 (train / valid / test v1) │ ├── 3000 新增样本 └── 200 标签修正 ↓ risk_m2 ← risk_dataset_v2 (train / valid / test v2)如果risk_m2上线后退化排查范围不再是整张表而是这条明确的变化集再加上代码、特征和配置的版本差异。把所有原语放回机器学习语境走完案例后再看 Git4Data 的几个原语会发现它们各自承担的是不同职责。Snapshot不是“备份一下”而是发布一个可引用的数据版本快照最有价值的时点不是每条数据写入之后而是语义边界原始批次通过接入门禁一轮清洗或标注完成一版训练 / 验证 / 测试数据集正式发布一个模型被批准上线一次高风险数据迁移之前。快照过密会增加保留成本和命名混乱快照过少又会失去关键现场。正确策略不是“逢写必拍”而是围绕可审计、可复现的发布节点建立版本。Branch不是多存一份数据而是隔离一个尚未被证明正确的假设分支适合承载未经验证的新批次一轮数据清洗一位标注员的结果一套新特征口径一个数据重采样或类别平衡方案一个候选数据集及其切分。这些工作共同的特点是要在完整数据上下文里计算但在通过评审之前不能影响主线。Diff不只是“拿增量”更是模型变化的解释入口DIFF 可以回答这轮清洗删掉了哪些样本新旧标签集差了哪 200 行候选特征表影响了多少用户m2相对m1的训练数据变量是什么线上反馈回流后新增、修改、删除各有多少所以 DIFF 既服务计算优化也服务审计、归因和 review。只把它理解成“增量训练的数据源”会低估它在整个流程里的价值。Merge 与 Pick把“验证通过”变成受控的数据晋升MERGE适合把一整条已审计分支的有效改动原子并回主线PICK适合只晋升一组明确主键例如复审通过的争议标签、人工确认的难例或某批高价值样本。这让训练数据也能形成类似代码 PR 的流程开分支 → 修改 → SQL 检查 → DIFF review → 评估 → MERGE / PICK → 打快照Restore 与 PITR一个恢复“版本”一个恢复“时间点”RESTORE适合回到某个已命名、已知正确的数据集版本PITR 适合处理“我们不知道是哪一笔写坏了但知道大约从星期三下午开始异常”的事故。它们首先是数据恢复能力。在机器学习流程里额外的价值是恢复后可以重新跑训练与评估判断数据事故对模型造成了什么影响。MatrixOne 在 MLOps 技术栈里到底站哪一层一篇完整的文章也必须讲清它不负责什么。更准确的分工如下对象更适合的版本 / 管理方式MatrixOne 的角色训练代码、SQL、特征定义Git在注册表里记录 commit与数据快照绑定结构化样本、标签、特征值MatrixOne Git4Data快照、分支、行级 diff / merge / pick、恢复图片、音频、视频、模型权重等大字节lakeFS、对象存储版本、DVC 等MatrixOne 保存目录、标签、URI、commit/hash不冒充管理字节内容Python / CUDA / 系统依赖容器镜像、lockfile记录 image digest 或环境 hash训练调度与资源Airflow、Kubeflow、Ray、云训练平台等提供稳定的数据版本输入不替代调度器实验指标与模型注册MLflow 或现有实验平台也可落表用dataset_snapshot split metric protocol补全数据与评估血缘在线部署、灰度、回滚模型服务与发布平台保存发布记录与数据版本关联不直接替代模型 serving一句话概括Git 管代码镜像管环境模型仓库管产物调度器管执行MatrixOne 用 Git4Data 能力管的是机器学习过程中不断演进的“结构化数据状态”并把它与其他版本连接起来。这比“用一个工具包办 MLOps”更现实也更容易落地。哪些数据应该进入 MatrixOne哪些不应该MatrixOne 最契合的是满足以下条件的数据以行、表和主键为基本语义会被反复清洗、订正、标注、合并需要在不同版本上直接做 SQL、JOIN、聚合或向量计算需要知道“哪些记录发生了变化”需要与模型、批次、标注员、规则或外部对象建立血缘。典型对象包括样本目录、标签、偏好对、特征值、数据质量结果、数据集切分 manifest、模型注册元数据和反馈记录。而图像、音频、视频、超大语料文件与模型权重等不可解析字节更适合交给对象存储、lakeFS 或 DVC。MatrixOne 的快照会冻结这些 URI / 引用字段当时的取值例如一个 lakeFS commit、对象版本号或 stage 路径但它保存的是“指针”而非字节本身——外部对象若在同一地址下被覆盖数据库快照不会替你留住旧字节。注v4.1.0 的datalink类型只解析file:///hdfs:///stage://并不支持s3://因此 S3 / lakeFS 对象应以 stage 路径或不可变的 object / commit 版本入库而不是指望datalink解析任意 URL。多模态场景要把“字节版本”和“目录版本”一起 pinmodel └── MatrixOne catalog snapshot └── lakeFS commit / object version └── image / audio / video bytes这会是后续多模态篇的主题。落地时最容易踩的八个坑1. 只给模型编号不绑定训练数据model_v17如果只对应一个文件名没有数据集快照、切分清单、代码 commit、特征版本和环境 digest就不是一个可复现版本只是一个标签。2. 训练任务仍然读取不断变化的主表即使训练前打了快照训练器却继续SELECT FROM samples长任务执行期间看到的数据边界仍可能与预期不一致。训练、验证和测试任务都必须显式引用同一个已发布快照及对应 split。3. 把随机切分当成可复现切分快照相同不代表随机切分相同。时间边界、哈希规则或随机种子也必须保存时间序列、风控等场景还要防止未来信息泄漏。4. 把验证集和测试集混成一套“评估集”验证集可以参与模型选择测试集负责选择完成后的最终确认。每看一次测试结果再回头调参都会把测试信息泄漏进开发过程。应分别记录 valid 与 test 指标并把二者绑定到明确的快照和切分版本。5. 把 DIFF 等同于漂移检测DIFF 回答记录发生了哪些增、改、删漂移检测回答统计分布或条件关系是否变化。后者仍需 PSI、KS、JS divergence、性能切片等统计与业务判断。6. 看到变化少就默认可以增量训练200 条标签订正可能比 20 万条同分布新增更值得全量重训。训练策略取决于变化性质、模型能力、遗忘风险和合规要求不只是数量。7. 忘记快照与分支也有保留成本快照和零拷贝分支创建很轻但被它们引用的历史对象不能被 GC。应区分长期保留的上线版本、短期保留的候选版本和任务结束即清理的临时分支。8. 合规删除与长期快照策略互相打架如果个人数据必须被彻底删除仍长期保留包含该数据的历史快照可能不符合要求。数据保留、快照 TTL、访问权限、删除证明和模型重训 / 遗忘策略必须一起设计。Git4Data 提供版本能力但不会自动替组织完成合规判断。一个可以直接采用的最小闭环如果不想一开始就建设一套宏大的 MLOps 平台可以先从下面这个最小闭环开始1. 新批次进入 staging 分支 2. SQL 质量门禁通过后 MERGE 到样本主线 3. 清洗、标注、特征变更都在分支完成DIFF 后再合入 4. 生成并审计 train / valid / test 切分清单用库级 CREATE SNAPSHOT 一起发布 5. 注册模型时强制写入 dataset_snapshot split_rule valid/test 指标 code_commit image_digest 6. 线上反馈回流后DIFF AGAINST 上次数据集快照 7. 根据变化类型和漂移指标决定增量或全量重训 8. 新模型通过门禁后生成新快照并更新模型血缘它不要求一次替换所有已有工具只要求确立三个纪律未经审计的数据不直接进主线没有数据集快照和切分清单的训练不进入模型注册表说不清两版数据与评估基准差异的模型不进入生产。一旦这三个纪律形成快照、分支、DIFF、MERGE 就不再是零散 SQL而会变成机器学习团队共同的工作语言。结语模型的生命周期本质上也是数据状态的生命周期回看整个流程Git4Data 这套能力没有替你训练模型也没有替你判断模型好坏。它做的是更基础的一层数据进入前可以隔离被修改时可以并行、评审和合并被训练时可以冻结并引用模型变化时可以解释数据变量出现事故时可以复原和回退反馈回来时可以精确知道下一轮从哪里开始。所以 Git4Data 对机器学习最大的价值不只是“增量训练省了多少算力”而是把一条原本依靠文件名、时间戳和口头约定维系的流程变成一条可执行、可审计、可复现的数据版本链。这篇建立的是 AI 训练实践篇的总地图。接下来我们会沿着其中几个最典型的节点逐一深入SFT 数据策展几十万条指令数据怎样原地去重、过滤、去污染而且每一刀都有 DIFF 收据标注协作如何把并行标注、分歧发现和资深评审映射成 branch / conflict / cherry-pickRLHF 偏好数据共识、争议、改判和奖励模型版本怎样形成完整谱系多模态训练集lakeFS 管字节MatrixOne 管目录、标签和行级演进两个版本世界怎样拼成一个可复现整体。当这些环节共用同一套版本原语时Git4Data 才真正从一个数据库功能变成 AI 数据工程的工作方式。 可运行 SQLgithub.com/matrixorigin/git4data-tutorial 前七篇文章github.com/matrixorigin/matrixorigin-blog 源码与社区github.com/matrixorigin/matrixone参考资料MLflow — 实验跟踪与模型注册https://mlflow.org/docs/latest/tracking.html、https://mlflow.org/docs/latest/model-registry.htmlApache Airflow — 工作流调度https://airflow.apache.org/docs/scikit-learn — 数据泄漏与常见陷阱https://scikit-learn.org/stable/common_pitfalls.html#data-leakagelakeFS — 对象存储上的数据版本控制https://docs.lakefs.io/Bourtoule 等《Machine Unlearning》IEEE SP 2021https://arxiv.org/abs/1912.03817本文配套可运行脚本已在 MatrixOne 4.1.0 验证08-ml-lifecycle/ml_lifecycle_demo.sql
![[C++]内存管理：串顺序存储的内存回收](http://pic.xiahunao.cn/yaotu/[C++]内存管理：串顺序存储的内存回收)
