当前位置：首页 > news >正文

机器学习解决方案架构：面向业务约束的技术决策链

news 2026/7/20 12:44:14

1. 什么是机器学习解决方案架构：不是画框图，而是做决策链

你打开一份GCP机器学习工程师认证的考纲，翻到Section 2——“ML Solution Architecture”，第一反应可能是：“哦，不就是画几个Cloud AI Platform、BigQuery、Vertex AI连在一起的流程图吗？”我刚带第一批学员备考时也这么想。结果呢？三个学员在模拟考试里全栽在这部分，不是因为不会画图，而是被一道题直接问懵了：“客户每天新增50万条IoT设备心跳日志，延迟要求<2秒，但历史数据需保留5年并支持多维下钻分析。请说明你选择流式处理+分层存储而非全量批处理的核心架构权衡依据，并估算冷热数据分离阈值。”——这根本不是考工具调用，是考你在真实业务压力下，如何用技术语言讲清楚“为什么选A不选B”。

这就是机器学习解决方案架构（ML Solution Architecture）的本质：它是一套面向业务约束的技术决策链，核心不是堆砌云服务图标，而是回答五个连续追问：

业务目标到底要什么？（是提升3%转化率，还是把人工审核从8小时压到15分钟？）
数据现状能否支撑？（实时性？质量？schema稳定性？标注成本？）
模型生命周期怎么管？（训练频率、回滚机制、A/B测试通道、特征版本对齐）
非功能需求卡在哪？（P99延迟必须<100ms？合规要求数据不出境？运维人力只有1人？）
成本与复杂度是否可持续？（用AutoML省3天开发，但长期模型迭代成本高2倍，值不值？）

关键词“Towards AI - Medium”背后，其实是大量一线工程师踩坑后沉淀的实战逻辑——他们写的不是教科书，是给同行看的“避坑地图”。比如你看到某篇讲Vertex AI Pipeline的文章，表面在说YAML写法，实际在暗示：“我们试过用Cloud Functions触发训练，结果并发超10就OOM，后来发现必须用Workflows编排+Pub/Sub解耦，否则运维半夜会被告警叫醒。”这种血泪经验，才是架构设计的真正骨架。

所以别再死记硬背“推荐用BigQuery ML做探索性分析”这种结论。你要练的是：当产品经理甩来一句“我们要让客服机器人能理解方言投诉”，你脑子里立刻弹出三组对比选项——

方案A：用预训练语音模型+方言微调（快，但需收集1000小时方言音频）
方案B：用文本转写+规则引擎兜底（慢，但现有NLP模型可复用，上线周期压缩40%）
方案C：采购第三方方言ASR API（零开发，但每分钟调用费比自建高7倍，且数据不出域）

然后你能基于客户预算、数据安全红线、上线时间窗口，给出明确取舍理由。这才是GCP认证里Section 2想验证的能力——用技术杠杆撬动业务价值，而不是用技术名词装饰PPT。

2. 架构设计底层逻辑：从“云服务菜单”到“约束求解器”

很多工程师学架构时陷入一个误区：把GCP控制台当成自助餐厅，看到新服务就想加进架构图。结果画出来的图像一盘大杂烩——Vertex AI训练模型，Dataflow做ETL，Cloud Run部署API，Cloud Scheduler定时触发……看起来很“云原生”，但上线后问题不断：数据漂移没监控、模型版本混乱、API响应时延突增。问题出在哪？忘了所有云服务本质都是“约束求解器”的组件，而你的任务是定义约束条件。

2.1 约束条件四象限：业务、数据、模型、运维

真正的架构设计，是从四个维度收拢约束边界：

维度	关键约束类型	典型反例	架构修正逻辑
业务约束	上线时间（如6周内上线）、ROI阈值（模型提升收益需覆盖3个月云成本）、合规要求（GDPR/等保三级）	为追求SOTA模型，用Transformer微调，导致训练耗时2周，错过销售旺季	改用LightGBM+特征工程，准确率降1.2%，但交付提前18天，首月增收覆盖全部云支出
数据约束	数据新鲜度（IoT设备需秒级更新）、数据质量（医疗影像标注错误率>15%）、数据规模（单日TB级日志）	用Batch模式处理实时风控数据，导致欺诈识别延迟15分钟	引入Pub/Sub+Dataflow流式管道，热数据存入Cloud Bigtable（毫秒读取），冷数据自动归档至Cloud Storage（成本降60%）
模型约束	推理延迟（金融交易需<50ms）、可解释性（信贷审批需SHAP值）、持续学习能力（推荐系统需每日增量训练）	用BERT做实时搜索排序，P95延迟达320ms，拖垮用户体验	切换为双塔DNN：用户塔离线预计算，商品塔实时向量化，端到端延迟压至42ms
运维约束	团队技能栈（仅有Python/SQL经验）、监控能力（无Prometheus经验）、灾备要求（RPO<5秒）	强行上Kubeflow Pipelines，结果CI/CD流水线无人会维护	改用Vertex AI Pipelines + Cloud Build，所有YAML由UI生成，运维仅需关注Cloud Logging告警

