评测与可观测性

评测不是从排行榜或工具开始，而是从一次评测发布开始。所谓评测发布，是针对完整系统某个版本作出一项明确决策，并给这次决策一个稳定的名称。在运行任何评测之前，先固定系统指纹、决策主张、目标总体、关键分层定义、发布门槛和回滚目标。结果应当帮助负责人决定是合并、金丝雀发布、扩大流量、停止还是继续运行，而不只是说明某个仪表盘数字发生了变化。

本章把 第 47 章、第 48 章、第 49 章、第 50 章、第 51 章、第 52 章 和 第 53 章 中的测量原则整理成一套运营流程。评测对象是正在运行的完整应用，包括服务层（第 82 章）、模型网关（第 88 章）、检索系统、智能体（第 85 章）以及任何微调模型（第 84 章）。

固定发布契约

一份完整的契约会在看到结果前回答六个问题。

系统指纹之所以重要，是因为模型名称不等于系统身份。即使应用版本号没变，提示词、索引、工具描述、安全策略、解析器、路由或提供商别名发生变化，都可能改变应用行为。每项评测结果都应绑定不可变的组件摘要。否则，生产机器学习系统会逐渐积累隐藏依赖，并在环境变化时暴露出故障 (Sculley et al. 2015; Breck et al. 2017)。

三项不同的工作

评测要回答的是：已声明的证据是否足以支持针对固定系统作出某项决策。可观测性（observability），也就是可观测性，会记录足够的结构化事件，用来重建运行中的系统做了什么。监控会持续比较指标与阈值，并把异常交给明确的负责人。三者可以共用存储和埋点，但它们回答的问题不同。

一条追踪记录只是部分证据，不是标签，也不是真值。埋点可能缺失、被采样、丢弃、脱敏或记录错误，质量分数也可能出错。必须保留这些区别，否则遥测数据导出失败反而会看起来像产品质量提升了。

构建评测数据集

一个评测用例包含版本化的输入，以及评分所需的环境、预期行为、允许执行的操作、标签来源、隐私状态和分层元数据。还要记录它来自设计场景、公开基准、合成生成器、专家复核还是生产环境。

生产流量很有价值，但它本身已经经过选择。使用这些数据必须有用户同意或其他有效的使用授权。一条追踪记录进入任何评测集之前，应先脱敏、筛查并初步分类、裁定预期行为、去重，再分配到相应的数据集。三类数据应始终分开：

• 用于迭代提示词、策略和评分器的开发集；
• 用于事故、对抗用例和探索性分层的诊断集；
• 用于确认结论的锁定留出集。

分配数据集之前，先按可能发生泄漏的单元分组，例如用户、租户、对话族、代码库、源文档或时间块。随后搜索数据集之间完全相同和高度相似的内容。留出用例、答案、标签或近义改写只要影响过提示词、检索器、裁判、解析器或候选系统的选择，就应标记为污染，不得再用作确认性证据 (Kapoor and Narayanan 2023)。

用例不是试验

一次随机性试验是某个系统在一个评测用例上的一次运行，它需要记录随机种子和环境快照。重复试验能估计运行波动，但不会创造出另一个独立用户、任务或文档。保留每一次超时、拒答、解析失败、工具错误和空结果。只有生产系统也采用相同的选择策略时，从多次尝试中挑最好的结果才有效。

独立单元和用例权重必须与部署主张一致。在对话产品中，轮次和文本片段嵌套在对话中；在代码库助手中，文件和工具调用可能嵌套在一次代码库任务中。行数不等于样本量。

评分时不要掩盖失败

每项准则都应优先使用最直接的证据。

1. 确定性检查会执行一项不变量，例如 Schema 有效性、授权、精确计算、工具参数、引用是否存在或延迟上限。输出能够解析，不代表语义就一定正确。
2. 任务或参考评分测量可观察的结果，例如通过的测试、找到的证据、得到支持的主张、完成的轨迹或达成的用户目标。
3. 人工判断在需要专业知识和上下文时，按彼此独立的评分准则作出判断。
4. 合格的模型裁判近似执行一套具体的人工或可执行评分流程。
5. 运营指标测量可用性、端到端延迟、资源用量或成本。安全性准则应另行测量策略违规率和攻击成功率。

