Amazon MLS-C01: MLOps、监控、标注与模型治理 — 学习指南
属于 AWS Machine Learning Specialty MLS-C01 — 学习指南. 使用经过验证的答案练习： Amazon 考试中心, 或参加限时模拟考试： ExamRoll.io.
管道、CI/CD 和自动化
生产级机器学习需要端到端的自动化，将数据摄取、验证、训练、调优、模型打包和部署整合到可重复的管道中。使用 Amazon SageMaker Pipelines 定义步骤，用于处理作业 (Data Wrangler 或 ScriptProcessor)、训练 (使用 Distributed Data Parallel 或 XGBoost/BlazingText 进行托管训练)、超参数调优 (使用 HyperparameterTuningJob，并设置目标指标和训练作业的 StoppingCondition)，以及在 SageMaker Model Registry 中注册模型。将 Pipelines 与 AWS CodePipeline 和 CodeBuild 集成，以进行代码级 CI 检查和单元测试，并使用 CloudFormation 或 CDK 来预置一致的环境。在步骤上配置缓存，以避免重新运行未更改的工作，并参数化管道输入（S3 前缀、实例类型）。对于 HPO，不要仅依赖 MaxNumberOfTrainingJobs；还应为每个训练作业设置 StoppingCondition (MaxRuntimeInSeconds)，并在可用时启用自动提前停止，以避免成本失控。常见的陷阱包括对不断增长的数据集使用 File 模式（对于大型数据集，应切换到 Pipe 模式或分布式训练）、不对数据集和特征进行版本控制，以及在重新训练前未能包含数据验证关卡（SageMaker Processing + Deequ 或 Data Wrangler 检查）。在数据库内模型 (Redshift ML) 和 SageMaker 之间的决策标准基于模型复杂性、延迟和操作控制：Redshift ML 便于在 SQL 内部使用简单的 XGBoost 模型，而深度网络、自定义架构和可扩展的端点则需要使用 SageMaker。
监控、漂移检测和模型质量
持续监控必须同时捕获模型性能和数据质量。启用 SageMaker 模型端点的数据捕获功能，将请求和响应存储到 S3，然后使用 SageMaker Model Monitor 基线作业为训练数据分布建立基线。使用内置的 Model Monitor 检查功能来检测模式违规和单变量漂移指标；对于分布偏移，计算 KL 散度、群体稳定性指数 (PSI) 或 KS 检验，并针对漂移阈值设置 CloudWatch 警报。跟踪模型指标——分类：精确率/召回率、ROC AUC、混淆矩阵和特定类别的 FPR/FNR；回归：RMSE、MAE 和 MAPE。Clarify 可以在训练前和训练后运行偏见和可解释性检查，并生成基于 SHAP 的特征归因；使用 Clarify 检测子群体的性能差异（敏感属性）。常见的操作陷阱包括不捕获推理上下文（特征映射、模型版本、请求 ID）、忽略标签延迟（延迟的标签会破坏及时的评估），以及将群体偏移与概念漂移混为一谈——应区别对待（前者重新训练，后者收集标签并重新评估特征）。对于警报，将聚合指标和漂移指示器推送到 CloudWatch，并在超过阈值时通过 SageMaker Pipelines 自动执行回滚或重新训练。
标注、数据准备和特征工程
高质量的标签和一致的特征管道是基础。使用 Amazon SageMaker Ground Truth 创建标注工作流，该工作流具有自动预标注（模型辅助标注）、主动学习和注释合并功能；选择工作者类型（私有员工、供应商或公有）并配置标签验证和用于评估标注者之间一致性的指标。对于 EDA 和转换，将数据集摄取到 SageMaker Data Wrangler 中以分析分布、插补缺失值，并将处理脚本导出到 SageMaker Processing 作业中。在 Amazon SageMaker Feature Store 中持久化在线和离线特征，以实现一致的运行时检索和简单的回填。编码决策取决于规模和基数：低基数的分类变量可以进行独热编码；高基数项（例如，100 个产品 SKU）使用目标编码或嵌入（TensorFlow/PyTorch 嵌入层或 SageMaker 内置算法），而多选调查答案则映射到多热向量。警惕常见的陷阱，例如在附加每日元数据时发生标签泄漏（应包含特征工程窗口和泄漏测试）、对非常大的 S3 数据集使用 File 模式（Pipe 模式以流式传输记录并支持多实例分布式训练），以及不对转换进行版本控制——应将 Data Wrangler 转换导出为可重用的 Processing/Training 步骤，以确保训练和推理之间的一致性。
可解释性、治理和扩展机器学习团队
可解释性和治理需要可操作的工件和审计跟踪。使用 SageMaker Clarify 计算训练前偏见指标和训练后特征归因 (SHAP)，并将结果与 Model Registry 条目一同存储。在 SageMaker Model Registry 中注册模型时，应包含审批状态、签名的 ModelPackageGroups 和自动化的晋升门控。使用 SageMaker Experiments 跟踪实验和血缘关系，并启用 CloudTrail 来审计 API 调用。对于可解释性技术，树模型（如 XGBoost 内置的 SHAP）优先使用模型原生的特征重要性；对于深度网络，则使用 SHAP 或积分梯度，同时注意运行时成本——为批量客户离线预计算解释，并为实时请求暴露摘要信息。治理的最佳实践包括：使用模型卡片记录数据集描述、公平性检查和业务规则；以及为模型部署强制执行 IAM 最小权限原则。为了扩展团队，应将管道模块化，为预处理/验证创建标准模板，集中化 Feature Store，并自动化漂移检测和重训练触发器，以便数据科学家能专注于模型改进而非运维工作。常见的陷阱包括：过度依赖特征重要性来推断因果关系、未能为已部署的模型维护审计日志，以及在低延迟端点中同步暴露计算成本高昂的可解释性计算。
实践问题：用例场景
场景： Acme 制造公司运营着一个连接间歇中断的远程传感器集群，并使用 AWS IoT 和 S3 进行集中式数据聚合。他们的 AWS ML 环境包括 SageMaker、IoT Core、Kinesis Data Streams 和启用了 Greengrass 的边缘设备。
挑战： 在连接间歇中断的情况下，在远程站点提供低延迟的异常检测，同时在没有 Direct Connect 的情况下收集遥测数据用于集中式重训练和漂移检测。
推荐方法：
- 将一个使用 SageMaker Neo 编译的紧凑型异常检测模型部署到边缘设备上的 AWS IoT Greengrass，以实现实时的本地推理和操作（如本地警报、短期缓冲）。
- 通过 AWS IoT Core 将摘要遥测数据和异常标志流式传输到 Amazon Kinesis Data Streams，并使用 Kinesis Data Firehose 将原始和聚合数据以 parquet 格式持久化到 S3 进行集中存储。
- 构建一个 SageMaker Pipeline，用于接收 S3 批次数据，运行 Processing 作业 (Data Wrangler) 来计算基线和进行特征工程，根据需要触发 HyperparameterTuningJobs，并将验证后的模型注册到 SageMaker Model Registry。
- 在中心端点上启用 SageMaker Model Monitor，并调度批处理作业，将边缘收集的数据分布与训练基线 (PSI/KL) 进行比较，同时使用 SageMaker Ground Truth 对抽样的警报进行人工标注，以形成闭环。
基本原理： 通过 Greengrass + Neo 进行边缘推理，确保了在连接间歇中断时也能做出低延迟决策；Kinesis + Firehose 保证了数据能可靠、有序地注入 S3 用于重训练；SageMaker Pipelines 和 Model Registry 提供了可重复的重训练、版本控制和带有漂移检查的自动化晋升，以维持模型质量。
练习这些题目 → · 在 ExamRoll.io 上限时练习 →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
通过考试 →