在一座热闹的城市里，有一栋年久失修的“模型公寓”。它曾扛住双十一流量洪峰，也为千万用户推荐过满意的商品。可如今住户零散、管线老化、维护费居高不下，社区管委会终于决定：让这栋楼退役。真正专业的做法，不是抡大锤蛮干，而是请来一支“拆迁队”：先鉴定危房等级、评估周边影响，再贴告示分栋拆、分片清，最后回收钢筋、回填地基、归档图纸。AI 平台里的模型退役，与这场城市拆迁如出一辙：模型会被污染、会过时、会被新版本取代，总有一天要体面离场。这篇文章就跟着“拆迁队”的施工手册，零基础看懂模型退役策略的完整流程。

岗位关联

模型退役策略是 AI 工程化的收尾能力。掌握它，你能在模型生命周期的末端不慌不乱：既节约算力成本，又满足合规审计，还能随时回滚，为团队守住最后一道底线。

目录
  1. 可视化演示
  2. 退役触发标准
  3. 退役影响评估
  4. 退役流程设计
  5. 灰度下线策略
  6. 资源回收机制
  7. 退役应急预案
  8. 退役记录存档
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

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

模型退役四维标准 任一维度触发即启动退役评估任一维度触发即启动退役评估任一维度触发即启动退役评估任一维度触发即启动退役评估 任一维度触发即启动退役评估任一维度触发即启动退役评估任一维度触发即启动退役评估任一维度触发即启动退役评估

退役触发标准

拆迁队什么时候进场？不是邻居嫌楼丑就动手，而要等官方的房屋安全鉴定结果：结构裂缝超过红线、能耗超标、住户投诉率居高不下，综合分数亮红灯。旧模型也一样，退役需要一个客观的“鉴定标准”，不能凭运维同学的心情随手一删。技术团队把“危楼鉴定”翻译成四个可量化的触发器：性能跌破阈值、业务需求变化、合规监管要求和成本效益失衡。这四类信号只要积累到一定程度，旧模型就会进入退役候选池。

性能类最常见也最直观：在线准确率、召回率或 P99 延迟连续 N 天不达标，比如连续 7 天低于 90%，就构成触发条件。业务类更直接：当推荐目标从“点击率”改为“成交额”，旧模型的目标函数与业务 KPI 脱节，继续服役只会拖后腿。合规类拥有“一票否决权”：新法规禁止继续使用某些用户特征，模型必须立即下线。成本类考验财务嗅觉：推理成本升高而收益不变，退役就是最好的止损。把四项信号写成加权公式，就能像鉴定危楼一样给模型打分：

这样一来，“危楼鉴定”就变成了白纸黑字的量化表，拆迁队不会因为情绪或直觉乱拆楼。看到红灯再行动，是退役理性的第一步。

Tretire=w1Pfail+w2Bchange+w3Cexcessw1+w2+w3\displaystyle T_{\text{retire}}=\frac{w_1 P_{\text{fail}} + w_2 B_{\text{change}} + w_3 C_{\text{excess}}}{w_1 + w_2 + w_3}
这是“危楼综合评分”：每一项分数乘以一个权重后取平均，总分超过“退役分数线”才触发评估，而不是某一项稍微抖动就动手。
  1. 性能缺口 P_fail度量实际性能低于阈值的程度。阈值 90%、实际 85%，缺口就是 (90%-85%)/90%。
    Pfail=θperf−SactualθperfP_{\text{fail}}=\frac{\theta_{\text{perf}}-S_{\text{actual}}}{\theta_{\text{perf}}}
  2. 业务变化度 B_change取 0 到 1 之间的值，由产品与算法共同打分，目标函数不再匹配时接近 1。
    Bchange∈[0,1]B_{\text{change}} \in [0,1]
  3. 成本超额率 C_excess实际成本超出预算的比例，超出越多，这项得分越高。
    Cexcess=Cactual−CbudgetCbudgetC_{\text{excess}}=\frac{C_{\text{actual}}-C_{\text{budget}}}{C_{\text{budget}}}
  4. 加权平均与触发判定分子总和除以权重和，得到退役触发得分；当分值大于阈值 θ_retire 时，才启动正式退役评估。
    trigger if Tretire>θretire\text{trigger if } T_{\text{retire}} > \theta_{\text{retire}}

