大模型应用灰度发布的工程实践指南

CH-11-04-018·约 19 分钟·AI应用开发·更新 2026-08-11

云顶轩是城里最火的一家餐厅，招牌老火汤熬了十年，回头客就认这一口。有一天，主厨老陈端出一锅新配方——用智能算法优化过的汤底，据说更鲜、更养生。可老陈心里没底：万一客人觉得味道不对，砸了招牌怎么办？老板黄姐出了个主意：先别急着端上所有餐桌，先请一两桌熟客尝尝，观察他们的表情；觉得不错，再加到五桌、十桌；等到没人皱眉，才敢写进菜单全店推广。如果中途有客人变了脸，立刻撤下来，换回老汤。这个“小范围试菜、逐步加桌、随时撤菜”的过程，就是大模型应用里的灰度发布。AI 系统上新版本，和餐厅换汤底是一模一样的道理：代码写得再好，也无法预见线上所有真实情况，最稳妥的方式，就是让一小部分流量先走新版本，边观察边放量，平稳后再全量接管。

岗位关联

掌握灰度发布策略，是 LLM 应用从原型走向生产的必修课：它让每一次模型升级都能在可控风险下验证效果、保住用户体验，是算法工程师、MLOps 平台工程师与 SRE 的核心工程能力之一。

可视化演示
灰度发布概念
流量切分策略
A/B测试设计
效果监控指标
平滑切换机制
熔断止损机制
AI 应用场景
Python 演示
常见误区
面试题

可视化演示

动态演示大模型应用灰度发布的工程实践的核心机制，通过全局/局部/动态/静态四种模式展示关键概念与交互流程。

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

大模型应用灰度发布的工程实践：sLLM s1. LLM应用灰度发布总览 s2. 流量切分策略与灰度放量核心机制可视化大模型应用灰度发布的工程实践整体架构与关键组件

灰度发布概念

云顶轩的老火汤卖了十年，靠的是稳定的味道。主厨老陈研发了新配方，但谁也不敢保证三百位客人人人满意。黄姐的经验是：新菜绝不能一上来就写进菜单全店推广，而是先拿给一桌熟客试，再慢慢加桌——这就是灰度发布的直觉。它存在的根本原因，是“发布风险”无处不在：代码在测试环境跑得再顺，到了线上也会遇到千奇百怪的真实请求，一个没见过的输入格式、一次预料之外的并发高峰，都可能让新版本当场翻车。

翻车的代价有多大？看受影响的人数。一次全量发布把所有用户都暴露在风险里，就像把整店客人都押在一锅没试过的新汤上。灰度发布的思路恰恰相反：先让一部分用户试，稳住后再逐步扩大，每一步都把爆炸半径控制在最小。工程上常用的放量节奏，是 10% → 30% → 60% → 100% 这样几个台阶。每一个台阶之间留出观察窗口，等监控指标证明新版本和旧版本一样健康，才推进到下一档；任何一档出问题，都能立刻回滚，这就是“全量回滚保障”——后厨永远留着一口老汤灶。

整个过程可以用一张“放量时间表”来描述，用分段函数表示就是：

这张台阶表就是灰度发布的骨架：每一格台阶，都意味着一次“确认安全再前进”的承诺。但仅有骨架还不够——怎么把客人分到新桌？怎么判断客人满不满意？这就要靠后面的切分、监控和熔断来填肉。

p(t)=\begin{cases}10\%, & 0 \le t < t_1 \\ 30\%, & t_1 \le t < t_2 \\ 60\%, & t_2 \le t < t_3 \\ 100\%, & t \ge t_3\end{cases}

通俗说明：p(t) 表示 t 时刻新版本承接的流量比例。它就像餐厅的“加桌计划”——几点加几桌，白纸黑字写清楚，没到时间不提前。

