第七部分 · 评测 · 第 53 章

运营评测与治理

作者Changkun Ou

阅读时长约 14 分钟

离线评测止于一个结果，运营评测止于一项运营决策。这项决策要说明完整系统版本是继续推广、暂缓上线、缩小适用范围、回滚，还是升级处置，同时说明什么新证据可以改变决定。受审查的不只是一个模型名称，而是模型连同提示、检索数据、工具、政策、路由和服务配置组成的完整系统。

本章为第七部分收尾，把测量、部署、监控和学习连接起来。前几章已经定义了有效任务、统计比较、人类评分准则、模型评判者、事实性检查和智能体结果；这里要把这些测量工具汇成一个发布循环。具体的实现工具将在第 87 章介绍，本章关注的是这些工具必须执行的运营契约。

图 53.1. 质量、成本和延迟共同形成 Pareto 前沿：在前沿上的每个运营点，任何一项已测指标的改善都会以另一项变差为代价。位于前沿后方的点，会被另一个已测选项支配。此图仅作示意，不代表实测数据。

运行前先写好发布政策

研究比较要回答的是：在已公布的协议下发生了什么。发布门禁要回答的则是：一个明确的候选版本能否影响一个明确的目标群体。因此，门禁是一项有版本的政策，不是一张看起来有利的图，也不是开会时临场作出的判断。

这种做法早于生成式 AI。Sculley 等人在 2015 年指出，数据依赖、配置、监控及其他外围机制会在机器学习系统中积累隐性技术债。Breck 等人随后在 2017 年把生产就绪程度定义为跨越数据、模型、基础设施和监控的一组测试 (Sculley et al. 2015; Breck et al. 2017)。生成式系统扩大了受测范围，却没有改变这个基本事实：发布决策属于已部署的完整系统及其运行环境。

一份最小的门禁规范会明确写出这个范围：

ReleaseGateSpec:
  decision_id
  candidate_system_hash
  baseline_system_hash
  target_population
  evaluation_manifest_hash
  metric_and_scorer_versions
  primary_decision_rule
  guardrail_margins
  invalid_outcome_policy
  stage_plan
  rollback_target
  decision_authority
  override_policy
  evidence_expiry

两个系统哈希覆盖每个会影响行为的组件，包括模型版本与路由、解码政策、提示、工具与 API 模式、检索器与语料库、安全政策、沙箱和应用代码。目标群体说明决策适用于哪些用户、任务、语言、风险等级和时间段。无效结果政策预先规定超时、评分器故障、标签缺失和基础设施失败如何进入分析。整份规范必须在确认运行开始前写好。仪表盘是证据，不是政策。

统计规则可以写得很紧凑。设 $v$ 表示候选系统版本， $b$ 表示基线版本。对于越高越好的质量指标 $j$ ，在预先声明的切片 $s$ 上，定义

\Delta_{js}(v,b)=q_{js}(v)-q_{js}(b).

其中， $q_{js}(v)$ 是候选版本 $v$ 在切片 $s$ 上指标 $j$ 的目标值， $q_{js}(b)$ 是相应的基线值， $\Delta_{js}(v,b)$ 是候选版本与基线版本之差。一条实用的发布规则可以写成

\begin{aligned} G(v) &= N(v)\land F(v) \\ &\quad \land H(v)\land E(v). \end{aligned}

其中， $G(v)$ 是最终门禁结论。只有每个必需的 $\Delta_{js}(v,b)$ 的置信下界都高于 $-\delta_{js}$ 时， $N(v)$ 才为真；这里的 $\delta_{js}\ge 0$ 是预先声明的非劣效界值。只有每个必需的 $q_{js}(v)$ 的置信下界都达到绝对质量下限 $f_{js}$ 时， $F(v)$ 才为真。 $H(v)$ 是硬性运营谓词，涵盖安全断言、有效输出、延迟上限和错误预算等条件。 $E(v)$ 是证据有效性谓词，要求运行了正确的清单、达到必需样本量、评分器通过健康检查，而且没有发生被禁止的排除。四个条件必须全部成立。对于越低越好的指标，可以反转符号，或明确写出上界谓词，沿用同一套逻辑。

这条规则区分了仪表盘经常混在一起的三种结论：通过、失败和未决。通过表示满足已声明的界值；失败表示越过阻断边界；未决表示有效证据不足，还不能排除实质性回退。未决不等于通过，政策必须说明此时是继续收集证据、缩小暴露范围，还是维持基线版本。

