城市里有一家生意火爆的“智慧餐厅”。几十位厨师的灶台分布在不同楼层，客人进门后，领位员会根据每位客人的口味偏好，把他们领到不同的“出餐线”：有些人尝到的是新菜谱，有些人吃到的是经典老味道。餐厅中央调度台记录每位客人的用餐反馈，只有当新菜谱用数据证明自己“确实更好吃”时，调度台才会让更多客人尝尝它；一旦发现口碑下滑，马上切回老菜谱。这套“调度台—领位员—厨师线—记分员”的配合，正是实验平台与模型服务集成部署的缩影。 本文要讲的，就是如何把这个“智慧餐厅”的机制搬进 AI 系统：实验平台如何调度模型服务、怎样把用户流量稳定地分成实验组和对照组、如何用统计学判断模型好坏、以及如何安全地灰度发布与回滚。

岗位关联

掌握实验平台与模型服务集成，你就掌握了模型从离线评估走向线上真理验证的最后一公里，是算法工程师晋升 MLOps 专家的核心能力。

目录
  1. 可视化演示
  2. 平台核心定位
  3. 模型服务接入
  4. 流量分流策略
  5. 实验评估体系
  6. 部署发布流程
  7. MLOps工程实践
  8. AI 应用场景
  9. Python 演示
  10. 常见误区
  11. 面试题

可视化演示

动态演示实验平台与模型服务集成的核心机制，通过基础/核心/应用/扩展四种模式展示关键概念与交互流程。

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

实验平台与模型服务集成：实验平台 实验平台与模型服务的协作架构 分流路由与实验配置下发 核心机制可视化 实验平台与模型服务集成整体架构与关键组件

平台核心定位

智慧餐厅的老板发现，自己的价值不在于颠勺炒菜，而在于把“哪位客人吃哪位厨师做的菜”这件事安排好。他站在调度台前，左手是一本记录所有新菜谱试吃名单的报名册（实验目录），右手是一块写着每位厨师当前是否在岗的告示板（服务目录）。调度台不炒菜，但它决定炒出来的菜端给谁。

实验平台在 AI 系统里扮演的正是这个调度台。它不做模型训练，也不直接处理用户请求，而是把“这条请求该由哪个模型服务处理”这件事管起来。当推荐请求到达时，平台先查实验配置，再查模型服务目录，最后把请求路由到正确的模型版本上。

平台的核心能力通常包含三块：实验管理中枢（创建、启停、归档实验）、模型服务网关（统一入口、灰度路由、负载均衡）、A/B 测试支撑（分流、埋点、数据回流）。模型服务通过统一接口注册到平台，平台以“版本”为单位管理线上模型，同一个模型 ID 可以同时存在 v1、v2 等多个版本。

对调度台而言，最重要的是“清清楚楚地知道每位厨师今天用哪套菜谱”。实验平台与模型服务的集成，正是把这种“对应关系”固化成了系统里的路由规则，让一切有据可查、随时可切。

y=fs(x),s∈{A,B}y = f_{s}(x), \quad s \in \{A, B\}
这是实验平台路由决策的抽象表达：对于同样的输入特征 x，实验分配 s 决定了调用哪个版本的模型服务，从而得到预测 y。
  1. 特征 x 与预测 yx 是用户请求的特征向量，y 是模型服务输出的预测结果。
    x∈Rd,y∈Rx \in \mathbb{R}^{d}, \quad y \in \mathbb{R}
  2. 下标 s 的角色s 是实验分配结果，只能取实验组 A 或对照组 B 之一。
    s∈{A,B}s \in \{A, B\}
  3. 整体路由含义同样的输入 x，因 s 不同而调用不同模型版本，得到不同预测——这就是实验平台路由模型服务的核心机制。
    y=fA(x) 或 y=fB(x)y = f_{A}(x) \ \text{或} \ y = f_{B}(x)

模型服务接入

调度台再聪明，如果每位厨师的灶台布局都不一样——有的出餐口在南墙，有的在北墙，有的盘子是方的、有的是圆的——那调度台也协调不过来。智慧餐厅的规矩是：所有厨师必须使用统一的“标准化工位”。