退役影响评估

危楼鉴定通过后，拆迁队不能直接上锤子，得先画一张“城市管网图”：这栋楼连着哪几条水管、哪条电缆，旁边的学校会不会受影响。模型退役也同理，先做影响评估，才能判断这次下线是否足够安全。影响评估的输入是“依赖关系”：谁在调用这个模型？它的输出喂给了多少下游服务？训练时是否共享了特征？把调用链梳理清楚，风险就浮出水面了。

通常要看三件事：一是依赖清单，列出直接下游、间接下游以及共用的数据管道；二是流量权重，计算该模型承载的业务流量占总流量的比例；三是不可用损失，若模型突然黑屏，每分钟损失多少订单或用户。三者相乘得到风险分，风险过高时不仅退役要缓行，还得提前准备替代方案。用公式表示就是：

当拆迁队看完这张城市管网图，心里就有数：哪些楼必须最后拆、哪些楼可以先拆。评估不是拖延，而是为了不伤及无辜。

Rrisk=Ddeps×Wtraffic×Lloss\displaystyle R_{\text{risk}} = D_{\text{deps}} \times W_{\text{traffic}} \times L_{\text{loss}}
风险分 = 牵连的线路数量 × 这根线路的车流量 × 堵车造成的损失。三项都大，说明这栋楼碰不得。
  1. 依赖数 D_deps直接和间接依赖旧模型的下游服务总数。牵连越多，退役波及面越大。
    Ddeps=number of downstream servicesD_{\text{deps}} = \text{number of downstream services}
  2. 流量权重 W_traffic旧模型承载的 QPS 占全部业务 QPS 的比例，比如 60% 的请求都经过它。
    Wtraffic=QPSmodelQPStotalW_{\text{traffic}} = \frac{QPS_{\text{model}}}{QPS_{\text{total}}}
  3. 不可用损失 L_loss模型突然不可用时，每秒损失的订单量或金额，是风险的经济度量。
    Lloss=loss per second when unavailableL_{\text{loss}} = \text{loss per second when unavailable}
  4. 三者相乘得到风险分乘积越大，说明退役的风险越高，越需要谨慎设计或推迟执行。
    Rrisk=Ddeps×Wtraffic×LlossR_{\text{risk}} = D_{\text{deps}} \times W_{\text{traffic}} \times L_{\text{loss}}

退役流程设计

正式动工前，拆迁队会贴出《告居民书》：几月几日断水电，哪几天拆东楼，哪一天做最后的爆破。模型退役也需要一份作战计划书，把每一步排进日历。流程设计不是写文档敷衍了事，而是把“退役”拆成四个可执行的时间段：准备、影子、切换、验证。每段都有明确的进入条件和退出条件，算法、运维、产品各司其职。

准备阶段 T\_prep 要做三件事：冻结模型版本、通知全部下游负责人、给模型权重打镜像备份。影子阶段 T\_shadow 让新旧模型并行在线，把真实流量复制给新模型对拍输出，但不改变线上结果。切换阶段 T\_switch 把生产流量从旧模型迁到新模型，按灰度比例逐步推进。验证阶段 T\_verify 紧盯核心指标，达到稳定阈值后，才允许旧模型正式退役。四个阶段串起来，就是退役的总工期：

有了这张施工排期表，拆迁队就有了共同的节奏感：有人负责贴告示，有人负责断水电，有人负责最后验收，谁也不会在工地上乱成一团。

