假如你要把一家面馆开成一百家连锁店，最让你头疼的是什么？不是没客人，而是“标准”——每家分店厨师手抖一下，酱油多一勺，这家就咸了；那边面条多煮三十秒，这碗就软了。于是聪明的老板会建一座中央厨房：统一采购、统一切配、统一调料包、统一出餐流程，分店只负责加热和上桌。机器学习团队面临的麻烦一模一样：数据散落在各部门的数据库里，模型在同事的笔记本上训练完就“失传”，上线三个月后数据悄悄变了，模型早就悄悄“馊了”，却没人发现。谷歌云的 Vertex AI，就是给 AI 团队准备的“中央厨房”。它把数据准备、特征仓库、模型训练、超参调优、模型注册、部署上线、监控告警、管道编排，全部收进一个平台、一套权限、一套 API。这篇文章，我们就跟着面馆开连锁的故事，把这座“一站式 MLOps 中央厨房”的每个操作间都转一遍，看看它到底怎么搭、每一站能帮你省下什么。

岗位关联

掌握 Vertex AI 的平台架构，等于拿到企业级 MLOps 的通用图纸——无论将来用哪朵云，你都能看懂平台该在哪些环节帮你省力，以及自己该在哪些环节守住数据与监控的底线。

目录
  1. 可视化演示
  2. 平台全景定位：一座中央厨房管百家分店
  3. 数据准备环节：先切配再入冷库
  4. 训练调优环节：大厨掌勺与自动试味
  5. 模型注册管理：留样柜里的每道菜
  6. 部署上线环节：出餐口与试吃台
  7. 监控运维保障：质检员的每日抽查
  8. 管道编排总控：总调度台的自动化菜单
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

展示Vertex AI的MLOps流水线DAG编排、自定义训练与AutoML两种模式及GPU/TPU算力支持，以及与AWS SageMaker和Azure ML的平台对比。

本节配有交互动效（进入视口后自动加载，约 3KB）。

'+captions.pipeline+'

平台全景定位：一座中央厨房管百家分店

老王的连锁面馆开到第 12 家时，后厨彻底失控了：不同店的汤底咸淡不一，有的店买不到同款面条，有的店连煮面计时器都没有。他咬牙盖了一座中央厨房，从此每家分店不用自己买菜、自己熬汤，只要按流程加热、按手册出餐。Vertex AI 对谷歌云用户的意义，就是这座中央厨房。

Vertex AI 是谷歌云推出的统一机器学习平台，目标是把 AI 开发从“各路工具拼凑”变成“一个平台走完”。它覆盖从数据准备、特征工程、模型训练、超参调优、模型注册、部署上线到监控运维的完整生命周期，也就是常说的“一站式 MLOps”。你在同一个控制台里操作，IAM 权限、日志审计、账单也都是同一套体系。

从架构看，Vertex AI 分三层：底层是 GCP 的计算与存储，包括 CPU、GPU、TPU 和 Cloud Storage、BigQuery；中间层是平台服务，如 Training、Prediction、Pipelines；最上层是统一控制台与 API。它与 GCP 生态深度集成——数据在 BigQuery 里，可以直接被 Vertex AI 的数据集和管道引用，不需要来回搬文件。托管服务自带可用性承诺，基础设施由谷歌运维。

中央厨房的价值不在某一台灶有多好，而在于所有环节被统一管理。Vertex AI 的 IAM、账单、审计就是这套统一标准——谁有权限进货、谁改了菜谱、哪一步出了问题，全部有据可查。

可用性=T运行−T故障T运行×100%\displaystyle \text{可用性} = \frac{T_{\text{运行}} - T_{\text{故障}}}{T_{\text{运行}}} \times 100\%
可用性衡量“一年里模型服务有多长时间是醒着的”。99.9% 意味着一年累计故障不超过约 8.76 小时，这也是托管的中央厨房和自建灶台的本质区别。
  1. 运行总时长统计周期内的总时长，比如一个月 720 小时或一年 8760 小时。
    T运行T_{\text{运行}}
  2. 故障时长服务不可用的累计时长，通常不含计划内维护。
    T故障T_{\text{故障}}
  3. 正常服务时间总时长减去故障时长，得到真正对外提供服务的时间。
    T运行−T故障T_{\text{运行}} - T_{\text{故障}}
  4. 计算占比正常时长除以总时长，得到“整个周期里可用时间的比例”。
    T运行−T故障T运行\frac{T_{\text{运行}} - T_{\text{故障}}}{T_{\text{运行}}}
  5. 换算百分比乘以 100% 得到可用性百分比，99.9% 的 SLA 意味着每个月最多允许故障约 43 分钟。
    ×100%\times 100\%