只要条件允许，就让候选版本和基线版本运行在同一批独立单位上，并分析配对差值，而不是比较两个互不相关的得分区间。对于分歧样本很少的配对二元结果，采用 McNemar 精确检验；对于数值型任务得分，采用保留抽样单位的配对随机化或自助法。无论使用哪种方法，都要保留效应估计及其区间，而不只是经过阈值化的检验结果。完整的分析契约见第 48 章。不能在运行结束后寻找有利切片，再把它抬成主要结论。

分阶段收集不同证据

离线套件无法代表所有生产条件，因此发布工程要分阶段扩大暴露范围。Google 的 SRE 工作手册把金丝雀定义为一种局部、有时限的部署，并将它与对照版本比较，同时强调流量代表性、指标归因、隔离和回滚 (Warner and Davidovič 2018)。AI 系统同样适用这套结构，只是每个阶段除了常规服务健康状况，还必须检查模型特有的质量指标。

图 53.2. 一次发布会依次经过四个证据阶段。任何阶段出现失败或证据不足，候选版本都会被暂缓或回滚。经确认的生产故障先成为私有套件的候选项，经过审查后才会正式进入套件。

阶段	能够证明什么	常见阻断原因	主要局限
离线确认	已知任务和锁定案例上的可复现性	质量或安全回退、无效运行、违反预算	看不到套件未覆盖的流量和线上依赖
影子流量	与当前请求及生产形态负载的兼容性	模式错误、工具缺失、检索故障、延迟或成本异常	输出不影响用户，因此缺少下游结果
金丝雀放量	有限线上群体中的行为和服务健康状况	绝对服务目标被突破，或候选版本相对对照版本回退	有限流量可能覆盖不到罕见结果或延迟结果
持续生产监控	全量发布后的持续有效性	漂移、长尾故障、违反政策、延迟显现的伤害	发现问题前已有一部分用户受到影响

影子流量会把请求复制给候选版本，却只向用户返回基线版本的回复。候选版本不得执行用户可见的写入、发送消息、扣款，或改变共享环境。有状态智能体必须运行在沙箱或只试运行的工具层中，否则所谓影子版本只是第二个生产行为者。

金丝雀版本会真正影响用户。分配流量时，应让金丝雀版本与对照版本同时运行，并把用户或整段对话固定在同一组中；每项指标还要标明系统版本。发布前后的比较会把版本变化与时间变化混在一起。先检查崩溃、无效工具调用、严重违反政策和尾部延迟等便宜且快速的阻断项，只有积累了足够证据，才扩大到下一阶段。每个阶段都需要自动停止或回滚路径，还要为含混结论指定一位负责人。

任何阶段都不能替代另一个阶段。离线确认最擅长复现已知故障；影子流量能在不显示候选输出的情况下暴露集成问题；金丝雀放量测量有限的线上影响；生产监控捕捉后续变化和罕见结果。通过最容易的阶段，并不能证明系统已经获得下一阶段才能提供的证据。

让私有套件持续有用

私有套件的价值在于，它包含组织自身的真实任务分布、政策、事故和代价高昂的边界案例。保密本身并不能保证它有效。反复调优会消耗套件的独立性，标签会过时，客户数据会带来处理义务，可执行评分器也会随依赖变化而损坏。

应按用途把案例分开：

开发套件对开发者可见并频繁运行，用于调试，因此不能充当独立确认。
锁定的确认套件在选择期间不可访问，只能由发布流程打开。它的暴露台账记录所有可能见过案例或答案的人员、系统、模型和训练作业。
诊断套件包含探索性切片、红队探针和新观察到的故障，用来定位问题，但不会悄悄获得发布决策权。

事故只是候选案例的证据，不能直接成为阻断性测试。案例必须先完成去标识化、范围审查、复现检查、标签或结果验证，以及评分器的正例和反例。一次客服报告可能完全真实，却无法复现；一条生产轨迹可能包含私密数据；一个评判者也可能只偏好原回答的措辞，而没有检查目标行为。接收流程必须先解决这些问题，下一次发布才能依赖这个案例。

