2 篇博文 含有标签「rollout」

客户将智能体的回答粘贴到支持聊天中，并要求人工代表进行确认。代表看着同一款产品，却给出了相反的说法。那天，客户并没有对智能体失去信心。他们是对公司失去了信心，因为公司的两个部门在同一个小时内告诉了他们两件截然不同的事情。

一切都没有出错。AI 团队在周二通过特性标志（feature flag）发布了一个提示词更改，到周四已推行至 100%，然后便继续下一项工作了。客户成功（CS）团队的赋能周期是按月进行的 —— 以前每个产品特性都是这样落地的，而且没人针对 AI 重新协商这一流程。CS 代表队列中的宏（macro）和公共网站上的 FAQ 文档描述的仍然是之前的行为。智能体是对的。代表根据他们掌握的文档也是对的。但公司表现得各说各话。

我上个月交流过的一个团队，在四个星期内将一项新的 Agent 功能从 1% 的用户灰度推广到了 50%。聚合质量指标保持在噪声范围内，延迟也保持在 SLA 之内。他们正在准备 100% 全量发布的备忘录时，支持队列突然“起火”了——一个拥有六工具研究工作流的客户，自 10% 灰度阶段以来就一直在接收静默损坏的输出。困难查询（Hard queries）一直存在，均匀地分布在每个分群中，被平均化到了底噪中。直到一个高频用户在大规模使用中撞上了这些问题，大家才发现。

这不是监控失败，而是灰度发布维度的失败。功能标志工具（Feature flag tooling）——包括 LaunchDarkly、Flagsmith、Unleash 和 Cloudflare-Flagship 等所有此类工具——都假设爆炸半径（blast radius）随接触到的人数成比例扩大。对于确定性软件，这在很大程度上是正确的：一个空指针异常（NullPointerException）要么影响所有人，要么谁都不影响，将其暴露给 1% 的用户会将可见的爆炸范围限制在 1%。但对于 AI 功能，爆炸半径并不在“人”这个维度上扩展，而是在“输入”维度上扩展。而几乎没有人会在输入维度上进行灰度发布。