数据准备环节：先切配再入冷库

中央厨房的第一课是“切配前置”。葱姜蒜在总店切好、分装、贴标签、进冷库，分店临时取用，不需要自己洗菜。机器学习项目里最耗时也最容易出错的，同样是上游的数据。

Vertex AI 的数据侧有三件套。Dataset 负责数据集管理，支持图片、文本、表格、视频类型，可做版本化和训练集/验证集/测试集的自动拆分；Data Labeling Service 提供人工与半自动标注，相当于请专业切配师傅把食材切成统一规格；Feature Store 是特征仓库，统一存放与更新特征，像冷库里的标准半成品，训练和在线推理拿的是同一批特征。

数据版本与血缘由 Vertex AI Metadata 记录——哪次训练用了哪一版数据、哪一版特征，一目了然。与 BigQuery 深度集成后，数仓中的表可以直接变成训练集，省去导出搬运。特征仓库区分在线与离线通道，但底层同源，避免“训练时用 A 特征、上线时特征缺字段”的灾难。

中央厨房宁可花一小时切配，也不让大厨现场切菜——ML 项目花在数据上的时间往往超过模型本身。数据这一站做扎实，后面训练调优才有好底子。

x标准化=x−μσ\displaystyle x_{\text{标准化}} = \frac{x - \mu}{\sigma}
标准化就是“把不同尺寸的食材切成统一规格”。年龄和收入数值差几百倍，不统一量纲，训练时“收入”就会把“年龄”的作用压没。
  1. 原始特征值某一条样本在这个特征上的取值，比如用户年龄 35 岁。
    xx
  2. 特征均值整个训练集该特征的平均值，代表“大多数食材的常规分量”。
    μ\mu
  3. 特征标准差数据波动的剧烈程度，标准差大说明数值散得开。
    σ\sigma
  4. 中心化用原始值减去均值，把分布中心挪到 0，让不同量纲的特征可比。
    x−μx - \mu
  5. 归一化缩放再除以标准差，把不同尺度的特征压到同一量级，避免数值大的特征压过数值小的特征。
    x−μσ\frac{x - \mu}{\sigma}

训练调优环节：大厨掌勺与自动试味

食材备齐，大厨上场。连锁店有两种大厨：一种是“速成大厨”，你把食材倒给他，他自己摸索出一套菜谱；另一种是“老法师”，你把自己几十年的独门配方带过来，锅碗瓢盆全自备。

Vertex AI 的训练同样两条路。AutoML 适合没时间写模型的团队——上传数据集，平台自动选模型结构、做特征工程并给出评估，图像、文本、表格、视频都能覆盖；自定义训练（Custom Training）适合想掌控一切的场景——你可以带任意框架（PyTorch、TensorFlow、JAX）甚至自定义容器，谷歌负责调度算力、拉起训练集群、展示日志。

大厨试菜要调火候，模型训练要调超参数。超参调优（Hyperparameter Tuning）由 Vertex AI 内置的调优组件自动完成，它像试菜员一样试几组组合就推断出更好用的配方，而不是把每个可能性都跑一遍。实验跟踪（Experiments）则把每次训练的超参、指标、产物都记录下来，形成一本“试菜记录本”。

大厨反复试炒、记录火候，最终把最佳菜谱写进手册。训练完成、指标合格的模型，就该进入下一站——留样与注册。

