假如你是一家生意红火的餐厅老板，厨师老王做了八年招牌菜，口碑一直很稳。这时来了一位新主厨小李，手艺了得、创意十足。你敢直接让小李明天就掌勺吗？当然不敢——万一客人觉得味道不对，招牌就砸了。聪明的做法是：让小李先在后台“影子试岗”——每天午市高峰，把每份真实订单复印一份交给小李，让他按同样的菜单做一道“影子菜”，老王照常出菜给客人。评审团在旁边记录小李的出品质量、出餐速度，跟老王的菜逐项对比。试岗一周，数据说话：小李确实更好，再正式上岗；若是翻车，立刻换回老王。这套“后台并行验证、前台不受影响、数据定胜负”的思路，就是 AI 领域的 影子测试（Shadow Testing）。 在本篇中，你会看到影子测试如何帮你在上线新模型之前“复印订单”（流量镜像）、“保留评审记录”（结果存储）、“量化评菜标准”（指标对比）、“排除运气成分”（统计检验），最后建立一道安全的“上岗闸门”（发布与回退）。学会它，你就能像稳重的餐厅老板一样，让每一次模型迭代都有惊无险。

岗位关联

影子测试是 AI 模型迭代上线前的“安全气囊”：它能用线上真实流量在后台验证新模型效果，避免有问题的模型直接上线造成事故。掌握它，是 AI 工程师走向可靠交付的必修课。

目录
  1. 可视化演示
  2. 核心原理
  3. 流量镜像
  4. 结果存储
  5. 指标对比
  6. 显著检验
  7. 发布回退
  8. AI 应用场景
  9. Python 演示
  10. 常见误区
  11. 面试题

可视化演示

动态演示影子测试并行验证模型效果的方的核心机制，通过采集/分析/决策/反馈四种模式展示关键概念与交互流程。

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

影子测试并行验证模型效果的方：Shad Shadow Testing核 流量镜像实现方式与技术架构设计 核心机制可视化 影子测试并行验证模型效果的方整体架构与关键组件

核心原理

餐厅老板最怕的，就是新主厨第一次正式掌勺就翻车。聪明的做法不是直接让小李上岗，也不是赌运气，而是先安排一场“影子试岗”：把经营日的真实订单复制一份给小李练手，但客人的菜仍然由老王做。这样试岗既不打扰顾客，又能真实检验小李的水平。影子测试的原理正是如此——把线上进来的真实请求复制一份，让一个新模型在后台同步处理，旧模型继续服务用户，两者各自产出结果，事后对比。

这套流程在技术上分为四步：复制流量、并行推理、结果落库、对比评估。旧模型的输出决定用户体验，新模型的输出只进入验证通道。关键点在于“复制”，而不是“切换”——用户完全感知不到新模型的存在，这正是影子测试区别于 A/B 测试的地方。A/B 测试是真实地把一部分用户分流到新模型，影子测试则是“影子”只在后台跑，任何异常都不会波及线上用户。

用数学语言描述这个对比决策，就是看新旧两个模型在同一批请求上的效果差：

回到餐厅场景：评审团每天记录小李和老王在同一批订单上的“出品合格率”，一周下来用数据说话。影子测试也是这样，用同源请求、同标尺衡量新旧模型，让每一次模型决策都有据可依，而不是拍脑袋。

Δ=Mnew−Mold\displaystyle \Delta = M_{new} - M_{old}
$\Delta$ 表示新模型相对旧模型的指标增量。若 $\Delta$ 显著大于 0，说明新模型值得考虑上线；若小于 0，则说明存在回退风险。
  1. $M_{new}$新模型（影子模型）在镜像请求上计算出的指标值，比如准确率、成功率。
    Mnew\displaystyle M_{new}
  2. $M_{old}$旧模型（线上模型）在同批请求上的指标值，它是对比的基准线。
    Mold\displaystyle M_{old}
  3. 差值 $\Delta$两者之差。正数代表新模型更好，负数代表新模型更差；差值的绝对值越大，说明两个模型的效果差异越明显。
    Δ=Mnew−Mold\displaystyle \Delta = M_{new} - M_{old}

流量镜像

订单复印件是怎么到小李手里的？餐厅的传菜口装了一台神奇的“复印机”——每张堂食单经过时，机器自动打出一份一模一样的副本，一份照常进厨房给老王，另一份送到后台给小李。在 AI 系统里，这台“复印机”就是流量镜像（Traffic Mirroring），通常部署在网关或代理层。

