1. Google Cloud机器学习平台全景

在 Google Cloud 上建设机器学习平台，最容易踩的坑不是“不会用某个 API”，而是把训练、部署、监控当成三个彼此独立的工具来拼装。真实的生产系统是一条从数据到反馈的闭环链路：数据进入特征层，特征被训练作业消费，模型产物被注册与版本化，推理服务对外提供预测，线上流量与标签又回流成新的训练数据。理解这条链路上每个组件的职责边界，比记住服务名称更重要。

一、平台的四层结构

把 Google Cloud 的 ML 相关服务按职责划分为四层，可以快速定位“某个问题该找谁”。

• 数据与特征层：Cloud Storage 存放原始数据与模型产物，BigQuery 承担大规模分析与特征计算，Vertex AI Feature Store 负责特征的在线/离线一致供给。这一层的核心约束是“训练与推理使用同一份特征定义”。
• 训练与实验层：Vertex AI Training 提供托管训练作业与自定义容器，Vertex AI Experiments 记录超参与指标，Vertex AI Pipelines（基于 Kubeflow Pipelines）把数据预处理、训练、评估串成可复现的流水线。
• 模型与部署层：Vertex AI Model Registry 管理模型版本与血缘，Vertex AI Endpoint 提供在线推理，Batch Prediction 处理离线批量打分。模型从注册到上线，本质是“把某个版本绑定到某个服务端点”。
• 监控与治理层：Vertex AI Model Monitoring 检测训练-服务偏差（training-serving skew）与数据漂移，Cloud Logging/Monitoring 采集延迟、错误率与资源指标，IAM 与 VPC-SC 控制访问边界。

需要特别区分的是服务边界：BigQuery ML 适合在数据仓库内快速做 SQL 驱动的建模，适合探索与轻量场景；Vertex AI 适合需要自定义代码、自定义容器、复杂流水线和严格版本管理的生产场景。二者不是替代关系，而是“快速验证”与“工程化落地”的分工。

二、生产部署的整体生命周期

把上面的四层串起来，一个模型从想法到稳定服务，通常经历六个阶段。这里以一个“电商复购预测”场景为例说明，参数为教学示例，非实测结果。

1. 问题定义与数据准备：明确预测目标是“用户未来 30 天是否复购”，正样本比例约 8%。原始订单数据落在 BigQuery 表 project.dataset.orders，导出到 gs://bucket/features/ 供训练读取。
2. 特征工程与一致性校验：在 Feature Store 中定义 user_purchase_count_30d、days_since_last_order 等特征。关键动作是同时生成离线训练集和在线特征视图，确保两者计算逻辑一致——这是避免 training-serving skew 的根本手段。
3. 训练与评估：使用 Vertex AI Training 提交自定义容器作业，机器规格示例为 n1-standard-8，训练 200 轮。评估指标要求 AUC ≥ 0.78、Recall@10% ≥ 0.35，未达标则回到特征或超参调整。
4. 模型注册与审批：达标模型写入 Model Registry，打上 staging 标签，记录训练数据版本、代码 commit 与评估指标，形成可追溯血缘。
5. 部署与灰度：将 staging 版本部署到 Endpoint，先分配 10% 流量做金丝雀发布，观察 24 小时延迟 P95 与错误率。示例阈值：P95 < 120ms、错误率 < 0.5%。
6. 监控与迭代：Model Monitoring 持续比对线上特征分布与训练分布，当 days_since_last_order 的分布偏移超过阈值时触发告警，并将新标注数据回流至 BigQuery，进入下一轮训练。

三、服务边界速查