组合数=∏i=1mki\displaystyle \text{组合数} = \prod_{i=1}^{m} k_i
超参组合是乘法爆炸：3 个参数各给 5 个候选，就是 125 次完整训练。所以别手工人肉试参，交给自动调优更划算。
  1. 超参数个数需要调的超参数数量，如学习率、批大小、网络层数。
    mm
  2. 候选个数第 i 个超参数准备尝试几个值，比如学习率试 3 个值、批大小试 2 个值。
    kik_i
  3. 全部相乘连乘符号把所有候选个数乘起来，得到全部组合总数。
    ∏i=1mki\prod_{i=1}^{m} k_i
  4. 组合爆炸展开后等于各个候选数相乘，3 个参数各 5 个候选就是 125 次训练，因此需要聪明的自动搜索而非穷举。
    k1×k2×⋯×kmk_1 \times k_2 \times \cdots \times k_m

模型注册管理：留样柜里的每道菜

中央厨房有个留样柜：每道菜出锅必须留一份，贴上日期、厨师、配方版本和品检合格证。哪天某个分店被投诉“味道不对”，开柜一查就能定位是哪批原料、哪个版本出了问题。

Vertex AI Model Registry 就是模型界的留样柜。训练好的模型上传后获得唯一版本号，可以附带评估指标、说明文字、部署区域；要上线哪一版，直接从柜子里取，不用再去翻“上次存在谁的笔记本里”。

注册表支持多版本并存、模型别名（如 current、staging、production）和审批流程——只有通过审批的版本才能被标记为 production。模型与数据集、训练作业、实验之间的血缘关系由 Metadata 记录，可以做从线上模型一路回溯到训练数据和代码的完整追查。

没有留样柜的餐厅出事故只能认栽，没有模型注册表的企业出线上事故只能靠猜。版本、指标、血缘齐备，模型才谈得上“可管理”。

F1=2×Precision×RecallPrecision+Recall\displaystyle F1 = \frac{2 \times \text{Precision} \times \text{Recall}}{\text{Precision} + \text{Recall}}
F1 是“不偏科”的综合分。只有精确率和召回率都高，F1 才高。注册表里给每个版本存档 F1，选菜谱时先比对留样。
  1. 精确率预测为正例的样本里真正对的占比，类比“捞出来的到底是不是真金”。
    Precision=TPTP+FP\text{Precision} = \frac{TP}{TP + FP}
  2. 召回率真正的正例里被找出来的占比，类比“该捞的金子捞全没有”。
    Recall=TPTP+FN\text{Recall} = \frac{TP}{TP + FN}
  3. 分子部分精确率与召回率相乘再乘 2，是调和平均的分子。
    2×Precision×Recall2 \times \text{Precision} \times \text{Recall}
  4. 分母部分两者相加，任一指标很低时 F1 都会明显下降，防止“偏科”。
    Precision+Recall\text{Precision} + \text{Recall}
  5. F1 取值结果落在 0 到 1 之间，越接近 1 代表模型综合表现越好，注册表里按此横向比较各版本。
    F1∈[0,1]F1 \in [0, 1]

部署上线环节：出餐口与试吃台

留样合格的菜要送往分店出餐口。刚开业不敢全量卖——万一新配方顾客不买账呢？先做 5% 试吃，观察反馈，再逐步放量。

Vertex AI 的部署分两种。在线端点（Endpoint）提供毫秒级实时预测，适合推荐、风控这类“点单即出餐”的场景；批量预测（Batch Prediction）适合离线处理海量数据，比如每天晚上把第二天的全部订单统一跑一遍，第二天直接看结果。

端点背后是托管预测实例，支持自动扩缩容（配置最小/最大副本数）、GPU 加速、模型预热。流量分配（Traffic Split）实现灰度发布：新版本模型先接 5% 流量，指标正常后一键切到 100%，异常时立刻回滚。这些操作都在控制台或 API 里完成，不需要自己养运维团队。

自动扩缩容就像那个聪明的蒸笼：人多自动加屉，人少自动撤屉，按量付费不浪费。但端上菜只是开始——菜端上桌后，还要有人负责质检。