不要把这些证据压缩成一个所谓的“质量”数字。报告所有预先声明的分层，尤其是样本量小或风险高的分层。将 pass、fail、invalid、error、abstain 和 fallback 分开记录。对小样本分层，应当得出“尚未确定”的结论，而不是默认它安全。总体指标提升也不能掩盖其中某个分层的退步。HELM 采用多指标、多场景的框架，正好说明了为什么不应用单一分数代替评测 (Liang et al. 2023)。

比较完整的系统修订版本

如果指标的数值越高越好，就在相同用例和可比环境中比较候选系统 $B$ 和基线系统 $A$。这里，$i$ 表示用例，$R_i$ 表示重复次数，$s$ 表示分数，$w_i$ 表示预先声明的用例权重。先计算每个用例的平均配对差 $\bar{\Delta}_i$，再得到总体估计：

$$\begin{aligned} \bar{\Delta}_i &=\frac{1}{R_i}\sum_{r=1}^{R_i} \left(s_{ir}^{B}-s_{ir}^{A}\right),\\ \widehat{\Delta} &=\frac{1}{\sum_i w_i} \sum_i w_i\bar{\Delta}_i. \end{aligned}$$

其中，$s_{ir}^{B}$ 是候选系统的分数，$s_{ir}^{A}$ 是同一用例、同一次重复中基线系统的分数，$\widehat{\Delta}$ 是按部署权重加权后的配对变化。候选系统和基线系统应共用用例、语料快照、工具策略、预算和评分器。如果两种实现对同一随机种子的解释不同，不要强行共用种子。

报告该估计量的置信区间。对用例重采样，或对契约中声明的更高层单元重采样，例如用户、对话、代码库或文档簇。不要重采它们内部嵌套的轮次、片段或重复试验。分层 bootstrap 可以同时表示用例差异和运行波动；当多行数据共享同一部署单元时，按行 bootstrap 会凭空增加信息 (Efron 1979; Bouthillier et al. 2021)。

预先声明发布门槛

设 $L_j$ 是经过方向统一后，第 $j$ 项准则与分层变化的置信下界，$\delta_j$ 是允许的非劣效界值。发布可以要求每个必需的分层和准则都满足：

$$L_j \ge -\delta_j.$$

这项规则同时要求所有硬性约束通过。例如，跨租户访问必须为零，工具授权必须有效，风险上界必须低于上限，尾部延迟也不得超过预算。不存在通用的界值或置信水平。应根据后果、所需精度、样本设计和决策成本来选择。确认性主张要事先声明；如果要从多个结果中搜索有利结论，就要处理多重比较 (Dror et al. 2018)。

“没有观测到失败”不等于风险为零。关键事件稀少时，应报告不确定性上界。如果样本无法排除风险上界，那么门槛结果是尚未确定。硬性策略失败仍可以直接阻止发布，即使其估计发生率尚不精确。

把模型裁判当作测量工具

模型裁判能够扩大复核能力，但它是一种受版本管理的测量工具，不是神谕。固定裁判修订版本、评分准则修订版本、提示词、解码设置、候选项顺序、输出 Schema 和解析器。随后，针对它将要评分的每项准则和分层，在锁定的人工标注集上完成验证。

报告混淆矩阵、假通过率、假不通过率、弃权、解析错误、不确定性以及与人工判断的分歧。通过交换候选项顺序和标识来测试位置偏差；用不改变语义的扩写测试冗长偏差；分别使用带有生成器身份信息的输出及其改写版，测试自偏好；另外还要测试多次运行的稳定性，以及候选内容中的提示注入。研究已经记录了位置、冗长和自偏好效应，因此改用另一个模型家族只是一项待测试的假设，不是独立性的证明 (Zheng et al. 2023; Wang et al. 2024; Panickssery et al. 2024)。G-Eval 表明，由评分准则引导的裁判可以在具体任务上更接近人工判断，但它不是通用有效性的证明 (Liu et al. 2023)。

