第 5 章 发布与运营

学习目标

• 确定发布范围（用户群、功能范围、排除的类型），并在影子测试、金丝雀发布、Beta 测试、A/B 实验中选择适用的发布方式。
• 在发布前确定中止标准与回滚方法，并通过样本量与对照组对比来评估金丝雀发布结果。
• 将系统、质量、用户行为、业务指标分层，设计运营指标与告警。
• 通过版本控制、回归评测、分阶段生效来管理模型与提示词的变更，并为模型生命周期公告做好准备。
• 发生事故时，按照阻断扩散、通报与纠正、修复原因与恢复、记录与不指责复盘、落实防重演措施的顺序进行响应，并依据运营数据确定改进优先级。

引言

发布 AI 功能的当天，团队通常会松一口气。评测已经通过，也达到了发布标准。然而，评测集代表的只是截止到昨天的世界；发布之后，用户会提出评测集中未曾出现的问题，模型提供商会调整模型，团队也会修改提示词。AI 功能的质量在发布当天往往最为明确，此后若不持续监控，就会悄然发生变化。

Anthropic 指出，最高效的团队会将自动化评测、生产监控、A/B 实验、用户反馈以及人工复核结合使用。作为自愿性风险管理指南，NIST AI RMF 建议执行部署后监控计划，并向包括受影响人员在内的相关方通报事故与错误。发布与运营，正是将这些原则转化为具体时间表与量化指标的工作。

本章首先探讨如何确定发布范围与发布方式，并设计金丝雀发布及中止标准。接着讲解运营指标与告警、模型及提示词变更管理，最后学习事故响应与复盘，以及如何利用运营数据确定改进优先级。

核心概念

发布是度量的开始

发布并非开发的终点，而是在真实世界中开始度量性能的起点。离线评测无法回答的问题——例如真实用户如何使用、会有怎样的输入涌入、业务指标是否发生变化——只有在发布后才能给出答案。因此，发布计划中必须包含度量什么、度量到何时、出现什么数据时扩大范围、出现什么数据时停下。

打个比方，发布就像新建桥梁通车。即使通过了设计验算（离线评测），最初也要限制车辆通行并用传感器监测晃动幅度，并提前制定好超标即实施管制的规则。

确定发布范围

发布范围从三个维度来确定。

如果评测中仅有特定类型未达标，且有将该类型转交人工的链路，那么在发布时剔除该类型就是一种范围决策。由于排除操作必须在执行阶段强制落实，因此需要一并规划相应机制，通过意图分类器或规则过滤器识别该类型的输入，并将其转由人工客服或既有指引处理，而非交由模型。发布范围应设计为可通过特性开关（Feature Flag）等机制进行调控，以便后续扩大或收窄范围时无需重新部署代码即可调整。

发布方式对比

根据 AWS 对影子测试的说明，新变体接收实际请求的副本，但调用它的应用程序仅会收到既有（生产）变体的响应，影子变体的响应则被丢弃或记录下来用于离线对比。Google SRE 将金丝雀发布定义为对服务变更进行的局部性、有时间限制的部署与评估，并指出其本质上是一个 A/B 过程。

金丝雀发布设计

在 Google SRE 的金丝雀章节中，策划人员应当借鉴的原则有五项：

1. 从小规模起步。 缺陷造成的影响与暴露在缺陷下的流量成正比。
2. 与对照组对比。 金丝雀发布是将变更部分与其余服务（对照组）进行对比的过程。时间是引起观测指标变化的最大因素之一，因此不应对比发布前后，而应与同一时间段内的对照组对比。
3. 精选指标。 指标必须能够暴露问题、具备代表性，且能够归因于本次变更。
4. 足够久、足够大。 金丝雀发布的规模必须大到足以代表全量部署，持续时间必须足够长，且接收的流量要足以处理具有代表性的样本。
5. 一次只做一个。 切勿同时运行多个金丝雀测试。若两项变更一同发布，将无法断定指标变化究竟归因于哪一方。

在 AI 功能的金丝雀发布中，不仅要看系统指标（错误、延迟），还要结合质量与用户行为指标（举报率、转人工客服率、重新生成率）。因为 AI 的失效往往在没有返回错误响应的情况下发生。

中止标准与回滚

中止标准必须在发布前用具体数字确定。例如写成“若举报率比对照组高出 0.5 个百分点以上则中止”、“未引用依据的回答超过 2% 则中止”。若在看到结果后再定标准，往往会迎合结果去调整标准。

