AI 功能的灰度与 Feature Flag:敢上线、能回滚、控得住

传统功能上线,要么行要么不行,bug 顶多是个 500 页面。AI 功能不一样:它可能"看起来对、实际上错",可能一个 prompt 改动让成本翻三倍,可能在某些 query 上直接越界。上线一个 AI 功能,本质是上线一个概率系统——你无法用单测覆盖它的所有行为。

所以灰度发布(feature flag + 渐进式放量)对 AI 功能不是可选项,是必需品。这篇文章讲清楚:AI 功能的 flag 该怎么设计、灰度怎么走、怎么和 eval/回滚配合,让你真敢上线。

一、AI 功能为什么要灰度:四类你扛不住的风险

先说清楚为什么要费这个劲。AI 功能上线面临的风险,远超传统功能:

1. 质量不确定:线下 eval 跑得再好,真实分布的 query 总会暴露盲区。新 prompt 可能在 95% 的 case 上更好,却在 5% 上严重退化,这 5% 到了线上才看得见。

2. 成本失控:AI 的边际成本是按 token 算的。一个"加个总结功能"看起来无害,但如果 prompt 变长、模型升级到更贵的版本、并发没限流,一天就能烧掉一个月的预算。传统功能不会这样。

3. 安全/合规风险:生成式输出可能泄露 PII、产生有害内容、越权调用工具。红队在实验室能拦住的,真实用户一发奇思妙想就可能绕过——你需要能快速止血。

4. 模型行为漂移:厂商静默更新模型、你换了 embedding、上下文长度变了,同一个 prompt 的输出分布会慢慢移动。今天好的功能,两周后可能悄悄变差。

这四类风险有一个共同特点:你无法在上线前发现,只能在上线后控制影响范围。这就是灰度的核心价值——把"上线"变成一个可观测、可刹车的过程,而不是一个开弓没有回头箭的赌博。

二、AI 特性的 flag:不止是开关,是一个"变体选择器"

很多人对 feature flag 的理解停留在 if (flag.enabled) { newCode } else { oldCode }。这对 AI 功能远远不够。AI 功能的可变维度太多了,flag 要管理的是一个变体空间:

一个 AI 功能的 flag 需要能切:
- prompt 版本   (v1 → v2,prompt 也是代码,也要版本化)
- 模型          (gpt-4o / claude / 本地小模型,成本质量权衡)
- 参数          (temperature、top_p、max_tokens、是否走工具)
- 降级路径      (主模型超时 → 备用模型 → 规则兜底)
- 后处理策略    (是否过审核、是否做 citation 校验)

一个实战的 flag 配置大概长这样:

flags:
  ai_summary:
    enabled: true
    variants:
      - name: control
        weight: 90
        spec:
          prompt_version: v1
          model: gpt-4o-mini
          temperature: 0.2
      - name: treatment
        weight: 10
        spec:
          prompt_version: v2
          model: gpt-4o
          temperature: 0.3
          fallback_model: gpt-4o-mini
    targeting:
      include: { user_tier: [pro, internal] }
    guardrails:
      max_cost_per_request_usd: 0.05
      block_on_moderation_flag: true

关键点:variant 不是布尔值,是一个完整的"运行规格"。切换 prompt 版本不需要改代码、不需要发版,改个配置即可。prompt 和模型配置要从代码里抽出来,当成可独立部署的资源,这是 AI 功能和传统功能最大的工程差异之一。

三、灰度策略:百分比、按人群、按 case 三板斧

有了 flag,怎么放量?三类策略,通常组合使用。

百分比灰度(1% → 10% → 50% → 100%) 是最基础的。关键是每档至少停留一个完整观察周期(通常 24-72h),让成本曲线和质量指标都稳定下来。不要 1% 跑一小时觉得没问题就拉满——很多成本异常是流量峰值时才出现的。

按人群灰度 更精细,也更能控制风险:

- 内部员工 (dogfood):最早放,真实使用,出问题自己扛
- 付费用户 / Pro tier:对质量容忍度低,但反馈质量高
- 免费 / 区域 / 新用户:最后放量,降低爆炸半径

一个常见做法是新功能先给 internal 跑一周,再放给 5% 的 Pro 用户,确认无异常后逐步扩到免费用户。免费用户的爆炸半径要放最后,因为他们基数大、行为更野、ROI 也低。

按 case 灰度(定向 query) 是 AI 功能独有的:只对特定类型的 query 开启,比如先只支持英文 query、只支持长度 < 500 字符的输入、只支持某些 intent。这让你能在"功能边界"内验证,而不是一上来就面对开放域。

targeting:
  query_filters:
    lang: [en]
    input_length_max: 500
    intents: [summarize]

三种策略叠加,能把你对 AI 功能的"恐惧半径"压到最小。

四、配合 eval 与 A/B:灰度同时跑指标,质量下降自动暂停

灰度不是"放着看",是要同时跑指标。这分两层:

在线指标:成本(每请求均价、日总成本)、延迟(p95)、显式反馈(点赞/点踩)、隐式反馈(采纳率、复制率、重写率)。这些是质量下行的第一道信号。

A/B 实验:control 和 treatment 并行,核心看业务指标(转化、留存、功能复用率),而不只是模型好不好看。模型更好的不一定业务更好——比如更长的回答质量更高,但用户反而更少读完。

最有杀伤力的是自动暂停(auto-halt):设定一组阈值,一旦触发立即把 flag 权重切回 control。

