Predictive AI & MLOps预测式 AI 与 MLOps

01「我们已经有一堆模型了」：两种 AI 各管什么#pam-what-why

六格摆开，「你们跟它什么关系」当场有答案

这张表最值钱的是「换供应商」那行：预测式那一侧客户换不掉，因为权重是他自己数据训出来的资产——这既是他不肯换的理由，也是你不该去碰它的理由。生成式那一侧的选型与价格不在本页，见下面的串联。

同一笔可疑交易，两种 AI 各站一棒

大模型接不了预测式的活，卡在三处

这三件事它在结构上做不到，跟能力强弱无关——客户提「为什么不直接让大模型预测」时，答这三条比答「效果不好」有力得多。

答不上这四句，模型就先别立项

这四句是立项会上最省时间的四句。答不上来比答错更值钱：它当场把「要不要做模型」变成「先做哪件事」。

「先上规则版」不是保守，是有出处的做法：Google《Rules of Machine Learning》第 1 条写的是别怕先发一个没有机器学习的版本，并写明若你认为机器学习能带来 100% 的提升，启发式规则能带你走完其中一半。核实 2026-08-02，来源 Google 官方工程指南。不可外推边界：这是经验法则，那「一半」不是任何具体项目的实测值，别拿去当承诺给客户。

第四句「谁来养」有一篇经典论文撑着：Sculley 等《Hidden Technical Debt in Machine Learning Systems》（NeurIPS 2015）论断真实世界的机器学习系统普遍会背上巨大的持续维护成本，风险因子包括边界侵蚀、纠缠、隐藏反馈回路、未申报的消费方、数据依赖与外部世界变化。核实 2026-08-02，来源 工程实践文献。不可外推边界：这是 2015 年的定性论述，不含任何成本比例或金额——报价时别说「论文说维护占几成」。

02算法取舍地图：表格、时序、排序、异常#pam-model-choice

四种数据形状，各有一个不用解释的默认解

两处口径要记准：GBDT 的常见实现是 XGBoost、LightGBM、CatBoost，客户报哪个名字都落在同一格里；排序那行的指标写作 precision@k，k 就是客户每天处理得了的条数，不是一个可调的超参。

想上更新的算法，先过这三道门槛

客户那三句话，公开基准早就正面回答过

这三条改变的动作很具体：客户说「先上深度模型」，你把预算谈成「先用树立基线，省下的时间做切题」；客户说「一个标签都没有」，你把第一期做成凑那 1% 标签的工程，而不是直接交一个没法验收的无监督方案。

TabArena 为 NeurIPS 2025 数据集与基准赛道 Spotlight（arXiv:2506.16791 v4，2025-11-03）；表格基础模型的规模上限按 Prior Labs 官方文档：TabPFNv2 为 1 万样本 / 500 特征 / 10 类，TabPFN-2.5 与 2.6 为 10 万样本 / 2000 特征，TabPFN-3 与 TabPFN-3-Plus 为最多 100 万行、最多 2000 列（行列上限此消彼长、不能同时取满）、原生 160 类，2026-09 新出的 TabPFN-3.5 系列为 100 万行 / 2 万列。核实 2026-10-20，来源 表格模型基准与官方文档。不可外推边界：TabArena 是公开精选数据集上的排名，不代表客户数据上的名次；那几个规模上限只说跑得动多大，不代表在该规模上压得过树，也不含耗时与显存。

M5 结论出自竞赛组织方的官方总结论文 Key findings 一节；ADBench 为 NeurIPS 2022 数据集与基准赛道论文。核实 2026-08-02，来源 竞赛总结与异常检测基准。不可外推边界：M5 是零售销量单场竞赛的结论，不能外推到所有时序场景；ADBench 那个 1% 是公开数据集上的平均结论，不是保证——客户拿不出这 1%，方案就得改口径。

03把业务问题切成可学的题：预测时点、标签窗口、样本单元#pam-problem-framing

三段时间轴，画错一段模型就在偷看未来

同一句「预测流失」，四种切法切出四道题

四道题的样本量、正样本比例、上线方式全不同，报价也不同。现场先问一句「这个分数谁在什么时候看」，客户答完，四行里落哪一行当场就定了——这比讨论算法快十倍。上表的时点与天数同样是举例。

