为什么 AI 功能开关不同于普通功能开关

金丝雀部署完美收工：错误率纹丝不动，延迟没有飙升，监控大盘一片绿色。你将新模型全量推送给所有流量——三周后，客服队列里挤满了用户投诉，说 AI "感觉不对劲"、"不再有用了"。

这正是将传统功能开关机制套用到 AI 系统上的核心问题。一个模型可以在"没有崩溃"的情况下悄悄退化：它照常返回 200 状态码，以正常速度生成 token，输出的文本也能通过表面校验——但与此同时，它的幻觉频率在悄悄上升，回答越来越简短或回避，或者在你的用户真正依赖的细微推理模式上悄然退步。你多年来一直监控的遥测指标，从来就不是为了捕捉这类故障而设计的。

传统金丝雀分析建立在一个简单前提之上：功能要么正常，要么不正常。错误就是 5xx 状态码，失败就是超时或崩溃。你把 5% 的流量路由到候选版本，观察错误率和延迟百分位数，如果经过足够多的请求后什么都没炸，就发布上线。这套方法对确定性软件非常奏效，却在概率性系统上严重失灵——在这类系统中，"正确"是一个分布，而不是一个布尔值。

确定性假设的崩塌

传统功能开关假设：给定相同输入，功能行为是固定的。你改变按钮颜色，按钮要么渲染要么不渲染；你上线新的结账流程，要么完成要么报错。如果有随机性，那来自用户行为，而不是功能本身。

LLM 的输出在设计上就是随机的。温度大于零意味着同一个 prompt 每次调用都会产生不同的输出。但即使在温度为零——理论上应该是确定性的——的情况下，研究也表明，由于注意力机制的随机性、硬件层面的浮点数非确定性，以及跨服务副本的基础设施差异，生产环境中的模型输出仍然存在方差。你在预发布环境测试的模型，并不完全等同于你的用户在生产环境中实际体验到的模型，即便你的代码什么都没改。

这立刻带来了一个测量难题。金丝雀分析中的统计显著性，依赖于将方差压缩到足以检测信号的程度。对于二元指标（报错/不报错），这是可行的。但对于连续的、多维的、主观的质量指标，要可靠地检测出有意义的回归，所需的样本量会急剧增大——往往在你已经造成相当损害之后，才能达到统计显著性。

"退化但未崩溃"究竟是什么样子

那些在生产环境中扼杀 AI 产品的故障，看起来不像停机事故。它们更像是摩擦感慢慢积累，直到用户停止使用。

一次模型更新改变了响应长度的分布。偏好简洁回答的用户开始收到长篇大论；需要详细解释的用户开始收到一句话回复。没有人触发错误。点击率略有波动，但在正常的周度方差范围内。问题是不可见的，直到你审视三周后流失的那批用户，才发现他们的会话时长在上线后变短了。

又或者：一次模型更新悄悄改变了系统处理模糊查询的方式。新模型不再追问澄清，而是自行选择一种解读然后径直执行。对无歧义查询的准确率保持不变甚至有所提升。对真实世界中模糊查询长尾的准确率下降了 15%。你的聚合准确率指标持平。那些提问复杂的用户，则在悄悄学会不再信任这个产品。

行业数据为这种模式提供了佐证：超过 91% 的 ML 模型在生产中会随时间退化；2024 年的一项调查显示，75% 的企业观察到了 AI 性能下降，其中超过一半报告了收入影响；MIT 和 RAND 对生成式 AI 试点项目失败率的估计在 80% 到 95% 之间。这些不是部署失败——大多数模型在技术上运行正常。它们是质量失败，而标准监控没能捕捉到。

值得埋点的领先指标

如果错误率和延迟告诉不了你质量退化的信息，你就需要能代理质量的信号。这些信号分为四类。

语义漂移信号追踪模型输出是否在独立于明显错误的情况下发生了性质变化。基于嵌入的漂移检测，通过计算最近输出的嵌入与基线分布之间的余弦相似度来实现。当曾经紧密的语义簇开始扩散，说明某些东西已经改变——即便你暂时说不清楚是什么。种群稳定性指数（PSI）将同样的量化方法应用于特征分布，让你能够用一个数字衡量输入模式偏离训练分布的程度。

幻觉与事实性信号需要更精密的检测方式。2024 年《自然》论文中的语义熵方法，通过测量同一 prompt 多次生成之间的不确定性来检测捏造——高熵意味着模型更不确定，而这与幻觉相关。HaluGate 等 token 级实时监测器，甚至可以在输出到达用户之前就在生成过程中检测到幻觉。对于 RAG 系统，检索验证则核查输出是否有所提供的上下文作为依据。

用户满意度代理是对质量最直接的衡量，但采集最慢。附加在 AI 响应上的 CSAT 调查、点赞/踩信号、编辑率（用户修改 AI 生成内容的频率），以及会话级参与度信号（用户是否继续追问，还是就此停下？），都能告诉你输出是否满足了预期。在专业场景下，AI 生成内容的行业平均采纳率为 44%——这应该是底线，而不是目标。

行为漂移指标衡量模型的性格和风格随时间如何变化。响应长度方差、指令遵从率，以及格式一致性（当被要求时，模型是否还在使用项目符号，还是已经默认改成散文？），都是无需人工评估即可测量的维度。生产环境中的模型已被观察到响应长度有 23% 的方差，指令遵从一致性有 31% 的波动——这些变化，任何延迟监控都不会发现。

为概率性功能定义回滚触发器

AI 功能开关最难的部分，是回滚决策函数。对于传统软件，这是一个阈值：错误率超过 1%，回滚。对于 AI，没有任何单一指标能干净地映射到"这个版本更差"。

