图像生成管线：上线后监控与迭代

CH-24-01-061·约 16 分钟·AI实践项目·更新 2026-08-13

想象你是一名餐厅老板，经营着一家叫“图生光年”的 AI 美术餐厅。客人在菜单上写下“给我画一只坐在云朵上看星星的橘猫”，后厨的机器大厨便挥动画笔，几分钟后端上一幅图像。开业那天，你发现客人络绎不绝——可你很快意识到，开业只是开始，真正的考验在于：如何让每一道菜都稳定好吃，如何根据客人的抱怨改良菜谱，又如何在不关店的前提下试验新配方。这正是图像生成管线上线之后要做的事——监控、反馈、灰度、迭代。本文就带你走进这家餐厅的后厨，看看 AI 工程师如何用数据监控和版本灰度，让一个“能跑通”的模型，成长为“靠得住”的生产系统。

岗位关联

学会上线后监控与迭代，你才真正完成从“会训模型”到“会养产品”的转变——这是 AI 工程师独立负责生产级管线的核心能力，也是晋升与面试中拉开差距的关键一棋。

可视化演示
搭建监控体系
用户反馈闭环
灰度发布机制
质量指标体系
模型迭代优化
稳定与演进平衡
AI 应用场景
Python 演示
常见误区
面试题

可视化演示

上线后通过线上指标采集与用户反馈闭环驱动持续优化。观察反馈闭环各阶段流转，以及生成质量随迭代逐步提升的趋势。

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

反馈闭环采集监控质量提升灰度发布采集→迭代持续优化

搭建监控体系

走进“图生光年”餐厅的后厨，你做的第一件事不是研究新菜，而是在墙上装摄像头。从点单进厨房，到成品端上桌，每一道菜的状态都要被看见：沙拉酱有没有挤歪、牛排有没有过火、出菜有没有超时。图像生成管线上线之后，AI 工程师的第一课同样不是优化模型，而是给管线装上“摄像头”——一套覆盖每一次生成请求的监控体系。

这套“摄像头”由三块拼图组成：指标（Metric）、日志（Log）与告警（Alert）。指标回答“系统现在健康吗”，日志回答“刚才到底发生了什么”，告警则负责在指标恶化时，把值班工程师从凌晨三点的梦里叫醒。

最核心的指标之一，是请求错误率。它统计所有生成请求中失败的比例，一旦异常升高，往往意味着模型推理出错、显存溢出或上游存储服务抖动。与此同时，还要紧盯 P95 延迟——即 95% 的请求在多少毫秒内完成。平均延迟可能被大多数快请求拉低，而 P95 能精准暴露那 5% 的“慢尾巴”。

摄像头装好了，还要有人盯着屏幕。告警机制就是那个永不疲倦的“盯屏人”：错误率一越红线，它立刻在工作群里敲响警钟。于是，菜品的翻车不再由客人先发现，而是由后厨先知晓——监控的意义，正是把“事故”变成“故事发生前的一声提醒”。

\displaystyle E = \frac{N_{\text{fail}}}{N_{\text{total}}} \times 100\%

请求错误率 = 失败请求数 ÷ 总请求数 × 100%，是判断生成服务是否正常工作的第一信号。

统计失败请求数 $N_{\text{fail}}$在一个统计周期（通常取 1 分钟或 1 小时）内，统计所有未成功生成图像的请求，包括超时、服务端 500 与参数校验错误。
$\displaystyle N_{\text{fail}} = \sum_{i=1}^{N_{\text{total}}} \mathbf{1}(\text{status}_i \neq 200)$
统计请求总数 $N_{\text{total}}$同一周期内进入管线的全部请求，无论成功与否都计入分母，避免用“成功数除以成功数”制造虚假的健康。
$\displaystyle N_{\text{total}} = N_{\text{success}} + N_{\text{fail}}$
求比值并换算百分比失败数除以总数得到一个 0～1 之间的小数，再乘以 100% 转为百分比，便于与告警阈值（如 2%）直接比较。
$\displaystyle E = \frac{N_{\text{fail}}}{N_{\text{total}}} \times 100\%$

用户反馈闭环

摄像头看得到菜端上桌，却看不到客人咬下第一口时的表情。于是餐厅在每张桌上放了“表情评价卡”：非常满意、满意、一般、不满意、非常不满意。图像生成产品同样如此，生成图下方的一排“点赞/点踩”按钮，就是线上的表情评价卡。

