1 MLOps 基础要覆盖什么
把模型训练成功，只回答了“这批数据上能不能学到规律”。把模型持续用于真实业务，还要回答：正在使用哪个版本，训练数据来自哪里，评估结果能否重现，输入变化后谁会发现，出现问题怎样恢复。MLOps 是围绕这些问题组织机器学习开发与运行的方法。它把数据、代码、模型、评估和运行责任连接起来，让模型的变化有依据、有记录、有退路。
本课以公开的电信客户流失表格数据为教学场景。每行代表客户在观察时点的状态，输入包含在网月数、月费、合约类型、互联网服务类型和付款方式，标签表示之后规定窗口内是否流失。公开数据适合练习流程，但字段含义和采样方式必须阅读数据说明；某些公开版本只提供静态快照，不能凭空声称具备完整的历史预测窗口。教材中的时间窗口与线上事故均为教学设定，不代表数据发布方的真实运营情况。
假设业务希望提前联系高风险客户，模型输出流失概率，运营人员根据容量选择联系名单。此时“预测正确”并不是孤立目标：误报会占用联系名额，漏报会错过潜在流失者。还要考虑客户能否被联系、干预是否有效，以及数据使用是否得到允许。模型指标用于衡量预测，联系后的留存变化属于干预效果，不能把它们混成同 1 个结论。
最小生命周期包含数据准备、训练、验证、登记、发布、观测和反馈。数据准备说明样本与标签怎样形成；训练产出候选模型；验证判断候选是否符合约定；登记保存版本证据；发布改变服务使用的版本；观测发现运行和效果异常；反馈把新证据带回后续决策。即使团队只有 2 人，也应能指出每个环节由谁负责，而不必先购买复杂平台。
MLOps 的对象也不只是模型权重。把“月费”从数值改成字符串，或者改变缺失值处理方式，都可能改变预测结果。预处理器、特征定义、类别映射、决策阈值和运行依赖应与模型配套管理。可复现意味着在明确的输入与环境下能解释并尽量重现结果，不意味着所有硬件上的浮点结果必须逐位相同。入门时先做到版本可识别、证据可查、回退可执行。
图片分类与短文本分类也遵循相同原则。图片任务要保留类别映射、图像尺寸和归一化方法；短文本任务要保留分词与截断规则，并防止同源文本跨越数据集合。不同任务的特征不同，生命周期中的核心问题却相通：变化是否可追踪，评估是否可信，运行是否受控。后续各节会把这些问题落到可执行的记录与门禁上。
2 实验跟踪、注册与血缘
实验跟踪记录“尝试了什么、用什么条件、得到什么结果”。对流失预测，1 次运行至少记录运行编号、代码提交标识、数据快照标识、切分规则、随机种子、特征列表、算法参数、依赖版本、指标和产物位置。不要只保存“最好 AUC 为 0.86”的截图；如果不知道它用了哪批样本、是否包含泄漏字段，这个数字就无法支持发布决策。
先固定评估设计。作为入门练习，可按流失标签分层，将数据划为训练集 70%、验证集 15%、测试集 15%，并确保同 1 客户只出现在 1 个集合。训练集用于拟合，验证集用于选参数和阈值，测试集用于冻结方案后的最终检查。若场景预测未来，应优先采用符合时间先后的切分，并让标签窗口在相邻集合之间合理隔离；随机切分不能自动证明未来可用。
所有需要从数据估计的预处理参数，都应只在训练集上拟合。例如缺失月费的填充值、数值标准化参数和类别编码词表，不能先从全量数据计算再切分。否则测试信息已经进入训练流程。也要排除预测时点之后才出现的字段，如销户办理结果、最终退款金额。泄漏模型可能在离线取得漂亮成绩，却无法在真实预测时获得这些输入。
精确率 precision 表示被判为流失的客户中，实际流失的比例；召回率 recall 表示实际流失客户中，被找出的比例。F1 是 precision 与 recall 的调和平均，适合同时观察误报与漏报。ROC-AUC 衡量模型跨阈值的排序能力，但不直接告诉你每天联系多少人。类别不平衡时还应看正类占比、PR 曲线或 PR-AUC，不能只报告准确率。
例如测试集有 1000 人，其中实际流失 200 人。某阈值下报出 250 人，命中 150 人，则 precision 为 150÷250＝0.60，recall 为 150÷200＝0.75，F1 约为 0.67。把所有人判为不流失也有 80% 准确率，却没有识别任何正类。每个指标都要附上样本范围、时间和阈值，避免把不同条件下的数字直接排序。
模型注册把实验产物变成可管理的版本，例如候选 v12 关联运行 run-042、数据快照 ds-07、预处理器 prep-03、阈值 0.42 和评估报告 eval-12。注册不等于批准上线，状态可以是候选、已批准、使用中、已停用。血缘则回答“这个结果由什么产生”：从服务中的版本追到产物、训练运行、数据与代码，再从变化反查受影响的版本。
血缘记录应指向可取得的不可变快照或内容摘要，不能只写会被覆盖的文件名。原始客户数据也不应为了追踪方便而复制到公开日志。日志保存必要标识和统计摘要，敏感明细留在受控存储中，并遵守保留期限。记录越多并不必然越可靠；关键是让负责人员在需要时找得到、读得懂、能核对。
3 持续训练与门禁流水线
持续训练是按照约定重复生成候选模型的流程，不是“每天把最新数据训练后直接替换线上版本”。触发条件可以是新增了足量已确认标签、定期复评、数据修复，或监控发现值得调查的变化。触发只代表启动工作，能否发布还要经过门禁。把训练与发布分开，才能避免错误标签或临时数据波动直接变成用户面对的行为变化。
流水线首先检查输入契约：列是否齐全，类型是否一致，客户标识是否重复，标签是否只取允许值，样本时间是否合理。接着检查数据质量，例如月费缺失率和未知合约类型比例。契约检查回答“能否按约定读取”，质量检查回答“数据是否值得继续使用”。流水线通过技术检查，也可能因为样本过少或标签尚未成熟而暂停训练。
训练阶段使用固定切分策略，并将预处理与模型打包。评估阶段既看候选自身，也与当前使用版本在相同样本上比较。可以设教学门禁：正类 recall 至少 0.70，precision 至少 0.55，ROC-AUC 相对基线下降不超过 0.01，同时预测服务的错误率和延迟达到要求。这些数值只是练习用的明确约束，真实门槛应由误报成本、漏报损失和运营能力共同确定。
门禁不能只检查整体均值。整体 recall 合格，仍可能掩盖月付客户或新客户的表现下降。应选择与业务相关、样本量足够的分组，报告每组正类数量与指标；样本很少时标注不确定性，避免把偶然差异当成确定结论。验证集上选择阈值后应冻结方案，再做测试检查；如果根据测试结果继续调参，原测试集就不再是独立裁判。
门禁结果应包含通过、失败或证据不足，并给出具体原因。测试数据缺少标签，不能记为“指标为 0”，也不能默认通过。训练完成但产物缺失、输入模式不匹配、基线评估失败，都应阻止晋升。失败出口需要留下报告、通知责任人，并保持当前服务版本可用。队列中有新候选，也不意味着必须立刻替换稳定版本。
发布通常先在影子环境检查输入输出，或让少量请求使用候选版本，观察错误、延迟和预测分布，再逐步扩大范围。影子预测不会直接改变用户决策，适合检查兼容性；小流量发布会产生真实影响，需要可回退。它们都无法在标签尚未回来时证明长期效果更好，因此必须保留后续效果复核。入门阶段理解控制点即可，复杂调度与大规模训练实现留待后续学习。
4 动手：晋升一次模型版本
本节用可在本地表格或简单脚本中完成的操作，模拟将候选 v12 晋升为服务版本。准备当前版本 v11、候选版本 v12、同 1 份冻结评估集和版本登记表。若使用公开流失数据，先检查数据许可与说明，记录目标列的编码，并将数据快照固定。不要为了演示凑出更好的数字；下面的结果是教学示例，实际练习应填写自己得到的值。
第 1 步，建立运行卡片。填写 run-042、ds-07、代码提交标识、特征清单、70%／15%／15% 的分层切分配置和随机种子。特征可选在网月数、月费、合约类型、付款方式；客户标识只用于去重与追踪，不直接当作预测特征。若字段来自未来，先移除并记录原因。把缺失处理、类别编码与模型一起保存，保证评估和服务使用相同变换。
第 2 步，只在训练集拟合，在验证集比较基线与候选。可以用逻辑回归作为易解释的起点，再比较另 1 个简单分类器，不必立即寻找复杂模型。在验证集选择阈值，使联系人数符合运营容量，并冻结这一选择。若对类别不平衡做重采样或类别加权，只在训练流程内进行；验证与测试保持目标场景的类别比例，否则 precision 会失去现实含义。
第 3 步，对冻结的 v11 和 v12 做相同评估。示例中 v11 的 precision 为 0.61、recall 为 0.68、F1 约为 0.64、ROC-AUC 为 0.82；v12 的对应值为 0.60、0.75、约 0.67 和 0.83。v12 找出的流失者更多，但误报比例略增。晋升理由应说明业务接受了什么取舍，不能只写“AUC 更高”。同时记录每个版本采用的阈值及联系人数。
第 4 步，检查门禁与运行约束。确认 v12 达到事先约定的 recall 和 precision 下限；查看新客户、月付客户等分组是否存在明显退化；检查空输入、未知类别和缺失字段的处理结果。对于不符合输入契约的请求，服务应返回明确错误或使用已约定的降级策略，不能悄悄把所有缺失值变成 0。再用少量固定样例检查打包后的预测与评估时一致。
第 5 步，生成晋升记录并批准发布。记录候选 v12、目标环境、评估报告、批准人、批准时间、观察窗口、回退版本 v11 和回退触发条件。将服务引用从 v11 切换到已批准的产物标识，保留原产物和依赖。使用可变的“latest”标签作为唯一依据，会让回退时无法确定究竟恢复什么；登记表中必须保留真实版本映射。
第 6 步，检查发布后的服务版本、输入模式、错误率和预测比例，确认回退操作能够恢复 v11 的完整组合。教学练习可在本地模拟切换服务配置并重新预测固定样例，不需要真实生产流量。完成标准是另 1 位同学仅凭登记表就能解释为什么发布、使用了什么以及怎样恢复。只拿到模型文件而无法找到评估依据，仍不算完成晋升。
5 自动化与人工审批取舍
自动化适合规则清晰、频率较高、结果可重复检查的环节，例如字段校验、训练执行、指标汇总、产物登记和兼容性测试。人工审批适合需要理解业务代价、例外情况或影响范围的决策，例如接受某个客群 recall 下降，或在标签规则改变后判断历史指标是否还能比较。让人重复点击所有通过按钮，并不能自动提高安全性；让人看到关键差异才有意义。
审批人至少应看到数据与标签变化、同基线的指标差异、受影响分组、运行检查和回退准备。批准必须对应具体版本和证据快照，不能用聊天里“可以试试”的消息长期授权所有后续版本。若批准后又更换阈值或预处理器，应重新确认相关门禁，因为这已经改变了实际决策行为。审批超时应保持原版本，而不是把沉默解释为同意。
交互中可以调整单次发布影响范围，观察发布策略如何从自动校验后小范围试用，转为增加人工审批与更长观察窗口。滑块不计算真实事故概率，也不把“影响范围”伪装成数学风险评分。它表达的原则是：影响越广、反馈越慢、恢复越困难，发布前后需要的证据越充分。实际流程仍要结合任务后果、数据稳定性与团队值守能力。
对低影响的图片分类演示，错误结果能立即被发现并快速撤回，自动化可以覆盖较多步骤。对决定是否给予客户某种服务的模型，错误可能影响权益，还可能存在标签延迟，人工应审查目标是否适当、分组表现是否可接受。相同技术流水线可以采用不同批准策略。重点是按后果与证据设计流程，而不是按模型名称决定审批强弱。
也要计算人工环节的维护成本。只设 1 位批准人容易造成等待与疲劳，应明确代理人、工作时间和紧急处理办法。自动检查失败时，人可以调查并修复数据或门槛配置，但任何例外放行都应记录理由、有效期限和补救措施。对于缺少关键证据的候选，继续收集证据通常比凭经验强行上线更合适。自动化应帮助人集中注意力，而不是隐藏决策责任。
6 常见坑：无监控就自动重训上线
最危险的入门误解，是认为“每天训练”自然等于“模型越来越新、越来越好”。训练只会学习输入数据中的模式。如果新标签混入了错误状态，或流失定义从主动销户变成所有暂停服务，自动训练会稳定地复制这些问题。若流水线又直接发布，错误会在没有解释的情况下进入业务。训练频率越高，错误传播也可能越快。
监控至少分为服务、数据和效果 3 层。服务层看请求失败率、延迟、资源使用和实际加载的版本；数据层看缺失率、取值范围、未知类别比例和特征分布；效果层在标签到达后看 precision、recall、F1、AUC 及分组变化。数据正常不保证效果正常，服务可用也不保证预测有用。每层都要有责任人、观察窗口和可执行的处理动作。
分布漂移表示输入分布发生变化，例如月付客户占比从 30% 升到 55%。这种变化可能来自真实客群变化，也可能来自编码错误。它是调查信号，不是模型必然失效的判决。相反，即使月费和合约分布看起来稳定，客户流失原因也可能变化，导致输入与标签的关系改变。因此数据监控只能提供较早信号，效果监控仍需要等待可信标签。
另 1 个坑是训练与服务预处理不一致。训练中把未知合约类型映射为“其他”，服务中却直接报错；训练使用元为单位，服务传入分；训练把空文本保留为缺失，服务变成字符串“null”。这些问题不一定会被总体 AUC 暴露。应让同 1 份预处理定义用于训练和服务，并用固定输入样例做兼容性检查，检查对象包括编码、单位和字段语义。
告警必须能够导向动作。收到“未知类别比例超过 5%”后，值守者应知道去核对上游字段变更、采样检查受影响记录，并判断是否暂停候选发布或切换降级策略。不要直接写成“漂移超过门槛就重训上线”：上游编码错误需要修数据，新客群变化需要评估覆盖，标签未成熟则应等待。自动重训最多是可选调查动作，不能替代原因分析与发布门禁。
7 案例：特征漂移未报警导致效果滑坡
以下是流失预测的教学事故。团队每周生成联系名单，服务版本 v11 已稳定运行。原训练样本中月付合约占 30%，在网时间小于 3 个月的客户占 12%。后来新套餐吸引大量短期用户，线上这 2 项比例分别升到 55% 和 28%。服务接口没有报错，预测照常返回，团队却只监控请求量与延迟，没有观察特征分布。
流失标签需要等待 30 天确认，因此问题最初表现为运营反馈“名单越来越难联系，命中变少”。团队先怀疑阈值太高，准备降低阈值增加召回。但降低阈值会扩大联系量，也可能引入更多误报；没有成熟标签时，不能证明这样做有效。负责人先冻结自动晋升，保存受影响时间段的数据摘要、服务版本与阈值，避免调查期间继续改变多个条件。
标签成熟后，团队按预测时点对齐结果，只分析观察窗口完整的客户。整体 recall 从历史参考的 0.74 降到 0.58，precision 从 0.60 降到 0.46。进一步按在网时长分组，发现下降主要集中在不足 3 个月的新客户。比较时还检查了样本数量、正类比例和标签定义，避免把“本周尚未确认流失”误当成负类，从而误报模型退化。
接着沿血缘核对版本、数据和代码：线上确实使用 v11，月费单位未变，合约编码也未改变，排除了部署与输入格式问题。新套餐客户在历史训练数据中覆盖不足，并且其流失模式不同。这里既观察到了客群构成变化，也获得了分组效果下降证据；仅凭占比变化本身，还不能下同样结论。调查记录应把“观察到的事实”与“原因假设”分开书写。
处置先考虑业务连续性。旧版本 v10 同样缺少新客群样本，盲目回退未必改善效果。团队临时限制自动联系范围，对新客群使用经过业务确认的规则，并向运营标明覆盖范围。随后收集标签成熟的新样本，按时间划分训练与评估窗口，生成候选 v12，检查新旧客群的指标和联系容量，再经过门禁与审批逐步发布。
修复完成还要补监控。团队为合约类型、新客户占比、缺失率和预测正类比例设置参考窗口，对持续变化发出调查告警；每次标签成熟后补算分组效果。参考窗口应保留日期与版本，不能每天无条件向前滚动，以致缓慢退化被不断吸收成“正常”。告警阈值也要结合正常波动调校，避免值守者被大量短暂噪声淹没。
这次事故的教训是把信号接到责任链上：数据变化由数据负责人核对，标签成熟由业务负责人确认，效果退化由模型负责人分析，发布由指定人员批准。补上 1 张监控图还不够，还要演练谁收到告警、多久响应、先保留什么证据。恢复服务与修复模型可以采用不同节奏，但都必须留下可追溯的决定。
8 把模型生命周期写进运营方案
运营方案应描述模型怎样进入日常工作，而不是只列训练工具。先写使用目标、预测时点、输入字段、标签窗口与采取的行动。流失模型可以每周生成联系名单，运营按容量联系，并记录实际执行情况。若客户没有被联系，不能把之后的留存直接归功于模型；若联系策略同时改变，也要在分析效果时明确说明。预测、决策和干预记录需要关联。
接着写版本证据与发布规则。每个使用中的版本都应关联数据快照、代码、预处理、阈值、评估报告和批准记录。方案要明确训练触发条件、最低标签数量、验证方式、整体与分组门禁，以及证据不足时的处理。对公开静态数据练习，可以模拟周期；对真实系统，则要说明数据何时可用、标签何时成熟，避免许诺不可能实现的每日效果监控。
运行部分应列出监控对象与责任归属。例如数据负责人检查月费缺失率、未知合约类型和新客户占比，服务负责人检查错误率与版本一致性，模型负责人在标签成熟后复核 recall 和 precision。告警后的动作要具体到核对字段、暂停晋升、限制使用范围或执行回退，并说明谁有权采取这些动作。只有阈值而没有处理人的告警，无法形成闭环。
最后写恢复条件和复盘方法。保存可恢复的旧版本组合，说明回退是否仍兼容当前输入；如果旧模型也不适用，要有经过业务认可的降级办法。恢复后核验服务与业务流程，再补做效果检查。复盘记录发现时间、影响范围、证据、决定和后续责任，不把“重新训练成功”当作事故结束。模型生命周期进入运营方案，才意味着团队承诺持续管理它的表现。
9 从MLOps 基础走向AI 评测（A40）
现在可以把 1 次模型变化讲成完整的证据链：目标是什么，样本怎样形成，训练与评估如何隔离，为什么批准某版本，发布后观察什么，出现问题怎样恢复。MLOps 提供执行与管理这些工作的框架，但门禁是否合理仍取决于评测质量。如果测试集代表性不足，或者指标与实际使用目标脱节，再整齐的流水线也可能持续批准不合适的模型。
A40 将继续讨论如何设计可信评测，包括测试样本覆盖、基线比较、分组分析和误差归因。本课先记住边界：AUC 更高不直接代表联系策略更有效，离线通过不代表线上永远稳定，漂移告警也不等同于性能退化。对于短文本分类，还要检查同源改写是否跨集合；对于图片分类，要检查相同对象的近重复图片是否同时进入训练与测试。这些都属于评测有效性问题。
在进入下课前，拿任意 1 个候选版本核对 3 件事：能否找到输入数据和预处理版本，能否说明发布门槛与实际证据，能否指出标签延迟期间靠什么监控。如果答不出来，先补记录与责任，再增加自动化。能把这 3 件事讲清楚，就已经具备继续学习 AI 评测所需的生命周期视角。
放进方案里
本项目使用流失预测辅助每周客户联系，输入限定为预测时点已知的在网月数、月费、合约类型与付款方式，输出为流失概率及联系建议。标签按约定的后续 30 天窗口确认，未成熟记录不作为负类。运营按可执行容量确定名单，模型预测效果与联系干预效果分别统计，避免将留存变化直接归因于模型。
数据负责人维护快照、字段定义与标签规则；模型负责人维护训练配置、预处理、阈值和评估报告；服务负责人维护版本映射与恢复操作；业务负责人批准联系策略。每个候选关联运行编号、代码、数据、依赖和产物标识。训练与验证隔离，正式发布前冻结方案并检查独立测试结果，同时报告新客户与月付客户的样本量和表现。
晋升门禁采用事先确认的 precision、recall 与运行约束，并与当前版本在相同评估样本上比较。指标不足、数据契约失败或标签证据不全时暂停晋升。批准记录绑定具体版本、阈值、报告和批准人；先小范围观察错误率、延迟与预测分布，再扩大使用。门禁具体数值由误报成本、漏报损失与联系容量共同确定。
运行期间监控缺失率、未知类别、新客户占比和预测正类比例，标签成熟后补算整体与分组效果。持续异常触发负责人调查，先核对上游变更与输入语义，再决定修数据、重训或调整使用范围。每次发布保留完整的旧版本组合和回退条件；旧版本也失效时采用经业务确认的降级流程。恢复后登记影响范围、证据、处置和复盘责任，并验证告警与恢复链路可执行。
10 小结：下一步AI 评测（A40）
MLOps 基础是让模型从实验进入可管理的运行过程：跟踪尝试，登记版本，连接血缘，通过门禁发布，再用监控与成熟标签检查真实表现。自动训练只生成候选，晋升必须有证据，异常必须有人处理。
自测时尝试解释：为什么预处理也需要版本，为什么高准确率可能掩盖类别不平衡，为什么漂移后不能立即自动重训上线。下一步进入 AI 评测（A40），继续判断“评估证据本身是否可信，以及它足以支持什么决定”。