灰度与金丝雀发布

• LLM-as-Judge 门禁的阈值与样本量设计
• 置信区间与显著性判定
• judge 误判的处理（人工复判、二次评估）

LLM-as-Judge 灰度门禁需在灰度期采集样本，用 judge 打分，并统计质量指标。设计要点：样本量要足够（依据指标方差与期望功效计算，如要达到 95% 置信、检测 1% 差异需要对应样本量）；用置信区间而非单点值判断（如"新版本胜率 95% CI 下限 > 50%"才放量）；阈值分层（质量差则停、中则观察、好则放量）。judge 误判不可避免，处理方式：对 judge 判定的边界样本与异常样本做人工复判（抽样人审）；对 judge 自评置信度低的样本做二次评估（换 judge 或人审）；定期用标注集校准 judge 的准确率与一致性，评估 judge 与人类的一致性（如 Cohen's Kappa）。

门禁的本质是"用统计方法评估新版本是否优于旧版本"。样本量、置信区间与阈值共同决定结论可靠性；judge 误判通过人工复判与校准兜底，避免门禁被错误判断带偏。

• 用户分群维度（地域、活跃度、风险等级、付费）
• 分群放量节奏
• 分群质量指标监控

按用户分群灰度是把用户按维度（地域、活跃度、付费、风险等级、设备）切成群，逐步放量。放量策略：先放内部/低风险/小流量群，再逐步扩展到中高风险群；对高风险群（企业客户、付费用户）最后放或单独放。监控上按群粒度看质量指标（准确率、引用支持率、满意度、延迟、成本、错误率），因为不同群对质量敏感度不同。分群灰度还要考虑群间隔离（避免同一用户在不同群被不一致对待）与群内均匀性（保证同群内版本一致）。放量节奏由各群指标的置信达成决定。

分群灰度的本质是"按风险与价值对用户分层，逐层放量"。分群监控比全局监控更能早发现特定人群的质量问题，也便于控制爆款风险。

• 影子流量的原理（并行跑新旧版本，不影响生产）
• 影子验证的指标与对比
• 安全的升级路径

影子流量（shadow）是把生产流量复制一份，并行送给新版本（新 Prompt/新模型）运行，但新版本结果不返回给用户、不影响生产，只用于离线比较。这样能无风险采集新版本在真实流量下的表现。安全验证流程：生产流量按比例复制到影子环境；影子环境运行新版本，与生产版本结果对比（质量、延迟、成本、引用支持率）；用 judge 或离线评测对比新旧版本在真实问题的差异；影子期间观察新版本是否有异常（幻觉、错误、格式问题）。验证达标后再转为真实灰度。关键点：影子流量要真实反映生产分布，且影子运行不能拖慢生产。

影子流量的价值是"用真实流量零风险验证新版本"。它把"变更→影响"解耦，先观察再落地，是 Prompt/模型升级的安全路径。

• 生成结果的随机性与多样性
• 好坏样本界定的主观性
• 对灰度判定的影响

AI 生成的不可预测性给灰度判定带来多重挑战：一是同一输入每次输出可能不同（温度、采样），导致好坏样本不稳定，需要用多次采样或固定 seed 才能对比；二是好坏没有唯一标准，主观性强（同一答案有人觉得好有人觉得差），自动判定难；三是边界样本多（部分正确、部分相关），难以二分类；四是新版本可能在某些场景好、另一些场景差，需要分场景评估而不能只看均值。应对：用评测集+固定 seed 做确定性对比；用 judge 打分+人工复核；按场景分组统计而非单点均值；用置信区间包容随机性。

不可预测性挑战的本质是"判定对象不稳定且标准主观"。确定性对比、场景分组、置信区间与人工复核是应对的核心手段。

• 阶梯放量的阶段划分（5%、10%、25%、50%、全量）
• 每阶段停留时长
• 暂停/继续判定标准

阶梯放量先小步验证再逐步扩大。典型节奏：5%（内部/低风险）→10%→25%→50%→全量。每阶段停留时长取决于指标的置信达成与数据量积累，通常 1-2 天到数天，需保证该阶段样本量足够支撑统计判定。暂停/继续判定标准：继续的条件是质量指标（准确率、引用支持率、满意度）与延迟（TTFT、P95）、成本（单请求成本）均达标且相对基线无显著退化；暂停的条件是任何关键指标跌破阈值、异常率上升、成本超预算或收到风险反馈。设计时要明确"每提升一个档位需重新评估"，不达标则回退上一档或暂停。