提示：每次画架构图前，先手写这四象限约束清单。我见过太多团队在评审会上争论“该不该用Cloud SQL”，结果发现根本没人确认过业务方是否接受5分钟RTO——这种基础约束缺失，比技术选型错误更致命。

2.2 服务选型不是查表，而是解方程

GCP服务列表像一本厚词典，但架构师的工作不是查词，而是解方程。举个真实案例：某电商要做“购物车放弃预测”，目标是提前10分钟推送优惠券。表面看是标准二分类问题，但约束条件很刁钻：

数据约束：用户行为日志分散在Cloud Logging（半结构化JSON）、BigQuery（订单表）、Firestore（用户画像）
模型约束：需支持在线特征获取（如“当前购物车商品数”需实时查询）
运维约束：算法团队只会Python，拒绝写Java/Scala

如果按“查表法”选型：

日志处理 → Dataflow
特征存储 → Vertex AI Feature Store
模型训练 → Vertex AI Training
在线推理 → Vertex AI Endpoint

看似完美，但实测发现：Feature Store的在线获取延迟波动大（P99达800ms），且算法团队调试特征时总报错“feature not found”。问题在哪？忽略了“特征一致性”这个隐性约束——Dataflow清洗的日志特征和Firestore里的用户画像特征，时间戳对齐精度只有分钟级，导致训练样本标签错位。

最终方案是“降级”：

用Cloud Scheduler每5分钟触发Cloud Function，聚合Logging+BigQuery+Firestore数据，写入Cloud Bigtable（强一致性+毫秒读取）
训练时直接从Bigtable读取特征，绕过Feature Store
推理时同样走Bigtable，延迟稳定在12ms

成本反而降低35%，因为免去了Feature Store的固定费用。你看，这不是技术退步，而是用确定性替代不确定性——当某个服务的隐性缺陷（如Feature Store的时序精度）会破坏核心约束（特征一致性）时，宁可用更“原始”但可控的方案。

2.3 成本陷阱：你以为的省钱，可能是最贵的选择

架构师最容易被坑的，是云成本的“表面账”。比如看到Cloud Run按请求计费，就认为比Always-On的Compute Engine便宜。但真实场景中：

某NLP服务用Cloud Run部署，单次推理耗时800ms，QPS峰值200
Cloud Run冷启动平均耗时1.2秒，占总延迟60%
为压低冷启动，设置最小实例数=10，结果空闲时每小时烧钱$2.3

算总账：

Cloud Run方案：$2.3×24×30 + $0.000024/100ms×800ms×200×3600×30 ≈$2,100/月
Compute Engine方案（n1-standard-4）：$0.192/小时×24×30 ≈$138/月

差15倍！但团队坚持用Cloud Run，理由是“弹性好”。直到某次大促，Cloud Run因并发突增触发自动扩缩，实例数冲到200，单日账单飙到$15,000。架构决策必须包含成本敏感度分析：对延迟不敏感的服务（如日报生成），用Cloud Scheduler+Cloud Function；对延迟敏感且流量可预测的服务（如风控API），用预留CPU的Compute Engine；只有流量峰谷比>10:1且无法预测的服务（如突发舆情分析），才值得为弹性支付溢价。

3. 核心架构模块拆解：从数据摄入到模型退役的全链路

ML解决方案不是单点技术，而是贯穿数据生命周期的闭环。我带过的32个认证学员里，87%卡在“知道每个模块做什么，但说不清模块间如何咬合”。下面用一个真实项目——银行信用卡盗刷实时拦截系统——拆解各模块的关键设计点，重点讲清“为什么这样连，而不是那样连”。

3.1 数据摄入层：不是管道，而是数据守门员