中止标准中还应注明判定所需的最小样本量。60 次对话中出现的 2 个百分点差异可能是偶然，而 2 万次对话中出现的差异则绝非偶然。以比率判定的指标，在样本不足时既不扩大也不回滚，而是保持曝光比例并延长观察。一旦在充足样本下超过阈值，应不存争议地立即停止并回滚，随后调查原因。但是，对于个人信息泄露、有害生成内容、违法违规等哪怕一例也不容许的即时中止条件，无论样本量大小，一经发现便立即停止并回滚。哪些条件属于即时中止，也必须在发布前明确记录。Google SRE 指出，一旦发现问题，应停止部署并回滚，或召集人员排查解决。在超标状态下直接推送修复版本，无异于再次将未经检验的变更暴露出去。

回滚方法同样要在发布前完成测试。确认关闭特性开关后是否能恢复至先前状态，并预先规定好如何纠正已经处理的结果（已发送的消息、已执行的工具调用、已计入的结算账目）。发送更正说明、冲正反向交易处理、责任人手动校正等措施中究竟由谁执行哪一项，都要写入发布计划书。

A/B 实验的前提条件

A/B 实验是将效果归因于功能的最可靠方法，但必须满足一定条件：

1. 风险较低。 向半数用户展示新方案必须是可接受的。
2. 流量充裕。 必须积累足够区分目标指标差异与偶然波动的样本量。
3. 目标指标明确唯一。 若在看结果后再挑指标，容易把偶然差异误当成方案效果。
4. 设有护栏指标。 即便目标指标改善，但若举报率或退款率恶化也必须停下。
5. 严格随机分组。 若让用户自行选择，就会导致对比的群体本身具有不同的属性偏好。

Anthropic 阐述道，A/B 实验是在具备充足流量时验证重大变更的方法。若流量不足，则不应强行实验，而应结合运营指标、日志审查与用户访谈综合观察，并在汇报时如实调低结论的确定性。

运营指标的分层

运营指标应划分为四个层级，方能严密无虞。

仅看系统指标会漏掉捏造的回答，因为系统可能在没有任何错误响应的情况下输出似是而非的错误答案。Google PAIR 指南中所说的“背景错误”（Background Error），即用户与系统均未察觉是错误的失败，甚至可能连用户行为指标都无法捕获。因此，必须引入质量层的指标，例如依据引用比例，或是对每日抽样进行自动打分与人工评阅。相反，如果智能体反复调用同一工具但最终给出了正确答案，这种失败在质量指标上体现不出来，却会反映在单请求 token 数等成本指标上。

告警设计

指标只有在有人关注时才有意义。设计告警需要明确三要素：

1. 阈值。 超过什么数值触发告警。需了解平时的正常波动范围，并将阈值设定在波动范围之外。
2. 接收人与处置动作。 谁来接收，接收后做什么（排查、功能降级、停用）。
3. 紧急程度。 区分需要立即响应的事项（服务故障、个人信息泄露、费用暴增）与可在下一个工作日处理的事项（平缓的质量下滑）。

有时仅靠告警无法有效控制成本。针对智能体循环调用导致几小时内费用暴增的事故，应在提供商控制台设置支出限额等硬性上限。Claude 文档说明，一旦达到为组织或工作区设置的支出限额，API 将返回错误。

NIST AI RMF 要求监控运行中系统的功能与行为（MEASURE 2.4），并在部署后监控计划中纳入捕捉并评估用户及利益相关方反馈的机制、申诉与撤销机制、系统废弃、事故响应、恢复以及变更管理（MANAGE 4.1）。告警是该计划的神经网络。告警若过于泛滥，便会无人理会；因此，若某项指标无法明确回答“收到此告警后该做什么”，就应将其放在监控大盘中，而非设为告警。

模型与提示词变更管理

AI 功能即便代码未变，本身也会发生变化。修改了提示词、更换了模型、抑或是提供商淘汰旧模型或修改 API，都会导致输出结果不同。因此，必须像管理代码一样管理提示词与模型配置。

1. 留存版本。 将提示词、模型名称、配置作为版本记录下来，并在运行日志中记录由哪个版本生成的回答。
2. 生效前运行回归评测。 哪怕改动一行，也可能改变其他类型的回答。应使用回归测试集逐案对比。
3. 更换模型需综合考量质量、延迟与成本。 即使提示词相同，模型一旦更换，生成效果与成本也会随之改变。
4. 分阶段发布生效。 重大变更需通过金丝雀发布逐步推行。