实例数=⌈QPS×t推理并发⌉\displaystyle \text{实例数} = \left\lceil \frac{\text{QPS} \times t_{\text{推理}}}{\text{并发}} \right\rceil
出餐口的蒸笼放几屉，看高峰下单速度、每屉蒸多久、一屉能放几个。算出来向上取整，再留点余量。
  1. 每秒请求数线上平均每秒到达的预测请求数量，单位 QPS。
    QPS\text{QPS}
  2. 单次推理耗时模型处理一个请求需要的耗时，比如 50 毫秒。
    t推理t_{\text{推理}}
  3. 每秒处理量请求数乘以单次耗时，得到一秒钟内所有请求需要的总计算时间。
    QPS×t推理\text{QPS} \times t_{\text{推理}}
  4. 并发折算除以单实例并发上限，得到至少需要几个实例。
    QPS×t推理并发\frac{\text{QPS} \times t_{\text{推理}}}{\text{并发}}
  5. 向上取整实例数必须是整数且只多不少，防止流量尖峰打爆服务。
    ⌈⋅⌉\left\lceil \cdot \right\rceil

监控运维保障：质检员的每日抽查

连锁餐厅最怕“供货商换了，味道悄悄变了”。质检员每天抽查各分店出餐的咸淡、色泽，和标准菜谱比对，偏差过大立刻上报。

模型上线后也要天天“试吃”。Vertex AI Model Monitoring 持续检测线上预测输入分布与训练分布的偏差（drift）、训练与服务特征不一致（training-serving skew）、以及训练时没见过的数据类别。这些指标在模型的监控页可视化呈现，超过阈值触发告警。

分布偏移的量化常用 PSI（群体稳定性指标）。一般经验：PSI 小于 0.1 表示稳定，0.1 到 0.25 需要关注，大于 0.25 说明分布已明显变化，建议告警并考虑重训。告警可对接 Cloud Monitoring、邮件或 webhook；运营成熟后，监控结果直接触发管道自动重训，形成“监控—重训—再部署”的闭环。

质检员不直接炒菜，但他们的存在让“偶尔味道不对”变成“系统会自动发现”。监控发现问题之后，怎么让重训、评估、上线自动跑起来？这就轮到总调度台出场。

PSI=∑i=1n(实际占比i−期望占比i)×ln⁡实际占比i期望占比i\displaystyle \text{PSI} = \sum_{i=1}^{n} \left( \text{实际占比}_i - \text{期望占比}_i \right) \times \ln \frac{\text{实际占比}_i}{\text{期望占比}_i}
PSI 像“质检偏差分”：把预测分数分成 10 个桶，逐桶比较线上与训练时的占比差异，差异越大分数越高。
  1. 分箱数量把预测分数或特征值切成 n 个桶，比如 10 个区间。
    nn
  2. 期望占比训练时每个桶里样本的比例，相当于“标准菜谱的咸淡分布”。
    期望占比i\text{期望占比}_i
  3. 实际占比线上近期每个桶的比例，相当于“抽查店铺的实际咸淡”。
    实际占比i\text{实际占比}_i
  4. 偏差与方向两个占比的差乘以对数比值，同时度量偏差的大小和方向。
    (实际占比i−期望占比i)×ln⁡实际占比i期望占比i\left( \text{实际占比}_i - \text{期望占比}_i \right) \times \ln \frac{\text{实际占比}_i}{\text{期望占比}_i}
  5. 累加所有桶把每个桶的偏差分相加，PSI 小于 0.1 稳定、0.1 到 0.25 关注、大于 0.25 建议告警重训。
    ∑i=1n\sum_{i=1}^{n}

管道编排总控：总调度台的自动化菜单

中央厨房真正的杀手锏，是那张总排程表：夜里 11 点自动进货，凌晨 3 点切配，6 点分拣装车，全程不用人盯着。谁晚点了、谁缺料了，系统自动提醒。

Vertex AI Pipelines 就是总排程表。它以组件（component）为单位，把数据校验、特征工程、训练、评估、注册、部署串成有向无环图（DAG），支持一键重跑，还能在可视化页面看到每个节点每一步的状态和日志。

组件基于 KFP（Kubeflow Pipelines）标准编写，可复用、可版本化；触发方式支持手动、定时（Cloud Scheduler）、事件驱动（如新数据入库自动触发重训）。与 CI/CD 工具（Cloud Build、GitHub Actions）打通后，代码提交即自动走完“构建—训练—部署”全流程。每次运行都有完整审计记录，满足合规要求。