具体实现上，网关收到线上请求后，把请求内容复制一份，转发给影子模型所在的服务，同时原请求继续走正常链路。复制过程要注意几点：第一，影子请求必须与线上请求具有相同的业务参数，否则对比不公平；第二，复制动作不能阻塞线上请求，影子请求要异步发送，哪怕影子服务崩溃也不能影响主链路；第三，要有标签标识，在请求头上打上 shadow: true，方便下游识别这是影子流量。

生产环境流量很大，不可能每个请求都复制，所以需要采样控制。按比例采样是最常见的做法：

传菜口的复印机也有一本“复印比例”旋钮：高峰时复印三成，避免后厨忙不过来；平峰时复印全部，多积累样本。流量镜像的采样控制也是同样的道理——既要喂饱评估，又不能压垮影子服务，更不能拖累线上。

rs=nsampledntotal\displaystyle r_s = \frac{n_{sampled}}{n_{total}}
$r_s$ 是采样率，表示实际复制了多少比例的线上请求给影子模型。采样率越高，评估越准，但资源消耗也越大，需要权衡。
  1. $n_{sampled}$被复制到影子模型的请求数量。
    nsampled\displaystyle n_{sampled}
  2. $n_{total}$线上请求的总数量。
    ntotal\displaystyle n_{total}
  3. 比值 $r_s$采样率。开 10% 的采样率意味着每 10 个请求复制 1 个。通常从低采样率开始，确认影子链路稳定后再逐步调高。
    rs=nsampledntotal\displaystyle r_s = \frac{n_{sampled}}{n_{total}}

结果存储

评审团不能光靠嘴记，需要一本专门的“评审记录本”:小李做的每一道影子菜，从色泽、口味到出餐时间都要记下来，还要和对应的订单复印件钉在一起，方便周末复盘。AI 系统的影子测试也一样，影子模型的每一次输出都必须落库存储，否则无从对比。

结果存储方案的核心问题是：存什么、存哪、怎么关联。存什么？除了影子模型的输出，还要存输入请求的关键字段、模型版本号、推理耗时、置信度等元信息。存哪？常见选择有数据仓库（如 Hive、ClickHouse）、对象存储（如 S3）或消息队列（如 Kafka）。怎么关联？影子输出必须能通过请求 ID + 时间戳回溯到对应的线上请求，才能把新旧结果一一配对比较。

存储环节容易踩坑的是数据完整性问题：如果影子服务处理过程中发生超时或崩溃，部分结果会缺失，导致对比样本不完整。因此要监控落库成功率：

评审记录本如果丢了记录，这周的试岗就白干了。结果存储就是影子测试的“记录本”，只有数据完整、关联清晰，后面的指标对比和统计检验才有意义。数据安全也要跟上——这些记录里可能包含用户敏感信息，存储时要做好脱敏和访问控制。

I=NwrittenNshadow×100%\displaystyle I = \frac{N_{written}}{N_{shadow}} \times 100\%
$I$ 是结果落库完整率，表示影子请求中有多大比例成功写入了存储。完整率过低时，对比结果会有偏，需要排查链路故障。
  1. $N_{written}$成功写入存储的影子请求结果数量。
    Nwritten\displaystyle N_{written}
  2. $N_{shadow}$影子模型实际接收到的请求总数量。
    Nshadow\displaystyle N_{shadow}
  3. 百分比 $I$落库完整率。理想情况接近 100；如果低于 95%，就要检查存储写入链路、超时配置或服务稳定性。
    I=NwrittenNshadow×100%\displaystyle I = \frac{N_{written}}{N_{shadow}} \times 100\%

指标对比

评审记录本攒了一周，怎么判断小李到底行不行？老板定了几条硬标准：菜品的口味一致率、出餐时间、顾客好评率。每条标准都有明确的数值定义，比如“口味一致率要 ≥ 95%”。AI 系统的指标对比也是同理，需要定义统一的评估指标，才能量出新旧模型的差距。

指标分两类。离线指标：基于历史标注数据计算，如准确率、精确率、召回率、F1 值，适合在影子结果落库后快速计算。在线指标：来自真实业务反馈，如请求成功率、响应延迟、用户点击率、转化率，更适合衡量真实体验。影子测试的独特价值在于，它用在线真实请求驱动，所以能同时拿到离线指标所需的预测结果和在线业务指标。

计算指标差异时，用相对变化率比绝对差值更直观，因为它消除了指标本身量纲的影响：