阶段区间把发布时间轴切成 [0,t₁)、[t₁,t₂)、[t₂,t₃) 三个连续区间，每个区间就是一个灰度阶段。
$\displaystyle 0 \le t < t_1$
固定比例每个区间内新版本的流量占比固定不变，先稳住再求变。
$\displaystyle p(t)=10\%$
最终全量越过 t₃ 后，新版本承担 100% 流量，灰度完成，全量上线。
$\displaystyle p(t)=100\%$

流量切分策略

黄姐要加桌了，又遇到新麻烦：哪几桌客人先尝新汤？如果只挑熟客，新客会觉得被怠慢；如果随口乱指，又可能同一桌客人今天喝新汤、明天喝老汤，舌头都喝乱了。流量切分要解决的，正是“选谁进来”和“选了之后别变来变去”这两个问题。

最朴素的做法是给每位客人发号码牌：号码尾号是 0~9 的进新菜区。在系统里，这号码牌就是用户 ID 的哈希值。我们把用户 ID 扔进一个哈希函数，得到一个看似随机但始终固定的整数，再对 100 取模，就映射到 0~99 这 100 个桶里；桶号小于放量比例 p 的用户走新版本，其余走旧版本。这种方法的妙处在于：同一个用户的哈希值永远不变，所以他在整个灰度期间只会稳定地待在同一个版本里，不会被来回切换。

除了按用户比例切分，还可以按用户维度（地域、会员等级）、渠道维度（App、小程序、Web）切分，灰度期间也能动态调整权重——相当于黄姐随时可以喊一句“下一批再多加五桌”。但无论怎么切，号码牌的稳定性都不能破。公式如下：

号码牌一旦发出就不再更改，这正是灰度发布里“稳定性优先”的智慧——让客人安心，数据才可信。

g(u) = (h(u) \bmod 100) < p

h(u) 是用户 ID 的哈希值，g(u) 为真代表该用户进入新版本。要点在于：同一用户灰度期间只会稳定落在一个版本里，避免“同一桌客人两锅汤来回换”。

用户哈希将用户唯一标识（如会话 ID、手机号）代入哈希函数，得到一个分布均匀的整数。
$\displaystyle h(u)$
映射桶号对 100 取模，把用户均匀撒进 0~99 号桶，每个桶代表 1% 的流量。
$\displaystyle h(u) \bmod 100$
阈值比较桶号小于当前放量比例 p 就进新版本，否则留在旧版本；p 越大，新版本分到的客人越多。
$\displaystyle g(u) < p$

A/B测试设计

试菜试到一半，熟客们说新汤更鲜，也有几位老主顾说还是老汤对味。公说公有理，婆说婆有理，到底听谁的？黄姐的解决方法是：把客人随机分成两拨，一拨喝老汤、一拨喝新汤，分别记下续碗率、皱眉次数和餐后评分，让数据说话。这就是 A/B 测试——在 LLM 世界里，就是随机让两组用户分别使用旧模型和新模型，再比较关键指标。

A/B 测试的第一要义是“随机分组”：只有随机，才能让年龄、口味、饮食习惯等差异在两组间均匀分布，这样最后观测到的指标差异才能归因于汤的配方，而不是客人的喜好。第二要义是“并行进行”：两锅汤同时上桌，排除季节、心情等时间因素的干扰。第三，样本量要够：每组至少要积累到能分辨出差别的用户数，业界常用功效分析估算最小样本量；实验周期也别太短，一般要覆盖完整业务周期（比如一周）。

数据收齐后，新组好评率 52%，旧组 48%，这 4 个百分点是真的因为新汤好，还是纯属运气？统计学家用 z 检验回答这个问题：

老陈看完数据长舒一口气——新汤确实更能打。A/B 测试给了厨师“数据撑腰”的底气，也替老板挡住了“我觉得”“我听说”这类拍脑袋决策。灰度期间每次放量，其实都是一次规模更大的 A/B 验证。

\displaystyle z = \frac{\hat{p}_A - \hat{p}_B}{\sqrt{p(1-p)(\frac{1}{n_A}+\frac{1}{n_B})}}