最简单的做法是选一个质量代理指标然后设阈值："如果 CSAT 低于 4.2 分就回滚。"这在两个方向上都会失败：阈值太敏感，就会出现回滚抖动——系统在正常方差下不断在两个版本之间来回切换；阈值太宽松，真正的退化就会在造成足够损害之前一直被忽视。

更好的方法是加权多信号评分。根据各领先指标对实际用户影响的预测可靠性，为它们分配权重：

• 幻觉率：30%
• 行为漂移分数：25%
• 用户满意度代理：25%
• 语义漂移指数：20%

只有当综合评分降到你根据历史事故校准的阈值以下时，才触发回滚。对综合评分做异常检测——而不是对单个指标设硬性限制——能显著降低误报率。你在寻找的是质量信号分布的变化，而不是某个指标越过某条线。

回滚触发器还需要遵从统计置信度。基于 50 条响应的 CSAT 从 4.3 降到 4.1，不能作为退化的证据。要求在评估回滚触发器之前达到最低样本量，可以防止因噪声而轻举妄动。Statsig 等工具已经将这种预测脉冲逻辑内置到发布流水线中——在指标真正突破阈值之前，就根据预测轨迹阻断发布。

当"正确"是主观的时候如何做 A/B 测试

针对转化率的经典 A/B 测试之所以有效，是因为有明确的事实：用户要么转化了，要么没有。AI 质量没有事实标准——它有因用户、情境和任务类型而异的人类偏好分布。

实践中效果最好的方法是成对 LLM 评判（Pairwise LLM-as-Judge）。不是问"这个输出好不好？"（需要定义评分量表，且结果不一致），而是问："给定相同的 prompt，这两个输出哪个更好，为什么？"成对比较与人工评估者的一致性高于基于评分的方法，同时绕开了校准绝对质量量表的难题。

G-Eval 框架在此基础上进一步扩展，将质量分解为评估 prompt 中的显式维度：相关性、事实性、有用性、格式遵从性、语气。每个维度单独评估，然后再汇总。这让你能够识别模型版本之间哪些维度发生了变化——一个变得更准确但更不简洁的模型，与一个在两个维度上都退步的模型，需要截然不同的产品决策。

LLM 评判无法替代人工评估，尤其是在专业领域。在技术领域，领域专家只有 60-70% 的时间与 LLM 评判一致；在开放式推理任务上，这一比例降至 47%。务实的做法是分层进行：在发布期间使用自动化成对评估获取快速的金丝雀反馈，同时并行对每个模型版本的采样输出进行有针对性的人工评估，重点关注自动化评判最不确定的案例。

生产环境中的 RLHF 信号可以直接输入到发布决策中。如果你在采集隐式或显式的偏好信号——点赞评分、编辑历史、会话延续情况——你可以在你的生产分布上训练一个奖励模型，并在金丝雀分析期间将其评分作为质量指标使用。即使在人工评估赶上之前，候选模型版本在你的生产奖励模型上得分高于当前版本，也是一个有意义的信号。

你真正需要的基础设施

要把 AI 功能开关做对，需要的埋点是大多数团队在发布第一个模型时都还没有的。

在推理层，记录完整的 prompt 和补全内容、模型版本、各层级延迟（token 生成、模型调用、端到端）、置信度分数（如果有的话），以及任何检索上下文。这些日志是质量分析的原材料。没有它们，你就无法在事后还原故障——而 AI 故障在没有精确输入的情况下，出了名地难以复现。

在评估层，你需要一条持续运行的离线评估流水线，针对生产流量的分层样本运行。这条流水线应用你的质量指标、检测漂移，并产出供发布和回滚决策使用的综合质量评分。它需要足够快，以便在 5% 金丝雀流量下部署后的数小时内（而非数天内）就能获得足够的评估覆盖率。

在发布层，你的功能开关基础设施需要做的不仅仅是流量切分。它需要读取质量指标、与阈值比较，并自动暂停扩量或触发回滚。在金丝雀部署期间靠人工盯仪表盘太慢——等人注意到漂移信号并决定回滚时，你已经暴露了远超必要数量的用户。

LaunchDarkly 的 AI Config 系统和 Statsig 的发布流水线都在朝这个方向演进——将模型配置管理与实时质量指标挂钩，而不是将发布视为纯粹基于百分比的操作。无论你使用哪种工具，这个模式都至关重要：发布速率和质量信号需要连接在一起，而不是各自独立运行。

下次模型发布前该做什么

不要在没有质量基线的情况下启动金丝雀。在暴露任何真实用户之前，先用具有代表性的生产流量样本运行候选模型，测量你关心的每个质量维度。如果没有基线可供比较，你就没有信号。

在开始发布之前定义回滚触发器，而不是在看到问题之后。决定哪些指标重要、如何加权、阈值是多少、如何处理不确定性。写下来。退化事故发生的当中，不是争论 0.2 分的 CSAT 下降是否显著的时候。

影子测试的时间要比你认为需要的更长。AI 模型在规模化时的故障模式往往需要时间才能显现——它们取决于测试集中代表性不足的用户输入长尾中的边缘案例。如果算力允许，运行一周的影子部署几乎零成本，却能捕捉到 24 小时金丝雀会错过的分布偏移问题。

最后，默认将模型更新视为破坏性变更。当基础模型提供商更新 API 端点背后的底层模型时，即便你的代码没有任何改动，你与用户之间的行为契约也已经发生了变化。对模型版本升级应用与重大 API 版本变更同等的发布纪律——因为从你的用户角度来看，这正是所发生的事情。

好消息是，相关工具正在迅速成熟。难的地方在于认识到这种纪律本身是必要的。大多数团队发现 AI 功能开关需要有别于普通功能开关的方式，和他们发现任何架构缺口的方式一样：在一次本可完全避免的生产事故发生之后。