Cohen's kappa 会根据边际标签频率，扣除预期的偶然一致 (Cohen 1960)：

$$\begin{aligned} p_o&=\frac{1}{n}\sum_{a\in\mathcal C}n_{aa},\\ p_e&=\frac{1}{n^2}\sum_{a\in\mathcal C}n_{a\cdot}n_{\cdot a},\\ \kappa&=\frac{p_o-p_e}{1-p_e}. \end{aligned}$$

其中，$\mathcal C$ 是标签集合，$n_{ab}$ 是人工标签为 $a$、裁判标签为 $b$ 的用例数，$n$ 是用例总数，带点下标表示边际总数。Kappa 衡量一致性，不衡量正确性或安全性，而且会随标签基率改变。它应与各准则的错误率和置信区间一起报告，不能作为通用的信任门槛。

def cohen_kappa(matrix):
    total = sum(sum(row) for row in matrix)
    observed = sum(matrix[i][i] for i in range(len(matrix))) / total
    row_totals = [sum(row) for row in matrix]
    col_totals = [sum(matrix[r][c] for r in range(len(matrix)))
                  for c in range(len(matrix))]
    expected = sum(r * c for r, c in zip(row_totals, col_totals)) / total**2
    return observed, (observed - expected) / (1 - expected)

# 行是人工标签，列是裁判标签：[不好，好]。
agreement, kappa = cohen_kappa([[16, 4], [18, 162]])
assert round(agreement, 2) == 0.89
assert round(kappa, 2) == 0.53
print(f"agreement={agreement:.2f}, kappa={kappa:.2f}")

谨慎地把生产证据纳入评测

持续评测循环应该不断强化评测集，而不是污染它。用户投诉、事故、裁判分歧或异常追踪首先进入诊断队列。负责人要核实使用授权、删除敏感数据、重建系统指纹、确认用例是否可重现、标注或裁定预期行为、去重，并分配数据集角色。只有完成这些工作后，它才能成为回归用例。

生产数据应维护两类样本：

• 用于估计总体行为的概率采样或分层采样；
• 用于发现事故、罕见故障、投诉和不确定用例的风险队列。

风险队列对发现问题很有价值，但它的平均值不是总体发生率。对用于推断的样本，记录纳入概率、分配单元、无响应情况和标签延迟。用户反馈、重试和放弃行为都是经过选择的观察信号，无法单独识别某次发布的因果效应。如果决策需要因果主张，应使用随机且粘性的分流，并保留有效的曝光日志 (Kohavi et al. 2009)。

定义追踪契约

一次追踪（trace）把同一个分布式请求或任务中的工作组合起来。每个跨度（span）都需要追踪 ID、跨度 ID、存在时的父跨度、操作名称、开始和结束时间、状态与属性。跨度事件记录跨度内带时间戳的事件，跨度链接则连接存在因果关系、却不是父子边的工作。队列、扇出、重试和多智能体工作都依赖这些区别。

对于 AI 操作，记录不可变的系统指纹、模型与路由、提示词和策略标识、检索与工具修订版本、输入摘要、输出摘要、用量、缓存结果、重试次数和证据 ID。关联这些工作并不需要记录原始内容。OpenTelemetry 提供了通用追踪语义和持续演进的 GenAI 约定，但自定义属性仍需要本地 Schema 及其版本 (OpenTelemetry 2026; OpenTelemetry 2026)。

使用 W3C Trace Context 跨服务边界传播 traceparent 标识 (Kanzhelev et al. 2021)。Baggage 用来传递应用元数据，不是存放秘密的地方。不得把凭据、个人可识别信息、租户内容或授权决定放入 Baggage。外部调用方可以伪造追踪上下文，因此必须验证收到的内容。

导出前先做数据最小化

在埋点时就应用数据分类。默认不记录原始载荷，导出前完成脱敏。只有威胁模型允许时，才可以使用词元化或哈希。对敏感内容的访问权限应与普通追踪访问分开。在收集器、后端、缓存、归档和派生评测数据集中，实施租户隔离、按用途限制的角色、访问日志、保留期限和经过测试的删除。遥测通路本身就是数据系统，也属于 AI 风险管理边界 (Tabassi 2023)。

