排期上写的是"一周内全量"。两周后那个常量还是 0.1。
倒不是出了什么问题。备用模型接好之后（85 篇那次故障之后加的），我们按会话 id 取模分流，放 10% 过去，打算看两天没问题就 50%、再全量。结果第一步就停住了。
分流做得挺随便
def use_fallback(session_id):
return (session_id % 100) < settings.AI_FALLBACK_PERCENT # 默认 10
按会话取模而不是按用户，是因为游客没有稳定身份；同一个会话始终走同一条路，这点够了。当时还顺手确认了每日限额的 key 是按身份加日期算的，跟走哪条模型无关，切流不会把限额重置掉。
要看四个数：拒答率、转人工率、p95 延迟、单次成本。前两个来自审计表的 verdict，后两个来自日志里的 usage 和打点。前面几篇折腾的那些埋点，这时候总算派上用场。
卡在哪
问题出在样本量。
客服离线时段的调用本来就不多，一天二十次封顶（AI_CHAT_DAILY_LIMIT 是按单个用户算的，但全站加起来也就几十次），10% 意味着一天落在新模型上的只有个位数。
这个量下，拒答率一天能从 20% 跳到 40%，也可能一天全是 0%。你没法判断这是新模型更爱转人工，还是恰好那几条问题本来就难。我做了张按天的表，四个格子有三个是空的，剩下那个数字看着还挺吓人，第二天又没了。
有人提议直接放到 50%，样本一大就看得清了。这个建议被否了，理由有点绕：放量的目的本来是"确认没问题再放"，先放到一半去看有没有问题，等于把验证和放量合成了一步。真出问题，影响面已经是 50% 了。
试过的办法有两个。一是延长观察窗，从两天改成两周，把足够多的会话攒起来再算；二是固定时段对比，只比较同一时间段（比如都是晚上十点到十二点）的数据，避开白天和夜里的问题类型差异。第二个比第一个有用，因为拒答率跟用户问什么关系太大了，晚上的问题跟白天的根本不是一回事。
两周攒下来，新模型的四个数跟旧的差别都在波动范围内。没有变好，也没有明显变差。这时候"要不要全量"就变成一个很难回答的问题——你手上没有证据说它更差，也没有证据说值得换。
严格讲这不叫 A/B。
同一批用户不能同时看到两种模型，我们只能比较"被分到新模型的那些会话"和"被分到旧模型的那些会话"，而这两组人问的问题、什么时段来、是新用户还是老用户，全都不一样。碰上节假日或者某天站里出了个解析故障，两边的问题分布立刻偏掉。
真要做对照组，得按用户稳定分桶，让同一群人始终看同一个版本，再跑够样本量做显著性判断。以我们这点调用量，跑出来可能要一两个月。为一个备用模型花这个时间，不划算。
所以最后其实是凭判断全量的：四个数没恶化、离线回归集上边界条款也守得住、故障切换那条链路测过能切回来，那就放吧。说"数据支持全量"是抬举自己了，准确说是"没发现反对理由"。
这个说法我在周会上讲了一遍，没人追问。可能大家也都清楚，这种量级的功能本来就不该装作在做严谨实验。
分流开关和熔断是两套状态。备用模型自己也有健康检查（85 篇那个探针），主模型熔断时切过去，如果备用同时在熔断，就会两边都不调、直接降级。这个组合在灰度期间没出现过，是后来演练才撞上的。
另外切到备用之后，提示词缓存是冷启动，头几百次请求的单价高一些。那几天成本曲线有个小凸起，我第一反应是备用商更贵，差点去问人家计价。查到是缓存没命中才作罢。
VidDown 技术博客，站内功能也是这么一点点放出去的。
那个 0.1 后来改成了 100，但注释还写着「临时灰度，观察后调整」。上回 81 篇里也提过一句类似的注释，看来我在写注释这件事上挺一致。