反馈闭环的关键不在收集，而在让环转起来。完整链路是：收集反馈 → 清洗噪音 → 问题分级 → 排入迭代队列 → 新版上线 → 再观察反馈。如果只是把问卷挂在页面上而不处理结果，这个环就是一条断掉的项链。

衡量反馈的核心指标叫满意度指数，由 1～5 星的评分均值换算成百分制。值得注意的是，低分往往不代表“图丑”，而代表“图不符合预期”——比如用户说“一只猫”，模型给了一只长着猫耳朵的少女。这类语义偏差无法靠清晰度指标发现，只能靠用户的真实打分和点踩行为捕捉。

意见卡上的每一颗星，最终都会回到研发排期里。当某个生成类别的满意度连续低于阈值，就意味着这道“菜”该改良了。客人的一次点踩，变成了训练数据里的一行标注，再变成下一版模型里一张更准确的图——这就是闭环的力量：它让餐厅的每一句抱怨，都成为进步的食材。

\displaystyle S = \frac{\sum_{i=1}^{n} r_i}{n \times 5} \times 100\%

满意度指数 = 所有用户评分总和 ÷ （人数 × 5 星满分）× 100%，把主观体验变成可对比的 0～100 分。

汇总评分 $\displaystyle \sum_{i=1}^{n} r_i$把 n 份有效反馈的星级逐一相加，$r_i$ 取 1～5 的整数，5 星代表“非常满意”。
$\displaystyle \sum_{i=1}^{n} r_i = r_1 + r_2 + \cdots + r_n$
计算满分总量 $n \times 5$n 位用户全部打 5 星时的总分，这是满意度能达到的理论上限。
$\displaystyle n \times 5$
归一化并转为百分制实际总分除以满分总量，再乘以 100%，得到一个 0～100 的满意度指数，可直接与业务阈值（如 80 分）比较。
$\displaystyle S = \frac{\text{实际总分}}{\text{满分总量}} \times 100\%$

灰度发布机制

改良菜谱是件危险的事。新配方万一翻车，整家店的口碑就砸了。聪明的老板会先搞一场“试吃预售”：让 5% 的客人悄悄试新菜，确认没人投诉后，再逐步扩大到 10%、20%，直到过半。这个过程，在软件发布领域叫作灰度发布。

灰度发布的核心问题是如何“切流量”。技术上通常由网关完成：按用户 ID 哈希取模、按百分比随机、或按地域与设备维度切分，把一小部分真实请求导向新模型，其余请求继续走旧模型。真实流量的多样性，是任何离线测试都给不了的。

灰度期间必须做新旧对比，绝不能只看新模型自己的指标。典型节奏是从 5% 起步，每阶段观察数小时到一天，确认错误率、满意度、延迟均未恶化，才进入下一阶段；一旦异常，立即触发回滚，把流量全部切回旧模型。

试吃预售的精髓，是客人并不知道自己吃的是新菜。吐不吐槽，后厨都在默默记录。等新菜口碑坐实，就悄悄写入正式菜单；若试吃翻车，撤下配方，菜单毫无波澜。稳定与演进，就在这“小范围试错”的哲学里握手言和。

\displaystyle R_k = \min(R_0 \times 2^k, R_{\max})

第 k 阶段的灰度流量比例 = 初始比例 × 2 的 k 次方，但封顶不超过 50%，直到确认新模型可信再全量。

确定初始比例 $R_0$灰度第一阶段只分给新模型 5% 的流量，规模小到即使翻车也无伤大雅。
$\displaystyle R_0 = 5\%$
每阶段翻倍 $2^k$第 k 个观察期结束后比例翻倍，表示信任度逐步提升。
$\displaystyle R_1 = 10\%, \quad R_2 = 20\%$
封顶于 $R_{\max}$比例上限设为 50%，超过一半流量意味着新模型已基本可信，接下来应做全量发布评估而非继续放量。
$\displaystyle R_k = \min(R_0 \times 2^k, 50\%)$

质量指标体系

客人的满意是终极目标，可“好吃”二字太难量化。于是餐厅请来三位品鉴师：一位盯清晰度，一位核对菜品是否符合点单描述，一位从构图与配色打分。三位品鉴师各握一票权，合成一道菜的“综合质量分”。