阶梯放量的本质是"每一档都是一个小型验证"。停留时长与判定标准要数据驱动，核心是"每档独立评估、不达标不放量"。

• 缓存键中版本信息的缺失导致串扰
• 新旧版本共用缓存的风险
• 缓存隔离方案

新旧版本共用语义缓存或响应缓存时，若缓存键不含版本信息，新版本请求可能命中旧版本生成的缓存结果，造成串扰与污染（旧版本结果被当作新版本返回）。隔离方案：缓存键必须包含版本维度（模型版本、Prompt 版本、参数版本），不同版本使用不同缓存命名空间/前缀；语义缓存还需要防止"跨越版本语义等价"的误命中；旧版本淘汰时同步清理其缓存，避免污染新版本；对缓存写入做版本标记，读取时校验版本匹配。这样保证缓存结果只属于生成它的版本。

缓存隔离的本质是"缓存结果必须与生成它的版本绑定"。版本维度的缓存键与命名空间隔离是最直接有效的防串扰手段。

• 异常检测信号（错误率、延迟、质量下降）
• 自动熔断机制
• 回退到稳定模型

灰度异常自动熔断需监控关键指标（错误率、超时率、延迟 P95、质量下降、成本突增），当指标连续超过阈值（如错误率连续 N 分钟 > X%）触发熔断。熔断逻辑：自动把流量切回稳定模型/旧版本，暂停灰度，停止新流量进入新版本。设计上要防抖动（用连续窗口+滞后阈值，避免单点波动误熔断）；熔断后记录现场（样本、日志）供复盘；人工介入确认后决定是否恢复灰度或终止。回退要保证平滑（缓存隔离、会话连续），避免熔断本身造成二次故障。

自动熔断的本质是"把异常检测与控制流量的能力自动化"。用连续窗口避免误报，熔断后回退到已知稳定版本，并保留现场供复盘。

• 业务指标（转化、留存）与 AI 质量的关系
• 因果归因（A/B、DID、时序）
• 混淆与因果推断

AI 灰度影响业务指标（转化/留存）时，需要严谨的因果归因而非简单相关。方法：随机化 A/B 实验（实验组/对照组随机分桶，最可靠的因果推断）；若无法随机，用准实验方法（DID 双重差分、before-after 对比、回归断点）；控制混淆变量（用户活跃度、时间趋势、季节性）。归因要点：区分"AI 质量变化导致的业务变化"与"其他因素导致的"，用对照组隔离；检查样本量是否足够支撑转化/留存这类低基率指标的显著性；避免辛普森悖论（分群后汇总的结论反转）。

因果归因的本质是"排除混淆、建立因果"。随机化实验最可靠，准实验方法作补充，并警惕低基率指标与辛普森悖论。

• Prompt 热更新（不重启服务更新）
• 灰度标签（打标用户群）
• 命中与快速收回

Prompt 热更新与灰度标签联动，核心是"按用户标签动态路由 Prompt 版本"。实现：给用户打灰度标签（如百分比、用户 ID 哈希、特定客户群），配置中心维护"标签→Prompt 版本"映射；请求时按用户标签查映射，命中对应 Prompt 版本，无需重启即可生效（热更新）。快速收回：只需把映射中该标签的 Prompt 版本改回旧版本，或把标签从新版移除，即可让该用户群立即回到旧 Prompt，不回滚代码。结合实时配置下发与缓存失效，实现秒级生效。关键是标签系统稳定、映射可审计、收回可一键执行。

热更新+灰度联动的本质是"把 Prompt 版本选择从代码中解耦到配置层"。标签路由让指定用户群命中断版本，收回只需改配置，实现快速、可逆的控制。

• 成本统计的维度（token、单请求成本）
• 实验组与对照组的成本隔离
• 成本差异的统计与显著性

灰度期间要分别统计实验组（新版本）与对照组（旧版本）的成本，隔离统计避免新版本成本被整体均值掩盖。做法：按实验组/对照组打标签，日志与账单按标签归集；分别统计 token 用量（输入/输出/缓存）、单请求成本、总成本；对比两组成本差异（均值、分位数），用统计检验判断差异显著性（成本波动大需足够样本）。还要注意成本与质量/业务的联动（新版本成本高但质量好，需权衡），并防止成本突增（设置成本预算上限）。