z 值刻画的是“两组差异”相对于“随机波动”有多大。波动越小、样本越多，z 值越大；|z| 超过 1.96 时，我们就说差异在 95% 置信水平下统计显著。

组间差异分子是实验组与对照组观测指标之差，是我们关心的“信号”。
$\displaystyle \hat{p}_A - \hat{p}_B$
合并标准误分母综合两组样本量 n_A、n_B 和整体比例 p，估计随机波动的“噪声”大小。
$\displaystyle \sqrt{p(1-p)(\frac{1}{n_A}+\frac{1}{n_B})}$
显著性判断信号除以噪声得到 z 值，|z|>1.96 代表差异有 95% 把握不是偶然。
$\displaystyle |z| > 1.96$

效果监控指标

试菜阶段最怕什么？怕客人嘴上说“还行”，出门就发朋友圈说踩雷。光听好话不靠谱，黄姐定下铁规矩：每一桌都要记录续碗率、皱眉率、退菜率，还要翻看外卖平台的评价。这些数字，就是餐厅的“仪表盘”。

LLM 应用的仪表盘要看四类表针：一是性能，比如响应延迟和超时率，对应“上菜够不够快”；二是质量，比如回复是否跑题、格式是否规范，对应“汤好不好喝”；三是业务，比如点击率、转化率有没有涨，对应“客人有没有多花钱”；四是用户反馈，比如投诉率和满意度，对应“口碑有没有崩”。灰度期间，新旧版本要双份统计、逐项对比，任何一个指标显著恶化，都要立刻暂停放量。

以回复质量为例，我们可以请评估器（人工抽检或更强的模型当裁判）给每条回复打一个质量分 s_i，再求 N 条回复的平均分：

黄姐盯着那块监控大屏，就像盯着后厨的仪表盘：汤的咸淡、火候大小一目了然。指标的意义不在于数字本身，而在于它能在问题发酵成事故之前，提前举手喊停。

\displaystyle \bar{S} = \frac{1}{N}\sum_{i=1}^{N} s_i

平均质量分是新版本总体健康度的核心信号。训练时看的是损失曲线，上线后看的是这条质量分曲线——两者都是“这锅汤到底行不行”的读数。

单条评分对单次回复按预设标准（相关性、准确性、友好度等）打分。
$\displaystyle s_i$
整体均值把 N 条回复的质量分加起来取平均，得到版本级质量水平。
$\displaystyle \bar{S}=\frac{1}{N}\sum_{i=1}^{N} s_i$
对比告警新版本均分低于旧版本均分超过容忍度 δ 时触发告警，停止放量。
$\displaystyle \bar{S}_{\text{新}} < \bar{S}_{\text{旧}} - \delta$

平滑切换机制

新汤终于要大范围上桌了。可黄姐发现还有一道坎：老汤锅里一直煨着料，直接熄火换锅，高峰期可能供不上；更尴尬的是，有熟客喝到一半，突然发现汤味变了，以为自己点错了菜。切换这件事，讲究的是“无感”。

对应到系统里，就是平滑切换：新版本上线时，不能让用户感觉到服务中断、响应变慢或上下文断片。这需要三件套配合：一是模型版本管理，新老版本同时在线、可随时切换，就像两个灶台同时备着；二是缓存预热，新版本启动前先把常用请求的结果备好，避免冷启动慢得像新锅第一次烧水；三是会话连续性，同一个多轮对话必须始终由同一版本处理，不能上一句新模型答、下一句老模型答。

从流量角度看，平滑切换意味着新版本的权重不是一步跳满，而是沿 S 形曲线缓缓爬升。逻辑函数可以描述这个过渡：

客人边喝汤边聊天时，后厨已经悄悄完成了灶台交接。真正高级的发布就是这样：用户毫无感知，体验无缝过渡，新配方已经稳稳立住。

\displaystyle w_{\text{新}}(t) = \frac{1}{1 + e^{-k(t - t_0)}}

w_新(t) 是 t 时刻新版本承接流量的权重，t_0 是切换中点，k 控制切换快慢。曲线先慢后快再慢，给系统留足缓冲，像大火转小火那样一步步调。