标签是等出来的，等多久直接写进 POC 排期

这是预测式项目最容易被低估的一项成本，也最容易在排期会上翻车。它和数据标注不是一回事：标注的成本在人力，标签成熟的成本在时间，加人加不快。

离线亮眼、上线掉一截，症状全在这四行

这四种在训练集上一个都不报错，只有上线那天才显形——所以它们不是「调参没调好」，是题切错了。

前两行从源头堵住的办法是时间点正确的取数，那是特征的时间语义整节在讲的事，也是本页公认的头号事故源。现场遇到「离线测出来很漂亮，为什么上线掉一大截」，先按这四行对号，别先去动模型。

指标不是挑出来的，是被容量和成本逼出来的

上表的 500 和千分之一都是举例。这三行合起来是一句对客的话：验收线由客户的处理容量和错判成本定，不由我们挑指标定——先把这两个数问出来，验收争议在立项那天就消掉一半。

Google《Rules of Machine Learning》第 4 条：先把第一个模型做简单，把基础设施做对（Keep the first model simple and get the infrastructure right）。核实 2026-08-02，来源 Google 官方工程指南。不可外推边界：这是工程经验法则，一个阈值都不含——标签窗该多长、前 N 名的 N 该多大，它一个数都给不了，只能由业务动作和客户当天的处理容量定。

04特征的时间语义：穿越与训练服务偏差#pam-features-time

取数纪律：把自己放回预测发生的那一秒

规矩只有一条——那一刻取不到的数据，训练时也不许取。展开是五步：

事情发生的时间，不等于你知道它的时间

同一条记录挂着两个时间，训练时用错哪个都会翻车。

AWS 的托管特征库把这层语义做成了默认字段：离线库自动给每条记录附加 api_invocation_time（服务收到写入调用的时间）、write_time（记录写入 S3 文件的时间，官方注明这不一定是可查询的时间、记录也不一定按它的顺序变得可查）与 is_deleted，事件时间则由用户自建的时间列提供。核实 2026-10-20，来源 AWS 官方文档 · 离线库数据格式。不可外推边界：这是 AWS 一家的字段设计，别家命名与语义不同，看到「有时间列」不等于看到同一件事。

同一个样本，两种取数口径差多少（举例）

预测时点举例定在 6/10 09:00，表内日期与延迟都是举例数字。逐行算一遍就有了一句能拿去客户会上说的话：离线拿 4 行喂模型，上线那一刻真到手的只有 1 行，虚增的就是这 3 行。真实系统的写入窗口按官方口径查——特征平台一节登记了一个具体数字。

穿越有五种长相，只有一种叫「用了未来数据」

五种里只有第二种是「时间」问题，其余四种在没有时间维度的数据上照样犯——别把泄漏排查简化成「加个时间过滤」。这张表说的是取数与切分层面的泄漏；微调实验里那一族（近重复没扫、冻结切分哈希、多 seed 报区间）在 Fine-tuning 一册，不重讲。

分数好得反常，就按这五步查

同一套特征走两条路径，必然会漂

训练服务偏差（training-serving skew）是穿越之外的第二个坑：训练时算出的特征值，和线上算出的对不上。为什么必然——训练是数仓里一条 SQL 跑全量，线上是一段代码在请求里现算，两套代码、两种空值处理、两个时区。像两个厨子照同一张菜谱：一个用秤，一个凭手感，菜名一样，端上来不是一道菜。对齐只有三招半，代价各不相同：

第二招出自谷歌《Rules of Machine Learning》第 29 条：把服务时用过的那组特征打进日志、再拿去训练，是保证「训得像服务」最稳的办法；同文把训练服务偏差的成因分成三类——训练与服务管线处理数据的方式不同、训练与服务之间数据变了、模型与算法之间存在反馈回路。核实 2026-08-02，来源 Google for Developers · Rules of Machine Learning。不可外推边界：这是工程原则，不含任何阈值，也不代表日志回流适合所有新特征——新特征上线前根本没有历史日志可训。

这一章保证的是分数可信，不是模型可用