必须为模型生命周期做好准备。Claude 文档将模型状态划分为 Active（完全支持，推荐）、Legacy（不再更新，后续可能停止支持）、Deprecated（仍可运行但不推荐，已确定替代模型与退役日期）、Retired（不可用，请求将报错）。公开模型会在退役前至少 60 天发出通知，并建议在退役日期之前尽早使用新模型完成测试。不仅是模型本身，该文档的参数弃用表中指出，temperature、top_p、top_k 等采样参数在 2026-10-21 API 版本中已被移除，若指定则会返回 400 错误；即便在更早的 API 版本中，若对 Claude 4.7 及后续模型传入非默认值，也会引发 400 错误。定期查阅提供商的公告同样是运营工作的重要一环。

事故响应

AI 功能的事故形式多样，包括错误指引、个人信息泄露、不当生成内容、费用激增等。响应顺序如下：

1. 控制扩散。 关闭该功能，或将相应类型分流至人工，或回滚至先前版本。
2. 排查受影响人群，予以告知并纠正。 若仍有人可能因轻信错误信息而采取行动，告知排查应放在首位。
3. 修复原因并恢复。 查明原因并完成修复后，通过回归评测验证新版本，随后分阶段重新放量。
4. 将记录整理为报告。 响应过程中持续记录系统状态与采取的措施，事后将经过、影响、原因及措施整理成事故报告。
5. 进行复盘。 绝不归咎个人，围绕诱发原因展开分析。
6. 落实并核验防重演措施。 明确责任人与完成期限。

NIST AI RMF 要求向包括受影响群体在内的相关方通报事故与错误（MANAGE 4.3）。绝不能认为修复原因并重新部署就意味着事故响应的终结，因为此前已经接收到错误指引的人依然存在。

不指责复盘

Google SRE 将复盘（postmortem）定义为记录事故及其影响、为缓解或解决问题所采取的措施、根本原因以及防止重演的后续措施的文档。召开复盘的触发条件示例包括：对用户可见并达到一定程度的故障或质量下降、任何形式的数据丢失、以及责任人的介入（部署回滚、切流等）。同时，SRE 强调，不指责的复盘不应归咎于个人或团队，而应聚焦于找出事故的促成原因。

在 AI 功能的复盘中，常见的诱发原因如下：提示词变更未经验证回归评测便直接生效；评测集中缺乏相应类型用例；质量指标未配置告警；复核人员无法查看回答依据。防重演措施必须针对这些根因发力：将事故案例补充至回归测试集中、补齐遗漏的告警、改进变更流程。将运营对话纳入评测集时，须先行对个人信息进行脱敏或去标识化处理。Google SRE 同样建议事故指挥官在响应期间维护一份实时更新的事故文档，并妥善保留该记录以用于复盘分析。

依据运营数据确定改进优先级

随着运营数据的积累，需要修复和改进的事项也会随之增多。鉴于改进人力有限，必须排定先后顺序。NIST AI RMF 建议根据影响程度、发生可能性、可用资源或方法来确定已记录风险的处理优先级（MANAGE 1.2）。

在实际工作中，针对每种失败类型，通常会计算“每月发生次数 × 单次损失 × 实际触达客户的比例”。既有管控措施（校验环节、人工复核）所拦截的部分，将从最后一项中扣除。

从该表来看，排在首位的并非看似最为危险的“无依据指引”，而是过度拒答。然而，并非所有决策都仅凭数字来定，也有例外情况。对于法律与安全隐患，或是可能严重损害信誉的类型，即便发生次数很少，也必须单独确认既有管控是否充分。将类型名称带来的主观印象与实际造成的损失区分开来，是此类判断的核心所在。

分阶段发布计划书

[分阶段发布计划书]
功能与版本：
发布范围：用户群 / 包含类型 / 排除类型及其处理链路
发布方式：影子 / 金丝雀 / Beta / A/B，选择原因
阶段：例）1% → 10% → 50% → 100%（根据流量与风险动态调整），各阶段最小周期与最小样本量
对比对象：同一时间段对照组
中止标准：指标、阈值、判定最小样本量
回滚方法：开关、旧版本、已处理结果的处置措施
运营指标与告警：系统 / 质量 / 用户行为 / 业务，接收人与处置动作
变更管理：提示词与模型版本、回归评测触发条件、提供商公告核查周期
事故响应：联络机制、复盘触发条件