有了总调度台，中央厨房的菜才算真正“一站式”——从进货、切配、掌勺、留样、出餐到质检，全生命周期在掌控之中。这，就是 Vertex AI 想交付的 MLOps。

自动化率=自动执行步骤数n×100%\displaystyle \text{自动化率} = \frac{\text{自动执行步骤数}}{n} \times 100\%
自动化率就是“整条流水线里不需要人盯的比例”。MLOps 的目标，就是把它推到接近 100%。
  1. 总步骤数一条完整流水线从数据校验到部署的环节总数。
    nn
  2. 自动执行步骤数无需人工干预的环节数量，比如自动取数、自动评测、自动注册。
    自动执行步骤数\text{自动执行步骤数}
  3. 换算比例自动执行步骤占总步骤的比例，再乘以 100% 得到覆盖率。
    自动执行步骤数n×100%\frac{\text{自动执行步骤数}}{n} \times 100\%
  4. 逼近 100%一次性把流水线搭好，之后每次自动跑，这就是 MLOps 的复利效应。
    ≈100%\approx 100\%

AI 应用场景

金融风控：深夜自动备菜的中央厨房

阶段：管道编排 + 模型监控（全生命周期闭环）

解决的问题：传统风控团队每季度手工重训一次，模型上线后没人盯分布漂移，监管部门要审计时拿不出完整的“数据—训练—上线”链条。Vertex AI 让“定时重训—监控—再部署”变成自动驾驶。

具体案例：某消费金融公司用 Vertex AI Pipelines 编排“取数→特征→训练→注册→部署→监控”的周更流水线，Cloud Scheduler 每周日凌晨自动触发；当模型监控发现欺诈模式漂移、PSI 超过阈值时，自动拉起重训并灰度发布。平均从发现问题到新模型上线，从 3 周缩短到 1 天。

电商推荐：统一酱料包避免“串味”

阶段：数据准备 + 特征仓库 + 在线端点

解决的问题：推荐模型训练用离线特征、上线用在线特征，两端字段不一致导致效果打折，这是经典的“训练服务偏差”。特征仓库让训练与推理共用同一特征空间，就像所有分店用同一包酱料，味道才统一。

具体案例：某跨境电商用 Feature Store 管理用户实时行为特征（点击、加购、停留时长），训练流水线从离线通道取特征，在线端点从在线通道取同一套特征定义；新特征上线时注册一次、两端同步生效，彻底避免了“训练好好的，上线就崩”的经典事故。

制造业质检：速成大厨今日上岗

阶段：训练（AutoML）+ 批量预测

解决的问题：工厂缺少算法工程师，缺陷样本少且标注贵，从零搭视觉模型不现实。AutoML 和托管标注服务把建模门槛降到“会上传数据”即可。

具体案例：某汽配厂把 2000 张缺陷照片传到 Vertex AI 数据集，用 Data Labeling 服务辅助快速打标，再用 AutoML 图像分类训练瑕疵检测模型；每个夜晚用批量预测跑完当天产线照片，次日清晨输出质检报告，全程不需要自建 GPU 集群。

Python 演示