老板定的“口味一致率 ≥ 95%”就是阈值设定。阈值不能拍脑袋：定太高，新模型永远上不了线；定太低，滥竽充数的也混进来了。指标对比这一步，就是在数据与决策之间搭一座桥，让“好不好”变成“好多少”。

reldiff=Mnew−MoldMold×100%\displaystyle \text{reldiff} = \frac{M_{new} - M_{old}}{M_{old}} \times 100\%
$\text{reldiff}$ 是新模型相对旧模型指标提升的百分比。阈值通常由业务方预先设定，比如“相对提升 ≥ 2% 才允许上线”。
  1. 分子 $M_{new} - M_{old}$新模型与旧模型指标的实际差距。
    Mnew−Mold\displaystyle M_{new} - M_{old}
  2. 分母 $M_{old}$以旧模型为基准，消除指标本身的尺度影响。
    Mold\displaystyle M_{old}
  3. 乘 $100\%$把比值换算成百分比。比如准确率从 80% 提升到 82%，相对变化率就是 $2.5\%$。
    Mnew−MoldMold×100%\displaystyle \frac{M_{new} - M_{old}}{M_{old}} \times 100\%

显著检验

小李试岗第三天，有两道菜做得特别惊艳，评审团一阵欢呼——但老板冷静地说：“再等等，不能因为两天的表现就下结论，万一是运气呢？” 这正是统计显著检验的核心思想：区别“真实差异”与“随机波动”。影子测试中，新模型效果看起来更好，可能是模型真的更优，也可能只是这批请求恰好更“照顾”新模型。

显著检验的常用工具是比例 z 检验。对于影子测试这种“新旧模型在同一批请求上各跑一遍”的场景，我们可以把两个模型各自处理成功的比例（如请求成功率、预测正确率）拿出来比较：

老板说“再看一周”，本质上就是在等样本量足够大、让 z 检验的结论稳定下来。样本量不足时，再大的差异也可能是噪声；样本量足够时，微小的真实差异也能被发现。统计检验就是给“运气”划了一道清晰的警戒线。

z=pnew−poldppool(1−ppool)(1nold+1nnew)\displaystyle z = \frac{p_{new} - p_{old}}{\sqrt{p_{pool}(1-p_{pool})\left(\frac{1}{n_{old}}+\frac{1}{n_{new}}\right)}}
$z$ 值反映两个比例差异的显著程度。$|z|$ 越大，说明差异是真实存在的可能性越高；通常 $|z| > 1.96$ 时，我们认为差异在 95% 置信水平下显著。
  1. $p_{new}$ 与 $p_{old}$新旧模型各自的成功率或正确率。分母的平方根是“两个比例之差”的标准误差。
    ppool=xold+xnewnold+nnew\displaystyle p_{pool} = \frac{x_{old}+x_{new}}{n_{old}+n_{new}}
  2. $p_{pool}$合并成功率，把新旧模型的数据合在一起估算总体成功率，用于计算标准误差，比单独估算更稳定。
    ppool(1−ppool)\displaystyle p_{pool}(1-p_{pool})
  3. $\frac{1}{n_{old}}+\frac{1}{n_{new}}$样本量倒数之和。样本量越大，这一项越小，标准误差越小，差异越容易被检测出来。
    ppool(1−ppool)(1nold+1nnew)\displaystyle \sqrt{p_{pool}(1-p_{pool})\left(\frac{1}{n_{old}}+\frac{1}{n_{new}}\right)}
  4. 整体比值 $z$差异除以标准误差，相当于“差异相当于几个标准误差”。超过临界值，就认为新模型不是靠运气赢的。
    z=pnew−poldppool(1−ppool)(1nold+1nnew)\displaystyle z = \frac{p_{new} - p_{old}}{\sqrt{p_{pool}(1-p_{pool})\left(\frac{1}{n_{old}}+\frac{1}{n_{new}}\right)}}

发布回退

试岗两周后，评审数据汇总：小李的出品合格率稳定超过老王，口味一致率达到 97%（阈值 95%），出餐速度持平。老板满意地点头：“通过，明天正式上岗！”——这是发布门禁。但老板手里还握着另一张底牌：如果小李上岗后头两天连续出现客人投诉，立刻让老王回来顶班。这就是自动回退。

在 AI 工程实践中，门禁与回退是一对“双保险”。发布门禁确保只有达到标准的模型才能上线，它通常是一个自动化的检查流程：指标达标 → 人工确认 → 灰度放量。自动回退则持续监控线上表现，一旦新模型的关键指标跌过警戒线，系统自动切回旧模型，无需人工干预。