对客的收口话术只有三句：训练集是否按时间切分、每个特征有无落库延迟记录、有没有用上线当天真实拿到的特征重放过。第三件最硬，答不出就别谈离线分数。

05特征平台：什么时候才真需要#pam-feature-store

一份特征，两个库，中间靠物化连着

训练要读全历史，推理要几毫秒出结果——一套存储做不到，所以是两个库一张账。

AWS 的托管特征库写入后先缓冲、批量，在 15 分钟内写入对象存储上的离线库；离线库只支持 Parquet 文件格式，表格式可选 AWS Glue（默认）或 Apache Iceberg。国内侧，阿里云 PAI 的特征库自动完成在线表与离线表的构建并保证两侧一致：离线对接 MaxCompute，在线可经 Flink 处理后写入 Hologres、Tablestore 或自研的 FeatureDB。核实 2026-08-02，来源 AWS 与阿里云官方文档。不可外推边界：15 分钟是离线库的写入窗口，不是在线库的读延迟——这一条最容易被读反，客户会上说错方向就成了「你们的特征库要等一刻钟」；国内那条是平台形态描述，不含延迟与配额，选型仍需实测。

先数这五个数，再决定要不要买

特征平台是拿运维负担换复用收益，数不够就是净亏。

五行里三行以上落在中间那列，才谈得上买；只落一两行，先用「共享转换库 + 特征可用时刻表」顶着——省下的运维人力，多半比平台省下的算力值钱。这张表的用法是当着客户逐行打分，不是发一份材料让他自己看。

它不替你做的事，比它做的更该讲清楚

这四条不是评述，是 Feast 官方文档里专门列的一节「Feast 不是什么」：不是通用数据管线系统、不管理或编排复杂工作流、不是数据仓库也不是组织内加工数据的权威存放地、不是数据库；它把自己定位成数仓下游的一层轻量服务层，核心卖点之一正是生成时点正确的特征集以避免数据泄漏。核实 2026-08-02，来源 Feast 官方文档。不可外推边界：这是 Feast 一家的定位声明，不代表所有特征平台的边界都划在同一处。

买托管之前，先查两件事

一件是产品还能活多久，一件是「时点连接」这项能力到底是内建的还是要自己搭——这两件都决定了三年后谁在为口径迁移买单。

谷歌云的 Vertex AI Feature Store（Legacy）已弃用：官方通告写明自 2026-05-17 起不再新增功能、只提供关键补丁，2027-02-17 完全退役且接口下线，去处是 2023-11-17 推出的 V2 版本或按官方指南迁到 Bigtable。能力侧，Azure 机器学习的托管特征库支持时点连接（官方也称 time travel）来避免数据泄漏；Databricks 侧的对应能力靠在特征表上声明时间列，且时序特征表须恰有一个时间键、不能带分区列。核实 2026-08-02，来源 Google Cloud、Microsoft Learn 与 Databricks 官方文档。不可外推边界：退役表只针对 Legacy 版，V2 的能力与配额另算，别家产品也不同期；「支持时点连接」只证明能力存在，不代表默认开启或性能达标——它按你给的那个时间列算，列给错了照样穿越。

特征这一层定了，接下来是模型本身：从一次实验走到线上，中间隔着哪几道门。

06从实验到生产：实验记录、注册表与发布门#pam-lifecycle

实验记录是写给三个月后的自己看的

手抄表格撑不过第二十次实验，自动记录才撑得住。判断一套实验记录合不合格只问一句：三个月后能不能只凭它把结果跑出来。

从「阶段」改成「别名」，改的其实是回滚方式

注册表最常见的一次语义改动，正好当例子讲——它改的不是界面，是回滚这个动作本身。

别名的好处是能让 champion 和 challenger 两个指针同时指向不同版本，灰度与对照不用再造第二套状态。对客那句话是：出了问题回滚是分钟级——前提两条，旧实例拉得起来、依赖的特征定义没被改过；两条不成立，回滚就成了重新发布，按小时算。