过渡进度用当前时间 t 与切换中点 t_0 的差距衡量走到哪一步，差距越大进度越大。
$\displaystyle t - t_0$
权重映射把进度塞进逻辑函数，输出 0~1 之间的平滑权重，不会出现跳变。
$\displaystyle \frac{1}{1+e^{-k(t-t_0)}}$
斜率控制k 越大切换越陡、越快完成，但波动也越大；k 越小越平缓，适合高并发核心链路。
$\displaystyle k > 0$

熔断止损机制

最坏的情况最终还是来了。灰度放到 60% 时，监控大屏突然飘红：新版本异常率飙升，有客人投诉 AI 答非所问，还有人反馈响应卡死。黄姐当机立断：撤菜！后厨关掉新汤灶，所有流量无缝回到老汤。从发现到止血，不到五分钟。

手工撤菜太依赖人眼和手速，更稳妥的是让系统自己“闻到焦味就关火”——这就是自动熔断。系统用一个滑动窗口滚动统计最近几分钟内新版本的异常率，一旦超过阈值，立即把流量全部切回旧版本，同时拉起告警通知工程师。整个判断和切换都在秒级完成，不需要等任何人拍板。阈值定多少？要参考历史波动：定太低会频繁误伤，新版本永远放不出去；定太高又兜不住事，等于没装保险丝。

熔断逻辑可以用一个带阈值判定的状态机描述：

熔断只是保命，不是终点。撤菜之后，后厨要查清是食材问题还是做法问题，改好了重新试菜，再走一遍灰度。同样，工程师要复盘异常根因、修复问题、重新从 10% 灰度开始。有了熔断这道护栏，试菜失败最坏的结果也就是一桌客人多等几分钟——而不是整条街的口碑崩盘。

\displaystyle \text{熔断} = \begin{cases} 1, & E_{\text{5min}} > \theta_{\text{err}} \\ 0, & \text{其他} \end{cases}

最近 5 分钟异常率 E 超过阈值 θ 时输出 1，触发熔断；否则输出 0，继续放量。熔断不是终点，而是“快速回滚预案”自动启动的开关。

滑动窗口统计统计最近 5 分钟内新版本的异常请求占比，窗口不断向前滚动。
$\displaystyle E_{\text{5min}} = \frac{N_{\text{异常}}}{N_{\text{5min}}}$
阈值判定异常率超过预设阈值 θ 时判定为需要止损。
$\displaystyle E_{\text{5min}} > \theta_{\text{err}}$
切换动作熔断为 1 时全部流量切回旧版本，并触发告警与自动回滚预案。
$\displaystyle \text{流量} \to \text{旧版本}$

AI 应用场景

智能客服系统的新模型灰度升级

阶段：发布与上线（灰度放量）

解决的问题：传统客服系统换模型要么全量切换、出事故就是大范围舆情，要么长期双系统并行、成本翻倍。用灰度发布把新 LLM 客服先放在 10% 流量上，用真实用户请求验证回答质量，再逐步放量到全量，风险始终可控。

具体案例：某电商平台客服机器人从通用大模型切换到自研客服大模型时，按 10%→30%→60%→100% 四档灰度。灰度期间自动抽取新版本会话进行人工质检，三天后发现新模型在处理“退款时效”类问题上有 5% 的答非所问，立即熔断回滚，修复 prompt 后重新灰度，最终安全全量。

电商导购推荐的 A/B 验证

阶段：实验评估（A/B 测试）

解决的问题：推荐文案改版效果难以量化，凭感觉换文案常常“改了跟没改一样”，甚至悄悄伤害转化率。用 A/B 测试把用户随机分两组，新旧文案并行跑两周，用点击率、加购率等业务指标做显著性检验，让数据决定去留。

具体案例：某购物 App 用新模型重写“商品种草文案”，抽取 2% 用户做 A/B 测试。实验组加购率 6.2%、对照组 5.1%，z 值达到 2.3，确认显著提升后才放量到全量用户，单月加购量提升约 8%。

