想象一家生意火爆的餐厅，主厨老王的手艺是招牌，但老板想试试新配方。直接换配方？万一老顾客不满意，损失惨重。于是老板想了个妙招：让新来的学徒小张在后厨角落，照着每一张真实订单悄悄做一份同样的菜——但小张做的菜绝不端上桌，只留给老王品尝、记进笔记本。顾客吃到嘴里的，永远是老王的手艺。一个月后，老板翻开笔记：小张的咸淡、火候、摆盘和老王出奇一致，这才放心让他掌勺。 这就是“影子部署”（Shadow Deployment）的精髓：新模型像后厨学徒，接收线上真实请求的“复制品”，但它的预测结果从不返回给用户，只悄悄写进日志，供团队离线比对。用户毫无感知，风险为零，而新模型却在真实流量下接受了最严苛的检验。这篇文章会带你认识影子部署的流量复制机制、结果比对方法、监控指标设计，以及它和 A/B 测试、金丝雀发布的区别与配合方式。

岗位关联

掌握影子部署，你就能在不打扰任何用户的前提下验证新模型实力，让模型上线从“心惊胆战”变成“胸有成竹”，这是 MLOps 工程师必备的零风险交付技能。

目录
  1. 可视化演示
  2. 影子部署核心
  3. 流量复制机制
  4. 结果比对方法
  5. 监控指标设计
  6. 与A/B测试区别
  7. 与金丝雀区别
  8. 上线决策流程
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

展示系统处理流水线、实时性能指标曲线及多方案对比分析，包含数据流转、吞吐延迟监控与方案评估。

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

系统可视化 处理流程：输入→处理→模型→输出 性能监控：实时指标 P=L×T

影子部署核心

老板给学徒小张的任务，是“照着订单做菜，但菜不许出后厨”。这套规矩听起来简单，却是影子部署的灵魂。新模型以“影子”身份挂在请求链路上，收到的是线上真实请求的副本，做出的预测却只写进日志，永远到不了用户面前。用户眼里，餐厅的招牌菜始终是老王的手艺——这就是零风险原理：不管影子模型犯多大的错，受伤的只有笔记本，不会伤到任何一个顾客。

把这个场景翻译成技术语言：线上流量先到 API 网关，网关把请求同时发给生产模型和影子模型。生产模型的预测作为正式响应返回用户，影子模型的预测被丢弃或写入日志。两条链路并行跑，但只有一条“出网”。影子模型因此能在真实数据分布下持续试运行，暴露那些离线测试发现不了的问题，比如线上特征的取值漂移、依赖服务的抖动、长尾样本上的离谱预测。

影子部署的本质，是把“验证模型质量”和“服务用户”彻底解耦。生产链路负责业务，影子链路负责考试——考试题目是真实的，但考试成绩不会泄露给考场外的任何人。

回到餐厅的场景：顾客拿到的永远是老王做的菜，小张的菜只存在于笔记本里。但正是这些“见不得光”的菜，决定了小张未来能不能掌勺。

Responseuser=Mprod(x),Logshadow←Mnew(x)\displaystyle \text{Response}_{\text{user}} = M_{\text{prod}}(x), \qquad \text{Log}_{\text{shadow}} \leftarrow M_{\text{new}}(x)
用户只能收到生产模型的结果，新模型的结果只会追加进日志，两条路互不交叉。
  1. 生产预测用户请求 $x$ 送入生产模型 $M_{\text{prod}}$，输出作为唯一响应返回，这是用户唯一能看到的答案。
    Responseuser=Mprod(x)\displaystyle \text{Response}_{\text{user}} = M_{\text{prod}}(x)
  2. 影子记录同一请求 $x$ 送入新模型 $M_{\text{new}}$，输出通过左箭头“写入”日志，而非返回用户。
    Logshadow←Mnew(x)\displaystyle \text{Log}_{\text{shadow}} \leftarrow M_{\text{new}}(x)

流量复制机制

为了让小张能练手，老板发明了“两联点菜单”：前台写好一张单子，一联送到老王灶台，另一联被复印机悄悄递给小张。菜单复制这件事，得做得足够快、足够隐蔽，绝不能影响前台接单的速度。流量复制机制，就是这个“复印机”。