深入阅读

更改指标的诱惑

上线后，如果目标指标没有起色，人们往往会想去寻找其他指标。“转化率虽然没有变化，但推荐点击量增加了30%。”这份报告固然不是假话，但也绝非该功能实现了既定目标的证据。如果点击量增加而购买量毫无起色，这可能意味着推荐只是引起了用户的好奇，并没有真正发挥作用。

Google PAIR指南警告称，优化短期内看起来不错但在长期可能带来危害的指标（例如分享量），并建议设想一下当指标被完全优化时，用户和社会会发生什么。目标指标与护栏指标应在上线前确定，若结果不理想，应查明原因，而不是更换指标。只有当有证据表明最初选定的指标无法衡量目标，且该证据与结果本身无关时，更换指标才是合理的；即便在这种情况下，也必须记录更换指标的原因。

静默质量下降

即使什么都不改动，AI功能的质量也可能会下降。随着用户群体的扩大，输入的分布会发生变化（新地区、新商品类别、新表达方式），依据文档的更新会导致陈旧引用的残留，供应商的模型也会发生更替。而上线时的评估集并不知道这些变化。

捕捉这种静默下降的方法有三种。一是每天或每周从运营日志中抽取样本，采用相同的评分方式打分并观察趋势。二是将输入的类型分布与上线时进行对比，观察是否出现了更多的新类型（输入分布的变化通常称为数据漂移）。三是观察用户行为指标（重新生成、转人工客服）的趋势。如果这三者中有任何一个出现波动，就应查阅日志，并将新发现的失败用例补充到评估集中。

关停功能的决定

并非所有的AI功能都必须一直运行。当运营成本超过效益、用户不再使用，或是风险无法控制时，缩减或关停该功能也是一种运营决策。NIST AI RMF要求设立相应的机制与职责，以便对偏离预期用途的系统进行替换、解除或关停。

关停功能同样需要周密的计划。需要提前通知用户，指引替代路径，按照既定策略处理该功能遗留的数据（对话记录、生成内容），并记录关停的原因。关停判断的依据若以第1章的AI适用性评估备忘录（课题、吞吐量、解决方案、数据与成本条件、法律合规审查、结论）相同的格式保留，日后当再次提出相同构想时，就能清楚知道需要做出哪些改变。

工作场景

新芽银行的转账咨询业务

互联网银行“新芽银行”计划上线一款解答转账额度与手续费咨询的AI客服。该业务每日咨询量达3万件，且在离线评估中全部通过了拦截标准。不过，由于跨境汇款手续费类型未达到标准，团队决定将其移出服务范围，转入现有的人工客服渠道。

产品经理选择了金丝雀发布。因为结果由客户查看，即便出错人工客服也能进行纠正，回滚成本较低，同时还需要观察真实客户的投诉率以及转人工率。阶段划分为 1% → 10% → 50% → 100%，判定条件设定为：1%阶段至少观察3天且累积900次对话，从10%阶段起至少观察3天且累积5,000次以上对话。中止标准为“手续费错误引导投诉率比对照组高出0.3个百分点以上”以及“无依据引用的回答超过1%”。原定在同一时期进行的App首页改版被推迟到金丝雀发布结束之后。因为如果两项变更重叠，将无法确定指标变化究竟归因于哪一方。

在10%阶段的第3天，该阶段累计对话9,000次，其中无依据引用的回答占比达到1.6%，超过了标准。团队立即停止扩大规模，关闭功能开关，将所有咨询导回原有的人工客服渠道，并开始排查原因。调查发现，由于手续费规定文档发生修订，旧文档与新文档被同时检索到了。在核对了1%和10%阶段的全部记录后，发现共有152次对话提供了旧手续费的错误指引。团队向这些客户发送了更正通知，修复了文档索引，并在通过回归评估后重新从1%阶段开放。随后，团队举行了复盘会。复盘会上制定的防复发措施包括“依据文档修订时移除旧版本索引的流程”以及“将文档修订日期添加到回归评估触发条件中”。被否决的方案则是“在提示词中加入优先参考新文档的语句，并直接以相同比例重新开放”。因为当时尚未确认根本原因，这样做相当于重新暴露未经检验的变更；而且仅凭提示词指令，也无法彻底避免检索索引中残留的旧文档被召回。

晚霞视频的搜索助手运营