回退条件的设定要科学，不能“一有波动就回退”，否则会频繁抖动。常见做法是：连续多个观测窗口内指标显著差于阈值 + 样本量达到最小要求，两者同时满足才触发回退：

餐厅的“底牌”和 AI 系统的“回退”本质相同：给决策留一条退路。发布门禁是“进”的规矩，自动回退是“退”的保障，两者结合才能让模型发布过程安全可控。真正成熟的团队还会用灰度发布做缓冲——先放 5% 流量，观察无异常再逐步放量，把风险压缩到最小。

rollback if Δˉ≤−ε\displaystyle \text{rollback if } \bar{\Delta} \leq -\varepsilon
$\bar{\Delta}$ 是最近多个窗口的平均指标差，$\varepsilon$ 是容忍阈值。只有当平均差持续跌破 $-\varepsilon$ 且样本足够时，才认为新模型确实有问题。
  1. $\bar{\Delta}$最近 k 个时间窗口的平均指标差，平滑掉单次抖动。
    Δˉ=1k∑i=1kΔi\displaystyle \bar{\Delta} = \frac{1}{k}\sum_{i=1}^{k}\Delta_i
  2. $\varepsilon$容忍阈值，业务上可接受的性能回退上限。比如成功率允许下跌不超过 0.5%。
    ε\displaystyle \varepsilon
  3. 触发条件 $\bar{\Delta} \leq -\varepsilon$平均差跌破负阈值，触发自动回退。
    rollback if Δˉ≤−ε\displaystyle \text{rollback if } \bar{\Delta} \leq -\varepsilon

AI 应用场景

智能客服模型升级前的影子验证

阶段：模型验证与发布

解决的问题：客服机器人直接升级新对话模型，可能因回答风格突变或意图识别回退，导致用户大量转人工、投诉率上升。传统做法是离线评测，但离线数据无法反映真实用户的提问分布。影子测试用线上真实对话请求驱动新模型，在不影响用户的前提下提前发现“新模型对某类问题明显变差”的风险。

具体案例：某银行智能客服要升级对话模型。运维团队在网关层开启 20% 流量镜像，新模型在后台并行处理 1 万条真实对话后，发现“信用卡挂失”相关意图的准确率从 92% 跌到 81%，触发告警，团队决定暂缓上线。经过数据排查修复后再次影子验证，达标才发布。

电商推荐系统的推荐效果回归测试

阶段：模型迭代与回归测试

解决的问题：推荐模型迭代频繁，每次改动都可能让部分用户群体体验下降。直接上线再做 A/B 测试成本高、风险大。影子测试可以在全量流量上并行跑新旧两个推荐模型，离线计算 CTR、覆盖率等指标，先筛掉明显回退的版本。

具体案例：某电商平台每次大促前会迭代推荐模型，团队搭建了影子测试流水线：把线上请求复制一份给候选模型，结果存入数据仓库，每日定时计算新旧模型的 AUC、CTR 和延迟分位数。某次候选模型 AUC 提升 0.02，但 P99 延迟从 120ms 涨到 480ms，因延迟超阈值被门禁拦截，避免了上线后核心链路超时事故。

Python 演示