在工程上，复制动作通常发生在网关或服务网格（Service Mesh）的 sidecar 层。网关收到一个线上请求后，除了把它路由给生产模型，还会按配置复制一份发给影子模型。影子链路与生产链路完全独立，影子请求的响应直接被吞掉，不参与用户返回。复制时还要带上同一个请求 ID，这样两份预测才能在事后“对得上号”。

为了避免影子链路把生产链路拖垮，复制常常配合采样策略：不一定每个请求都复制，而是按概率抽样，比如 10% 的流量复制给影子。采样率可以动态调整——刚开始跑用低采样率试水，确认稳定后再调高。复制机制还要保证一致性：原请求的 headers、body、时间戳都要原样复制，不能因为复制而篡改数据。

复印机虽然低调，却是整个影子模式的基石。没有可靠的复制机制，小张连“照着练”的机会都没有。

xtshadow={xt,ρt=1∅,ρt=0,ρt∼Bernoulli(p)\displaystyle x^{\text{shadow}}_t = \begin{cases} x_t, & \rho_t = 1 \\ \varnothing, & \rho_t = 0 \end{cases}, \qquad \rho_t \sim \text{Bernoulli}(p)
每个请求按概率 $p$ 被复制给影子模型，没被抽中的请求就跳过，这是控制资源成本的关键旋钮。
  1. 入站请求第 $t$ 个线上请求 $x_t$ 到达网关，它是真实用户产生的流量。
    xt\displaystyle x_t
  2. 采样开关$\rho_t$ 服从伯努利分布，以概率 $p$ 取 1，以 $1-p$ 取 0，决定是否复制。
    ρt∼Bernoulli(p)\displaystyle \rho_t \sim \text{Bernoulli}(p)
  3. 影子请求当 $\rho_t = 1$ 时复制出 $x^{\text{shadow}}_t$ 送进影子链路，否则记为空 $\varnothing$。
    xtshadow={xt,ρt=1∅,ρt=0\displaystyle x^{\text{shadow}}_t = \begin{cases} x_t, & \rho_t = 1 \\ \varnothing, & \rho_t = 0 \end{cases}

结果比对方法

笔记本上记满了小张做的菜。可光记没用，得比——把同一天同一张订单的两份菜放在一起，看咸淡是否一致、火候差多少、摆盘是否走样。比对方法的精髓，是“同一份订单、两个答案”。

技术上的第一步是请求对齐。影子日志里每一条记录都带着请求 ID，用这个 ID 把生产模型的预测和影子模型的预测配成一对。对齐之后，就能计算各种离线指标：分类任务可以看预测类别的一致率、混淆矩阵；回归任务可以看平均绝对偏差；排序任务可以看相关性系数。比对的目的不是追求两份预测一模一样——完全一致说明新模型没学到新东西，合理的一致率加上在有价值样本上的差异，才是好信号。

比对结果最终要落到决策阈值上。比如一致率高于 90% 且关键样本上偏差不超过 5%，才认为新模型“接得住”生产流量。阈值定得过严，好模型被误杀；定得过松，烂模型混上线。这个阈值通常由业务容忍度决定，也要参考历史上线案例。

老王尝了一口小张的菜，点了点头，又在本子上画了个勾。一千个“勾”加起来，就是小张上岗的底气。

Agreement=1N∑i=1N1(∣Mnew(xi)−Mprod(xi)∣<ε)\displaystyle \text{Agreement} = \frac{1}{N} \sum_{i=1}^{N} \mathbb{1}\left( \left| M_{\text{new}}(x_i) - M_{\text{prod}}(x_i) \right| < \varepsilon \right)
一致率 = 误差小于阈值 $\varepsilon$ 的样本占比，它衡量新模型与生产模型的“默契程度”。
  1. 逐条比较对同一请求 $x_i$，取新模型预测与生产模型预测的绝对差。
    ∣Mnew(xi)−Mprod(xi)∣\displaystyle \left| M_{\text{new}}(x_i) - M_{\text{prod}}(x_i) \right|
  2. 阈值判定$\mathbb{1}$ 是指示函数，括号内条件成立取 1，否则取 0——差值小于 $\varepsilon$ 记为一次“一致”。
    1(⋅)∈{0,1}\displaystyle \mathbb{1}(\cdot) \in \{0, 1\}
  3. 平均一致率把 $N$ 条影子样本的判定结果求和再取平均，得到直观的 0 到 1 之间的比例。
    1N∑i=1N1(⋅)\displaystyle \frac{1}{N} \sum_{i=1}^{N} \mathbb{1}(\cdot)

监控指标设计

比完菜还不够，老板还做了一张“品菜表”：咸度、火候、摆盘、出菜速度，每项打分。单项再好吃，出菜慢十分钟也得扣分。监控指标设计，就是为影子模式量身定制这样一张品菜表。

第一项是预测质量，即影子模型与生产模型的一致率、误差等离线评估指标，这是“好不好”的度量。第二项是性能开销，影子模型虽然不出网，但会消耗 CPU、内存和带宽——如果和生产模型共享资源池，影子请求可能拖慢线上响应，所以必须监控额外的延迟和资源占用率。第三项是特征漂移，用 PSI（群体稳定性指数）监控输入特征的分布是否随着时间偏移，特征漂移意味着模型赖以生存的数据环境变了。第四项是异常告警，比如影子链路超时率飙升、日志写入失败、影子服务崩溃，都需要及时报警。

这张品菜表可以用加权评分合成一个总分：质量占大头，性能与漂移各占一部分。分数超过阈值，说明影子模型“德智体美劳”全面发展，可以进入下一步。

品菜表上的每一项，都是小张未来掌勺的“质检报告”。指标设计得越周全，误判的概率就越低。

Score=w1⋅A+w2⋅(1−Δlatency)+w3⋅(1−PSI)\displaystyle \text{Score} = w_1 \cdot A + w_2 \cdot (1 - \Delta_{\text{latency}}) + w_3 \cdot (1 - \text{PSI})
综合评分 = 一致率加权 + 延迟惩罚加权 + 漂移惩罚加权，三个维度各占权重 $w_1, w_2, w_3$。
  1. 一致率项预测一致率 $A$ 越高，质量分越高，权重 $w_1$ 通常最大。
    w1⋅A\displaystyle w_1 \cdot A
  2. 延迟项$\Delta_{\text{latency}}$ 是影子带来的额外延迟，它越大，$1-\Delta_{\text{latency}}$ 越小，分数被扣。
    w2⋅(1−Δlatency)\displaystyle w_2 \cdot (1 - \Delta_{\text{latency}})
  3. 漂移项PSI 衡量特征分布漂移程度，PSI 越大说明环境变化越剧烈，该项分数越低。
    w3⋅(1−PSI)\displaystyle w_3 \cdot (1 - \text{PSI})
  4. 加权求和三项相加得到总分，与决策阈值比较。
    Score=w1A+w2(1−Δlatency)+w3(1−PSI)\displaystyle \text{Score} = w_1 A + w_2 (1 - \Delta_{\text{latency}}) + w_3 (1 - \text{PSI})

与A/B测试区别

有人问：A/B 测试不也是拿两个模型对比吗？影子部署和它到底差在哪？打个比方就清楚了。A/B 测试像是两支球队同时打正式比赛，各带一半观众——观众真的看到了两支球队的表现，他们的欢呼、嘘声、退场都是真实反馈。而影子部署是替补队员在训练场复刻比赛，观众从头到尾只看得到主力队。

这个比喻点破了最本质的区别：用户体验。A/B 测试把真实流量分流，一部分用户看到新版本，一部分用户看到旧版本，用户行为（点击、转化、留存）会被记录下来做统计检验。影子部署则复制流量，用户永远只看到生产版本，根本不会产生“针对新版本”的行为数据。因此 A/B 能回答“新模型能否带来业务收益”，影子只能回答“新模型输出质量是否达标”。

另一个区别是统计周期与置信结论。A/B 测试需要按效应量、显著性水平计算最小样本量，往往要跑一到两周才能下结论；影子部署随时可以启动和停止，它的结论是描述性的——新模型和生产模型到底差多少、差在哪，不需要等样本量凑够，但也给不出用户层面的置信结论。

影子是“摸底考试”，A/B 是“实战对抗”。摸底考得高分，才有资格上实战赛场。

n=2σ2(z1−α/2+z1−β)2Δ2\displaystyle n = \frac{2\sigma^2\left(z_{1-\alpha/2} + z_{1-\beta}\right)^2}{\Delta^2}
A/B 测试的最小样本量公式：波动越大、想检测的差异越小，需要的样本就越多，这也是它比影子部署“慢”的原因。
  1. 波动方差$\sigma^2$ 是指标的方差，业务指标越不稳定，需要的样本越多。
    σ2\displaystyle \sigma^2
  2. 显著性水平$z_{1-\alpha/2}$ 是标准正态分布的分位数，对应显著性水平 $\alpha$（通常 0.05）。
    z1−α/2\displaystyle z_{1-\alpha/2}
  3. 统计功效$z_{1-\beta}$ 对应检验功效 $1-\beta$，功效越高越能发现真实差异。
    z1−β\displaystyle z_{1-\beta}
  4. 最小提升$\Delta$ 是期望检测到的最小业务提升幅度，$\Delta$ 越小所需样本越大。
    Δ2\displaystyle \Delta^2

与金丝雀区别

金丝雀发布的名字来自煤矿里的金丝雀——矿工先放一只鸟进矿道，鸟还活着才敢下去。这个典故说明金丝雀发布是把新版本放到“有一点真实风险”的环境里试探：把 5%-10% 的真实流量切给新模型，让少量真实用户“试毒”，同时紧盯错误率，一旦异常立刻回滚。反观影子部署的小张，从头到尾都在后厨练手，根本没有顾客吃过他做的菜。

两者最直观的区别是风险等级。影子部署的风险是零——新结果不出网，无论影子模型多离谱，用户都无感；金丝雀发布的风险是“小但非零”——那 5% 的用户确实可能遇到新模型的错误，所以必须配套快速回滚机制和实时告警。第二个区别是两者能验证的东西：金丝雀能看到新模型在真实链路上的稳定性，包括真实用户请求的全链路表现；影子只能验证模型输出本身，拿不到用户反馈。

实际工程中，两者常常接力使用：影子部署先跑一两周，确认输出质量达标后启动金丝雀，把小比例流量切过去验证线上稳定性；金丝雀平稳运行后，再逐步放量到全量。影子负责“刷掉明显不行的”，金丝雀负责“考验真正能打的”。

煤矿里的金丝雀替人趟雷，后厨的小张替人练手——一个在真实险境里小赌，一个在后台零风险地大练。聪明的老板，两样都用。

Riskshadow=0,Riskcanary=ptraffic⋅Impact\displaystyle \text{Risk}_{\text{shadow}} = 0, \qquad \text{Risk}_{\text{canary}} = p_{\text{traffic}} \cdot \text{Impact}
影子部署风险恒为零；金丝雀的风险 = 放量比例 × 单次错误的影响，比例越大风险越高。
  1. 影子风险新模型结果不出网，用户影响恒为零，所以风险表达式等于 0。
    Riskshadow=0\displaystyle \text{Risk}_{\text{shadow}} = 0
  2. 金丝雀风险$p_{\text{traffic}}$ 是切给新模型的真实流量比例，$\text{Impact}$ 是单次错误造成的业务影响。
    Riskcanary=ptraffic⋅Impact\displaystyle \text{Risk}_{\text{canary}} = p_{\text{traffic}} \cdot \text{Impact}

上线决策流程

小张的品菜表连打三周满分，老板终于点头：先让他做两桌熟客的菜试试——这就是金丝雀；熟客纷纷夸好，才放心让他全权掌勺——这就是全量切换。影子部署不是终点，而是整条上线流水线的第一道闸门。

完整的决策流程分四步。第一步是准备环境：部署影子服务、配置流量复制、搭建日志存储和离线评估管道。第二步是灰度试跑：开启影子模式，按采样率复制真实流量，持续采集若干天，覆盖足够多的样本和业务时段。第三步是评估达标：跑完离线比对和监控指标评分，对照预设阈值判断是否放行；不达标就回头调模型、调阈值。第四步是正式切换：评估通过后先走金丝雀，小流量验证线上稳定性，再逐步放量到全量，切换后仍要继续监控一段时间，防止上线后出现离线没暴露的问题。

这套流程的本质，是给模型上线装上“双闸门”：影子闸门挡住质量不达标的，金丝雀闸门挡住线上不稳定的。两道闸门都打开，模型才被允许进入全量生产。

从影子到金丝雀再到全量，每一步都像在层层解锁：先证明“菜做对了”，再证明“上桌不出事”，最后才敢让新配方端到每一位顾客面前。

Go=1[(Score≥θ1)∧(Errcanary≤θ2)]\displaystyle \text{Go} = \mathbb{1}\left[ \left(\text{Score} \geq \theta_1\right) \wedge \left(\text{Err}_{\text{canary}} \leq \theta_2\right) \right]
上线信号 = 影子综合评分不低于阈值 且 金丝雀错误率不高于阈值，两个条件同时满足才放行。
  1. 影子达标影子模式跑完后，综合评分 $\text{Score}$ 必须达到质量阈值 $\theta_1$。
    Score≥θ1\displaystyle \text{Score} \geq \theta_1
  2. 金丝雀达标金丝雀阶段的实际错误率 $\text{Err}_{\text{canary}}$ 不能超过稳定阈值 $\theta_2$。
    Errcanary≤θ2\displaystyle \text{Err}_{\text{canary}} \leq \theta_2
  3. 逻辑与$\wedge$ 表示“且”，两个条件缺一不可。
    ∧\displaystyle \wedge
  4. 决策输出$\mathbb{1}$ 指示函数输出 1 表示上线，0 表示继续观察。
    Go∈{0,1}\displaystyle \text{Go} \in \{0, 1\}

AI 应用场景

电商推荐系统换模型

阶段：模型评估与上线验证

解决的问题：推荐算法升级最怕点击率下滑，直接影响营收。传统做法直接全量替换或盲目 A/B，要么风险大，要么成本高。影子部署让新排序模型在真实请求流下试跑，离线对比新旧模型的排序一致率，先筛掉明显更差的候选。

具体案例：某电商平台把新训练的推荐排序模型接入影子通道，跑了 2 周真实流量，发现新模型在长尾商品上的排序与生产模型分歧较大，团队据此针对性调优后才转入 A/B 测试，最终点击率提升 4%。

风控模型升级

阶段：模型上线前风险评估

解决的问题：反欺诈模型误杀会直接损伤正常用户，银行风控团队不敢贸然上线新评分卡。传统离线验证无法覆盖线上特征分布，影子部署让新评分卡在真实交易流量下跑分，离线对比逾期率、误杀率等关键指标。

具体案例：某银行风控团队把新评分卡挂影子模式 30 天，覆盖了完整的账单周期，发现新模型对特定客群误杀率偏高，调整阈值后再走金丝雀，最终在零客诉的前提下完成了模型升级。

大模型助手换底座

阶段：LLM 质量评估与灰度上线

解决的问题：给客服机器人换更强的 LLM 底座，最怕回答风格突变引发用户投诉。传统方式是人工评测集打分，但覆盖不了线上真实 prompt 的多样性。影子部署把线上真实用户问题复制给新底座，离线自动评估回答质量与一致性。

具体案例：某互联网公司客服机器人将新 LLM 接入影子通道，对 10 万条真实对话进行离线评估，发现新模型在复杂多轮对话上明显更优，但在简洁回复上过于啰嗦，团队加了风格约束后才转金丝雀放量。

Python 演示

python58 行
import randomimport time  def prod_model(x):    """生产模型：老规则，精度较低"""    return round(0.35 + 0.5 * x + random.uniform(-0.15, 0.15), 4)  def shadow_model(x):    """影子模型：新策略，精度较高"""    return round(0.30 + 0.6 * x + random.uniform(-0.05, 0.05), 4)  def serve_request(x, shadow_enabled=False, shadow_log=None):    """网关入口：生产结果返回用户，影子结果只写日志"""    t0 = time.perf_counter()    y_prod = prod_model(x)    latency = time.perf_counter() - t0    if shadow_enabled and shadow_log is not None:        y_new = shadow_model(x)        shadow_log.append({            "input": x,            "prod": y_prod,            "shadow": y_new,            "latency": round(latency, 6),        })    return y_prod  def compare(shadow_log):    """离线比对：计算一致率与平均偏差"""    if not shadow_log:        return 0.0, 0.0    agree = sum(        1 for r in shadow_log if abs(r["prod"] - r["shadow"]) < 0.05    ) / len(shadow_log)    avg_gap = sum(        abs(r["prod"] - r["shadow"]) for r in shadow_log    ) / len(shadow_log)    return round(agree, 3), round(avg_gap, 3)  def main():    shadow_log = []    for i in range(200):        x = i / 199        serve_request(x, shadow_enabled=True, shadow_log=shadow_log)    agree, avg_gap = compare(shadow_log)    print("影子日志条数:", len(shadow_log))    print("预测一致率:", agree)    print("平均偏差:", avg_gap)    verdict = "可进入金丝雀" if agree > 0.7 else "继续调优"    print("结论:", verdict)  if __name__ == "__main__":    main()
目的：模拟影子部署的完整链路——生产请求正常返回，影子请求写日志，最后离线比对给出上线结论。
  1. shadow_enabled and shadow_log is not None影子开关打开时才会复制请求给影子模型，对应网关的流量复制机制。
  2. serve_request(...)网关入口函数：无论是否开影子，用户拿到的都是生产模型结果。
  3. shadow_log.append(...)影子预测只追加到日志，绝不返回给调用方。
  4. abs(r["prod"] - r["shadow"]) < 0.05误差小于阈值的预测记为“一致”。
  5. round(agree, 3)保留三位小数，方便阅读一致率。
  6. verdict = "可进入金丝雀" if agree > 0.7 else "继续调优"决策阈值：一致率高于 0.7 才放行。

常见误区

误区我以为影子部署是 A/B 测试的一种，反正用户都没感觉，把流量分给两个模型跑就行。

正解影子部署不是 A/B。A/B 把真实流量分流，用户会真实看到新旧两个版本，并产生点击、转化等行为数据；影子部署是“复制”请求，新模型的结果根本不出网，用户只看到生产模型。影子测的是模型输出质量，A/B 测的是用户行为反馈，两者验证的对象完全不同。

为何常见：两者都涉及两个模型和流量分配，表面相似；不深入理解“结果是否出网”这一关键差异，就容易混为一谈。

误区影子模型的结果又不给用户，慢一点、多占点资源应该无所谓吧？

正解如果影子模型与生产模型共享同一批机器或网关资源，影子请求会挤占 CPU、内存和带宽，轻则让生产响应延迟上升，重则把整个服务拖垮。因此必须监控影子带来的额外延迟和资源开销，必要时用采样率限制影子流量的规模。

为何常见：只盯着“用户可见的结果”，忽略了基础设施资源共享带来的隐性风险。

误区影子部署就是把新旧预测存下来比一比谁准，能验证的东西很有限。

正解除了准确率，影子模式还能验证特征分布是否漂移（PSI）、依赖服务的稳定性、超时率、资源成本，甚至新模型在长尾样本上的表现。它本质是一个“真实流量压力测试场”，验证维度远比“谁预测得准”丰富。

为何常见：直觉上影子就是“偷偷跑一遍看结果”，容易低估它作为真实环境试验场的价值。

误区既然影子零风险，那影子验证通过就直接全量上线好了，不需要再搞金丝雀和 A/B。

正解影子拿不到任何真实用户行为反馈——用户压根没看到新结果，无法判断新模型是否带来业务收益。影子通过后仍需金丝雀验证线上稳定性，再用 A/B 验证业务指标，三者是接力关系，缺一环都会留下盲区。

为何常见：过度放大影子“零风险”的优势，忽略了它“无用户反馈”的天然局限。

误区影子数据是宝贝，所有请求的影子预测都该全量存下来，免得以后分析时缺数据。

正解高流量系统全量保存影子日志会引发存储爆炸和成本飙升。实践中常采用采样（如 10%-50%）加聚合统计，保留请求 ID、特征哈希、预测值等核心字段，就能覆盖绝大多数离线分析需求。

为何常见：数据焦虑——担心丢数据，却没算清存储成本与分析收益之间的平衡。

面试题

Q1. 影子部署中，影子模型生成的预测结果最终去向是？

单选题 · easy

  • A.直接返回给在线用户
  • B.写入日志离线比对← 正确答案
  • C.立刻覆盖生产结果
  • D.随机丢弃其中部分

答案：B。影子部署的核心是“复制请求、不出网”。影子模型的预测写入日志供离线比对，用户收到的永远是生产模型的结果。A 选项是 A/B 或金丝雀的行为，C 和 D 都改变了用户可见的结果，违背影子模式的定义。

Q2. 影子部署最大的核心优势是什么？

单选题 · easy

  • A.完全不干扰用户体验← 正确答案
  • B.能降低模型训练成本
  • C.可直接提升模型准确率
  • D.不需要任何额外资源

答案：A。影子部署最突出的优势是零风险——新模型结果不出网，用户毫无感知。它降低的是“验证”成本而非“训练”成本，本身不会提升准确率，而且需要额外的计算和存储资源，所以 B、C、D 都不对。

Q3. 影子验证通过后，下一步最合理的操作是？

单选题 · easy

  • A.先进金丝雀或A/B小流量验证← 正确答案
  • B.直接全量替换掉生产模型
  • C.暂停所有模型迭代工作
  • D.删除全部影子运行日志

答案：A。影子验证通过说明模型输出质量达标，下一步应进入金丝雀或 A/B 小流量验证，确认线上稳定性和用户行为收益。直接全量替换风险过高，暂停迭代或删除日志都不合理。

Q4. 流量复制时对请求做采样（如 10%）的主要目的是？

单选题 · mid

  • A.控制影子的计算开销← 正确答案
  • B.提高生产模型的精度
  • C.减少用户请求的数量
  • D.让A/B测试提前出结论

答案：A。影子请求会占用计算和存储资源，采样率是控制资源成本的关键手段。采样不改变生产模型的精度，也不减少真实用户请求，且与 A/B 测试的样本量计算无关，所以 B、C、D 都不是采样目的。

Q5. 影子部署与 A/B 测试最本质的区别是？

单选题 · mid

  • A.用户是否感知到新结果← 正确答案
  • B.模型训练数据是否相同
  • C.是否使用深度神经网络
  • D.是否运行在云服务器上

答案：A。A/B 测试将真实流量分流，用户能感知到不同版本并产生行为数据；影子部署复制请求，新结果不出网。最本质的区别就是“用户是否感知到新模型结果”。其余选项与两者的区别没有直接关系。

Q6. 影子部署与金丝雀发布相比，风险等级的区别是？

单选题 · mid

  • A.影子零影响金丝雀有影响← 正确答案
  • B.影子影响所有线上用户
  • C.金丝雀不影响任何用户
  • D.两者风险高低完全相同

答案：A。影子部署的结果不出网，风险为零；金丝雀把 5%-10% 的真实流量导向新模型，部分用户确实会遇到新结果，风险约为“流量比例 × 错误影响”。B、C、D 的描述都与事实相反。

Q7. 影子部署监控指标中，以下哪一项不属于常规监控维度？

单选题 · mid

  • A.预测结果的一致率
  • B.影子模型的延迟开销
  • C.输入特征分布漂移
  • D.用户活跃度的变化← 正确答案

答案：D。影子部署的监控维度包括预测一致率（质量）、延迟开销（性能）、特征分布漂移（环境变化）。用户活跃度是业务指标，用户根本没有看到影子结果，影子模式无法反映用户活跃度变化，所以 D 不在常规监控范围内。

Q8. 为什么影子部署无法直接衡量转化率等用户行为指标？

单选题 · hard

  • A.用户没看到影子结果故无行为反馈← 正确答案
  • B.影子模型没有使用真实的历史数据
  • C.转化率只能通过离线统计来计算
  • D.影子模型只部署在离线测试环境里

答案：A。影子模型的结果用户根本看不到，自然不可能产生点击、转化等针对该结果的行为反馈。A/B 测试之所以能衡量转化率，正是因为用户真实看到了对应版本。B、C、D 描述的数据、统计方式和环境都不构成根本原因。

Q9. 影子部署可以验证以下哪些指标？

多选题 · mid

  • A.模型预测结果一致率← 正确答案
  • B.模型额外资源开销← 正确答案
  • C.监控特征分布是否漂移← 正确答案
  • D.直接衡量用户点击转化率

答案：ABC。影子部署能验证预测一致率、额外资源开销、特征分布漂移等“模型侧”指标，这些都不依赖用户感知。用户点击转化率必须由真实用户看到结果才能产生，影子模式测不了，所以 D 不选。

Q10. 关于影子部署、金丝雀、A/B 的组合策略，说法正确的是？

多选题 · hard

  • A.影子通过后再小流量金丝雀← 正确答案
  • B.金丝雀出问题能快速回滚← 正确答案
  • C.影子部署可完全替代金丝雀
  • D.三者接力能降低上线风险← 正确答案

答案：ABD。影子验证“模型输出质量”，金丝雀验证“小流量稳定性与回滚能力”，A/B 验证“业务收益”，三者接力能从零风险一直验证到业务价值，降低整体上线风险。影子拿不到用户行为反馈，无法完全替代金丝雀，所以 C 错误。