Tretire=Tprep+Tshadow+Tswitch+Tverify\displaystyle T_{\text{retire}} = T_{\text{prep}} + T_{\text{shadow}} + T_{\text{switch}} + T_{\text{verify}}
总工期 = 准备期（贴公告）+ 试运行期（空跑演练）+ 切换期（搬行李）+ 验收期（查水电）。
  1. 准备期 T_prep写退役方案、通知下游、备份模型权重，是“磨刀不误砍柴工”。
    Tprep=planning and backup timeT_{\text{prep}} = \text{planning and backup time}
  2. 影子期 T_shadow新模型并行接收复制流量，结果只记录不生效，用于提前发现不一致。
    Tshadow=parallel shadow run timeT_{\text{shadow}} = \text{parallel shadow run time}
  3. 切换期 T_switch按灰度比例把真实流量从旧模型切到新模型，是唯一改变线上行为的阶段。
    Tswitch=traffic cutover timeT_{\text{switch}} = \text{traffic cutover time}
  4. 验证期 T_verify观察新模型是否稳定，确认无误后关闭旧模型，并签署退役确认单。
    Tverify=stability observation timeT_{\text{verify}} = \text{stability observation time}

灰度下线策略

拆迁队绝不会让整栋楼的居民同一天搬家，而是先清空低楼层，再清高楼层。灰度下线就是“分批搬家”：让旧模型的流量按批次切给新模型，每切一批就观察一阵。为什么要这么麻烦？因为线上环境有一万种离线评估测不出的意外：某地的网络网关不同、某类用户特征缺失、某个下游服务还没升级。把小范围流量当成“试拆迁”，发现异常立刻回滚，损失能控制在 1% 以内。

灰度比例常用一个简单的算式控制。假设把流量切成 N 批，当前已完成 n 批，那么已切换比例就是 n/N。为了避免最后一轮超切，用 min 函数把比例封顶在 100%：

搬家搬得从容，拆迁才能不惹众怒。灰度下线的智慧，就是“小步快跑、随时刹车”：每批切换后观察 10 到 30 分钟，盯住错误率、延迟、业务转化率三盏信号灯，全部绿灯再放行下一批。

g(n)=min⁡(1,nN)\displaystyle g(n) = \min\left(1, \frac{n}{N}\right)
这相当于把整栋楼的居民分 5 批搬迁，每搬一批就检查一次水电和楼道，确认安全再搬下一批。
  1. 当前批次 n表示已经完成流量切换的批次序号，从 1 开始计数。
    n=finished batch numbern = \text{finished batch number}
  2. 总批次数 N预先规划的灰度批次总数，N 越大，每批流量越少，越保守。
    N=total batch countN = \text{total batch count}
  3. 灰度比例 g(n)已切换流量占总流量的比例；当 n 超过 N 时，min 函数将结果锁在 1，即全量切换完成。
    g(n)=min⁡(1,nN)g(n) = \min\left(1, \frac{n}{N}\right)

资源回收机制

楼拆平了，剩下的钢筋、砖头、废旧电缆不会白扔，全都要送进回收厂。模型退役的最后一环，是把占据的算力、存储、服务名额全部还给平台。很多团队把“流量切完”当成退役终点，却忘了清理基础设施：GPU 实例还在计费、模型权重还占着几个 T 的存储、监控大盘还在抓取早已不存在的接口。定期做资源回收，是运维成本控制里最容易被忽略的利润来源。

可回收资源分四类：算力资源（GPU/CPU 实例、推理容器）、存储空间（模型权重文件、日志、缓存）、推理服务（K8s Deployment、负载均衡入口）、依赖清理（定时任务、消息队列订阅、监控告警）。为了决定回收优先级，可以计算每类资源的容量和实际利用率：容量越大、利用率越低，越应该优先释放。把每类资源被释放的量加总，就得到了总回收量：

工地清场之后，寸土寸金的地皮才能重新投入开发。资源回收同样让 GPU、存储和各种配额重新回到资源池，为公司省下真金白银。