每个案例都要记录来源、负责人、目标故障模式、群体标签、严重程度、不可变输入夹具、允许行为、评分器版本、暴露状态和退役条件。有状态任务还要运行重置检查。除了失败案例，也要抽查通过的案例，防止过于宽松的评分器制造套件健康的假象。当政策、事实、API 或产品行为发生变化时，应让案例退役或重新标注，同时保留它的历史，而不是改写旧发布证据。

因此，完整生命周期是：

observe -> triage -> de-identify -> reproduce -> label and test grader
        -> assign suite role -> version -> monitor exposure -> retire or relabel

这是评测数据维护，不是文书整理。隐藏依赖和未声明的使用方，恰恰会让测试基础设施变成技术债 (Sculley et al. 2015)。第 47 章讨论污染与基准有效性，第 92 章则负责接收和整理生产数据。

调整门禁前先诊断漂移

“漂移”不是根因。真正发生变化的可能是三类对象：

**系统变化：**模型端点、路由、提示、检索器、语料库、工具、政策或应用版本发生变化。
**群体变化：**用户、任务、语言、威胁或外部条件的构成偏离了发布时的目标群体。
**测量变化：**评分准则、评判者、标注人员构成、遥测覆盖、解析器或结果定义发生变化。

三类变化需要不同的处理。系统变化要与最后一个已知版本比较；群体变化可能要求增加切片、调整权重或收窄产品主张；测量变化则要把新旧测量工具应用于同一份留存证据，然后才能把行为变化归因于系统。

应结合三种互补的监控信号。固定哨兵案例用来发现本应固定的系统是否变化；抽样线上流量估计当前服务群体中的实际行为；延迟结果标签把代理得分与任务完成、纠正、申诉或事故等事件连接起来。第一种稳定但范围窄，第二种及时却需要兼顾隐私的抽样和评分，第三种最接近用户价值，却往往来得晚而且有选择偏差。直接风险监控方法可以使用抽样或延迟标签，并在反复查看结果时继续提供保证，但它仍然依赖事先声明的损失函数和抽样过程 (Podkopaev and Ramdas 2022)。

输入分布告警可以帮助定位变化。Rabanser、Günnemann 和 Lipton 比较了多种数据集迁移检测方法，发现在他们研究的图像迁移中，基于表示的双样本方法表现有效 (Rabanser et al. 2019)。这个结果并不意味着提示嵌入之间的距离就是质量结论。分布告警不能证明质量回退，稳定的输入分布也不能证明行为稳定。应把信号送去调查，再检查受影响切片上的实际结果。