MLflow 自 2.9.0 起把模型注册表的四阶段（None / Staging / Production / Archived）标为弃用、将在未来某个大版本移除，官方替代是模型版本别名与标签，理由是这套状态机对流程「过于死板」，而别名允许同一版本挂多个、可随时改指。另一侧，AWS 的模型注册表用的是三态批准字段——PendingManualApproval / Approved / Rejected，可由接口、控制台或流水线中的条件步骤更新。核实 2026-08-02，来源 MLflow 与 AWS 官方文档。不可外推边界：弃用不等于已移除，旧接口在当前版本仍可用，别拿它去劝客户马上改造；批准状态字段只记录流程走到哪一步，不代表模型质量已被验证。

上线前的三道门，是预测式自己要过的

「离线指标过线就发」是这条路上最贵的一条捷径。

客户常问「新模型明明更好，为什么还要跑影子期」——离线比的是历史数据，影子比的是今天真实进来的请求，差最多的一处就是特征取数：线上有超时、空值、降级，离线表里都没有。

影子测试的具体规格以 AWS 为例：影子变体接收从生产变体复制来的一定比例请求但不返回任何响应，一个端点最多挂一个影子变体、且此时最多一个生产变体；时长默认 7 天、最短 1 小时、最长 30 天，测试结束端点自动恢复原状；Serverless 推理、异步推理、多模型端点、多容器端点、Marketplace 容器与 Inf1 实例的端点不支持。核实 2026-08-02，来源 AWS 官方文档 · 创建影子测试。不可外推边界：7 天与 30 天是 AWS 一家的默认值与配额上限，别家做流量镜像的规格与限制不同，报方案前逐项复核；影子只比得出预测值的差异，比不了业务结果。

流程挡得住草率，挡不住这四件事

发布门是过滤器，不是保险。四个洞得当着客户说清，否则第一次出事就是「你们不是说走了流程吗」。

国内落点上，阿里云 PAI 在同一工作空间内提供两件对应能力：「AI 资产管理 > 模型」支持把训练好的模型注册进来、按版本持续更新并直接部署，部署配置自动透传；Model Gallery 创建微调训练任务时可关联新建或已有实验，任务的超参等元数据、指标与输出模型统一落在实验输出路径下。核实 2026-08-02，来源 阿里云帮助中心。不可外推边界：这只说明「注册」与「实验关联」两件事存在，不等于一套完整的实验跟踪与发布门禁，其余环节要逐项自查。

07上线之后：七类信号、七种动作与再训练触发#pam-monitoring

七类信号按「要不要等真值」分两层

不用等标签的四类，先把它们排除掉

多数告警查到这一步就解释完了。四类都不必等真值，也都不必碰模型。

剩下三类必须等标签，等不起就别承诺

真值来得慢，是预测式和生成式最不一样的一处。标签成熟期直接决定 POC 周期——客户说「三个月才知道结果」，那就是排期，不是借口。这里说的标签是等出来的，成本在时间；人去打的标注是另一件事，成本在人力。越准的模型盲区越大：被它拦下的样本永远不会产生结果，随机放行那一小片是唯一的补救。

分清两个记号，才知道哪一种漂移真的伤人

客户会上最值钱的一句就是这个区分：变的是「谁进来」还是「同样的人结果不同」——只有后者必然让模型变差。

标签没到的那几个月，性能可以估，但估不了概念漂移

阈值不是查出来的，是定出来的

PSI，Population Stability Index（群体稳定性指数）的 0.1／0.25 出自 1994 年信用评分实务，不随样本量调整：样本大了到处报警，样本小了该报不报。客户要「行业标准阈值」时，能给的答案是拿自家历史数据跑出正常波动带，再往外放一档。

Evidently 默认切换规则与 PSI 阈值来历核实 2026-08-02，来源 Evidently 官方文档与 PSI 阈值统计评述。不可外推边界：表里第二、三行是 Evidently 这一个工具的默认值，不是业界统一标准；PSI 的两档是对来历与统计缺陷的评述，不是替代阈值的推荐值——照抄任何一档之前先看它假设了什么。

重训排在最后一位：告警到动作的五步分诊

「监测到漂移就自动重训」，是这一章最贵的一种错

客户问「多久重训一次算正常」，按日历重训是最贵的默认答案。该定的是评估节奏：标签成熟一批评一批，指标越线且归因到关系变了才动模型。这句话要写成一份触发条款，让不写模型的人也能照着执行。