在图像生成领域，这三位品鉴师对应三个自动评估维度：清晰度，衡量图像是否模糊、有无明显噪点；语义一致性，衡量画面内容是否与提示词匹配；美学评分，衡量构图、色彩与光影的观感。三者均可由 CLIP、FID 等模型或指标自动计算，无需人工逐张查看。

单看任何一项都会失真：一张图可能构图绝美却完全跑题，也可能清晰锐利却呆板无神。因此生产实践把三个维度归一化到同一量纲后加权求和，权重根据业务场景调参——电商海报更看重语义一致性和清晰度，艺术创作则更看重美学评分。

三位品鉴师的意见不会永远一致，但“综合意见”永远比任何单人口味稳定。同样，综合质量分让团队在灰度对比和版本决策时有了统一的裁判：图好不好，不再依赖某位工程师的个人审美，而依赖一套可量化、可对比、可告警的指标体系。

\displaystyle Q = w_1 \times q_{\text{clarity}} + w_2 \times q_{\text{semantic}} + w_3 \times q_{\text{aesthetic}}

综合质量分 = 清晰度得分 × 权重₁ + 语义一致性得分 × 权重₂ + 美学评分 × 权重₃，把多维质量压缩成单一对比口径。

各维度得分 $q$清晰度、语义一致性、美学评分分别归一化到 0～100 分，消除量纲差异。
$\displaystyle 0 \le q_{\text{clarity}}, q_{\text{semantic}}, q_{\text{aesthetic}} \le 100$
设定权重 $w_i$权重反映业务优先级，三者之和必须等于 1，确保综合分仍在 0～100 区间。
$\displaystyle w_1 + w_2 + w_3 = 1$
加权求和三个维度得分与对应权重相乘后累加，得到单一的综合质量分，用于跨版本对比与告警。
$\displaystyle Q = w_1 \times q_{\text{clarity}} + w_2 \times q_{\text{semantic}} + w_3 \times q_{\text{aesthetic}}$

模型迭代优化

试吃收集了意见，品鉴师打完了分，接下来该改良菜谱了。改良不是推翻重来，而是从差评里找出最集中的痛点，把对应的失败样例带回原料间反复试做。这个从线上问题到新配方的循环，就是模型的迭代优化。

第一步是数据回流：把灰度期收集的低分图、被用户点踩的图，以及人类标注的期望效果，整理成新的训练数据。第二步是重新训练：数据量较小时做增量微调，数据量足够或分布偏移明显时做全量重训。第三步是离线评测：用历史数据验证新模型的综合质量分是否提升。

离线评测通过只是入场券，新模型还要回到灰度通道接受真实流量的检验。工程师用成功率等核心指标计算新旧版本的相对提升幅度（Lift），只有提升显著为正、且无新增故障模式，才批准全量部署。至此，一次迭代闭环才算完整走完。

菜谱改良是一个永无止境的回环：差评 → 新数据 → 重训 → 灰度 → 对比 → 放量。每转一圈，菜品水准就上一个台阶。而每一圈都以“上一版口味”为锚——客人在任何时刻尝到的，都是目前最稳的一版。

\displaystyle \text{Lift} = \frac{S_{\text{new}} - S_{\text{old}}}{S_{\text{old}}} \times 100\%

提升幅度 =（新版本成功率 − 旧版本成功率）÷ 旧版本成功率 × 100%，正值代表新模型更优。

旧版本成功率 $S_{\text{old}}$灰度期间分配给旧模型的那部分流量的成功率，作为比较基线。
$\displaystyle S_{\text{old}} = \frac{\text{old success count}}{\text{old total count}}$
新版本成功率 $S_{\text{new}}$同一观察期内新模型的成功率，与旧模型统计口径完全一致。
$\displaystyle S_{\text{new}} = \frac{\text{new success count}}{\text{new total count}}$
计算相对提升新旧成功率之差除以旧版成功率，得到相对提升比例；结果为正说明新模型优于旧模型。
$\displaystyle \text{Lift} = \frac{S_{\text{new}} - S_{\text{old}}}{S_{\text{old}}} \times 100\%$

稳定与演进平衡

后厨研发再热火朝天，饭点也绝不能停业。老板心里有本账：高峰期一秒钟来多少客人，一个炉灶一秒钟出几道菜，灶台不够就翻台，加多了又浪费。这笔账，是生产环境里“稳定”与“演进”之间的平衡学。