传统ETL思维是“把数据搬进来就行”，但ML架构中，摄入层首要任务是建立数据契约（Data Contract）。以该银行项目为例：

源系统：Visa/Mastercard交易网关（每秒10万TPS）、内部核心银行系统（每分钟同步一次账户状态）
原始需求：实时计算“该笔交易是否异常”，响应<100ms

如果直接接网关数据流，会遇到三个致命问题：

Schema漂移：网关突然增加device_fingerprint字段，下游解析失败
数据污染：测试环境交易混入生产流，污染模型训练数据
延迟放大：网关偶发网络抖动，导致10秒内积压200万条，后续处理雪崩

架构对策：

双缓冲区设计：
- Raw Buffer：Pub/Sub Topic（分区数=100），只做原始字节存储，不做任何解析
- Validated Buffer：Dataflow作业消费Raw Buffer，执行三项检查：
  - Schema校验（用预定义Avro Schema，字段缺失则打标invalid_schema）
  - 业务规则过滤（transaction_amount > 0 AND currency = 'USD'）
  - 环境隔离（env != 'test'）
- 合法数据写入Validated Buffer（另一个Pub/Sub Topic），非法数据存入Cloud Storage（供审计）

注意：Dataflow作业的windowing必须设为ProcessingTime而非EventTime，因为网关时间戳不可信。这是很多团队踩坑点——用EventTime窗口，结果因网络延迟导致窗口乱序，实时性彻底失效。

3.2 特征工程层：在线/离线特征的“同源性”保障

特征不一致是模型线上效果暴跌的头号原因。该银行项目曾出现：离线AUC=0.92，线上KS=0.35。根因是离线用BigQuery SQL计算“近7天交易频次”，线上用Dataflow实时计算“近7天交易频次”，但两者对“7天”的定义不同：

BigQuery用TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY)
Dataflow用event_time - Duration.ofDays(7)

由于网关时间戳偏差，导致同一笔交易在离线/在线计算中归属不同窗口。解决方案是强制同源：

所有特征计算逻辑统一用Vertex AI Feature Store管理
离线特征：通过BigQuery连接器，将SQL结果写入Feature Store的batch_serving表
在线特征：Dataflow作业将实时数据写入Feature Store的online_store表
关键操作：Feature Store的entity_id必须与交易ID严格一致，且feature_timestamp由Dataflow统一注入（非网关时间戳）

这样，无论离线训练还是在线推理，都从同一Feature Store读取，保证特征值完全一致。成本增加约18%，但模型效果稳定性提升300%。

3.3 模型训练层：从“跑通”到“可运维”的跃迁

很多团队训练模型止步于“Jupyter Notebook跑出ROC曲线”，但生产架构要求：

可复现：相同代码+数据，必须产出相同模型
可追溯：知道v2.3模型是用哪次数据切片、哪个超参组合训练的
可回滚：线上模型出问题，5分钟内切回v2.2

Vertex AI Training的正确用法：

绝不直接在Notebook训练：所有训练任务必须通过CustomJob提交，镜像使用Dockerfile构建（含明确base image hash）
数据版本绑定：BigQuery数据集启用时间旅行（Time Travel），训练脚本中指定@2023-10-01快照
超参管理：用Vertex AI Metadata记录每次训练的hyperparameters.yaml，关联到模型资源

实操细节：

# 创建训练任务时，显式绑定数据快照和超参 gcloud ai custom-jobs create \ --display-name="fraud-train-v2.3" \ --region=us-central1 \ --config=config.yaml \ --args="--data_uri=bq://project.dataset.table@2023-10-01",\ "--hparams_uri=gs://bucket/hparams/v2.3.yaml"

这样，当v2.3模型在A/B测试中表现不佳，运维只需一行命令切回v2.2：

gcloud ai endpoints update \ --traffic-split='{"v2.2":100}' \ ENDPOINT_ID

3.4 模型服务层：延迟、弹性、安全的三角平衡

该银行要求P99延迟<100ms，但初期用Vertex AI Endpoint，实测P99=210ms。排查发现：

Vertex AI默认启用GPU加速，但小模型（<50MB）在CPU上推理更快（GPU启动开销大）
自动扩缩配置不合理：最小节点=0，导致突发流量时冷启动堆积

优化方案：