python57 行
import mathimport random  def simulate_model(acc, n, seed):    """模拟一个模型处理 n 条请求，acc 为真实成功率"""    rng = random.Random(seed)    return sum(1 for _ in range(n) if rng.random() < acc)  class ShadowTest:    """影子测试结果的差异计算与显著性检验"""     def __init__(self, ok_old, n_old, ok_new, n_new):        self.ok_old = ok_old        self.n_old = n_old        self.ok_new = ok_new        self.n_new = n_new     @property    def p_old(self):        return self.ok_old / self.n_old     @property    def p_new(self):        return self.ok_new / self.n_new     def rel_diff(self):        """相对变化率：新模型相对旧模型的提升百分比"""        return (self.p_new - self.p_old) / self.p_old * 100     def z_score(self):        """比例 z 检验：判断差异是否显著"""        p_pool = (self.ok_old + self.ok_new) / (self.n_old + self.n_new)        se = math.sqrt(p_pool * (1 - p_pool) * (1 / self.n_old + 1 / self.n_new))        return (self.p_new - self.p_old) / se  def main():    random.seed(42)    n = 1500    ok_old = simulate_model(0.70, n, 1)    ok_new = simulate_model(0.86, n, 2)    test = ShadowTest(ok_old, n, ok_new, n)    print(f"旧模型成功率: {test.p_old:.3f}")    print(f"新模型成功率: {test.p_new:.3f}")    print(f"相对变化率: {test.rel_diff():.2f}%")    z = test.z_score()    print(f"z 值: {z:.3f}")    if z > 1.96:        print("结论: 差异显著，新模型可以准备发布")    else:        print("结论: 差异不显著，需要更多样本")  if __name__ == "__main__":    main()
目的：完整模拟影子测试的核心环节——用同一批真实请求分别驱动新旧模型，计算成功率差异并做 z 检验，判断新模型是否显著优于旧模型。
  1. simulate_model(acc, n, seed)用固定随机种子模拟模型处理请求的过程，确保实验结果可复现。
  2. class ShadowTest封装影子测试的样本数据，提供差异计算与显著性检验两个核心能力。
  3. rel_diff()返回新模型相对旧模型的提升百分比，对应正文中指标对比的相对变化率公式。
  4. z_score()实现比例 z 检验，先算合并成功率 p_pool，再算标准误差，最后得到差异的显著程度。
  5. if z > 1.96判断差异是否在 95% 置信水平上显著，显著才允许准备发布。
  6. if __name__ == "__main__"提供可执行入口，保证脚本可以直接运行。

常见误区

误区很多初学者以为影子测试要把每个请求都复制一份，影子模型还要同步等待结果，线上延迟肯定会被拖垮。

正解正好相反。影子流量是异步复制的：线上请求照常返回给用户，影子请求在后台独立执行，甚至可以通过采样率控制规模。影子服务即使崩溃、超时，也不影响线上响应。真实的风险不在线上延迟，而在资源消耗——影子模型会白白吃掉 CPU 和内存，所以要控制采样率、做好服务隔离。

为何常见：人们容易把“并行处理”理解成“同步等待”，忽略了异步镜像这个关键设计。

误区影子环境里新模型准确率 92%，旧模型只有 85%，那还等什么？直接全量上线！

正解影子测试只是发布流程的第一道关卡，只能说明“在后台跑没问题”，不能保证在真实流量、真实负载下也表现稳定。上线前还需要走发布门禁、灰度发布，逐步放量观察在线指标。影子测试再充分，也不能替代灰度对真实用户体验的验证。

为何常见：看到离线数据漂亮就容易冲动，忽略了“后台表现”与“实际生产环境”之间的鸿沟。

误区两者不都是新旧模型对比吗？把影子测试当成 A/B 测试的低配版，觉得可以互相替代。

正解这是两类完全不同的实验。A/B 测试把用户真实分流，一部分用户使用新模型，用户能感知到变化，适合验证业务因果效应；影子测试不让用户感知任何变化，新模型只在后台“陪跑”，适合验证模型本身的能力和安全性。影子测试通常跑在 A/B 测试之前，作为风险排查工具。

为何常见：两者都有“对比新旧模型”的表象，但它们在流量处理方式和用户感知层面有本质区别。

误区攒了一百万条影子请求，结论肯定是对的，不用做什么显著性检验了。

正解样本量大不等于差异可信。首先，影子请求可能存在系统性偏差，比如特定时段流量占比过高；其次，即使样本量大，差异也可能小到没有业务意义。正确的姿势是：先保证样本分布均匀，再用 z 检验或置信区间评估差异的显著性，最后看差异幅度是否超过业务阈值。

为何常见：直觉上“量变引起质变”，但统计上样本的代表性和独立性比数量更重要。

面试题

Q1. 影子测试的核心特征是什么？

单选题 · easy

  • A.将用户真实分流到新模型
  • B.后台并行验证新旧模型← 正确答案
  • C.离线回放历史数据测试
  • D.用规则引擎检查模型输出

答案：B。影子测试的核心是把线上真实请求复制一份给新模型，新旧模型在后台并行处理，用户无感知，所以选 B。A 是 A/B 测试的做法；C 是离线评测；D 不属于影子测试范畴。

Q2. 影子测试中新模型使用的输入数据来源是？

单选题 · easy

  • A.用户直接提交的实时请求
  • B.线上流量镜像得到的数据← 正确答案
  • C.人工构造的合成测试数据
  • D.历史标注好的离线数据集

答案：B。影子测试的价值就在于用线上真实流量验证模型，而非合成或历史数据。这些流量通过镜像从网关复制而来，与线上请求完全同源，所以选 B。