稳定性保障的第一课是容量规划：根据预测的峰值 QPS 与单实例吞吐量，预留 1.5～2 倍冗余，确保灰度放量和大促来临时请求不被压垮。第二课是降级策略：当模型服务过载时，自动切换为缓存命中、低分辨率生成或排队限流，宁可降速，不可瘫痪。

第三课是故障演练与回滚预案：定期在预发环境模拟“新模型错误率暴涨”等故障，演练告警触发、定位与一分钟回滚的完整链路。发布节奏同样重要：不在节假日与大促前夜上线新模型，灰度观察期未满不强行放量，这是成熟团队的发布纪律。

老板算清这本账，才知道后厨该扩几个灶台、什么时候能安心试新菜。稳定不是拒绝变化，而是给变化划边界——容量、降级、演练、节奏四道护栏立起来之后，灰度才敢大胆放量，产品才能既快又稳地演进。

\displaystyle N = \left\lceil \frac{QPS_{\text{peak}} \times H}{C_{\text{single}}} \right\rceil

所需实例数 = 峰值 QPS × 冗余系数 ÷ 单实例吞吐量，结果向上取整，保证高峰期有足够“灶台”。

峰值请求率 $QPS_{\text{peak}}$线上观测到的每秒最大请求数，取业务高峰时段的数值，如大促期间的 500。
$\displaystyle QPS_{\text{peak}} = 500$
冗余系数 $H$一般取 1.5～2，为流量突刺和灰度放量预留缓冲空间。
$\displaystyle H = 1.5$
单实例吞吐 $C_{\text{single}}$通过压测得到的单台推理服务每秒能处理的请求数。
$\displaystyle C_{\text{single}} = 50$
向上取整 $\lceil \cdot \rceil$除法结果带小数时向上取整，确保实例数只多不少。
$\displaystyle N = \left\lceil \frac{500 \times 1.5}{50} \right\rceil = 15$

AI 应用场景

电商海报生成服务的质量看板

阶段：线上监控与运营

解决的问题：电商平台每天生成数十万张商品海报，人工抽查根本看不过来，翻车图一旦流出就会影响品牌形象。借助综合质量分自动监控，低于阈值的图会触发重试或模板切换，同时积累坏样本用于后续迭代。

具体案例：某电商平台在“双 11”大促前上线海报生成服务，监控面板显示某品类海报美学分骤降，告警定位到新增的提示词模板导致构图失衡。团队随即灰度回滚该模板，并采集坏样例进入迭代队列，两天后新模板通过灰度验证重新上线。

社交平台头像生成功能的灰度回滚

阶段：模型版本迭代

解决的问题：新模型上线不再“一刀切”，而是按用户 ID 哈希切分 5% 流量观察满意度，一旦发现问题秒级回滚，避免全网差评。

具体案例：某社交 App 上线新版本“动漫头像”模型，灰度期间发现 5% 流量中用户点踩率比旧版高 40%，监控告警触发。值班工程师一键回滚到旧模型，同时把点踩样本加入训练集，两周后修复了“眼睛失真”问题的新模型重新进入灰度。

Python 演示

python69 行

import random  class PipelineMonitor:    """模拟线上图像生成管线的监控器"""     def __init__(self, old_success=0.93, new_success=0.97):        self.request_count = 0        self.failed_count = 0        self.satisfaction_scores = []        self.old_success = old_success        self.new_success = new_success     def simulate_request(self, model_version):        """模拟一次生成请求, 返回是否成功"""        self.request_count += 1        if model_version == 'old':            success = random.random() < self.old_success        else:            success = random.random() < self.new_success        if not success:            self.failed_count += 1            score = random.randint(1, 2)        else:            score = random.randint(3, 5)        self.satisfaction_scores.append(score)        return success     def error_rate(self):        """整体请求错误率"""        return self.failed_count / self.request_count     def satisfaction(self):        """整体平均满意度 (1-5 分)"""        if not self.satisfaction_scores:            return 0.0        return sum(self.satisfaction_scores) / len(self.satisfaction_scores)  def gray_release(monitor, new_ratio, stage_requests=200):    """按灰度比例把流量分给新旧模型, 返回各自成功率"""    old_ok = new_ok = 0    old_total = new_total = 0    for _ in range(stage_requests):        if random.random() < new_ratio:            new_total += 1            if monitor.simulate_request('new'):                new_ok += 1        else:            old_total += 1            if monitor.simulate_request('old'):                old_ok += 1    return old_ok / max(old_total, 1), new_ok / max(new_total, 1)  def main():    random.seed(42)    monitor = PipelineMonitor()    for ratio in (0.05, 0.1, 0.2, 0.5):        old_s, new_s = gray_release(monitor, ratio)        lift = (new_s - old_s) / old_s * 100        print(f"灰度 {ratio:.0%}: 旧成功率 {old_s:.1%}, "              f"新成功率 {new_s:.1%}, 提升 {lift:.1f}%")    print(f"整体错误率: {monitor.error_rate():.2%}")    print(f"整体满意度: {monitor.satisfaction():.2f} / 5")  if __name__ == '__main__':    main()

