无故障停机情况下的面向客户 AI 质量退化复盘指南

你的状态页是一片绿色。你的错误率为零。你的运行时间仪表盘连续第七个月显示为 100%。然而，在周二上午 9:14，你的客户团队给你转来了一条来自一家财富 500 强客户的消息，上面写着：“我们的团队注意到这周助手的表现变差了。你能告诉我们发生了什么变化吗？”午饭前，你又收到了 12 条类似的反馈。现有的事故沟通手册（incident-comms playbook）无法回答其中任何一个问题，因为那套手册是为停机事故准备的，而现在没有任何东西崩溃。

这就是面向客户的 AI 复盘难题，也是我在将 LLM 功能交付给企业合约的团队中看到的最普遍的差距。可靠性的维度已经从“系统是否在线”转向了“系统是否和上周一样好”，而几乎没有任何沟通基础设施跟上了这一变化。状态页上没有相应的展示块。严重性等级标准（Severity rubrics）没有对其进行评分。支持服务的回复模版默认为“我们发现了一个问题并已解决”，这取决于客户当天的情绪，听起来要么是敷衍，要么是危言耸听。

大多数团队犯的错误是将这些事件视为边缘案例（edge cases）。它们并不是边缘案例。从业者报告称，从质量下降开始到第一条用户投诉到达支持部门之间，存在 14–18 天的检测滞后。这意味着，几乎每次你发布提示词更改、评测标准更新或模型版本升级时，你的产品都会发生面向客户的“软衰退”事故——只是你通常听不到相关反馈。你听到的那些，是客户的内部评估、或者更糟糕的是他们 CTO 的直觉决定要升级处理的问题。当消息传到你这里时，客户对该渠道的基础信任已经丧失。此时，复盘已不再是可选的。

质量衰退事故的形态

描述这些事故的第一个问题是，工程师和客户之间缺乏共同的词汇。停机事故很简单：API 返回了 503，仪表盘变红了，道歉信手到擒来。软衰退则更难。每个 API 调用都返回了 200 状态码。延迟是正常的。面向用户的功能没有以任何监控器能捕获的方式损坏。改变的是助手开始给出更糟糕的答案，而这种“更糟糕”存在于大多数客户看不到、大多数内部团队也还没学会如何总结的衡量层。

这产生了四个典型的根本原因，每个 AI 团队都需要能够清晰地命名它们，因为它们是“发生了什么变化”的四个答案：

模型迁移（Model migration）。供应商弃用了你所固定的版本，或者你主动迁移到了新版本，新模型在你的提示词下表现出不同的输出特性。供应商的弃用时间表是真实存在的——主要的基座模型供应商现在会提前 60 天发出模型退役通知。这意味着，无论是否有所计划，每个在生产环境中运行 LLM 功能的团队每个季度都会面临迁移事件。迁移是最常见的根本原因，也是最容易误诊的原因，因为下降的指标并不总是你正在监控的那些。

提示词变更（Prompt change）。有人修改了系统提示词、评分标准、few-shot 示例或工具描述，这些变更下游的规划器（planner）开始表现出不同的行为。这通常是为了实现不同的优化目标而进行的刻意更改——例如，降低 Token 成本或修复拒绝回答的问题——而衰退发生的维度在更改发布时并没有人跟踪。

评测漂移（Judge drift）。你的 LLM-as-judge——你用来为评估运行评分并触发衰退警报的线下评分器——本身发生了漂移，通常是因为评测器自身的骨干模型被供应商静默更新了，或者是因为有人调整了评分标准提示词。评测器现在对相同的输出给出了不同的分数，这意味着你要么错过了一个真实的衰退（评测器变得更宽松了），要么就是在追逐一个虚假的衰退（评测器变得更严格了）。无论哪种情况，你对本季度评测器给出的每个分数的信任校准都存疑。

输入分布偏移（Input distribution shift）。你的客户使用方式发生了变化。也许是由于他们那边的产品上线导致路由到你助手的查询组合发生了变化。也许是季节性原因。也许是他们工作流中的竞争对手停止支持某些功能，从而将流量推向了你。模型没变，提示词也没变，但输入不再匹配你衡量评估时的输入，因此生产环境中的质量得分现在与你部署时报告的得分存在显著差异。

这四个维度就是你欠客户的全部词汇。每一个软衰退事故都是其中之一，或者是它们的某种组合。如果你的复盘不能用非 AI 采购团队能够理解并采取行动的语言将根本原因归入这些类别，那么复盘读起来要么像是在逃避责任，要么像是充斥着技术术语的噪音。

面向客户的严重程度分级标准必须涵盖的内容

下一个问题是，传统的严重程度分级（从 SEV0 到 SEV3，以受影响用户数和停机分钟数来衡量影响范围）无法以任何实用的方式对质量退化进行分级。如果一个单项任务评估分数从 88% 掉到了 82%，这算不上是零分钟停机，但也不是完全没有影响。它需要有自己的衡量维度。

我见过的做得比较好的团队会建立一套平行的严重程度分级标准，涵盖三个维度：

量级 (Magnitude)。指标波动的幅度有多大？“线上流量评估（Eval-on-traffic）下降了 4 个点”这类表述需要被定义为一类特定的事故。同样，“评判模型在校准集上与人工的一致性从 0.81 降到了 0.68”也是如此。分级标准应该有明确的阈值：1 个点的评估分下降是警告（warning），4 个点的下降等同于 SEV2，8 个点的下降则是 AI 质量层面的 SEV0。

影响范围 (Blast radius)。哪些客户群体受到了影响？AI 质量退化在客户群中很少是均匀分布的。模型迁移可能对具有结构化查询模式的企业级用户没有影响，但对评估集采样不足的长尾用例来说则是灾难性的。严重程度分级应明确地将“受影响流量百分比”和“受影响的具名客户百分比”作为独立数字，因为第二个数字是客户在复盘报告中判断是否需要在其组织内部升级处理的关键。

加载中…