Ereleased=∑i=1kCi×Ui\displaystyle E_{\text{released}} = \sum_{i=1}^{k} C_i \times U_i
把每一类“破铜烂铁”称重，再乘以它的“可回收率”，全部加起来就是这次拆除能回炉的建材总量。
  1. 资源容量 C_i第 i 类资源的总额度，比如 24 张 GPU、500GB 存储、10 个容器副本。
    Ci=capacity of resource item iC_i = \text{capacity of resource item } i
  2. 实际利用率 U_i该资源当前被使用的比例。闲置越多，U_i 越低，回收价值越大。
    Ui=usedcapacityU_i = \frac{\text{used}}{\text{capacity}}
  3. 求和得释放量把每类资源的“容量 × 利用率”累加，估算总释放量并以此安排回收顺序。
    Ereleased=∑i=1kCi×UiE_{\text{released}} = \sum_{i=1}^{k} C_i \times U_i

退役应急预案

任何拆迁现场都要有消防通道和急救车待命。模型退役也一样，最怕的不是退役失败，而是失败之后没人敢按下“重启键”。预案第一步是定义异常：新模型错误率超过旧模型两倍、P99 延迟翻倍、业务投诉激增，任何一个信号都足以触发回滚。关键在于监控系统要有“考古能力”：完整保留旧模型的版本、镜像、加载路径，让旧模型像消防车一样随叫随到。

回滚链路可以用总耗时来评估：从异常发生到业务恢复，等于检测时间、决策时间、恢复时间之和。自动化异常检测能把 T\_detect 从小时级压到分钟级；事前约定的决策人能把 T\_decision 从“开会讨论三小时”压到“按预案签字执行”；滚动复用旧镜像则能把 T\_restore 压到最短。三者加起来，就是业务的实际受损时间：

消防通道平时看着占地方，真出火情时却能救命。回滚预案就是那条永远不被杂物堵住的通道，让新模型翻车时，旧模型还能稳稳接住用户。

Trollback=Tdetect+Tdecision+Trestore\displaystyle T_{\text{rollback}} = T_{\text{detect}} + T_{\text{decision}} + T_{\text{restore}}
回滚总耗时 = 发现起火的时间 + 决定报火警的时间 + 消防员灭火的时间。每段都能被压缩。
  1. 检测时间 T_detect监控系统从异常发生到发出告警所花的时间，依赖告警阈值和采样频率。
    Tdetect=time to detect anomalyT_{\text{detect}} = \text{time to detect anomaly}
  2. 决策时间 T_decision值班工程师判断“要不要回滚”的时间，预案越明确，决策越快。
    Tdecision=time to make rollback decisionT_{\text{decision}} = \text{time to make rollback decision}
  3. 恢复时间 T_restore重新拉起旧模型并切回流量的时间，镜像预热和自动部署能显著缩短它。
    Trestore=time to restore old modelT_{\text{restore}} = \text{time to restore old model}
  4. 求和得回滚总耗时三项相加，数值越小，业务损失越小；这是退役预案核心要优化的指标。
    Trollback=Tdetect+Tdecision+TrestoreT_{\text{rollback}} = T_{\text{detect}} + T_{\text{decision}} + T_{\text{restore}}

退役记录存档

拆迁完工不等于项目结束，档案室里必须多出厚厚一摞：立项批复、危房鉴定书、施工日志、验收单、拆除前后照片。模型退役同样要在最后“归档”，让每个模型的生平有迹可循。归档的动机有两个：审计和溯源。大平台常要面对内部合规审计、外部监管检查；线上出问题时，要能查清“这个旧模型当时怎么退役的、谁审批的、流量怎么切”。没有档案，复盘就变成猜谜。

需要归档的内容至少包括三块：退役审批记录（谁决策、依据什么指标、有没有更高层签字）、过程日志（每个时间点的操作、灰度比例、指标变化）、模型档案（权重路径、版本号、训练数据范围、评估报告）。归档质量可以用合规率来度量：