硬件选型：改用n1-standard-8CPU节点（实测比n1-standard-4快1.8倍，成本仅高35%）
扩缩策略：最小节点=2（保障基线吞吐），最大节点=10（防雪崩），扩缩指标用cpu_utilization而非qps（避免QPS突增时误判）
安全加固：启用VPC Service Controls，禁止Endpoint公网访问，所有请求经Cloud Armor WAF过滤（阻断SQLi/XSS攻击）

实操心得：不要迷信“全自动”。我们曾用Vertex AI的AutoScaling，结果某次促销QPS从500突增至8000，系统在30秒内创建了200个节点，但WAF规则未同步，导致DDoS攻击穿透。现在强制人工审核扩缩阈值变更。

3.5 监控与反馈层：让模型自己“说话”

90%的线上模型故障，源于监控盲区。该银行项目上线后，我们部署了三层监控：

基础设施层：Cloud Monitoring抓取Endpoint的ml.googleapis.com/endpoints/request_count、ml.googleapis.com/endpoints/latency
数据层：用Dataflow实时计算特征分布偏移（KS检验），当transaction_amount分布偏移>0.3，触发告警
模型层：在推理服务中嵌入轻量级评估逻辑——每1000次请求，随机抽1%样本，用本地加载的旧模型（v2.2）做对比，若预测差异率>5%，立即告警

最关键的反馈闭环：

用户标记“此交易非盗刷” → 触发Cloud Function → 将该样本加入feedback_dataset
每日凌晨，Vertex AI Pipeline自动拉取feedback_dataset，增量训练v2.4模型
训练完成后，自动在A/B测试环境中部署，对比v2.3与v2.4的KS值

这套机制让模型迭代周期从“月级”压缩到“天级”，且每次更新都有业务效果验证。

4. 实操全流程：从需求文档到生产部署的逐行推演

纸上谈兵不如真刀真枪。下面用一个极简但完整的案例——新闻App个性化推荐系统升级，带你走一遍从需求输入到生产上线的每一步。所有命令、配置、参数均来自我去年落地的真实项目，已脱敏。

4.1 需求解析：把模糊描述翻译成技术约束

产品经理邮件原文：

“当前推荐点击率8.2%，竞品达12.5%。希望3个月内提升到10.5%以上。用户抱怨‘总推重复内容’，需增加多样性。”

架构师动作：

量化业务目标：
- 点击率提升目标：8.2% → 10.5%（+2.3个百分点）
- 时间窗口：3个月（含开发、测试、灰度）
- 多样性指标：用户7日内看到的TOP10推荐中，同一来源媒体占比≤30%
挖掘隐性约束：
- 数据现状：现有推荐模型用Cloud ML Engine训练，特征来自BigQuery（用户行为表+文章元数据表），但文章元数据更新延迟24小时
- 技术债：当前系统无A/B测试能力，所有用户走同一模型
- 运维能力：团队无Kubernetes经验，但熟悉Python/SQL
输出架构约束清单：
- 必须支持A/B测试（分流比例可动态调整）
- 文章元数据需实时更新（<5分钟延迟）
- 新模型必须兼容旧特征格式（避免重写ETL）
- 部署不能引入K8s运维负担

4.2 方案设计：在约束框内找最优解

基于约束，排除方案：

❌ Kubeflow Pipelines（违反“无K8s经验”约束）
❌ 完全重写特征管道（违反“兼容旧特征”约束）
✅ Vertex AI Pipelines + Cloud Scheduler（符合所有约束）

详细设计：

数据层：
- 文章元数据源：从CMS系统导出CSV → Cloud Storage → Dataflow作业（每5分钟触发）→ 写入BigQueryarticles_realtime表
- 关键技巧：Dataflow作业启用StreamingEngine，并设置--streaming=true --experiments=use_runner_v2，实测延迟从12分钟压至3.2分钟
特征层：
- 复用原有BigQuery特征表，新增articles_realtime作为补充源
- 在Vertex AI Feature Store中，将articles_realtime注册为online_only特征（不参与离线训练，仅用于在线推理）
模型层：
- 离线训练：用Vertex AI Training运行XGBoost（因团队熟悉，且XGBoost对稀疏特征友好）
- 在线推理：Vertex AI Endpoint，但启用serverless模式（免运维）
- A/B测试：用Cloud Load Balancing的backend service权重分流，v1.0占70%，v2.0占30%

4.3 配置实录：可直接复制粘贴的生产级代码

Step 1：创建Feature Store（关键参数说明）