模型服务接入实验平台，同样需要标准化契约。无论模型是用 TensorFlow、PyTorch 还是 XGBoost 训练出来的，一旦要上线，就必须被包装成符合统一接口协议的服务：输入是标准特征结构，输出是标准预测结构，通过 HTTP/RPC 暴露给平台调用。

接入规范通常包含三部分：一是服务封装（把模型权重、预处理逻辑打包成可独立部署的进程）；二是接口协议（规定请求字段、响应字段、超时与重试语义）；三是注册发现（模型服务启动时向注册中心登记 model_id、version、地址，下线时自动注销，平台动态感知可用服务）。这样新增一个模型版本，完全不需要改平台代码。

标准化工位让调度台闭着眼都知道出餐口在哪。同理，统一的服务接入规范让实验平台不用关心模型内部细节，只通过接口协议就能把流量安全地送进“每一间后厨”。

A=成功响应数总请求数×100%A = \frac{\text{成功响应数}}{\text{总请求数}} \times 100\%
服务可用性是衡量模型服务接入质量的核心指标，线上 SLA 一般要求 99.9% 以上。
  1. 分子 成功响应数在规定时间内正常返回结果的请求数量，即“成功出餐的订单数”。
    Nok=Ntotal−NfailN_{\text{ok}} = N_{\text{total}} - N_{\text{fail}}
  2. 分母 总请求数网关收到的全部请求，无论成败都计入，保证比例不超过 100%。
    Ntotal=Nok+NfailN_{\text{total}} = N_{\text{ok}} + N_{\text{fail}}
  3. 乘 100% 与可用性目标换算成百分数便于设定 SLA；99.9% 意味着每千次请求最多允许 1 次异常。
    A≥99.9%A \geq 99.9\%

流量分流策略

领位员遇到了难题：怎么决定哪位客人去试新菜？如果随手指着客人说“您来尝新菜”，同一个客人今天吃新菜、明天吃老菜，满意度记录就全乱了。领位员想了个办法：给每位客人发一张永久会员号，用会员号算一道固定的算术题，结果落在哪个区间，就去哪条线。这样同一个客人每次来，永远被分到同一条线。

这道“固定的算术题”就是哈希分桶。实验平台对 user_id（或 device_id）拼接实验盐值（salt）后做哈希，再对桶总数取模，得到一个稳定的桶号。只要盐值不变，同一个用户永远落在同一个桶里，也就永远属于同一个实验组。

典型实现分两层：第一层用哈希函数把用户映射到 N 个桶；第二层把桶按比例分配到实验组和对照组。例如 20% 流量给实验组，就把前 20% 的桶划过去。桶数 N 通常取 100 或 1000 以保持粒度。当需要扩容或调整比例时，普通取模会让大量用户换桶，而一致性哈希把用户映射到哈希环上，服务节点增减只影响环上一小段区间，迁移成本极低。

会员号算法让领位员既公平又稳定：新客尝鲜不重复，老客体验不漂移。哈希分桶正是这套“会员号算术”的工程实现，它是整个实验平台的基石——分组一旦不稳定，后面所有统计结论都失去意义。

bucket(u)=hash(user_id⊕salt) mod N\text{bucket}(u) = \text{hash}(\text{user\_id} \oplus \text{salt}) \bmod N
u 为用户的唯一标识；salt 为实验专属盐值，保证不同实验的分组互不干扰；N 为桶总数；⊕ 表示字符串拼接。
  1. user_id 输入用户的稳定唯一标识，如会员号或设备号，是分桶的原材料。
    user_id∈String\text{user\_id} \in \text{String}
  2. salt 盐值每个实验专属的随机字符串，让同一用户在不同实验中被独立打散。
    salt=random()\text{salt} = \text{random}()
  3. hash 与取模先哈希得到均匀分布的大整数，再对 N 取模，得到 0 到 N−1 的桶号。
    bucket∈{0,1,…,N−1}\text{bucket} \in \{0, 1, \ldots, N-1\}
  4. 阈值分组的整体逻辑桶号小于 p×N 的进实验组，其余进对照组；salt 不变则分配永远稳定。
    实验组⇔bucket<p×N\text{实验组} \Leftrightarrow \text{bucket} < p \times N

实验评估体系