视频服务平台“晚霞视频”的AI搜索助手已运营了四个月。下一季度负责优化的团队人力仅能承担两项课题。从运营数据中提取出的候选问题共有五项：演员姓名关联错误的故障、成人内容混入儿童个人资料结果的故障、响应延迟、无法理解搜索词而拒绝回答的情况，以及推荐结果每次都大同小异的问题。

产品经理制作了一张表格，根据每月发生频次、单次危害程度以及实际暴露给客户的比例，计算出了每月损失。其中，拒绝回答的频次最高，达每月2万件，用户被拒绝后流失导致播放量下降。儿童个人资料错误虽然每月仅有6件，但有2件穿透了拦截过滤器并实际展示给用户，可能引发法律风险及信任危机。产品经理从数据规模上将拒绝回答选为第一项课题，将发生频次虽少但管控机制被穿透的儿童个人资料错误选为第二项课题。这是明确区分了“已被控制的风险”与“已被突破的风险”后做出的决定。

团队还对变更管理流程进行了整顿。此前，提示词一直由负责人在需要时直接在生产环境中修改。现在改为对提示词进行版本管理，仅在每周二的例行发布时运行400条回归用例集，只有通过的版本才能以10%的金丝雀形式发布。此外还制定了一条规则：每月第一周检查模型供应商的弃用公告，一旦发布下线公告，须在当周使用备选模型运行全量评估。

易错点

1. “既然通过了离线评估，就可以直接全量上线。” 真实用户及其输入与评估集存在差异。应当限制曝光范围，边测量边逐步扩大。
2. “金丝雀只需对比发布前后的表现即可。” 时间是导致指标发生变化的最大因素之一。必须与同一时期的对照组进行对比。
3. “中止标准可以根据观察到的结果再决定。” 看过结果之后再定标准，往往会迁就结果。必须在上线前明确具体数值和最小样本量。
4. “一旦超标，修复后直接重新发布即可。” 应先暂停并回滚，查明原因后再行动。切勿重新暴露未经检验的变更。
5. “将多项变更合并分步发布可以节省时间。” 这会导致无法进行效果归因。同一时间只运行一个金丝雀。
6. “只需观察错误响应和延迟就能掌握运行状态。” AI的失败往往在没有报错的情况下发生。必须同时监控质量指标和用户行为指标。
7. “被停止支持的模型在下线日期之后只是变慢，仍然可以正常运行。” 发送给已下线模型的请求会直接失败。必须在下线日期前留出充分时间完成替代评估。
8. “只要修复原因并完成部署，事故处理就结束了。” 必须向接收到错误引导的用户发出通知，做好记录，并落实防复发措施，处理才算真正闭环。

要点速览

查阅官方文档

• Google SRE Workbook — Canarying Releases：金丝雀发布的定义、对照组对比、指标选择、周期与规模、一次只测一项。
• Google SRE Book — Postmortem Culture: Learning from Failure：复盘的定义与前提条件、免责复盘。
• Google SRE Book — Managing Incidents：处理过程中持续更新的事故文档。
• AWS — Amazon SageMaker AI shadow tests：影子测试的工作机制。
• Claude Docs — Model deprecations：模型生命周期、下线公告期、API参数弃用。
• Anthropic — Demystifying evals for AI agents：自动评估、生产环境监控、A/B测试与人工审核的组合。
• NIST AI RMF — Core：MANAGE 1.2（优先级）、2.4（替换·解除·关停）、4.1（部署后监控）、4.3（事故通知）。
• Google PAIR Guidebook — User Needs + Defining Success：奖励函数与短期指标优化的风险。

自测

5-1. 写出 Google SRE 对金丝雀指标要求的三个特性。

5-2. 影子测试无法衡量什么？如果需要衡量该内容，应该采用哪种发布方式？

5-3. 阐述在中止标准中必须同时注明最小样本量的原因。

5-4. 写出运营指标的四个层级，并解释编造的回答为何不会被错误响应率捕获。

5-5. 写出 Claude 文档中模型生命周期的四个阶段，并说明在最后一个阶段中请求会如何被处理。

5-6. 按顺序写出事故响应的六个阶段。

5-7. 现有两种类型：一种每月 50 起、每起损失 4 万韩元、在验证阶段有 90% 被拦截；另一种每月 1,200 起、每起损失 2,000 韩元、没有任何拦截机制。若按每月损失进行对比，哪一种更优先？

5-8. （设计）请按本章的格式，为当前负责的 AI 功能编写一份分阶段发布计划书，并在其中为两个中止标准附上最小样本量。

实操练习