云替你盯得住哪几类

不用等标签的那四类，云上开箱就有——前提是推理的输入和输出真的落了库；真值那几类云盯不了，它不替你等标签，也不负责回灌。托管件本身还会退场：AWS 官方文档已写明 SageMaker Model Monitor 不再向新客户开放、改荐开源方案自建，Azure 侧的模型性能与特征归因漂移两个信号当日仍标 preview。监控管线别绑死在一个托管件上，迁移计划一直在你这边。

监控服务形态与无真值期估计前提核实 2026-08-02，来源 Azure 与 AWS 监控文档、NannyML 官方文档。不可外推边界：服务名是当日快照、按 30 天一查的节奏保鲜，不代表三家云能力对等，也不代表形态不变；CBPE 这类无真值期估计在概念漂移下不成立，只能当预警，不能当验收依据或替代真值。

08可解释、公平与模型风险管理#pam-governance

全局解释和局部解释，回答的是两个问题

客户把这三种混着说，你得先分开：问法不同，做法也不同。第四行是防守用的——有人拿归因图当因果证据讲，当场要拦住。

归因值是分账，不是原因

对客的分寸就在这一句里：归因结果作为主要影响项可以发给被拒的人，作为整改建议不行。据此承诺整改效果，翻车的是你。

三个公平定义，数学上不可能同时满足

客户说「公平性我们全都要」，答案是数学上不行，不是工程做不到。能做的是把三个定义摆出来，跟业务一起先选一个主口径，再把另外两项的代价写进方案。

公平不可兼得与归因局限核实 2026-08-02，来源 Kleinberg 等 2016 与 Shapley 值因果分析等论文。不可外推边界：不可兼得是数学结论——除非各群基础率相同或预测完美，三者不能同时成立——它不指示哪个定义在具体业务里更合适；归因失真是这类方法的固有局限，不代表所有实现都同等失真。

模型风险管理这套老规矩，2026 年 4 月刚换了一版

客户说「我们不是银行，这套要不要做」，答案是这套动作可以裁剪：模型清单、三件验证、独立挑战三样带过去，评审会好过得多。至于「我们那套规则引擎算不算模型」，现行口径把模型定成用统计、经济或金融理论把输入变成定量估计的方法，纯算术和确定性规则不算——规则引擎多半在外，树模型一定在内。

SR 26-2 换版与适用范围核实 2026-10-20，来源 美联储 SR 26-2 通知页与指引全文。不可外推边界：这是主要适用于总资产超 300 亿美元美国银行的监管口径，不是通用企业合规要求；对非金融客户，它是可借鉴的方法而不是必须遵守的条文。

客户风控部门会要的三张纸，提前备好

这三样是工作量，报价时要算进去，别当赠品送。合规条目、法条时点与备案范围不在这一章——那些各有主场，现场别现编。

模型卡格式核实 2026-08-02，来源 Mitchell 等 2019 年模型卡论文。不可外推边界：模型卡是一种文档格式建议，不是任何监管强制模板；照它写不等于满足某地某行业的报送要求。

09一套平台装得下生成式和预测式吗#pam-platform

六层分界：能整层共用的只有两层

这张表是本册对客频率最高的一张，能当着客户的面从上往下讲完，每个「不能共用」都说得出是因为什么不同。向量库与文档管线、集群与 GPU 各有主场，这一节只讲两边的接缝。

共用得最好的是登记这一层

合不了的是算力和服务形态

客户最容易在这一层以为能省钱，其实是两套容量模型。先做分区和配额，把两边跑稳，再谈合池。

两边都说「漂移」，指的不是一件事

这是最容易在客户会上谈岔的一处，先声明口径再往下说：AI-Ops 那一节讲的是无真值的那一种，上线之后那一节讲有真值的那一种。采集层可以共用，判断方法不共用。

客户问「能不能一套搞定」，先答治理面

客户问该先做哪件事：把两种模型登进同一个注册表，把发布门禁和审计留痕统一。这一步几乎没有额外代价，也是后面谈合算力时唯一站得住的基础。选云也别按产品名选，按你们的登记与审计能不能一处满足来选。