金融风控助手的熔断兜底

阶段：稳定性保障（熔断回滚）

解决的问题：金融场景对错误几乎零容忍，一句错误的理财建议就可能引发投诉甚至合规风险。自动熔断让系统在异常率超标的瞬间切回旧版本，把止损从“人发现再操作”的分钟级压缩到秒级。

具体案例：某银行微信客服助手引入大模型升级时，设置了双阈值熔断：异常率 > 2% 或 P95 延迟 > 3 秒即自动切回规则引擎。上线当天遭遇一次外部攻击导致并发暴涨，熔断在 40 秒内自动触发，全程无用户感知服务中断。

Python 演示

python84 行

"""LLM 灰度发布模拟器: 演示流量切分, 分阶段放量, 指标监控与自动熔断.""" GRAY_STAGES = [10, 30, 60, 100]STAGE_LIMIT = 200ERR_THRESHOLD = 0.15  def old_llm(prompt):    return "旧版本回复: " + prompt[-6:]  def new_llm(prompt):    return "新版本回复: " + prompt[-6:]  def broken_llm(prompt):    raise RuntimeError("新版本服务超时")  class GrayReleaseSimulator:    def __init__(self, old_model, new_model):        self.old_model = old_model        self.new_model = new_model        self.stage_idx = 0        self.stage_count = 0        self.metrics = {            "old": {"total": 0, "error": 0},            "new": {"total": 0, "error": 0},        }        self.breaker_open = False     def pick_group(self, user_id, new_ratio):        return "new" if hash(user_id) % 100 < new_ratio else "old"     def record(self, group, is_ok):        self.metrics[group]["total"] += 1        if not is_ok:            self.metrics[group]["error"] += 1     def check_breaker(self):        cur = self.metrics["new"]        if cur["total"] >= 50:            err_rate = cur["error"] / cur["total"]            if err_rate > ERR_THRESHOLD:                self.breaker_open = True                print("熔断触发: 新版本异常率 %.1f%% 高于阈值 %.0f%%" % (err_rate * 100, ERR_THRESHOLD * 100))     def invoke(self, user_id, prompt):        if self.breaker_open:            return self.old_model(prompt), "old(breaker)"        ratio = GRAY_STAGES[min(self.stage_idx, len(GRAY_STAGES) - 1)]        group = self.pick_group(user_id, ratio)        model = self.new_model if group == "new" else self.old_model        try:            reply = model(prompt)            self.record(group, True)            return reply, group        except RuntimeError:            self.record(group, False)            self.check_breaker()            return "抱歉, 服务暂时不可用", group     def advance_stage(self):        if self.stage_idx < len(GRAY_STAGES) - 1:            self.stage_idx += 1            print("灰度放量至 %d%%, 新版本流量占比提升" % GRAY_STAGES[self.stage_idx])     def run(self, users, prompts):        for uid, prompt in zip(users, prompts):            if self.breaker_open:                print("已熔断, 停止放量并回滚到旧版本")                break            self.invoke(uid, prompt)            self.stage_count += 1            if self.stage_count >= STAGE_LIMIT:                self.stage_count = 0                self.advance_stage()        if not self.breaker_open:            print("灰度完成: 新版本已全量接管流量")  if __name__ == "__main__":    sim = GrayReleaseSimulator(old_llm, broken_llm)    sim.run(range(2000), ["帮我推荐今天的菜品" for _ in range(2000)])

目的：模拟一个 LLM 应用从 10% 灰度到全量的完整过程，在遇到新版本持续报错时自动熔断并回滚。