成本隔离统计的本质是"把成本与版本绑定，独立归因"。按标签归集成本、做差异显著性与显著性检验，才能避免新版本成本被均值溶解。

• 回滚对会话上下文的影响
• 上下文序列化与持久化
• 版本切换时的上下文兼容

回滚时若切换模型/Prompt 版本，用户已产生的对话上下文可能被破坏（格式不兼容、摘要语义不同）。保留连续性的做法：会话上下文在每次交互后持久化（结构化存储，而非只存内存）；上下文存储与版本解耦（存会话消息、记忆、状态，不绑定具体模型版本）；回滚时用同一份上下文重新喂给新版本，保证用户看到的是接续的对话而非空白。若版本间上下文格式不兼容（如工具调用格式不同），需做上下文迁移/转换。设计上"上下文是数据、版本是处理器"，两者分离才能无缝回滚。

上下文连续的本质是"上下文与版本解耦"。把上下文当持久化数据，版本切换只换处理器，并处理格式兼容，才能保证回滚后对话无缝。

• 主观评分的量化
• 主观评分与自动化指标的融合
• 纳入验收门槛

生成质量的主观评分（语言流畅度、有用性、语气）无法用客观指标完全覆盖，需纳入灰度验收。做法：用结构化评分表让 judge/人工给多维打分（准确、相关、流畅、有用），聚合成质量分；主观评分与客观指标（引用支持率、错误率、延迟）分层设门槛——客观指标不达标直接拒，主观评分不达标也拒；对主观评分做统计（均值、分布、置信区间）而非单点值；样本量需足够支撑主观差异的显著性。验收门槛可设为"客观指标全绿 + 主观评分均值不低于基线且置信区间达标"。

主观评分进门槛的本质是"把主观体验工程化量化"。结构化打分+统计化判定+与客观指标分层，避免主观评分被拍脑袋化。

• 实验组隔离统计（按版本分桶）
• 成本上升被均值掩盖的问题
• 隔离统计与告警

灰度期间新版本只占部分流量，若只看整体均值，新版本的成本上升/质量下降会被旧版本均值掩盖。隔离统计做法：按实验组/对照组（新旧版本）打标签，所有指标（质量、成本、延迟）都按标签独立归集，分别统计均值与分位数；对比两组差异而非看整体；对新版本单独设告警阈值（新版本成本突增、质量下降即便是小流量也告警）。这样小流量新版本的问题也能被及时发现。关键是把"版本维度"作为统计与告警的必选维度。

隔离统计的本质是"按版本分桶归集，避免均值稀释"。小流量新版本的问题要用版本粒度捕获，而非被整体均值平滑掉。

• 流量切分（随机/按 bucket）
• 指标对比口径（同口径、同场景）
• 显著性判定

避免灰度结论失真需要严谨设计。流量切分：用随机一致哈希分桶（相同用户/会话进入同一版本，避免同用户反复切换造成不一致），且保证两组样本分布可比。指标对比口径：对比同一场景、同一指标、同一统计口径（不能一个用均值一个用分位数）；排除时间/季节/流量波动影响。显著性判定：用统计检验（双样本 t 检验、置信区间），检查样本量是否满足功效；警惕多重比较（看多个指标时做多重检验校正）；避免辛普森悖论（必要时分群看）。结论失真多来自样本不均、口径不一与显著性不足。

灰度结论失真的根源是"样本不均、口径不一、显著性不足"。随机分桶、统一口径、统计显著性是保证结论可信的三大支柱。

• 灰度（渐进上线）与 A/B 实验（因果验证）的目标差异
• 指标口径差异
• 终止规则差异

灰度与 A/B 实验目标不同：灰度是"渐进降低风险的上线流程"，目标是安全地把新版本推给所有用户，通常最终全量；A/B 实验是"验证因果假设"，目标是判断新版本是否真的更好，可能终止于"不采用"。指标口径：灰度关注运维与质量指标（错误率、延迟、成本、可用性）；A/B 侧重业务因果指标（转化、留存、效果）。终止规则：灰度是"达标即继续放量，不达标暂停/回退"，最终收敛到全量；A/B 是"达到预定样本量后根据显著性做出采用/不采用的结论，可能不扩大"。实践中灰度可内嵌 A/B（先随机验证再扩量）。