档案袋合上的那一刻，拆迁项目才算真正画上句号。模型的一生从训练到退役都有记录，未来的工程师和审计师才能读得懂这份“城市更新史”。

Ccompliance=NarchivedNrequired\displaystyle C_{\text{compliance}} = \frac{N_{\text{archived}}}{N_{\text{required}}}
合规率 = 实际放进档案柜的文件数 ÷ 应该放进档案柜的文件数。越接近 100%，退役流程越规范。
  1. 应归档数 N_required按照规范和审计要求必须留下的记录总数，可由平台自动生成清单。
    Nrequired=required archive itemsN_{\text{required}} = \text{required archive items}
  2. 已归档数 N_archived实际完成留存、可被搜索与追溯的记录数量。
    Narchived=actual archived itemsN_{\text{archived}} = \text{actual archived items}
  3. 两者比值合规率若明显小于 1，说明存在档案缺口，需要补录或流程整改。
    Ccompliance=NarchivedNrequiredC_{\text{compliance}} = \frac{N_{\text{archived}}}{N_{\text{required}}}

AI 应用场景

金融风控模型合规退役

阶段：模型退役与合规审查

解决的问题：金融监管要求模型下线时保留完整证据链，传统手工下线容易漏报、错删关键材料，导致审计不通过。

具体案例：某银行风控模型 v3.2 因监管法规更新而停用。MLOps 平台自动触发影响评估，梳理出 6 个下游依赖服务；按 5 批灰度完成流量切换后，平台在 72 小时内自动归档审批记录和过程日志。季度审计时，合规率 100%，一次通过。

电商大促后闲置模型回收

阶段：资源回收

解决的问题：大促期间临时拉起大量模型实例，活动结束后 GPU 利用率暴跌，资源白白烧钱。

具体案例：某电商平台双 11 后扫描发现，有 40 个模型实例的 GPU 利用率低于 5%。平台按“容量 × 利用率”排序，优先回收 24 张最高配 GPU，并清理关联存储和日志任务，当月节省成本约 30 万元。

推荐系统季度模型换新

阶段：灰度下线与应急回滚

解决的问题：推荐模型每季度迭代一次，若直接全量切换，线上点击率和延迟容易出现断崖式波动。

具体案例：某内容平台在季度换新时采用 5 天灰度计划：第一天只让 5% 流量使用新模型，观察 CTR 与 P99 延迟；确认无异常后扩大到 50%，最终全量切换。第 3 天曾出现延迟翻倍，团队立即按预案回滚，10 分钟内恢复服务。

Python 演示

python60 行
import timefrom dataclasses import dataclass  @dataclassclass Model:    model_id: str    accuracy: float    qps: int    cost_per_hour: float    deps: int = 0    traffic_weight: float = 1.0    loss_per_sec: float = 0.0    retired: bool = False  class RetireScheduler:    def __init__(self, perf_threshold=0.90, risk_limit=50.0):        self.perf_threshold = perf_threshold        self.risk_limit = risk_limit        self.free_lists = []     def check_retire_candidates(self, models):        return [m for m in models if m.accuracy < self.perf_threshold]     def risk_score(self, model):        return model.deps * model.traffic_weight * model.loss_per_sec     def gray_release(self, model, batches=5):        for step in range(1, batches + 1):            ratio = min(1.0, step / batches)            print(f"  switch {ratio * 100:.0f}% traffic of {model.model_id}")            time.sleep(0.1)     def release_resources(self, model):        saved = model.cost_per_hour * 24        self.free_lists.append(model.model_id)        print(f"  release {model.model_id}, save ${saved:.2f}/day")     def retire(self, model):        print(f"== begin retire {model.model_id} ==")        if self.risk_score(model) > self.risk_limit:            print("  risk too high, skip")            return False        self.gray_release(model)        model.retired = True        self.release_resources(model)        print(f"== retire {model.model_id} done ==\n")        return True  models = [    Model("rec-v1", 0.88, 1200, 12.5, deps=3,          traffic_weight=0.6, loss_per_sec=2.0),    Model("rec-v2", 0.96, 2000, 15.0, deps=1,          traffic_weight=0.2, loss_per_sec=1.0),]scheduler = RetireScheduler()for m in scheduler.check_retire_candidates(models):    scheduler.retire(m)
目的：演示一个最小可用的“模型退役调度器”——自动筛选性能不达标的候选模型，执行风险评估、灰度切换和资源回收，并在终端打印每一步操作。
  1. def check_retire_candidates(self, models):定义退役候选筛选方法，把所有模型逐个检查。
  2. return [m for m in models if m.accuracy < self.perf_threshold]用列表推导式找出准确率低于阈值的模型，即“危楼鉴定”红牌名单。
  3. def risk_score(self, model):风险评估方法，实现正文中的风险公式：依赖数 × 流量权重 × 单次损失。
  4. ratio = min(1.0, step / batches)计算每一批已经切换的流量比例，并用 min 封顶在 100%。
  5. for step in range(1, batches + 1):分 5 批灰度切换流量，每批只放行 20%，符合“小步快跑”策略。
  6. model.retired = True将模型标记为已退役状态，防止后续被重复调度下线。
  7. self.free_lists.append(model.model_id)把已释放资源的模型 id 记入空闲清单，方便运维对账。