python124 行
# 简易MLOps流水线模拟：仿照Vertex AI"中央厨房"走完数据→特征→训练→调优→注册→监控import mathimport random  def sigmoid(z):    return 1.0 / (1.0 + math.exp(-z))  def make_features(raw_samples):    """标准化特征：相当于中央厨房的食材预处理，对应Feature Store"""    dim = len(raw_samples[0]) - 1    means = []    stds = []    for i in range(dim):        col = [row[i] for row in raw_samples]        mean = sum(col) / len(col)        std = math.sqrt(sum((v - mean) ** 2 for v in col) / len(col)) or 1.0        means.append(mean)        stds.append(std)    return [[(row[i] - means[i]) / stds[i] for i in range(dim)] for row in raw_samples]  def train_model(w, features, labels, lr, epochs):    """随机梯度下降训练逻辑回归：主厨按菜谱反复试炒"""    dim = len(w)    for _ in range(epochs):        for x, y in zip(features, labels):            pred = sigmoid(sum(w[i] * x[i] for i in range(dim)))            err = pred - y            for i in range(dim):                w[i] -= lr * err * x[i]    return w  def evaluate_model(w, features, labels):    """验证集准确率：相当于试菜打分"""    dim = len(w)    correct = 0.0    for x, y in zip(features, labels):        pred = sigmoid(sum(w[i] * x[i] for i in range(dim)))        if (pred >= 0.5) == (y == 1):            correct += 1.0    return correct / len(features)  def compute_psi(expect_pcts, actual_pcts):    """群体稳定性指标：监控线上分布与训练分布是否偏离"""    psi = 0.0    for exp, act in zip(expect_pcts, actual_pcts):        if act > 0 and exp > 0:            psi += (act - exp) * math.log(act / exp)    return psi  class VertexPipeline:    """仿Vertex AI的一站式工作台：中央厨房总调度台"""     def __init__(self, name):        self.pipeline_name = name        self.dataset_ver = 1        self.feature_map = {}        self.model_map = {}        self.monitor_log = []     def run(self, raw_samples, param_grid):        random.shuffle(raw_samples)        self.raw_samples = raw_samples        self.dataset_ver += 1        feats = make_features(raw_samples)        self.feature_map[self.dataset_ver] = feats         n = len(raw_samples)        cut1 = int(n * 0.8)        cut2 = int(n * 0.9)        labels = [row[-1] for row in raw_samples]        train_feats, train_labels = feats[:cut1], labels[:cut1]        val_feats, val_labels = feats[cut1:cut2], labels[cut1:cut2]         best_acc = 0.0        best_params = None        best_weights = None        dim = len(feats[0])        for lr in param_grid["lr_list"]:            for epochs in param_grid["epochs_list"]:                w = train_model([0.0] * dim, train_feats, train_labels, lr, epochs)                acc = evaluate_model(w, val_feats, val_labels)                if acc > best_acc:                    best_acc = acc                    best_params = (lr, epochs)                    best_weights = w[:]         self.model_map["v%d" % self.dataset_ver] = {            "acc": best_acc,            "params": best_params,            "weights": best_weights,        }         expect_pcts = [0.10] * 10        actual_pcts = [0.05, 0.03, 0.11, 0.09, 0.22, 0.17, 0.16, 0.08, 0.05, 0.04]        psi = compute_psi(expect_pcts, actual_pcts)        self.monitor_log.append(round(psi, 3))        return {            "best_acc": round(best_acc, 3),            "best_params": best_params,            "psi": round(psi, 3),        }  if __name__ == "__main__":    random.seed(42)    samples = []    for _ in range(2000):        x1 = random.gauss(0, 1)        x2 = random.gauss(0, 1)        label = 1 if x1 + x2 + random.gauss(0, 1.5) > 0 else 0        samples.append([x1, x2, label])     pipe = VertexPipeline("customer_churn")    result = pipe.run(samples, {"lr_list": [0.1, 0.3, 0.5], "epochs_list": [5, 10]})    print("最佳验证准确率:", result["best_acc"])    print("最佳超参数:", result["best_params"])    print("线上漂移 PSI:", result["psi"])    print("监控日志:", pipe.monitor_log)
目的：用约 2000 个模拟样本走完一条微型 MLOps 流水线——标准化特征、网格搜索超参、注册最优模型、用 PSI 模拟线上漂移监控，与 Vertex AI 的“中央厨房”各环节一一对应。
  1. feats = make_features(raw_samples)标准化特征，相当于食材统一切配进冷库，避免量纲不同的特征互相干扰。
  2. self.feature_map[self.dataset_ver] = feats特征按数据版本入库，对应 Vertex AI Feature Store 的版本管理。
  3. for lr in param_grid["lr_list"]: for epochs in param_grid["epochs_list"]:双层循环做网格搜索，是超参调优最朴素的“穷举版”。
  4. self.model_map["v%d" % self.dataset_ver] = {...}只把验证集上最优的模型注册进“留样柜”，对应 Model Registry。
  5. psi = compute_psi(expect_pcts, actual_pcts)用 PSI 量化线上分布与训练分布的偏差，对应 Model Monitoring 的漂移检测。
  6. self.monitor_log.append(round(psi, 3))每次监控结果入日志，方便追溯哪一轮出现异常。
  7. if __name__ == "__main__":可执行入口，直接运行就能看到一条完整流水线的输出。