目的：模拟图像生成管线的灰度发布全流程——按比例切分流量、采集成功率、计算 Lift、汇总错误率与满意度，演示监控与迭代的核心动作如何运转。

monitor = PipelineMonitor()建立监控器对象，它在后续每次请求中记录成败和满意度。
if random.random() < new_ratio:用随机数与灰度比例比较，等效于网关按比例切分流量。
monitor.simulate_request('new')模拟一次由新模型处理的生成请求，成功与否由模型自身成功率决定。
lift = (new_s - old_s) / old_s * 100计算新模型相对旧模型的成功率提升幅度，对应正文的 Lift 公式。
monitor.error_rate()汇总整个灰度过程的错误率，模拟监控面板的告警依据。
random.seed(42)固定随机种子，让灰度结果可复现，便于回归对比。

常见误区

误区我刚上线就把 Grafana 看板搭好了，各种图表应有尽有，监控这块就算搞定了。

正解看板只是“摄像头”的存储端，真正的监控必须包含告警、响应和复盘三件事。有指标无告警，等于装了摄像头却没人看屏幕；有告警无响应流程，等于看到了火警却不知道往哪跑。监控的价值在于“指标 → 告警 → 定位 → 修复”的完整闭环，而不是一张漂亮的图。

为何常见：看板可视化效果直观、交付感强，容易让人误以为“看见”就等于“可控”。

误区灰度发布不就是用网关把 50% 请求导到新模型吗？配置一下就行了。

正解灰度发布的核心不是切流量，而是“有对比、有门禁、有回滚”。必须同时观测新旧两组流量的质量指标和满意度，用统计显著性判断新模型是否真的更好；每阶段放量前都要过质量门禁，出问题要能秒级回滚。只切流量不做对比，等于盲人试菜。

为何常见：灰度的字面意思是“按比例分配流量”，初学者容易被这个表面动作迷惑，忽略了背后的评估与决策逻辑。

误区满意度都到 95% 了，模型肯定没问题，不用再盯着质量指标了。

正解用户评分和客观质量是两个信号。用户可能因为“出图快”给好评，却忽略图里的文字乱码；也可能因为操作流程繁琐给差评，与模型本身无关。正确做法是让满意度与清晰度、语义一致性、美学分等客观指标互相印证，两者长期背离才是真正的问题信号。

为何常见：满意度直观、贴近业务，容易让人一叶障目，忽略客观指标能发现的细粒度问题。

误区新模型离线效果更好，就应该马上全量上线，越快迭代越显效率。

正解生产环境里，稳定是演进的底座。跳过灰度直接全量，一次隐性 bug 就可能带来全网差评；在大促、节假日前夜发布新模型更是发布大忌。成熟的迭代节奏是“小步快跑 + 灰度门禁”，每次只前进一小步，用数据确认没有退步再继续——快，是稳出来的。

为何常见：离线评测指标好看会给人快速上线的冲动，但离线环境的 1% 提升，在线环境可能被 5% 的边缘 case 翻盘。

面试题

Q1. 图像生成管线上线后，最基础且首要监控的指标是？

单选题 · easy

A.服务器 CPU 核数
B.生成请求错误率← 正确答案
C.历史训练集大小
D.模型网络参数量

答案：B。请求错误率直接反映生成服务是否在正常工作，是判断“管线有没有挂”的第一信号。CPU 核数是运维资源指标而非管线健康指标；训练集大小和参数量属于离线训练阶段的概念，与线上监控无关。

Q2. 关于 P95 延迟的理解，下列说法正确的有？