常见误区

误区模型准确率从 95% 掉到 85%，肯定是废了，应该立刻删掉换新模型。

正解短时指标波动可能是数据漂移、流量异常或上游特征缺失，并不代表模型本身失效。正确做法是像房屋鉴定一样，连续观察 7 天窗口并做显著性校验，确认趋势之后再启动退役流程。贸然下线，反而会把正常波动的模型误杀。

为何常见：看到数字下降会本能焦虑，把“暂时表现差”和“应该退役”混为一谈，忽视了数据环境的干扰。

误区流量切完了，退役就结束了，把 deployment 和权重文件一删，万事大吉。

正解流量切换只是退役的一部分，后续还有资源回收和档案归档。模型权重文件应当归档留存而不是删除，否则回滚时会发现旧模型“尸骨无存”。正确顺序是：灰度下线 → 资源回收 → 档案存档。

为何常见：把“下线服务”简化成“删除文件”，忽略了模型作为可回滚资产的基本特性。

误区新模型离线测试指标都很好，直接切 100% 流量就行，回滚方案用不上。

正解离线评估无法覆盖线上复杂的流量分布、地域网络、特征缺失等场景，新模型“上车翻车”的概率永远存在。没有回滚预案等于工地不配消防车，出事就只能干瞪眼。回滚方案不是安全感，是必需品。

为何常见：过度自信于离线指标，再加上“写预案很麻烦”的惰性，省掉了看似用不上的保险。

误区模型下线了，GPU 实例先留着吧，万一以后还要用呢。

正解闲置资源每天都在烧钱，而且 GPU 存量的“以后再用”往往永远等不到。正确的做法是给退役流程加上回收时限，比如“退役完成后 24 小时内释放全部算力”，把资源回收到公共池。

为何常见：“留着备用”的心态让人忽视云账单上的隐性成本，总觉得资源是免费的存量而非按秒计费的流量。

面试题

Q1. 下列哪一项属于模型退役的“性能触发”条件？

单选题 · easy

  • A.产品需求迭代方向
  • B.监管合规新规定
  • C.准确率连续跌破阈值← 正确答案
  • D.GPU 实例单价上涨

答案：C。性能触发看的是模型自身的量化指标，如准确率连续多日跌破阈值。产品需求变化属于业务类触发，监管新规属于合规类触发，GPU 涨价属于成本类触发，均不属于性能类。

Q2. 退役影响评估的核心目的是什么？

单选题 · easy

  • A.预测新模型训练时间← 正确答案
  • B.梳理依赖并判断风险
  • C.计算 GPU 总浮点运算
  • D.优化模型压缩比例