常见误区

误区Vertex AI 就是把谷歌云的几个独立服务塞进同一个网页，换汤不换药，我自己在笔记本上写脚本也能干这些事。

正解真正的统一不是“页面放一起”，而是数据面与元数据的贯通：数据集、特征、实验、模型、端点之间共享血缘和 IAM，管道把各环节串成一条可复现的流水线。就像中央厨房不只是一间大屋子，而是从采购到出餐共享同一套台账和标准。自己拼脚本的团队，产品一多、人一换，流程就乱了。

为何常见：只用过控制台浅层功能时，确实看不到平台内部的数据流与编排能力，容易产生“只是聚合”的错觉。

误区用了 AutoML 我就把数据丢进去，等着出模型就行，数据质量根本不用操心。

正解AutoML 自动的是模型结构选择和训练策略，不是数据。脏数据、标签错、类别不平衡，AutoML 照样给出烂模型——它只是把“食材”做成菜的大厨，不是把烂菜叶变新鲜的魔术师。Vertex AI 提供的数据标注、特征仓库和数据集校验，恰恰是在提醒你重视数据这一环。

为何常见：“自动”两个字会让人误以为连数据准备都自动化了，而实际上数据质量永远是模型效果上限的决定因素。

误区模型上线那一刻最紧张，上线之后我就松口气了，后面基本不用管。

正解上线只是开始。真实世界的特征分布会漂移，用户行为会变，训练时没见过的类别会出现。Vertex AI Model Monitoring 存在的意义就是盯住这些变化，PSI 超过阈值就告警、触发重训。这就像餐厅开张后每天都要质检，而不是开业当天检查一次就再也不看。

为何常见：传统软件开发“上线即结束”的思维惯性，让很多团队忽略了模型是“会过期的东西”。

误区超参调优不就是把学习率 0.1、0.01、0.001 都试一遍，看哪个效果好就用哪个吗？

正解手动网格搜索在参数少时可行，但参数一多，组合数是指数爆炸。Vertex AI 的调优组件用贝叶斯优化等策略，根据历史实验动态选择下一组更可能出好成绩的参数，用更少的训练次数找到好配置。它像试菜员尝两勺就判断还要不要加盐，而不是把整锅汤都煮完再决定。

为何常见：初学者最先学会的就是写几个候选值循环跑，没接触过自动调参工具，容易把“试几次”当成调优本身。

面试题

Q1. Vertex AI 定位类似于餐饮连锁的“中央厨房”，其核心理念是什么？

单选题 · easy

  • A.只负责模型训练一个环节
  • B.统一平台覆盖全生命周期← 正确答案
  • C.仅提供 GPU 算力租赁
  • D.替代开发者编写业务代码

答案：B。Vertex AI 的核心是统一平台，覆盖数据、训练、注册、部署、监控、管道全生命周期，对应中央厨房“一站管全部”的定位。A 只覆盖训练，C 只提供算力，D 把平台和写业务代码搞混了，都属于只见树木不见森林。

Q2. 在 Vertex AI 中，统一存放训练和推理共用特征、避免“训练服务不一致”的组件是？

单选题 · easy

  • A.人工数据标注服务
  • B.模型版本注册中心
  • C.特征仓库统一管理← 正确答案
  • D.端到端管道编排引擎

答案：C。Feature Store（特征仓库）让训练和在线推理共用同源特征，就像所有分店用同一包酱料，味道才统一。Data Labeling 负责标注，Model Registry 管模型版本，Pipelines 做编排，都不解决特征一致性问题。

Q3. 想用自己写的 PyTorch 代码和自定义容器在 Vertex AI 上训练，应该选择？

