6.0
关注
AI SCORE
工具产品2026-07-31 00:10
SageMaker AI端点的推理监控体系
AWS ML Blog#AWS#监控#SageMaker
Editor brief · 编辑速览
AWS推出Bedrock上SageMaker的监控层，实时追踪预测质量、数据漂移和延迟。对云上模型部署的程序员有参考价值。
如果无法跟踪机器学习（ML）模型的预测质量，组织往往只有在客户投诉或进行抽查时才会意识到问题，这会危及客户信任。本文介绍针对 Amazon SageMaker AI 端点的推理元监控。它在生产 ML 推理管道之上提供一个治理层，用于持续跟踪预测质量和数据质量指标，并将趋势可视化。你将学习如何专门针对预测模型设计和实现推理元监控系统，其中使用 Amazon Quick，并可选择结合 Amazon SageMaker AI MLflow App。该系统包括漂移检测、延迟到达的真实标签数据集成，以及自动化性能仪表板。
开发预测型 ML 模型通常是一个资源密集型过程。你可能会投入数月时间构建训练管道，以便在欺诈检测、信用评分或需求预测等用例中获得较高的验证准确率。你部署的模型性能可能会悄然下降，而团队可能直到数周后才注意到。欺诈案件处理人员开始发现误报激增，信贷员开始发现更多原本应该被标记的申请。由于需求预测被高估，企业资源规划人员发现库存过剩。
因此，ML 团队需要一个能够持续反馈生产环境中模型性能的系统。每当检测到模型质量下降或数据漂移时，该系统都应该立即发出警报。这样，团队就能及早采取行动，使模型性能长期保持稳定，并维持较高的客户信任度。
这套推理元监控解决方案将 AWS 托管服务（Amazon SageMaker AI、Amazon Athena、AWS Lambda、Amazon EventBridge、Amazon Quick）与开源 ML 工具（SageMaker AI MLflow Apps、Evidently AI）结合起来。
使用仓库中提供的 CloudFormation 模板创建虚拟私有云（VPC）、子网、SageMaker AI 域、用户配置文件和 JupyterLab 空间。该模板还会克隆 Git 仓库，并使用实际值更新 .env。
CloudFormation 模板会自动完成整个设置过程。如果你打算使用现有的域，可以克隆仓库、更新环境变量值，然后按顺序运行各个 notebook。
运行 CloudFormation 设置会创建并初始化相关变量。
如果你打算使用自己的 SageMaker AI 域，请将 .env.example 复制为 .env，然后使用你的具体环境变量更新该文件。.env 中的设置会覆盖所有其他默认值以及 config.yaml 中的设置。
git clone --branch v2.0.0 https://github.com/aws-samples/sample-mlops-bestpractices.git
cd sagemaker-automated-drift-and-trend-monitoring
cp .env.example .env
该系统实现了集成式训练、推理和监控管道，并通过一个中央 Athena Iceberg 表、Amazon Quick 和 SageMaker AI MLflow Apps 将其统一起来。
图 1：基于 AWS 托管服务构建的端到端 MLOps 架构
训练管道包含 MLflow 中的实验跟踪。如图 2 所示，它建立了端到端模型训练流程。
下载 Kaggle 数据集：从 Kaggle 下载信用卡欺诈数据集。
数据摄取：将 S3 数据加载到训练数据中。该架构使用五个 Athena Iceberg 表构成中央数据湖。training_data 表存储用于拟合模型的 80% 数据切片。evaluation_data 表是固定的 20% 留出数据切片，用于对模型进行评分。漂移监控的基线是 evaluation_data，而不是 training_data，因为每个已注册模型的指标都是相对于该留出切片进行衡量的。两个表均由同一个初始化步骤从同一份预测 CSV 中填充，该步骤基于 transaction_id 执行确定性哈希拆分，因此各行的分区在多次管道运行之间保持稳定。
SeedAthenaTrainingData 步骤（参见图 2）基于 transaction_id 执行确定性哈希拆分，以幂等方式将 Amazon S3 中的预测 CSV 加载到 training_data（80%）和 evaluation_data（20%）Iceberg 表中。重新运行会产生完全相同的行分区，因此评估切片在不同模型版本之间保持稳定，并可作为固定的漂移基线。你也可以将训练数据替换为自己的数据。更多详细信息，请参阅 Bring your own dataset。
图 2：训练管道执行过程
推理处理程序会将所有推理写入 Amazon Simple Queue Service（Amazon SQS），然后由 inference-logger Lambda 函数处理。inference-logger Lambda 函数会批量处理最多 10 条预测，或者处理 30 秒内到达的预测，以先满足的条件为准，并将数据写入 Athena Iceberg 表。所有 notebook 还包含用于创建角色和基础设施的便捷脚本。
3_inference_monitoring.ipynb 中的步骤 3.3 使用发生漂移的输入特征调用已部署模型，从而注入数据漂移。在真实环境中，这些请求通常来自业务应用，它们会随时间推移发送包含漂移输入的推理请求。真实标签模拟是 notebook 中的步骤 4。该解决方案中的步骤 3 和步骤 4应替换为你的业务流程。这些业务流程会在计算数据漂移和模型漂移之前执行以下两个步骤：
a. 步骤 3：你的应用调用端点执行推理。这会触发推理端点，将推理请求推送到 SQS -> Lambda -> Athena (inference_responses)。
b. 步骤 4：生成真实标签数据。这是确定预测正确与否的过程。在本示例用例中，就是确定一次推理请求属于欺诈还是非欺诈。在该解决方案中，真实标签模拟会随机翻转 actual 字段，将其设为欺诈或非欺诈，从而在模型性能中注入 15% 的不准确率。这会引发模型漂移。在真实场景中，欺诈团队会基于自动批准的交易、客户提出异议的退单，或银行确认的欺诈/非欺诈案例进行调查并确认标签，从而得出实际的欺诈/非欺诈判定。
注意：notebook 3 中的步骤 2、3 和 4（生成漂移数据、发送预测、应用真实标签）不是计划任务。它们仅用于开发/测试。在生产环境中，你应当用自己的业务流程替换这些步骤：应用调用端点进行推理（步骤 2～3），以及欺诈调查数据源向 ground_truth_updates 写入数据（步骤 4）。要端到端试用此解决方案，请通过 notebook 单元格或仓库中提供的 CLI 脚本触发这三个步骤。
执行步骤 2 和步骤 3 后，存在数据漂移的推理请求已经写入 inference_responses。步骤 4 会将记录写入 ground_truth_updates 表。系统会选取 ground_truth = NULL 的记录，并在 ground_truth_updates 表中创建包含实际标签的新记录。这样，在执行计算时，我们就可以观察到模型漂移。
你可以随时通过自己选择的查询编辑器验证这些记录：
图 3：显示已生成记录的查询编辑器
图 4：inference_responses 表中包含真实标签更新的记录，以及 ground_truth_updates 表
inference_responses 表中 ground_truth=NULL 的记录，对应尚未应用真实标签的条目。
inference_id，将 inference_responses 表中捕获的预测和推理请求与 ground_truth_updates 进行连接。inference_responses 表会捕获每一次预测及其特征、置信度分数和时间戳。ground_truth_updates 表保存异步确认的标签，这些标签通过 notebook 中的步骤 4 合并回推理记录。现在我们已经有了可用于计算数据漂移和模型漂移的数据，接下来可以为这两类计算确定基线数据集和当前数据集：
如果训练数据中 transaction_amount 的均值为 $50，但近期预测显示均值为 $500，KS 检验就会将其标记为分布偏移。
漂移 Lambda 环境变量：
DATA_DRIFT_LOOKBACK_DAYS: 1 # Query last 1 days of inferences
DATA_DRIFT_THRESHOLD: 0.2 # Alert if ≥20% features drifted
Lambda 查询过去 30 天内带有真实标签的预测，
Lambda 查询过去 30 天内带有真实标签的预测，并计算当前 ROC-AUC。如果基线为 0.92，而当前值为 0.85，则 ROC-AUC 下降量为 0.07（超过 0.05 阈值）→ 发出警报！
0.05 阈值）→ 发出警报！
漂移 Lambda 环境变量：
MODEL_DRIFT_LOOKBACK_DAYS：1——在 deploy_lambda_container.sh 中设置为 1 天，因为 Lambda 按每日计划运行。请根据业务流程中真实标签到达的速度调整此值。config.yaml 的默认值为 30 天（适用于由 notebook 驱动的流程；在该流程中，由于真实标签往往会延迟到达，因此更长的窗口更合适）。
注意：如果你打算使用更短的窗口进行漂移计算，请按照“配置更短的漂移窗口（以分钟而非天为单位）”中详述的步骤操作。
monitoring_responses 表存储漂移计算的输出，包括计算该次运行时所针对的 ModelPackage ARN 和 Iceberg 快照 ID，因此可以按模型版本对趋势进行切片分析。
每个已注册模型都带有一个冻结的 baseline.json 构件，其中记录了模型在 evaluation_data 上获得的指标、该精确数据切片的 Iceberg 快照 ID，以及生成该构件的代码提交 SHA。漂移 Lambda 在每次运行时都会解引用这些指针，因此监控系统始终将生产环境数据与已部署模型所源自的数据和代码的精确版本进行比较，确保永远不会使用过时或错误版本的参考数据。后续的深入解析部分将详细介绍这一沿袭机制。
baseline.json。每次调用都会运行两项相互独立的检查，且各自使用自己的冻结基线。对于数据漂移，冻结的 training_data 切片（通过 baseline.json 中的 training_snapshot_id 固定）是模型训练时所使用的参考分布。滚动窗口内近期的 inference_responses.input_features 则是当前分布。Evidently 的 DataDriftPreset 会比较二者，并自动为每一列选择一种统计检验。对于较小的样本，它使用 Kolmogorov-Smirnov 或卡方检验（p 值）；对于 n ≥ 1000 的样本，则使用 Wasserstein 或 Jensen-Shannon 距离。对于模型漂移，冻结的 evaluation_data 切片（通过 evaluation_snapshot_id 固定）会提供模型在训练时进行评分所使用的基线 (target, prediction) 数据对。将当前推理行与 ground_truth_updates 连接后，通过 Evidently 的 ClassificationPreset 与该基线进行比较，跟踪 ROC-AUC、精确率、召回率和 F1 的下降情况。每个模型版本的两类基线都是不可变的，因此之后即使重新填充源表，也无法追溯性地改变历史漂移比较。由于 Evidently 会输出原始分数，而漂移方向取决于所选检验（p 值：越低表示漂移越严重；距离：越高表示漂移越严重），该解决方案还会计算一个标准化的配套字段 drift_magnitude，从而可以不受检验方法影响地比较特征并进行排序。有关这些指标的更深入说明，请参阅漂移相关内容。注意：系统还会创建另外两个表，但目前并未使用。ground_truth 表保存已确认的标签（欺诈/非欺诈），目前作为占位表保留；当模型已经重新训练，并且你希望向基线添加额外数据时，可以使用该表更新基线数据。drifted_data 表也是作为占位表创建的，用于在需要时保存发生漂移的数据集。
漂移日志记录：漂移监控 Lambda 函数使用 Evidently 生成交互式图表，并将其记录到 SageMaker AI MLflow App。你也可以选择仅使用 Amazon Quick 完成所有分析。该解决方案同时支持带 Evidently 的 MLflow 和 Amazon Quick，以满足数据科学家和治理人员这两类角色的需求。
监控自动化：漂移监控 Lambda 函数会检查漂移阈值，并在超过阈值时触发警报。
10–11. 漂移监控 Lambda 函数还会将计算结果推送到 Amazon SQS，Lambda 写入器读取这些结果，并将输出写入 monitoring_responses 表。由于该解决方案使用基于 Apache Iceberg 的 Athena 表，因此更新符合 ACID 事务规范。
4_governance_dashboard.ipynb）monitoring_responses 表。“模型漂移趋势”（11 个可视化图表）展示按模型版本和训练快照切片的 ROC-AUC 下降、分类指标和运行次数。“数据漂移趋势”（10 个可视化图表）展示 drifted_columns_share 随时间的变化、检测到漂移的判定比例，以及它与推理量的相关性。“特征漂移趋势”（11 个可视化图表）根据 drift_magnitude 对特征进行排序（与检验方法无关的“超过阈值倍数”——1.0 表示达到阈值，≥3.0 表示严重），并提供“特征 × 时间”和“特征 × 模型版本”的热力图，以及重复出现问题的特征图表。另外两个可视化图表按检验族拆分原始 drift_score（一个展示 p 值检验，另一个展示距离检验），使读者可以在各自的尺度上审查底层统计量；同时通过作用域限定在工作表内的 drift_method 筛选器组，确保坐标轴所表达的含义准确无误。严重程度的颜色编码使用根据 Athena 视图中的 drift_magnitude 计算出的分类区间（低：<1.0 / 中等：≥1.0 / 显著：≥3.0），因此，无论底层由哪种检验生成，红色单元格所表示的含义都相同。每个工作表末尾都有一个原始源数据表，便于查阅。以下部分将介绍如何使用自然语言查询扩展这些仪表板或构建自己的仪表板。以下部分将更详细地分解推理监控和元监控组件。
本节将更详细地介绍推理监控设置。
配置文件（config.yaml）提供了默认值，解决方案可以使用这些默认值端到端运行。
MLflow 和 Athena 日志记录。监控输出与训练指标一同存放在 SageMaker AI MLflow App 中。此外，指标还会写入 Amazon SQS，由其持久化到 Athena 中以供治理使用：
指标：drifted_columns_count、drifted_columns_share、每个特征的 drift_score_*（原始检验统计量，其方向取决于 Evidently 选择的检验）、每个特征的 drift_magnitude_*（与检验方法无关的“超过阈值倍数”；值越高表示漂移越严重，用于排序和阈值判断）、current_roc_auc、roc_auc_degradation_pct。monitoring_responses.per_feature_drift_scores JSON 列按特征存储 {score, magnitude, method, threshold}，以便下游仪表板选择任一种视图。
构件：交互式 Evidently HTML 漂移报告、分类报告和 JSON 摘要。
标志：用于自动决策的 data_drift_detected 和 model_drift_detected 布尔值。
如果保持默认设置，Evidently 会根据每列的类型和样本量自动选择漂移检验，因此，同一次运行中，monitoring_responses.per_feature_drift_scores 里的原始 drift_score 在不同特征上可能具有相反的含义：使用 KS 检验的特征得分为 0.001 时，表示发生了严重漂移（p 值：越低表示漂移越严重）；而使用 Wasserstein 检验的特征得分为 0.001 时，则表示完全没有发生漂移（距离：越高表示漂移越严重）。更糟糕的是，对于 p 值检验，drift_magnitude 的计算方式为 threshold / p_value，因此没有上限——每日 Lambda 拉取的样本量为 5,000–10,000 时，KS 检验会过于敏感，微不足道的差异也会产生接近于零的 p 值，并导致幅度值被夸大。
因此，该解决方案为每一列固定使用一种有界的距离指标：对于数值特征和分类特征，都使用 Jensen-Shannon 距离（取值范围为 [0, 1]，值越高表示漂移越严重），当其超过 DRIFT_THRESHOLD = 0.1 时标记为已漂移。该设置通过 evidently_reports.py 中的 DataDriftPreset(num_method=…, cat_method=…, num_threshold=…, cat_threshold=…) 完成。Jensen-Shannon 为每个特征提供相同的 0 到 1 分数，用于表示“当天数据与训练数据的差异程度”，因此你可以在同一个真实一致的尺度上对特征进行相互排序，而不必比较含义不同的数字。这样，检验选择是确定性的，不再依赖样本量；漂移方向保持统一；标准化的配套字段 drift_magnitude = score / threshold 也被限制在 [0, 10] 范围内：1.0 表示“达到阈值”，> 1.0 表示“已漂移”，且数值越高始终表示漂移越严重。
Amazon Quick 聚合、Amazon Simple Notification Service（Amazon SNS）警报文本和 MLflow 排名均使用 magnitude。原始分数和检验方法会保留下来，以供审计。
图 5：记录在 SageMaker AI MLflow App 中的交互式 Evidently 数据漂移报告和分类报告
警报和仪表板。当漂移超过阈值时，Amazon SNS 会向你发送警报，其中包含指向 MLflow 内交互式 Evidently 报告的直接链接。
Amazon Quick 从承载漂移计算的 Athena 表中读取数据。通过运行 4_governance_dashboard.ipynb 笔记本（或其后台脚本）可以创建 Quick 分析，包含 3 个工作表和 32 个预构建可视化（模型漂移趋势 11 个、数据漂移趋势 10 个、特征漂移趋势 11 个）。Quick 还提供计算字段和自然语言查询支持，用于构建其他可视化。预构建的集合只是起点，不是上限。如果你的账户中尚未设置 Amazon Quick，请按照 README 说明启用 Quick，然后再继续进行笔记本 4。
使用 Amazon Quick，可以通过拖拽甚至自然语言来构建可视化。如图 6 所示，可以通过以下类似的提示词来探索创建仪表板：
"Show me a time series chart of the top 5 drifted features over the last 30 days with drift_magnitude on the y-axis, grouped by day. Include a horizontal reference line at magnitude = 1.0 (the drift threshold). Add a second chart below showing daily prediction volume. Highlight days where more than 3 features had magnitude > 1.0 in red."
"Create a sankey diagram showing how prediction bucket distributions shifted from the baseline week to last week. Show flows from training data buckets (very_low to very_high fraud probability) to current production buckets. Highlight any bucket that changed by more than 10 percentage points in red."
图 6：使用自然语言生成 Amazon Quick 可视化
图 7：按特征划分的漂移严重程度分布。每条水平条显示有多少次监控运行将该特征分类为低漂移（< 1.0）、中等漂移（≥ 1.0）或显著漂移（≥ 3.0）——这些带段由 drift_magnitude 计算，而非原始 drift_score。
图 8：drifted_columns_share 在连续 8 天（7 月 10-17 日）保持 100%，然后在 7 月 18 日降至约 90%。每次漂移运行都标记了几乎所有特征，远超 20% 的告警阈值。关键信号是持续性而非高度：这是持续的全体特征漂移，而非一天的尖峰。
图 9：模型漂移——准确率线（绿色，约 0.85）在 9 天内保持平直；精准率、召回率和 F1 分数都重叠在 0.0，因为漂移的输入已将所有预测驱动到多数类（非欺诈），所以结构上 TP = FP = 0。这正是 config.yaml 中的漂移告警以 roc_auc_degradation 而非准确率作为触发条件的原因。右侧，当前 ROC-AUC（约 0.48，浅蓝）在整个 9 天窗口内保持平直，并比冻结基线（约 0.98，深蓝）低约 50 个百分点，接近随机。
图 10：num_transactions_24h 以巨大优势领先，约为漂移阈值的 11 倍（虚线红线为 magnitude = 1.0），其次是 customer_gender、distance_from_home_km 和 velocity_score，分别约为 5 倍、4 倍和 3 倍。前 15 个特征中的每一个都高于漂移线。
关于演示截图的说明。在这些截图中，最漂移的特征恰好也是高 SHAP 重要性特征。
图 11：柱状图显示 account_age_days（0.37）和 num_transactions_24h（0.29）是模型按平均绝对 SHAP 值计的主导特征，而蜂群图（右）则揭示了方向：account_age_days 上的红-左/蓝-右表示较老的账户将预测推离欺诈（反向关系，符合领域直觉），而 num_transactions_24h 则显示非单调模式，两个极值都混有颜色。
这种对齐是演示漂移配置的属性（config.yaml 刻意漂移了模型依赖的 PCA 分量），而非 Quick 发现的内容，因为它只是可视化 Evidently 的统计距离，无法访问模型或 SHAP。在真实的生产漂移中，magnitude 和 SHAP 重要性是独立的。推荐的做法是在优先排序漂移特征时交叉参考两者。
本解决方案在相同的持久化 Amazon Athena 表之上提供两个独立的监控后端：MLflow 和 Amazon Quick。它们是对等消费者而非堆栈，因此使用其中一个不需要另一个，禁用一个也不会影响另一个。每次漂移运行都将其判决、每个特征的分数和血缘引用（模型包 ARN、训练和评估快照 ID、监控运行 ID）直接写入 monitoring_responses 和 inference_responses Iceberg 表。
Amazon Quick 从 Athena 读取数据（如果启用了 AWS Lake Formation 则通过它），无论 MLflow 是否运行。
对于持续到达流量的实时或无服务器推理的在线端点监控，选择 Amazon Quick。Athena 支持的仪表板按计划刷新，可按模型版本、端点、训练快照或特征进行切片，并提供适合模型风险委员会和执行审查的利益相关者视图。对于具有定时转换、离线评分或离散作业的批量推理监控，根据团队偏好选择 MLflow 或 Quick：
MLflow 提供每次运行的实验跟踪、跨运行的超参数和指标比较，并将完整的交互式 Evidently HTML 报告作为工件托管，这对于每个批次都是独立实验的离散作业来说是自然的选择。
如果你想要跨在线和批量工作负载的统一仪表板界面，Amazon Quick 在这里仍然有效。两个后端能很好地回答不同的问题。
MLflow 回答"这次运行与上次之间发生了什么变化，我能否打开 Evidently HTML 逐列检查？"
而 Quick 回答"过去 90 天在所有模型版本和端点中的漂移看起来如何，我能否与合规部门共享该仪表板？"
由于两者都使用相同的 monitoring_responses 表，选择其中一个不会排除后来添加另一个的可能性，两者都不是漂移检测管道本身的先决条件。每日漂移 Lambda 无条件地将其结果持久化到 Athena。
所有计算在空闲时都可扩展到零。无服务器端点仅按实际调用次数计费（无基线实例小时数），Lambda 按需执行，Athena 查询仅在触发时运行，Amazon EventBridge 在定时运行之间不产生成本。
成本优化：Iceberg 表分区将 Athena 扫描成本降低 10-100 倍，因为你可以编写在分区列上过滤的查询，让 Athena 跳过分区。Lambda 批处理（100 条记录/调用）将执行费用最小化，无服务器端点自动扩展消除过度配置浪费。