餐厅的记分员拿着满意度小票，发现实验组平均分确实比对照组高了 0.3 分。但他不敢立刻宣布新菜获胜——万一只是这周来的客人心情普遍好呢？记分员需要一套数学方法，把“真实差异”和“随机波动”区分开。

这就是统计显著性检验。实验平台采集实验组和对照组的核心指标（如点击率、转化率），用双样本比例 z 检验判断两组差异是否显著。零假设是“两组真实效果没有差异”，如果观测到的差异大到几乎不可能是随机波动，就拒绝零假设。

除了 z 检验，还要报告置信区间：真实效果以 95% 的概率落在某个区间内，区间不含 0 才说明方向可信。样本量不足时差异再大也不可信，样本量过大时微弱差异也可能“统计显著”，所以要结合效应量一起判断。

记分员终于能拍着胸脯说“这不是运气了”。实验评估体系就是 AI 世界里的“记分员数学”——它用显著性检验和置信区间，替我们挡住随机性这位“最爱捣乱的食客”，让每一个上线决策都建立在可信证据之上。

z=p^1−p^2p^(1−p^)(1n1+1n2)z = \frac{\hat{p}_1 - \hat{p}_2}{\sqrt{\hat{p}(1-\hat{p})\left(\frac{1}{n_1} + \frac{1}{n_2}\right)}}
两组差异的置信区间；区间不包含 0 时，认为提升方向可信。
  1. 点估计两组比例之差是真实差异的最佳猜测值。
    d^=p^1−p^2\hat{d} = \hat{p}_1 - \hat{p}_2
  2. 临界值 z_{\alpha/2}95% 置信水平下取 1.96，决定区间宽度。
    z0.025=1.96z_{0.025} = 1.96
  3. 区间解读真实差异以 95% 概率落在该区间；区间不含 0 才说明方向可信。
    CI=[d^−1.96 SE, d^+1.96 SE]\text{CI} = \left[\hat{d} - 1.96\,\text{SE},\ \hat{d} + 1.96\,\text{SE}\right]

部署发布流程

新菜谱就算通过了内部试吃，餐厅也不敢直接换掉老菜谱。店规是：先在 VIP 老客里试 5%，观察几天没问题就扩到 20%、50%，最后才全量替换；一旦监控到差评率飙升，立刻切回老菜谱。

这对应模型部署中的灰度发布（canary release）。新模型版本先在实验平台的控制下接管少量线上流量，平台持续监控核心指标，指标健康则逐步扩大流量比例，直至全量；指标异常则触发自动回滚。

灰度发布与实验平台天然协同：实验平台负责按比例路由，监控系统负责指标采集与告警，部署系统负责版本切换。一个典型发布计划是 5% → 20% → 50% → 100%，每个阶段观察若干小时。回滚不是“重新训练”，而是把路由目标从新版本切回旧版本，几分钟内完成。

店规的本质是“让数据替新菜说话，而不是让老板拍脑袋”。灰度发布 + 自动回滚这个安全气囊，保证了新模型最坏情况也只是“悄悄退场”，绝不会让整家餐厅的口碑陪葬。