欠定性还带来另一项警告：如果测试没有约束所有相关行为，那么留出集得分相近的系统，在部署后仍可能表现不同 (D'Amour et al. 2022)。因此，运营监控必须保留结果和切片证据，不能只确认汇总数字看起来接近发布时的得分。

每个分数都必须能够重建。OpenTelemetry 的生成式 AI 语义约定目前仍处于开发状态，它为常见的模型、智能体、工具、评测和跨度数据提供了共享名称 (OpenTelemetry 2026)。这些约定只能覆盖可审计评测记录的一部分，其中的提示、输出和工具内容还可能很敏感。应固定约定版本，使用哈希或受控的工件引用，不能不加选择地复制原始内容。语义约定不能标识整个实验，应用仍需保存自己的不可变发布记录：

ReleaseDecision:
  decision_id
  system_component_hashes
  evaluation_result_ids
  rollout_stage
  traffic_assignment
  stage_results
  monitoring_window
  override_actor_and_reason
  override_expiry
  decision_and_timestamp
  rollback_target_and_trigger
  incident_followup_ids

evaluation_result_ids 指向第 48 章定义的不可变统计记录，其中已经包含群体、套件、评分器、原始结果、排除项、估计值和区间。发布记录再补上分析本身不知道的信息，包括放量阶段、决策权限、监控窗口和回滚动作。记录及其后续更正都要保存为只追加的证据。重新评分会生成一条新结果，并链接到旧结果；它不能覆盖当时实际作出的决定。从先前运行复制的证据也必须保留原始系统身份和证据年龄，否则一份报告可能表面上可复现，实则悄悄混合了不同条件。

选择运营点前先比较前沿

原始任务质量只是生产决策的一条轴。候选版本还会消耗资金和时间，增加人工复核负担，并带来未必可以互换的风险。应先报告 Pareto 前沿，剔除那些在所有已测指标上都没有更好、且至少一项更差的选项，再在剩余选项中按照产品约束作出选择。

图 53.3. 质量、成本和延迟共同定义运营前沿。拖动政策权重可以看到，质量最高的点未必总是最终选择。此图仅作说明，不能代替发布决策。

如果各项权衡确实可以放在同一尺度上，一项预先声明的效用函数可以让选择过程接受检查：

\begin{aligned} U(m) &= Q(m) - \lambda_c C(m) \\ &\quad - \lambda_l L(m) - \lambda_r R(m). \end{aligned}

其中， $m$ 是一个完整系统选项， $Q(m)$ 是任务质量值， $C(m)$ 是每项任务的计量成本， $L(m)$ 是预先声明的延迟统计量， $R(m)$ 是在既定政策下测得的预期复核或事故负担。非负权重 $\lambda_c$ 、 $\lambda_l$ 和 $\lambda_r$ 把这些负担换算到与质量相同的决策尺度。权重是政策选择，不是评测自动学到的事实。

输入必须具体。报告中位数和尾部延迟，不能只报平均值。把网关或计费台账中的计量成本与每次运行关联起来，不能依据过时的价目表估算账单。还要包含无效运行率和回退率，并说明效用代表谁的负担。

标量只能在硬边界之后使用。当产品不能用其他收益抵消严重的质量回退时，质量护栏仍应作为约束。一个危险选项不会因为更便宜或更快就获得许可，标量不能授权安全权衡。成本问题由第 76 章进一步展开，第 82 章和第 91 章则分别决定延迟与复核负担。

让决策经得起会后检验

当证据、权限和后续行动能够在发布会议结束后继续存在，治理才真正开始。模型卡提供了记录预期用途、评测流程和分组表现的结构 (Mitchell et al. 2019)。Datasheets for Datasets 记录数据资产的动机、构成、收集、使用和维护方式 (Gebru et al. 2021)。NIST 的 AI 风险管理框架把风险工作组织为治理、映射、测量和管理，并明确说明该框架自愿采用且不限定使用场景 (Tabassi 2023)。这些工件各自覆盖不同范围，任何一种都不能替代发布记录。

每项阻断指标、每个套件和每个生产监控项都要指定负责人。每次人工决定都要记录审查过的证据和所行使的权限。覆盖门禁意味着作出一项新决定，而不是删除失败记录。覆盖决定必须有期限，写明接受风险的负责人、理由和补偿控制；必要时缩小流量，并设定强制重新审议的证据条件或日期。

事故发生后，要分别记录四项结果：

用户或系统受到的影响；
促成事故的系统故障和测量故障；
纠正措施及负责人；
回归候选项或明确接受的风险。

回归候选项随后进入私有套件的接收流程。如果它可复现而且与决策相关，就进入有版本的套件。如果它不能成为测试，接受风险的记录必须说明原因和监控方法。这样可以避免“每次事故都变成测试”这类口号，把套件塞满脆弱或不符合隐私要求的夹具。

一次实用的运营审查会提出七个问题：

这项决策覆盖哪个完整系统和目标群体？
哪些锁定证据支持主要结论和每项护栏？
配对、不确定性、无效结果和切片是否按声明处理？
离线、影子和金丝雀阶段分别增加了什么证据？
哪些生产信号可以停止发布或触发回滚？
谁负责决策、覆盖、回滚和证据到期？
已确认故障将如何在不污染确认数据的前提下闭合循环？

如果任何答案只存在于某个人的记忆中，这道门禁就还没有真正进入运营。

争议所在

争议的边界在于，多少决策权限可以交给自动化。确定性的安全断言、模式有效性、服务目标和预先声明的统计界值，适合自动触发暂缓或回滚。开放式质量判断、政策变化、稀少但严重的伤害，以及指标之间的冲突，往往需要人工复核。人工复核不等于可以临场发挥，复核者仍需承担已声明的角色，使用同一份证据记录，并说明决定理由。自动化也不是中立的，过时的套件或有偏的评判者可能会稳定地执行一项错误政策。

下层约束

运营评测依赖部署和可观测性基础。如果没有稳定的系统哈希和轨迹标识符，第 87 章就无法重建证据。如果没有隔离的影子执行、流量分配、分阶段路由和已知可用的回滚目标，第 89 章就无法执行门禁。如果缺少第 52 章所定义的版本化任务和最终状态检查，智能体结果又会退回自报成功。治理只能在下层先把控制做实之后，才把决策权限交给它。