auto_halt_rules:
  - metric: cost_per_request_usd
    condition: "> control * 1.5"
    action: rollback_to_control
  - metric: negative_feedback_rate
    condition: "> 0.08"
    action: rollback_to_control
  - metric: p95_latency_ms
    condition: "> 3000"
    action: reduce_treatment_to_1pct

这套机制是灰度真正"敢上线"的底气。不是靠人盯着大盘,是靠系统在半夜三点也能自己刹车。AI 功能上线,没有自动熔断等于裸奔。

五、一键回滚:出问题秒切,prompt/模型分离部署让回滚不发版

flag 最大的价值,不是"能上线",是"能不下线地撤回"。传统回滚要重新发版、走 CI、重建镜像,几分钟到几十分钟。AI 功能等不起——一次 token 洪水几分钟就能烧出事。

正确的做法是把回滚做成改配置即生效:

# 出问题了,一行改动:
flags.ai_summary.variants[1].weight: 0   # treatment 立即归零
flags.ai_summary.variants[0].weight: 100 # control 立即全量

要做到秒级生效,需要:(1) flag 配置在配置中心,不在代码仓库;(2) 应用轮询或长连接订阅配置变更,无需重启;(3) prompt、模型名、参数都从 flag 读取,代码里不写死。

架构上建议:

[ 配置中心 (Postgres/Unleal/LaunchDarkly) ]
            │  (push / poll, <5s 生效)
            ▼
[ AI Gateway / SDK ] ── 读 flag 决定 variant
            │
            ▼
[ Prompt Registry ] ── 按 prompt_version 取模板(独立部署,独立回滚)
[ Model Router    ] ── 按 model 名路由(可切厂商)

Prompt Registry 是关键:prompt 作为独立可版本化资源,新版 prompt 上线、出问题回滚,都不碰应用代码、不走完整发版流程。很多团队把 prompt 硬编码在代码里,改一个词要 PR、要 review、要 deploy,这在 AI 时代是反生产力的。

分离部署 = 回滚自由。代码和 AI 资源解耦,是 AI 工程的底层纪律。

六、flag 管理:动态生效、审计、过期清理,别让 flag 变技术债

flag 用得好是安全网,用不好是技术债的重灾区。几条铁律:

动态生效:flag 必须能在不重启、不发版的情况下改值。靠环境变量或 JSON 文件做 flag 的,每次改动都要 redeploy,丧失了 flag 的核心价值。至少上一个带轮询的配置中心。

审计:谁在什么时间改了哪个 flag 的哪个值,必须有日志。AI 功能出事时,第一件事是查"最近谁动过 flag"。没有审计的 flag 系统等于没有责任边界。

audit_log:
  - actor: alice@team
    time: 2026-07-15T14:22Z
    flag: ai_summary.treatment.weight
    from: 10
    to: 50
    reason: "eval pass, expand rollout"

过期清理:每个 flag 必须有 owner 和 expire_at。一个 flag 全量稳定运行 N 天后,要么删除(把新代码变成默认路径),要么固化成配置。永久存在的 flag 不是 flag,是未完成的重构。 我见过代码里堆着上百个"暂时"的 flag,新人谁都不敢删,最后变成考古现场。

命名规范:ai_<feature>_<variant> 或 exp_<experiment_id>,让人一眼看出这是开关还是实验。实验型 flag 有起止时间,功能型 flag 有清理计划。

七、实战:一个 AI 功能从内部到全量的完整流程

把前面的串起来。假设我们要上线一个"文档智能摘要"功能,prompt 从 v1 升级到 v2、模型从 mini 升到 4o。

阶段 0:离线 eval(上线前) v2 prompt 在固定测试集上跑分,确认相对 v1 有提升且无显著退化(某些 case 退步超过阈值就打回)。eval 不过,不要进灰度。

阶段 1:internal dogfood(100% 内部,权重 0/0/100 给员工) 内部全量使用 3-5 天。收集 bad case,迭代 prompt。这阶段可以容忍质量波动,重点是发现明显 bug 和成本异常。

阶段 2:定向灰度(Pro 用户 5%) 按人群 + 百分比放出。同时 A/B 跑 control vs treatment,盯在线指标。配置 auto-halt:成本涨 50% 或负反馈 >8% 自动切回。

阶段 3:扩量(Pro 50% → 100%,免费用户 10% → 50% → 100%) 每档观察 24-48h,指标平稳再进下一档。免费用户最后放量,因为爆炸半径最大。

阶段 4:固化(全量稳定 14 天后) 删除 flag,v2 prompt + 4o 模型变成默认路径,prompt v1 归档。flag 进入清理列表。

整个过程的核心是:每一步都可观测、可刹车、可回退。你不是在"上线一个功能",你是在"把一个概率系统逐步推向稳定状态",这和传统发版是两种心智模型。

小结

1. AI 功能不是确定性功能,必须当概率系统灰度上线——质量、成本、安全、漂移四类风险,都只能靠小流量发现、靠小流量控制。
2. flag 是变体选择器,不是布尔开关。prompt 版本、模型、参数、降级路径都要能独立切换,prompt/模型要从代码里抽出来当资源。
3. 灰度三板斧:百分比、人群、case。组合使用,把爆炸半径压到最小;免费用户最后放。
4. 自动熔断是上线的真正底气。成本/负反馈/延迟超阈值自动切回 control,不靠人盯大盘。
5. 一键回滚的前提是分离部署:配置中心 + 动态生效 + prompt registry,让回滚改配置即生效,不发版。

金句:传统功能上线是"开弓",AI 功能上线是"试弓"——flag 不是为了让你敢按下发布按钮,是为了让你能在箭离弦之后,随时把它叫回来。