注册表可共用与微软两个门面的分工核实 2026-08-02，来源 MLflow 官方文档与 Microsoft Learn 平台说明。不可外推边界：只说登记与追踪层可共用，算力与服务层另算；微软那条分工只反映其当前产品划分，服务名是当日快照、产品名与形态月级变动，不代表另两家云同样切分。

10售前速查#pam-cheatsheet

客户一句话，往哪一节找弹药

预测式和生成式，一分钟对照

客户会拿生成式的经验套预测式，这张表用来当场拉回来。生成式那一列的展开各有主场，本册不重讲。

四句话，挡得住现场多数误判

串联地图：撞到别册的六处，各自怎么划

这六处最容易重讲，被客户追问时也最容易露怯。跨模块引用一律说清「那边讲什么、本册讲什么」，别两边都讲一半。

生产验收清单：这几样得当场演得出来

六条的出处都在七类信号与解释与治理两节。报价时把它们当工作量算，别当赠品送。

方案评审对照：每一面要能出示什么

上一张表验「演不演得出来」，这一张验「出不出示得了」。答不出证据，就还没到生产。

一句话记住每一节

速查各卡不新增事实，出处都在正文各节；治理文档那一行的口径核实 2026-08-02，来源 Mitchell 等 2019 年模型卡论文。不可外推边界：这两张验收表是本册口径的对照清单，不是任何行业标准模板；表里的服务与工具名随各节正文的保鲜节奏变动，引用其中任何数字前先回到对应小节核日期。

11上云怎么落地#cloud

阶段一 · 取数与特征：训练集是怎么来的

顺着追问什么：线上读要几毫秒、并发多少？每个特征的落库延迟有没有记录——这张表拿不出来，时点取数就没有输入（见特征的时间语义）。特征更新是分钟级还是天级？这套特征库的退役公告你们查过吗？再补上判断该不该买的那五行：几个模型共用同一批特征、几个团队在重复造、要不要毫秒级读、吃过一致性事故没有、要不要复现三个月前的训练集（见特征平台）。

云替你做不了什么：托管特征库保证两边读的是同一份存储，保不了两边算出同一个值——转换代码不同照样对不上，哪个字段是标签的代理量它更是一概不知（见特征的时间语义）。时点取数按你给的那一列时间算，列给错了照样穿越。在线库不留历史，要回溯还得回离线库；离线库有写入窗口，AWS 官方口径是写入调用之后 15 分钟内落进离线库——那是写入窗口，不是在线库的读延迟，这条最容易被读反（见特征平台）。云也替你迁不了口径：迁完要重跑。

Vertex AI Feature Store（Legacy）2027-02-17 完全退役、SageMaker 离线库 15 分钟写入窗口，核实 2026-08-02，来源 特征平台信源。不可外推边界：退役表只针对 Legacy 版，V2 的能力与配额另算，别家产品也不同期；15 分钟是离线库的写入窗口，拿它当实时通道就会把方案写反。

阶段二 · 从实验到发布：一个模型凭什么上线

顺着追问什么：训练现在跑在哪、留没留记录？谁有权批准上线、记录留在哪？门槛值现在是谁定的、写在哪一份文件里？影子期打算跑多久（AWS 那家最长 30 天）？模型和实验记录落在哪个工作空间？还有最容易漏的一句：判定日定在哪一天——标签没成熟前，影子期比不出胜负（见从实验到生产）。

云替你做不了什么：注册表的状态字段只记流程，不判断模型好坏——从待批改成已批，只说明有人点了同意。门槛值要你给，云不知道业务底线。影子只比得出两版预测值的差异，比不了业务结果，谁更准要等标签成熟（见把业务问题切成可学的题）。记录记得住入参和指标，抹不平库版本、算子、归约顺序带来的非确定性差异——别承诺同一份代码跑出同一份权重，能承诺的是差异查得到出处（见从实验到生产）。

影子测试默认 7 天、最长 30 天、一个端点只挂一个影子；MLflow 自 2.9.0 起把注册表四阶段标为弃用、改推别名与标签。核实 2026-08-02，来源 注册表与发布信源。不可外推边界：时长与端点限制是 AWS 一家的配额，别家做流量镜像的规格不同；弃用不等于已移除，旧接口在当前版本仍可用。