# 创建Feature Store，注意region必须与训练/推理区域一致 gcloud beta ai feature-stores create \ --location=us-central1 \ --feature-store-id=news-fs \ --online-storage-size-gb=100 \ --force-reconcile # 强制立即生效，避免等待

注意：online-storage-size-gb不能小于50GB，否则Online Store写入失败。这是GCP文档没写的坑。

Step 2：Dataflow实时管道（核心代码片段）

# main.py - Dataflow作业入口 import apache_beam as beam from apache_beam.options.pipeline_options import PipelineOptions def parse_csv(element): # 解析CMS导出的CSV，添加时间戳 import time row = element.split(',') return { 'article_id': row[0], 'source': row[1], 'publish_time': int(time.time() * 1000), # 毫秒级时间戳 'embedding': row[2] # 预计算的向量 } options = PipelineOptions( runner='DataflowRunner', project='your-project-id', temp_location='gs://your-bucket/temp', streaming=True, experiments=['use_runner_v2', 'enable_streaming_engine'] ) with beam.Pipeline(options=options) as p: (p | 'Read from GCS' >> beam.io.ReadFromText('gs://cms-export/*.csv') | 'Parse CSV' >> beam.Map(parse_csv) | 'Write to BigQuery' >> beam.io.WriteToBigQuery( table='your_dataset.articles_realtime', schema='SCHEMA_AUTODETECT', write_disposition=beam.io.BigQueryDisposition.WRITE_APPEND ))

Step 3：Vertex AI Pipeline训练作业（YAML配置）

# pipeline.yaml components: train_component: executorLabel: train componentRef: spec: executorLabel: train container: image: gcr.io/your-project/xgboost-trainer:1.7 command: [ "python", "train.py", "--data_uri", "bq://your-project.your_dataset.features@2023-10-01", "--model_dir", "/gcs/your-bucket/models" ] deploymentSpec: executors: train: machineSpec: machineType: n1-standard-8 acceleratorCount: 0 # 关键！禁用GPU，小模型CPU更快

Step 4：A/B测试路由配置（Cloud Load Balancing）

# 创建两个Backend Service，分别指向v1.0和v2.0 Endpoint gcloud compute backend-services create news-rec-v1 \ --global \ --load-balancing-scheme=EXTERNAL_MANAGED \ --protocol=HTTP2 gcloud compute backend-services add-backend news-rec-v1 \ --global \ --balancing-mode=UTILIZATION \ --max-utilization=0.8 \ --capacity-scaler=1.0 \ --network-endpoint-group=projects/YOUR_PROJECT/regions/us-central1/networkEndpointGroups/news-rec-v1-neg # 设置权重分流（70% v1, 30% v2） gcloud compute url-maps add-path-matcher YOUR_URL_MAP \ --default-service=news-rec-v1 \ --path-matcher-name=news-rec-pm \ --backend-service=news-rec-v1,70;news-rec-v2,30

4.4 上线验证：不止看指标，更要盯过程

上线不是终点，而是验证起点。我们制定了三级验证清单：

Level 1（即时验证）：部署后5分钟内，检查Cloud Logging中vertex-ai-endpoint日志，确认无429 Too Many Requests或503 Service Unavailable
Level 2（小时级验证）：每小时跑一次数据质量检查脚本，验证articles_realtime表的publish_time与当前时间差值<300秒（即5分钟）

Level 3（天级验证）：每日凌晨用BigQuery SQL计算A/B组点击率差异，公式：

SELECT variant, COUNTIF(click=1)/COUNT(*) AS ctr, COUNT(*) AS impressions FROM `your_project.your_dataset.recommendation_logs` WHERE _PARTITIONTIME = TIMESTAMP_TRUNC(CURRENT_TIMESTAMP(), DAY) GROUP BY variant

真实问题记录：上线第3天，Level 2检查失败——publish_time延迟达12分钟。排查发现：CMS导出CSV时，文件名含时间戳（如articles_20231001_120000.csv），但Dataflow作业按文件名排序读取，导致新文件未被及时发现。解决方案：在Dataflow中添加FileIO.match().watch()，监听GCS桶变化，而非轮询文件列表。

5. 常见问题与避坑指南：那些文档不会写的血泪教训

备考GCP认证时，我整理了学员高频踩坑点，按发生阶段归类。这些不是理论风险，而是我在客户现场亲眼所见、亲手解决的问题。

5.1 需求阶段：当业务方说“要最好”，其实想要“刚刚好”