GRAY_STAGES = [10, 30, 60, 100]定义灰度放量的四个台阶，相当于黄姐的“加桌计划”
self.metrics新旧两个分组分别记录请求总数与错误数，是监控指标的原始数据
def pick_group用用户 ID 哈希取模做流量切分，保证同一用户稳定落在同组
if hash(user_id) % 100 < new_ratio桶号小于当前放量比例就进新版本
def check_breaker新版本错误累计 50 次后计算异常率并判断是否熔断
err_rate > ERR_THRESHOLD异常率超过 15% 就打开熔断开关
def invoke每次请求按当前比例路由到新版本或旧版本
if self.breaker_open熔断一旦触发，所有后续请求一律走旧版本
def advance_stage每处理 200 个请求推进一档灰度
sim.run(range(2000), ...)模拟 2000 个真实用户依次发起请求

常见误区

误区灰度发布不就是先给一部分用户用新功能吗？把新功能放出来给少量人体验就完事了，重点是让他们“抢先试用”。

正解灰度发布的核心目的是用受控的、可观测的、可回退的方式验证新版本，而不是“尝鲜”。它要求流量切分、指标监控、熔断回滚三者配套，缺任何一个都只是“部分上线”，风险并没有被真正控制。就像试菜不是为了让熟客占便宜，而是为了确认新汤安全。

为何常见：从用户视角看，灰度确实表现为“一部分人先用到”，于是很容易把手段当成了目的。

误区灰度放量三天，新版本好评率比旧版本高了 3%，差异很明显，可以全量了。

正解样本量不足时，几个百分点的差异完全可能是随机波动。需要先估算最小样本量，再看 z 值或置信区间是否达到统计显著，同时排除节假日、大促等特殊时间干扰。差异“看起来有”和“统计上有”是两回事，就像一桌客人说好吃，不代表整条街都买账。

为何常见：人脑天然倾向于从少量观察中找规律，而对随机性缺乏直觉，总觉得“我亲眼看到的还能有假”。

误区新模型准确率比旧模型高，其他指标不用看了，直接放量就行。

正解LLM 应用在线上“变坏”的方式往往不在准确率上：可能是响应变慢、超时率升高、输出格式崩坏、业务转化率下降。准确率只是质量维度之一，性能、业务、用户反馈都要纳入灰度监控。准确率再高，如果延迟翻倍，用户照样流失——就像汤再鲜，上菜等一小时客人也会摔筷子。

为何常见：因为在离线模型评估阶段习惯只看质量分，忽略了线上工程和业务指标的复杂性。

误区发现异常后让运维手动把流量切回旧版本不就行了？反正团队人都在。

正解人工回滚有两个致命问题：一是人眼发现异常往往滞后于线上用户，二是手动操作需要时间，高峰期每多一秒都在放大损失。自动熔断用滑动窗口实时计算异常率，超过阈值立即切换，把止损时间从分钟级压缩到秒级。就像厨房装了烟雾报警器，而不是等厨师闻到焦味再跑过去关火。

为何常见：中小团队灰度频率低，容易低估“人工响应延迟”在故障中的放大效应。

面试题

Q1. 关于灰度发布的核心目的，下列说法正确的是？

单选题 · easy

A.让少数用户优先体验新功能
B.控制风险并逐步验证新版本← 正确答案
C.提升新版本的推理运行速度
D.减少模型的训练数据规模

答案：B。灰度发布是用逐步放量的方式控制发布风险、验证新版本稳定性，不是“尝鲜优先”，也与推理速度和训练数据无关。就像新汤先请一桌客人试，为的是确认安全性，而不是让熟客“占便宜”。

Q2. 流量切分把用户 ID 哈希后对 100 取模，目的是什么？

单选题 · easy

A.让用户分布更加集中在少数组
B.提升哈希函数的加密安全性
C.把用户映射到均匀的百个分桶← 正确答案
D.减少灰度发布时的运维成本

答案：C。对 100 取模是把哈希值映射到 0~99 的均匀桶号，再与放量比例比较，决定用户进入哪个版本。它并不提供加密能力，也不会让分布集中，更与运维成本无关。

Q3. 灰度发布进入全量的标志是什么？

单选题 · easy

A.所有流量都切到新版本且指标稳定← 正确答案
B.灰度阶段全部用户反馈良好无投诉
C.新版本模型训练损失降到了零点
D.新版本通过全部离线评测用例集