提示词、检索文本、工具结果和模型输出都是不受信任的数据。它们可能包含间接提示注入，或者专门针对之后的裁判。评测器不得拥有生产写入权限、秘密、网络工具或无上限的预算。

采样会改变估计

头部采样在请求开始时或刚开始后决定是否保留，通常使用固定概率。尾部采样等待结果信息，因此可以保留错误、慢请求、罕见路由或安全事件。尾部规则能改善诊断，也会对这些结果过度采样，使它们在样本中占比过高。

报告总体比率时，记录每个分层的纳入概率，并计算设计加权估计。在错误、罕见分层、安全信号和裁判分歧的专项保留之外，始终保留一份稳定的概率样本。否则，仪表盘展示的就会是有偏样本的结果。把缺失遥测数据、收集器队列深度、丢弃的跨度、父子关系断裂和导出失败作为一等指标。未知证据不能默认当作成功。

重放分为不同层级

精确重放需要不可变的模型制品、提示词、索引、工具结果、环境和随机状态。对托管模型别名和实时工具而言，这通常做不到。结构重放使用已记录的结果或桩（stub）替代外部依赖，重新运行同一操作图。语义重放只要求新系统在词元或步骤不同时，仍满足用例准则。

标明实际达到的保真度。记录外部状态和最终解析到的提供商修订版本；可变模型别名不是可重现证据。不得仅为重现追踪而重放写入、付款、发送消息或其他工具副作用。应改用幂等沙箱、已记录的响应，或明确只读的试运行适配器。

监控已通过验证的发布版本

告警定义是一份运营契约。记录指标修订版本、分子、分母、目标总体与分层、聚合窗口、标签延迟、阈值、持续时间要求、缺失数据规则、负责人和处置手册。参考窗口和检测器也要版本化。没有负责人和经过演练的响应流程，告警只会制造噪声。

至少监控以下内容：

• 流量构成、关键分层和系统指纹完整性；
• 追踪完整度、缺失遥测数据和 Schema 有效性；
• 确定性、任务和安全性比率，以及基于延迟到达的人工标签计算的比率；
• 在固定锚点集上的裁判输出，以及裁判与人工判断的分歧；
• 可用性、端到端延迟、词元数和每个合格任务的成本。

端到端延迟包括排队、每次重试、缓存查找、模型调用和工具调用，直到得到合格结果或进入终止回退状态。每个合格任务的成本包括失败尝试、裁判成本和分摊的人工复核成本，不只是最后一次模型生成。

漂移检测器只能说明某个受监控的分布发生了变化。它无法识别原因，也不能证明质量下降或定位发生变化的组件。归因之前，先核实追踪完整性、流量构成、系统修订版本、标签延迟和评分器稳定性。如果裁判在固定人工锚点集上发生变化，这是评分器漂移，不一定是应用漂移。

在发布前测试故障

运营发布生命周期

1. 固定决策、系统指纹、目标总体、分层、指标和隐私边界。
2. 对数据集清单、来源、同意依据、标签和数据集分配进行版本管理。
3. 声明用例、独立单元、重复试验、权重、无效结果和不确定性方法。
4. 用合适的参考证据验证每套人工评审流程和模型裁判。
5. 在匹配条件下运行基线和候选系统，并保留每次尝试。
6. 在每个必需的分层上执行硬性约束和置信区间门槛。
7. 在不影响用户的前提下，先用影子执行发现集成故障，再开启小规模粘性金丝雀发布。
8. 只有质量、安全性、延迟、成本和遥测完整性的停止规则都未触发时，才继续扩大流量。
9. 回滚触发条件出现时，以原子方式回滚到上一已知正常版本。
10. 保存估计值、区间、无效结果、豁免、审批、金丝雀结果、失效时间、回滚目标和每项重新验证触发条件。

最终产物是一份评测发布记录。它把主张和证据绑定到实际发布的系统版本，说明不确定性和尚未确定的分层，并让恢复操作可以直接执行。

延伸阅读