单选题 · mid

  • A.表格预测 AutoML
  • B.自定义训练作业← 正确答案
  • C.批量预测服务
  • D.模型监控服务

答案：B。自定义训练（Custom Training）允许自带任意框架和容器，是“老法师自带独门配方上台掌勺”。AutoML 是“速成大厨”，适合不想写模型代码的场景；批量预测和监控都在训练之后，与训练入口无关。

Q4. 想让新版本模型先接收 5% 流量，观察无误后再全量，应使用 Vertex AI 的哪个能力？

单选题 · easy

  • A.批量预测服务
  • B.流量分配能力← 正确答案
  • C.自动扩缩容
  • D.超参自动调优

答案：B。流量分配（Traffic Split）就是灰度发布：新版本先接 5% 流量，指标正常再逐步切到 100%，异常可秒级回滚，对应“先试吃再放量”。批量预测是离线跑数，扩缩容管的是实例数量，调优发生在训练阶段。

Q5. 关于 Vertex AI Model Registry 的说法，正确的是？

单选题 · mid

  • A.只保存模型文件不保存指标
  • B.版本发布后无法回滚
  • C.支持多版本管理与审批← 正确答案
  • D.只能人工手动上传模型

答案：C。Model Registry 是模型留样柜：支持多版本并存、别名和审批流程，只有通过审批的版本才能标记为 production，所以 C 对。它同时存档评估指标，能与训练作业联动自动上传，也支持回滚，所以 A、B、D 均错。

Q6. PSI 用于检测模型漂移，当其值为 0.3 时通常表示？

单选题 · hard

  • A.分布完全稳定无需处理
  • B.轻微波动暂可忽略
  • C.偏移明显建议告警重训← 正确答案
  • D.模型效果必然下降

答案：C。经验阈值是 PSI 小于 0.1 稳定、0.1 到 0.25 关注、大于 0.25 偏移明显，应告警并考虑重训，所以 C 对。PSI 衡量的是输入分布变化，不等于准确率一定下降，因此 D 的“必然”表述绝对化、不正确。

Q7. 部署端点扩容估算：QPS 为 2000，单次推理耗时 50 毫秒，单实例并发上限 20，至少需要几个实例？

单选题 · mid

  • A.3 个实例
  • B.5 个实例← 正确答案
  • C.10 个实例
  • D.50 个实例

答案：B。每秒需要的总处理时间为 2000 × 0.05 = 100 秒，再除以单实例并发 20，得到 5 个实例。这对应公式“实例数 = QPS × 单次推理耗时 ÷ 并发，向上取整”，答案是 B。

Q8. 以下哪些属于 Vertex AI Pipelines 的特性？

多选题 · mid

  • A.组件可复用可版本化← 正确答案
  • B.支持定时与事件触发← 正确答案
  • C.只支持手动执行
  • D.每次运行留审计记录← 正确答案

答案：ABD。管道组件基于 KFP 标准，天然可复用、可版本化；触发方式支持手动、定时和事件驱动；每次运行都有审计记录。C 说“只支持手动执行”与设计目标相反——管道存在的意义就是自动化。

Q9. Vertex AI Model Monitoring 能做哪些事？

多选题 · extreme

  • A.监控输入分布漂移← 正确答案
  • B.检测训练服务偏差← 正确答案
  • C.自动修复数据质量
  • D.识别新类别样本告警← 正确答案

答案：ABD。模型监控负责“发现”问题：输入漂移、训练服务偏差、新类别数据都在检测范围内。但监控本身不会“修复”数据质量——修复要靠管道重训与人工介入。C 是干扰项，把检测和修复混为一谈。

Q10. 关于 Vertex AI 数据准备与特征工程，说法正确的有？

多选题 · hard

  • A.数据集支持自动拆分训练集← 正确答案
  • B.特征冷热通道同源一致← 正确答案
  • C.数据标注必须人工完成
  • D.元数据可追踪特征血缘← 正确答案

答案：ABD。Dataset 支持训练/验证/测试自动拆分，特征仓库在线离线通道同源，Metadata 记录血缘可追溯，所以 A、B、D 正确。标注服务支持人工与半自动结合，并非“必须人工”，C 错。