答案：A。全量的标志是流量 100% 切到新版本且线上指标稳定。用户反馈好、离线评测通过都只代表“截至目前没问题”，训练损失更是离线训练阶段的指标，与线上发布无关。

Q4. 设计一次规范的 A/B 测试，需要考虑哪些要素？

多选题 · mid

A.用户分组做到随机均匀分布← 正确答案
B.提前估算灰度所需样本量← 正确答案
C.严格控制实验运行的时间周期← 正确答案
D.同步调大新模型的参数量

答案：ABC。规范 A/B 测试的三要素是随机分组、样本量估算和实验周期控制。随机分组消除用户偏差，样本量保证统计功效，周期覆盖完整业务场景。模型参数量是离线开发阶段的事，与实验设计无关。

Q5. 灰度监控指标 P95 延迟的含义是什么？

单选题 · mid

A.最慢的百分之五请求的平均延迟
B.最快 95 条请求的延迟中位数
C.全部请求按延迟排序的第 95 百分位← 正确答案
D.每五分钟延迟的平均变化速率

答案：C。P95 延迟是所有请求延迟排序后位于 95% 位置的值，代表绝大多数用户的体验，同时剔除极端慢请求的干扰。如果 P95 翻倍，说明大部分用户已经明显感觉到变慢。

Q6. 熔断阈值设置得过低会导致什么？

单选题 · mid

A.新版本流量永远无法完成放量← 正确答案
B.用户投诉数量会持续快速升高
C.旧版本模型负载反而会变轻
D.监控系统会漏报全部真异常

答案：A。阈值过低会让偶发的、无代表性的小波动频繁触发熔断，新版本刚放一点流量就被切回，永远走不完灰度流程。阈值过高才会漏报真异常，因此要参考历史波动合理设阈。

Q7. 用户会话在灰度期间被反复切到不同版本，最可能导致什么？

单选题 · hard

A.多轮会话上下文丢失造成体验割裂← 正确答案
B.用户请求数量呈现指数级增长
C.新版本模型参数被重置失效
D.旧版本模型产生数据泄漏风险

答案：A。同一会话反复横跳，会让多轮对话的上下文（历史消息、记忆）在版本间丢失或错乱，用户会感觉“这 AI 忘了我刚才说的话”。因此灰度路由必须保证同一会话始终落在同一版本上。

Q8. 关于 z 检验结果 |z|>1.96 的正确解读是什么？

单选题 · extreme

A.新版本指标有 95% 的概率优于旧版
B.组间差异是统计显著而非偶然波动← 正确答案
C.实验数据已经满足最小样本量要求
D.新版本上线后必然带来业务增长

答案：B。|z|>1.96 表示在 5% 显著性水平下，组间差异不太可能由随机波动造成，即“统计显著”。它不直接等于“新版本 95% 概率更好”（那是贝叶斯解读），样本量是检验前的设计问题，业务增长更无法由单个检验保证。

Q9. 灰度发布期间应当重点监控哪些指标？

多选题 · mid

A.响应延迟与超时率指标← 正确答案
B.错误率与异常回复比例← 正确答案
C.用户投诉与满意度反馈← 正确答案
D.模型离线训练的总轮次

答案：ABC。灰度监控覆盖性能、质量、用户反馈三个核心层面：延迟超时是性能，错误率是质量，投诉满意度是口碑。训练轮次是离线开发阶段的参数，与线上发布无关。

Q10. 平滑切换新版本时通常需要做哪些准备？

多选题 · hard

A.提前预热缓存以降低冷启动延迟← 正确答案
B.保证同一会话路由到同一版本← 正确答案
C.保留旧版本用于快速回滚← 正确答案
D.立即删除旧版本的部署资源

答案：ABC。缓存预热解决冷启动、会话连续性保证多轮体验、保留旧版本是回滚的前提——这三件事共同支撑“无感切换”。删除旧版本资源等于拆掉退路，与平滑切换的初衷背道而驰。