多选题 · mid

A.表示 95% 的请求都会失败
B.表示最快 5% 请求的平均耗时
C.表示 95% 的请求能在该耗时内完成← 正确答案
D.平均延迟低 P95 也可能偏高← 正确答案

答案：CD。P95 延迟指 95% 的请求在某个耗时以内完成，因此 C 正确；平均延迟被多数快请求拉低，少量极慢请求会让 P95 明显偏高，因此 D 也正确。A 混淆了“延迟”与“失败率”，B 描述的是最快分位而非慢请求，均不正确。

Q3. 灰度发布新模型时，第一阶段的流量比例通常取多少？

单选题 · easy

A.百分之五← 正确答案
B.百分之五十
C.百分之八十
D.百分之百

答案：A。灰度讲究从小范围试错起步，5% 是业界常见初始值。50% 以上意味着新模型已承担主要流量，风险过高；100% 属于全量发布而非灰度。

Q4. 某灰度阶段新旧模型成功率分别为 90% 和 96%，则新模型的提升幅度约为？

单选题 · mid

A.提升 6.0%
B.提升 6.7%← 正确答案
C.提升 5.0%
D.提升 10.0%

答案：B。Lift =（96% − 90%）÷ 90% = 0.06 ÷ 0.9 ≈ 6.7%。注意提升幅度是相对旧版本的比值，不是绝对差值。

Q5. 关于综合质量分的权重设计，下列说法正确的是？

单选题 · mid

A.三个权重之和可以大于 1
B.权重与业务场景完全无关
C.权重和为 1 且按业务分配← 正确答案
D.三个权重必须平均分配

答案：C。加权平均要求权重之和为 1，且按业务优先级分配。电商海报更看重语义一致性与清晰度，艺术创作更看重美学分，平均分配反而无法体现业务差异。

Q6. 用户满意度降低但客观质量指标没有恶化，最可能的原因是什么？

单选题 · easy

A.模型已经完美无需处理
B.预期与实际效果有偏差← 正确答案
C.客观指标体系必定有误
D.满意度与业务价值无关

答案：B。满意度是主观体验，反映“是否符合预期”；客观质量分衡量图像本身。两者背离时应优先排查提示词理解偏差、产品交互流程等“预期管理”问题，而不是盲目重训模型。

Q7. 高峰期 QPS 为 500，单实例吞吐 50 QPS，冗余系数 1.5，最少需要部署多少实例？

单选题 · hard

A.需要 10 个实例
B.需要 15 个实例← 正确答案
C.需要 12 个实例
D.需要 20 个实例

答案：B。代入容量规划公式 N = ⌈500 × 1.5 ÷ 50⌉ = ⌈15⌉ = 15。容量规划需同时考虑峰值、单实例能力和冗余缓冲，并向上取整保证实例数够用。

Q8. 灰度期间发现新模型错误率 3% 明显高于旧模型的 1%，此时最合理的操作是？

单选题 · mid

A.立即全量上线
B.继续加大新流量
C.暂停灰度并回滚← 正确答案
D.忽略指标继续看

答案：C。灰度门禁的核心原则是“新版本指标不劣化才放量”。错误率明显恶化时应暂停灰度并触发回滚预案，先保住线上稳定，再排查问题，而不是继续放量扩大影响面。

Q9. 下列属于图像生成质量指标体系中客观评估维度的是？

多选题 · hard

A.图像清晰度← 正确答案
B.语义一致性← 正确答案
C.用户点踩率
D.美学评分← 正确答案

答案：ABD。清晰度、语义一致性、美学评分是三个经典自动评估维度，可由模型自动打分。用户点踩率属于用户反馈信号，属于主观反馈而非客观指标维度。

Q10. 关于模型迭代与灰度发布的协同配合，下列说法正确的有？

多选题 · extreme

A.灰度坏样本应回流为训练数据← 正确答案
B.离线通过即可直接全量上线
C.每个灰度阶段都需新旧对比← 正确答案
D.放量节奏可结合业务日历调整← 正确答案

答案：ACD。A 对，灰度期的失败样例是宝贵的训练数据；C 对，每个阶段都要跑新旧对比与质量门禁；D 对，放量节奏可结合业务日历调整，但需避开大促与节假日。B 错，离线评测只代表历史数据表现，必须经过线上灰度验证才能全量。