阶段三 · 上线之后：云替你盯得住哪几类信号

顺着追问什么：推理的输入和输出落库了吗——没落库，四类不等标签的信号一条都跑不起来。标签多久成熟、谁负责回灌？这个场景的概念漂移风险有多大（它决定空窗期那套估计能不能当预警用）？训练数据还留着吗？这个托管件现在还收不收新客户？阈值谁来定——算子云给，阈值你定（见上线之后）。

云替你做不了什么：云不替你等标签，性能下降与概念漂移这两类必须有真值。无真值期估计在概念漂移下不成立，只能当预警、不能当验收依据；特征归因漂移同理，是预警不是结论。托管件退场时，迁移计划在你这边。最要紧的一条：告警响了不等于模型坏了——五步分诊里重训排在最后一位，云给的是查管线和看分布这两步的算子，对特征、等真值这两步都在你这边（见上线之后）。

Evidently 按参考集大小切换检验方式与阈值；Azure 的模型性能与特征归因漂移两个信号当日仍标 preview；AWS 同日文档改荐开源方案自建。核实 2026-08-02，来源 监控与阈值信源。不可外推边界：Evidently 的那组阈值是该工具的默认值，不是业界统一标准，照抄前先看假设；preview 状态与信号清单会变，也不代表三家云在监控这一面能力对等。

阶段四 · 两种 AI 摆在一起：哪一层合得起来

顺着追问什么：版本谁在管、审计要看到什么？两边的权限和账单打通了吗？延迟、并发、批量各要多少？出事之后多久拿得出当时那一版？还有现场最省时间的一句：你们的预测式和生成式现在分别在哪个控制台里——三家云自己的合并程度都不一样（见一套平台装得下生成式和预测式吗）。

云替你做不了什么：云管存放，晋级规则你定；跨控制台的审计要自己拼。容量规划不归云——共用一个 GPU 集群省下的钱，常被排队和碎片吃回去，先分区分配额再谈合池。证据齐不齐也在你这边：模型卡、独立验证报告、再训练记录，云一张都不会替你写（见可解释、公平与模型风险管理）。

本节的服务清单与「给客户一句话」和讲义各章的「上云怎么落地」页同源，未另立新数；两处服务名快照按 30 天一查的节奏保鲜。核实 2026-08-02，来源 平台与门面信源。不可外推边界：这是「哪一环有云件可用」的地图，不是选型结论——地域可用性、配额、计价单位与产品生命周期状态会月级变动，也不代表三家云在同一环节上能力对等，出方案前按当期官方文档逐项复核。

12现场高频追问#qa

只收会改变某个决定的问题——会改变技术方案、风险判断、验收方法、对客沟通或下一步行动。答不上来的不立题。

全部来自讲义对练页与本次网页化补题，日期 2026-08-02。

本节的数字与服务名都取自本页其他小节已登记的事实，未另立新数；核实 2026-08-02，来源 监控与阈值信源、解释与治理信源。不可外推边界：这些答法给的是判断口径与下一步动作，不是任何客户现场的实测值——阈值、窗口长度、命中率一律要在对方的数据上重算。

13相关模块#related

同一个概念在库里只有一个主要归属，其余模块讲的是它的另一个层面。

这几条指向都在本模块清单里登记过，标的是同一个词在两册各归哪一边，核实 2026-08-02，来源 平台与门面信源。不可外推边界：这是分工声明，不是能力对照——两页都叫漂移，判断方法并不通用，别把那边的做法直接搬到这边来用。

14来源与核实#sources

本页时效性数字均经联网核实后写入，完整登记（事实 × 核实日期 × 信源 × 等级 × 节奏 × 不能外推）见本模块 MANIFEST。核实窗口 2026-08-02。引用任何数字前先核日期。

保鲜节奏按等级分档：云服务名单 30 天一查，工具默认值与监管口径 90 天，论文类结论 180 天。核实 2026-08-02，来源 平台与门面信源。不可外推边界：复查日之前的数字也只是核实当日的快照——产品名、配额、生命周期状态与监管口径都会在两次复查之间变，出方案前按当期官方文档逐项复核。