灰度管"上线安全性"，A/B 管"因果验证"。前者保证不爆炸且最终全量，后者判断是否值得采用且可能终止，二者目标、口径、终止逻辑不同。

• AI 功能的不可预测性
• 金丝雀降低风险
• 与传统功能的差异

AI 功能更需要金丝雀部署，因为其输出不可预测、质量难事先完全验证、可能产生幻觉/有害内容/成本波动，且 prompt/模型/检索变更影响难以静态评估。传统功能逻辑确定、可单测、行为可预期，全量风险可控；AI 功能在真实流量下的表现未知，全量上线风险高（错误内容、成本突增、用户体验崩坏）。金丝雀先把小流量接入新版本，在真实用户下观察质量/延迟/成本/安全，达标再放量，能把不可预测性的风险限制在小范围，并快速回退。

AI 的"不可预测性"把全量上线变成高风险行为。金丝雀用小流量换"真实世界验证"，是 AI 上线的必要防线。

• 多版本流量分配（等分/按权重）
• 多组间的显著性判定
• 多重比较问题

多模型并行灰度（A/B/C 三个及以上版本）时，流量分配需保证每组样本量足够支撑组间对比，通常按等分或按权重分配；要把同用户/会话固定到同一版本避免串扰。显著性判定：两两比较组间差异（如 A vs 基线、B vs 基线）需要多重比较校正（Bonferroni、FDR），否则假阳性上升；可先做总体检验（ANOVA 类）再两两比较；每个版本都要有足够样本量。判定结论是"哪个版本显著优于基线"再决定放量哪个。流量分配还受成本与风险约束（新版本不宜一开始给太多流量）。

多模型并行灰度的核心是"多组比较的统计严谨性"。样本量充足、固定分流、多重比较校正是避免"看起来多个版本都好"的假象的关键。

• 质量/延迟/成本三类指标
• 联合停止规则
• 权重与优先级

灰度验收要同时看质量、延迟、成本三类，停止规则联合设定：质量指标（准确率、引用支持率）不达标→直接停止（质量是底线，不因成本低而放行）；延迟（TTFT、P95）超阈值→停止或限流（体验受损）；成本（单请求成本）超预算→停止或降级（成本不可持续）。联合逻辑：可用"硬门槛+综合评分"，任一硬门槛跌破即停，或者综合评分（质量权重最高）低于基线即停。停止规则要明确优先级（质量 > 延迟 > 成本）并设不同的容忍度，避免单一指标掩盖其他劣化。

联合停止规则的难点是"多指标权衡"。质量是底线、延迟体验、成本可持续，用优先级+硬门槛+综合评分联合判定，避免只看单一指标。

• 回滚触发条件设计
• 联合触发逻辑
• 回滚后的恢复灰度

自动回滚联合触发：错误率（如 5xx、超时、解析失败）连续超过阈值、延迟 P95 超过 SLA、成本单请求超过预算，三者任一或多个达到条件即触发回滚。设计上"连续窗口+阈值"防抖动；可设"任一关键指标连续 N 分钟超阈值"或"多指标同时劣化"触发。回滚后恢复灰度：先让回滚版本稳定运行观察基线；修复问题后重新走灰度流程（从影子/小流量开始），不得直接回放全量；复盘根因并纳入评测集防回归。回滚要保留现场（样本、日志）供分析。

联合回滚的关键是"指标触发条件与防抖动"。回滚不是终点，而是"修复后重新验证"的循环起点，恢复灰度必须重走小流量。

• 反馈信号收集（问题上报、满意度、行为信号）
• 信号聚合与量化
• 回流为放量/回滚决策

灰度期要主动收集反馈信号：用户问题上报（投诉、错误反馈）、满意度信号（点赞/点踩、评分、重试/放弃行为）、客服反馈、以及客观行为信号（对话中断率、二次编辑率）。把这些信号聚合量化（满意度分、问题率、负面反馈率），与质量指标一起回流决策：负面反馈率明显上升→暂停或回滚；满意度达标→继续放量；问题集中在特定场景→针对性修复后重测。反馈闭环要求"信号→量化→决策→修复→再验证"的循环，且反馈要能触发人工介入（高危反馈即时告警）。

反馈闭环的本质是"把用户真实体验变成可决策信号"。问题上报与满意度是主客观结合的信号源，需量化并与自动化指标联动，不能只看机器指标。