Q3. 控制影子测试资源开销最直接的手段是？

单选题 · easy

  • A.减少模型参数量
  • B.降低流量采样率← 正确答案
  • C.增加服务器数量
  • D.缩短请求超时时间

答案：B。采样率决定复制多少比例的线上请求给影子模型，采样率越低，影子模型的资源消耗越小，是最直接的成本控制手段。A 是模型优化，C 是扩容，D 会影响测试完整性。

Q4. 影子模型的处理结果需要落库的最主要原因是什么？

单选题 · mid

  • A.防止影子服务崩溃丢数据
  • B.以便后续离线分析对比← 正确答案
  • C.满足监管部门合规要求
  • D.给线上请求做数据备份

答案：B。影子结果只有落库保存，才能与线上旧模型的结果进行离线指标计算、显著性检验和人工复盘。B 是落库的核心诉求。A 是落库需要解决的一个问题而非目的；C 因业务而异非通用原因；D 混淆了影子数据与线上数据备份。

Q5. 相对变化率 $\text{reldiff} = \frac{M_{new} - M_{old}}{M_{old}}$ 表示什么？

单选题 · mid

  • A.新模型相对旧模型的绝对差值
  • B.新模型相对旧模型的提升比例← 正确答案
  • C.旧模型相对新模型的提升比例
  • D.新旧模型指标的平均变化量

答案：B。reldiff 以旧模型指标为基准，计算新模型指标的相对提升百分比。例如准确率从 0.80 升至 0.82，reldiff 就是 2.5%。A 说的是绝对差值，C 分子分母颠倒了，D 需要求平均，含义均不符。

Q6. 影子测试中用于关联新旧结果的核心字段是？

单选题 · mid

  • A.模型名字与版本号
  • B.请求 ID 与时间戳← 正确答案
  • C.用户 ID 与设备型号
  • D.输出结果的置信度

答案：B。只有通过唯一的请求 ID 配合时间戳，才能把影子结果与线上结果准确配对，实现一对一的指标对比。A 只能区分模型不能关联请求；C 粒度太粗，一个用户会发很多请求；D 是结果内容而非关联依据。

Q7. 影子测试发现新模型准确率提升 1.2%，但 z 值只有 1.2，最合理的解释是？

单选题 · hard

  • A.新模型确实显著优于旧模型
  • B.差异可能是随机波动导致的← 正确答案
  • C.样本量一定不够大造成的
  • D.旧模型效果出现了明显回退

答案：B。z 值 1.2 小于临界值 1.96，说明差异在 95% 置信水平下不显著，可能是随机波动。A 需要显著的 z 值支撑；C “一定”太绝对，样本量不足时 z 值通常也会变小，但不能仅凭 z 值断定样本量大小；D 与题干方向相反。

Q8. 影子测试相比 A/B 测试的优势有哪些？

多选题 · mid

  • A.用户对实验完全无感知← 正确答案
  • B.可以真实衡量业务转化效果
  • C.新模型出问题不影响线上← 正确答案
  • D.能预先发现模型回退风险← 正确答案

答案：ACD。影子测试不影响用户体验（A），新模型在后台运行，异常不会波及线上（C），天然适合做上线前的风险排查（D）。B 是 A/B 测试的优势——真实分流才能衡量业务因果效应，影子测试的后台模拟做不到这一点。

Q9. 设计影子测试结果存储方案时需要考虑？

多选题 · mid

  • A.存储的容量和保留周期← 正确答案
  • B.与线上请求的关联能力← 正确答案
  • C.用户敏感数据的脱敏处理← 正确答案
  • D.模型训练时的梯度更新

答案：ABC。影子测试会积累大量结果数据，容量与保留周期决定成本（A）；关联字段决定能否配对对比（B）；影子数据包含真实用户请求，脱敏是合规底线（C）。D 的梯度更新属于模型训练环节，与结果存储无关。

Q10. 以下哪些措施能有效防止影子测试结论误判？

多选题 · hard

  • A.确保新旧模型接收同一批请求← 正确答案
  • B.样本量达到最小要求再下结论← 正确答案
  • C.使用显著性检验排除随机因素← 正确答案
  • D.只选择准确率最高的指标对比

答案：ABC。同源请求是对比公平的基石（A）；样本量不足时结论不稳定（B）；显著性检验能区分真实差异与噪声（C）。D 只选一个指标会以偏概全，应该同时关注多个离线与在线指标才能全面评估。