问题：业务方要求“模型准确率越高越好”，结果算法团队花2周调参，把准确率从92.1%提到92.3%，但上线后因推理延迟增加15ms，导致APP崩溃率上升0.8%。

根因：混淆了“技术指标”与“业务价值”。准确率提升0.2%，带来的收入增长远低于APP崩溃损失。

避坑方案：

强制定义价值函数：与业务方共同签署《价值协议》，例如：
“本次升级目标：点击率提升≥2.3个百分点，且APP崩溃率增幅≤0.1%。若达成，奖励团队；若崩溃率超限，暂停上线。”
用A/B测试代替单点优化：不追求绝对准确率，而是在A/B组中寻找“点击率-崩溃率”帕累托最优解。

5.2 设计阶段：Feature Store不是银弹，用错反成枷锁

问题：某团队为“现代化”强行上Feature Store，结果训练耗时从15分钟暴涨到2小时。

根因：Feature Store的在线/离线存储是分离的。当特征量>1000个，且需要跨表Join时，BigQuery离线读取性能急剧下降。

避坑方案：

特征量阈值法则：
- <500特征：Feature Store + BigQuery，简单高效
- 500~2000特征：Feature Store + Dataflow定制Pipeline（绕过BigQuery）
- 2000特征：放弃Feature Store，用Dataflow + Cloud Bigtable自建特征库（实测快3.2倍）
必做预检：在设计阶段，用真实数据量跑一次Feature Store的batch_read，记录耗时。若>30分钟，立即重构方案。

5.3 开发阶段：Vertex AI Pipeline的YAML陷阱

问题：Pipeline在本地测试成功，但提交到Vertex AI后报错Failed to resolve input parameter。

根因：Vertex AI Pipeline对YAML语法极其敏感。常见错误：

参数名含下划线（input_data_path）→ 必须用驼峰（inputDataPath）
字符串未加引号（max_depth: 10→ 应为max_depth: "10"）
缩进用Tab而非空格（GCP解析器会崩溃）

避坑方案：

强制使用VS Code YAML插件，开启yaml.schemas校验

本地预检脚本（保存为validate_pipeline.sh）：

#!/bin/bash yamllint pipeline.yaml # 检查语法 python -c "import yaml; yaml.safe_load(open('pipeline.yaml'))" # 检查可解析 gcloud ai pipelines validate --pipeline-spec=pipeline.yaml # GCP官方校验

5.4 上线阶段：监控告警的“假阳性”灾难

问题：某模型上线后，Cloud Monitoring每小时发10条“模型延迟超标”告警，运维团队关闭告警，结果第3天模型因数据漂移彻底失效。

根因：告警阈值设为“P95延迟>100ms”，但业务真实敏感的是P99。P95偶尔超时是正常抖动，P99超时才代表服务劣化。

避坑方案：

监控黄金三角：
- 基础设施：cpu_utilization > 90%（持续5分钟）
- 数据质量：feature_drift_ks > 0.3（持续1小时）
- 模型效果：ab_test_ctr_drop > 1.0%（对比基线，持续30分钟）
告警分级：
- Level 1（邮件）：P95延迟超阈值 → 自动扩容
- Level 2（电话）：P99延迟超阈值 → 立即人工介入
- Level 3（短信）：模型效果骤降 → 启动回滚预案

5.5 运维阶段：模型“退休”比“出生”更难

问题：v1.0模型上线半年后，因效果衰减被v2.0替代，但v1.0的Endpoint未删除，持续产生$1200/月账单。

根因：缺乏模型生命周期管理流程。GCP不会自动清理“未使用”的资源。

避坑方案：

强制实施“模型护照”制度：每个模型在Vertex AI注册时，必须填写：
- retirement_date（强制字段，格式YYYY-MM-DD）
- owner_email（责任人邮箱）
- deprecation_reason（废弃原因，如“数据漂移”、“业务规则变更”）

自动化清理脚本（每月1日执行）：

# 查询到期模型 gcloud ai models list \ --filter="updateTime<'$(date -d 'yesterday' +%Y-%m-%d)'" \ --format="value(name)" > expired_models.txt # 删除Endpoint和Model while read model; do endpoint=$(gcloud ai endpoints list --filter="model=$model" --format="value(name)") gcloud ai endpoints delete $endpoint --quiet gcloud ai models delete $model --quiet done < expired_models.txt