答案：A。影响评估的本质是画“城市管网图”：梳理谁在调用旧模型、流量权重多大、不可用损失多高，从而得出风险分。训练时间、浮点运算、压缩比例属于训练与优化话题，与退役风险无关。

Q3. 灰度下线过程中，适合持续监控的指标有哪些？

多选题 · mid

  • A.错误率指标变化← 正确答案
  • B.请求延迟波动← 正确答案
  • C.模型参数量优化
  • D.业务转化率走势← 正确答案

答案：ABD。灰度关注的是新模型上线后是否“翻车”，因此要盯着错误率、延迟和业务转化率这些线上表现。模型参数量是架构属性，不会在灰度过程中变化，监控它没有意义。

Q4. 灰度批次数 N=5，完成第 3 批切换后的流量比例是多少？

单选题 · mid

  • A.约百分之二十
  • B.约百分之四十
  • C.约百分之六十← 正确答案
  • D.约百分之百

答案：C。由 g(n) = min(1, n/N) 可得 g(3) = 3/5 = 0.6，即 60%。20% 是第 1 批，40% 是第 2 批，100% 要等到第 5 批才达到。

Q5. 模型退役后，下列哪些资源应当被回收清理？

多选题 · mid

  • A.模型离线评估报告
  • B.分配 GPU 算力实例← 正确答案
  • C.模型权重存储文件← 正确答案
  • D.监控大盘配置项← 正确答案

答案：BCD。算力实例、权重存储、监控配置都属于退役后的资源占位，应释放或删除。评估报告属于档案记录，应当保留归档，而不是回收清理。

Q6. 下列哪项最能直接缩短回滚总耗时？

单选题 · hard

  • A.提高推理显卡性能
  • B.自动化异常检测← 正确答案
  • C.扩大训练数据集
  • D.提升模型参数量

答案：B。回滚耗时 = 检测 + 决策 + 恢复。自动化异常检测能压缩 T_detect，对缩短总耗时贡献最大。显卡性能和参数量影响推理或精度，与回滚链路没有直接关系。

Q7. 模型退役档案最主要的作用是什么？

单选题 · easy

  • A.提升模型预测精度
  • B.满足审计与历史追溯← 正确答案
  • C.加速梯度反向传播
  • D.减少 GPU 运行功耗

答案：B。退役档案服务于审计与溯源：谁审批、何时切换、灰度比例多少。精度提升属于训练目标，反向传播与功耗属于训练与推理性能，档案都不参与这些过程。

Q8. 设计一个合理的模型退役流程，正确做法有哪些？

多选题 · hard

  • A.分阶段灰度切换流量← 正确答案
  • B.保留快速回滚能力← 正确答案
  • C.跳过影响评估环节
  • D.退役完后立刻归档← 正确答案

答案：ABD。合理退役要“先评估、再灰度、留回滚、后归档”。跳过影响评估等于不看城市管网图直接拆楼，风险不可控，因此 C 错误，其余均为标准动作。

Q9. 风险公式 R = D × W × L 中的 L 代表什么？

单选题 · mid

  • A.依赖服务数量
  • B.业务不可用损失← 正确答案
  • C.模型活跃时长
  • D.日志平均长度

答案：B。L 是 loss，指模型突然不可用时每秒损失的业务价值，它和依赖数、流量权重共同构成风险分。依赖数对应 D，活跃时长和日志长度与风险评估公式无关。

Q10. 一个持续低利用率、效果平平的模型，最核心的退役理由是什么？

单选题 · extreme

  • A.代码可读性降低
  • B.模型精度将下降
  • C.训练框架已过时
  • D.成本效益持续失衡← 正确答案

答案：D。低利用率意味着调用少、分摊成本高，加之效果平平，成本效益已经失衡。代码可读性和训练框架过时是工程债务，不等于模型必须退役；精度是当下的“低”，而不是“将下降”。