r(t)=rmax⁡×min⁡(t,T)Tr(t) = r_{\max} \times \frac{\min(t, T)}{T}
r(t) 为 t 时刻新版本承接的流量比例；T 为完整的灰度周期；r_{\max} 是最终目标比例（通常 100%）。
  1. r_{\max} 目标比例灰度结束时的最终流量占比，通常为 100%。
    rmax⁡=100%r_{\max} = 100\%
  2. min(t, T) 封顶取 t 与 T 的较小者，防止 t 超过 T 后比例继续超卖。
    min⁡(t,T)={t,t<TT,t≥T\min(t, T) = \begin{cases} t, & t < T \\ T, & t \geq T \end{cases}
  3. 整体线性扩量比例随时间匀速爬升，配合每档停留观察，形成阶梯式灰度。
    r(t)=tT×100%(t≤T)r(t) = \frac{t}{T} \times 100\% \quad (t \leq T)

MLOps工程实践

餐厅越做越大，老板发现最值钱的不是某道菜，而是那本记了三年的大账本：每天进货多少、每桌客人点什么、满意度怎么变化。但账本如果被人涂改过、记串行，所有决策都会跟着错。所以餐厅专门设了一个“账房先生”，负责记账质量。

在 MLOps 体系里，这个“账房先生”就是数据可信层（Data Trust Layer）。实验平台做决策依赖数据，如果实验日志有缺失、埋点有偏差、特征分布发生漂移，统计检验再漂亮也是错的。数据可信层负责在数据进入实验评估之前进行质量校验。

数据可信层做三件事：质量评分（完整性、一致性、及时性）、漂移检测（特征分布与建模分布对比）、血缘追踪（每个指标能追溯到原始日志）。自动化流水线则把模型训练、服务打包、注册上线、实验开启串成一条 CI/CD 流水线，新模型从提交代码到 A/B 测试全自动。治理与合规要求实验数据脱敏、用户可申诉、操作可审计。

账房先生守住的是整家餐厅的“决策地基”。数据可信层为实验平台守住的是同样的地基——流量分得再准、检验算得再精，如果数据本身不可信，一切结论都只是“漂亮数字堆砌的空中楼阁”。

Q=∑i=1nwiqi∑i=1nwiQ = \frac{\sum_{i=1}^{n} w_i q_i}{\sum_{i=1}^{n} w_i}
数据质量总分 Q 是各维度得分 q_i 的加权平均，权重 w_i 由业务重要性决定。
  1. 维度得分 q_i每个数据质量维度的打分，如完整性 0.95、一致性 0.98。
    qi∈[0,1]q_i \in [0, 1]
  2. 权重 w_i维度的重要程度，如及时性权重更高，因为实验评估对延迟敏感。
    wi>0w_i > 0
  3. 加权平均分子是各维度得分乘权重之和，分母是权重之和，得到归一化的总分。
    Q=w1q1+w2q2+⋯+wnqnw1+w2+⋯+wnQ = \frac{w_1 q_1 + w_2 q_2 + \cdots + w_n q_n}{w_1 + w_2 + \cdots + w_n}
  4. 质量门禁总分低于 0.9 时，实验数据不允许进入显著性检验，直接标记为“不可信”。
    Q<0.9⇒拒绝评估Q < 0.9 \Rightarrow \text{拒绝评估}

AI 应用场景

场景 1：推荐系统的 A/B 测试接入

阶段：模型上线与在线验证

解决的问题：传统做法是算法工程师在离线数据集上比完指标就全量上线，但离线指标与线上真实效果常有偏差。实验平台接入推荐模型服务后，新模型先以 10% 流量上线，与线上 v1 模型实时对比 CTR、时长等指标，用显著性检验决定扩量还是回滚。

具体案例：某资讯 App 的推荐团队上线新版排序模型，通过实验平台创建"exp_rank_2101"实验，v2 模型承接 20% 流量。运行 3 天后 z 检验显示点击率提升 4.2%（z=3.1 > 1.96），平台自动将 v2 扩量到 50%，一周后全量。

场景 2：风控模型的灰度发布与自动回滚

阶段：模型部署与运维

解决的问题：风控模型误杀率升高会直接影响用户体验和资损。传统发布方式风险高，出了问题难以快速恢复。通过实验平台把新模型接入同一网关，按 5% → 20% 灰度放量，实时监控误杀率和召回率，指标恶化立即自动回滚。

具体案例：某支付平台上线反欺诈模型 v3，灰度到 20% 时监控发现交易驳回率从 1.2% 升到 2.8%，触发告警，平台在 3 分钟内将流量全部切回 v2，资损影响被控制在最小范围。

场景 3：数据可信层保障实验评估公平性

阶段：数据治理与实验分析

解决的问题：实验日志埋点缺失或线上特征分布漂移，会导致显著性检验得出错误结论。数据可信层在指标计算前自动巡检数据质量，质量分不达标时阻止评估并告警。

具体案例：某电商大促期间实验日志出现 12% 缺失，数据可信层打出的质量分仅 0.71（阈值 0.9），自动暂停了该实验的结论输出，运营团队排查发现是埋点服务扩容导致，修复后实验重新计时评估。

Python 演示

python93 行
"""实验平台与模型服务集成: 哈希分桶 + 模型路由 + 显著性检验"""import hashlibimport mathimport random  def hash_bucket(user_id, salt, n):    """将用户稳定映射到 0..n-1 的桶"""    key = "%s:%s" % (user_id, salt)    digest = hashlib.md5(key.encode("utf-8")).hexdigest()[:8]    return int(digest, 16) % n  class ModelService:    """模型服务注册表: 按 (model_id, version) 路由"""    endpoints = {}     @classmethod    def register(cls, model_id, version, fn):        cls.endpoints[(model_id, version)] = fn     @classmethod    def serve(cls, model_id, version, features):        fn = cls.endpoints.get((model_id, version))        if fn is None:            raise KeyError("model %s-%s not registered" % (model_id, version))        return fn(features)  class Experiment:    """实验: 决定每个用户进入实验组还是对照组"""     def __init__(self, exp_id, model_id, ctrl_version, exp_version, ratio):        self.exp_id = exp_id        self.model_id = model_id        self.ctrl_version = ctrl_version        self.exp_version = exp_version        self.ratio = ratio        self.bucket_size = 1000     def decide(self, user_id):        bucket = hash_bucket(user_id, self.exp_id, self.bucket_size)        if bucket < int(self.bucket_size * self.ratio):            return self.exp_version        return self.ctrl_version     def predict(self, user_id, features):        version = self.decide(user_id)        return ModelService.serve(self.model_id, version, features)  def model_v1(uid, features):    """对照组模型: 点击率基线预估"""    return 0.08 + (uid % 10) * 0.001  def model_v2(uid, features):    """实验组模型: 点击率提升版预估"""    return 0.10 + (uid % 10) * 0.001  def z_test(n1, p1, n2, p2):    """双样本比例 z 检验, 返回 z 值"""    p = (n1 * p1 + n2 * p2) / (n1 + n2)    se = math.sqrt(p * (1 - p) * (1.0 / n1 + 1.0 / n2))    return 0.0 if se == 0 else (p2 - p1) / se  if __name__ == "__main__":    ModelService.register("ctr", "v1", model_v1)    ModelService.register("ctr", "v2", model_v2)    exp = Experiment("exp_ctr_01", "ctr", "v1", "v2", ratio=0.2)     random.seed(42)    ctrl_total = exp_total = ctrl_click = exp_click = 0    for uid in range(50000):        version = exp.decide("user_%d" % uid)        prob = model_v1(uid, None) if version == "v1" else model_v2(uid, None)        click = 1 if random.random() < prob else 0        if version == "v1":            ctrl_total += 1            ctrl_click += click        else:            exp_total += 1            exp_click += click     p1 = ctrl_click / ctrl_total    p2 = exp_click / exp_total    z = z_test(ctrl_total, p1, exp_total, p2)    print("对照组: %d/%d = %.4f" % (ctrl_click, ctrl_total, p1))    print("实验组: %d/%d = %.4f" % (exp_click, exp_total, p2))    print("z 值: %.3f" % z)    print("结论: %s" % ("实验组显著更优" if z > 1.96 else "差异不显著"))
目的：用 5 万模拟用户完整演示实验平台的核心链路——哈希分桶决定用户分组、模型服务按版本路由、显著性检验判断新模型是否值得上线。
  1. digest = hashlib.md5(key.encode("utf-8")).hexdigest()[:8]对用户 ID 和实验盐值拼接后的字符串做 MD5 哈希，取前 8 位十六进制，相当于给用户“随机但稳定”地打了一个分桶牌。
  2. cls.endpoints[(model_id, version)] = fn把模型服务按（模型 ID, 版本号）注册进注册表，实验平台按版本名精确找到对应服务。
  3. ModelService.serve(self.model_id, version, features)统一接口路由：平台不关心模型内部实现，只按版本号转发请求。
  4. bucket < int(self.bucket_size * self.ratio)桶号小于 20% 阈值就进实验组，这就是哈希分桶的“门槛”决策。
  5. exp.decide("user_%d" % uid)模拟实验平台对每个用户做一次稳定的实验分配。
  6. z = z_test(ctrl_total, p1, exp_total, p2)用 z 检验判断实验组与对照组点击率差异是否显著，|z|>1.96 才允许下结论。

常见误区

误区“实验组分 50% 流量，这样样本量大，两三天就能下结论，而且对用户也公平。”

正解流量比例越大，用户体验受影响的面越大。正确做法是先用功效分析算出最小样本量，在保证统计功效的前提下尽量给实验组分小流量。比如 95% 功效、显著性 5%、最小可检测提升 1% 时，可能只需要 10% 流量跑两周。流量不是越多越好，而是“够用就行”。

为何常见：人们直觉认为“样本多等于结论快”，忽略了实验有最小样本量门槛，也低估了新版本给用户体验带来的风险成本。

误区“实验跑了一半发现分组不太均匀，我换个 salt 重新分一下，反正都是随机分组。”

正解换 salt 等于把全体用户重新随机打散，原本在实验组的用户可能跑到对照组，实验的“同期性”被破坏，之前积累的样本全部作废。盐值只在创建实验时确定一次，中途绝不能更换；分组不均匀应通过增加桶数或分层抽样解决。

为何常见：把哈希分桶误解为“每次独立的随机抽样”，忽略了实验需要“用户固定分组”这个前提。

误区“我把模型 API 地址告诉实验平台就行了，接口格式、版本管理、服务发现都是后端的事。”

正解模型服务的接口规范、版本注册、健康检查直接决定实验平台能否可靠路由。如果两个版本接口字段不一致、或者服务下线了注册表没更新，流量就会打到错误服务上。集成部署是平台和服务方的共同契约，任何一方改接口都要走变更流程。

为何常见：算法工程师习惯只关注模型效果，容易忽视工程侧的接入规范；但线上事故往往发生在“接口不兼容”这种细节上。

误区“z=2.1，说明实验组 100% 比对照组好，赶紧全量上线！”

正解z>1.96 只表示“在 95% 置信水平下拒绝两组无差异的零假设”，仍有 5% 的概率是假阳性。如果同时跑 20 个实验，按 5% 显著性水平，平均会有 1 个实验纯靠运气“显著”。还要检查效应量、置信区间下界、以及新奇效应（用户对新功能的新鲜感消退后效果回落）。

为何常见：把“统计显著”等同于“效果确定”，忽略了显著性本身是一个带概率的风险声明，不是确定性证明。

误区“灰度就是把新模型部署上去，让 20% 流量跑着，过两天没问题就全量。”

正解没有监控阈值的灰度等于裸奔。灰度发布必须预先定义好“红灯指标”（如错误率、时延 p99、核心业务指标）和触发回滚的阈值。指标一旦越界，平台应自动把流量切回旧版本，而不是等人发现再手工操作。

为何常见：把灰度简单理解为“部署策略的一部分”，忽略了它是“可观测性 + 自动控制”组成的闭环系统。

面试题

Q1. 实验平台中，把用户稳定地分到实验组或对照组，最常用的工程方法是？

单选题 · easy

  • A.对用户标识做哈希取模分桶← 正确答案
  • B.每次请求用随机数独立掷骰子
  • C.按请求到达时间的先后轮询
  • D.按用户所在城市自动来划分

答案：A。哈希取模分桶能保证同一用户每次请求都分到同一桶，从而固定在实验组或对照组，这是实验一致性的前提；随机数方案每次结果可能不同，按时间或城市分组既不随机也不稳定，都会引入系统性偏差。

Q2. 实验运行过程中更换哈希盐值（salt），最可能的后果是？

单选题 · easy

  • A.实验组点击率会明显变高
  • B.模型服务发生不可用事故
  • C.用户换组导致实验样本作废← 正确答案
  • D.没有任何影响分组仍随机

答案：C。盐值是实验分组的“固定编号规则”，一旦变更，同一用户会被重新哈希到新桶，可能从对照组换到实验组，破坏同期性，已积累的样本全部失去可比性；换盐值不会影响模型服务可用性，也不会定向改变指标高低。

Q3. 关于实验平台中模型服务的灰度发布，以下说法正确的有？

多选题 · mid

  • A.应从低流量比例开始逐步放量← 正确答案
  • B.新版本应一次性全量替换旧版
  • C.指标恶化时自动回滚到旧版本← 正确答案
  • D.发布过程中不需要监控告警

答案：AC。灰度发布的核心是“小步快跑、随时可退”：从 5% 等低比例开始，观察核心指标健康后再逐步扩大；指标一旦恶化，立即自动回滚到旧版本。一次性全量上线把整个系统置于风险之下，放弃监控则让异常无法被及时发现。

Q4. 双样本比例 z 检验中，|z| = 2.3 的正确解读是？

单选题 · mid

  • A.实验组效果比对照组好 2.3 倍
  • B.说明实验数据一定存在埋点异常
  • C.说明样本量一定已经足够充分
  • D.差异在 95% 置信水平下统计显著← 正确答案

答案：D。|z|>1.96 意味着在 95% 置信水平下拒绝“两组无差异”的零假设，观察到的差异超出随机波动范围，称统计显著；z 值本身不表示效果倍数，也不代表数据一定正确或样本量一定充分，还需结合效应量、置信区间等综合判断。

Q5. 模型服务通过注册中心接入实验平台，最主要的好处是？

单选题 · mid

  • A.模型推理的准确率得到提升
  • B.不再需要对模型进行训练
  • C.平台可动态感知服务上下线← 正确答案
  • D.模型可以自动完成数据标注

答案：C。注册发现机制让模型服务在启动时自动登记、下线时自动注销，实验平台通过注册中心实时感知可用服务并按版本路由，新增或下线模型无需人工改配置；它不改变模型精度，也不替代训练或标注。

Q6. 灰度发布中，新版本流量扩到 30% 时核心指标显著恶化，最合适的操作是？

单选题 · easy

  • A.继续扩大流量观察能否回升
  • B.关闭告警避免影响发布进度
  • C.调低监控阈值使指标变正常
  • D.立刻回滚到上一个稳定版本← 正确答案

答案：D。灰度发布的铁律是“指标异常即回滚”：新版本在更大流量下暴露问题，说明它不具备全量上线条件，应立即切回旧版本缩小影响面。继续放量会放大故障损失，关闭告警或调低阈值属于掩耳盗铃，只会让问题更严重。

Q7. 为确保实验评估结论可信，实验平台需要做哪些事情？

多选题 · hard

  • A.保证分桶稳定且样本量充足← 正确答案
  • B.对多实验做多重检验校正← 正确答案
  • C.无视缺失数据直接算显著性
  • D.结合置信区间与效应量判断← 正确答案

答案：ABD。可信结论依赖三件事：稳定分组与充足样本保证统计功效；同时跑大量实验时做多重检验校正控制假阳性；报告置信区间与效应量避免只看 p 值。数据缺失时应先走数据可信层校验，而不是无视缺失硬算显著性。

Q8. 一致性哈希相比普通哈希取模，在分桶场景中的核心优势是？

单选题 · mid

  • A.桶数变化时只有少量键迁移← 正确答案
  • B.哈希计算的速度会成倍提升
  • C.可以完全去除对用户标识的依赖
  • D.能保证不同实验分组互不干扰

答案：A。普通哈希取模在桶数 N 变化时几乎所有用户都会换桶；一致性哈希把用户映射到首尾相连的环上，扩容缩容只影响新增或删除节点附近的一小段区间，因此只有少量用户需要迁移。它不提升哈希速度，仍需用户标识，也不能替代盐值来隔离不同实验。

Q9. 关于实验平台与模型服务集成部署，下列做法正确的有？

多选题 · hard

  • A.模型服务按统一接口协议接入← 正确答案
  • B.实验版本和线上版本同台路由← 正确答案
  • C.新模型离线指标好就直接全量
  • D.监控告警与自动回滚机制联动← 正确答案

答案：ABD。集成部署的正确姿势是：模型服务遵守统一接口和注册发现规范，实验平台按 (model_id, version) 在同一网关内同时路由实验版本与稳定版本，监控与自动回滚联动保证异常时快速止损。离线指标好不等于线上真实效果好，必须经 A/B 实验验证后才能全量。

Q10. 实验数据显示实验组相对对照组提升 5%，但置信区间为 [-0.5%, 10.5%]，正确结论是？

单选题 · hard

  • A.实验组确实稳定提升了 5%
  • B.对照组效果反而显著更好
  • C.差异方向不确定，需要更多样本← 正确答案
  • D.立即全量上线新模型版本

答案：C。置信区间包含 0，说明在 95% 置信水平下“两组可能无差异”，点估计 5% 只是样本波动下的最好猜测，差异方向尚不确定，不能贸然上线。正确做法是继续积累样本或增大流量，直到区间收窄且不包含 0 再下结论。