灰度是给人接管的,不是给模型放权的

灰度不是给模型放权的过程,是给人接管的过程。接手的业务方有没有判断口径、兜底路径和暂停权——三样缺一样,他就不是在接管,只是在旁听。

前面聊上线前三道门时提到过灰度:它给团队留出一段可观察、可收缩的缓冲区,要回答放给谁用、放多少量、何时继续或暂停。那张清单解决的是"怎么放"。

这篇往下走一步,聊缓冲区里站着的那个人:他凭什么判断,敢不敢推翻,什么时候可以不用再站在那儿。

那场官司里,输的不是模型

2022 年 11 月,加拿大一位乘客的祖母去世,他上航空公司官网订机票,想申请家属丧葬的优惠票价。

机器人告诉他:可以先买全价票,90 天之内再申请退差价。

他照做了,还截了图。两个月后申请退费,人工客服说不行,政策不允许事后追溯。他掏出截图,对方承认机器人"用词有误导性",但退款还是不给。协商无果,他把航空公司告到了不列颠哥伦比亚省的民事仲裁法庭。

2024 年 2 月,法庭判他赢:赔偿 650.88 加元,外加利息和仲裁费。(案件编号 2024 BCCRT 149,判决书网上查得到)

法庭上有句回应挺硬。航空公司主张聊天机器人是独立的法律实体、该为自己说的话负责,法庭驳回:它仍然只是你们网站的一部分,信息来自静态页面还是来自机器人,没有区别。

这个案子里真正值得琢磨的,是柜台上那位员工:他错了吗?

他知道机器人给的政策不对。但他手上没有一条流程告诉他——客户拿的是自家机器人说的话,这时候该怎么办。是按机器人说的办,还是按内部政策办,还是往上报?没有。

那他能做的最安全的事,就是坚持按政策办。

这就是兜底路径缺位的样子。不是人不行,是没人告诉他推翻之后往哪走。

一个很常见的灰度现场

灰度期常见的安排,是让一位业务骨干盯着:每天抽两小时,翻几十条 AI 输出,觉得不对的就改掉,记到表里,周会同步。

从外面看这套安排很完整:有人、有表、有节奏。

但把问题问细一点就露馅了——他改掉的那些,是按什么标准判断"不对"的?

如果答案是"凭经验",灰度质量就完全挂在他一个人身上。他状态好的时候多拦几条,忙的时候少看几眼,判断的松紧跟着当天的工作压力走。

更关键的第二层:他拦下来之后走什么流程?

灰度是给人接管的不是给模型放权的 配图1
配图1

灰度的验收对象不是模型,是人

模型准不准、召回够不够,应该在评测那道门里定完。进了灰度还在调效果,说明前面那道门没关严。

灰度期真正要验的是另一件事:业务方在缺少项目组现场支持的情况下,能不能独立判断这条 AI 输出能不能用。

举个能落到数字上的场景。假设你在一家银行推信贷报告的智能审核,验收台阶其实可以定得很朴素:模型初测 60 分上下,研发自己测到 80 分,交给信贷员试运行调优,能稳定在 90 到 95 分。再往上不承诺,因为到不了 100。

这个台阶的价值不在数字,在于它把"谁来判断能不能用"提前交到了信贷员手上。等到灰度期再跟项目组争准确率够不够,就晚了。

一个 90 分准确率的模型,配上一套清楚的接管依据,业务方用得住;一个 95 分的模型,没有接管依据,业务方只能一直盯着,一盯就是半年。

人接不住,通常缺的不是意愿,是三样东西

下面这套是我们用来对照自查的实践框架,不是行业标准,也没有经过大样本验证,拿出来是便于逐条核对。

在我们复盘过的项目里,业务方接不住的情况,多半不是因为"不想接"。卡住的地方很集中,基本是这三样。

第一样:判断口径。

什么情况下可以信这条输出,什么情况下必须翻查。

接着上面这个场景。检查项可以这样劈成两类:格式、要素缺失、金额前后不一致这类能确定性判断的,写成脚本,机器直接判,结果稳定还不花钱;需要理解语义的——比如报告结论跟引用的材料是否自洽——才交给模型,模型给提示,人做最后判断。

这么一劈,信贷员要盯的范围就清楚了:脚本判出来的照单执行,模型给的提示自己过一遍,两类之外的自己拿主意。

口径的作用不是让人变聪明,是让不同的人在不同时间做出同一个判断。

第二样:兜底路径。

推翻一条 AI 输出之后,业务走什么流程。

这一条最容易被漏。在我们看到的项目里,定义了"什么情况要转人工"的不少,但接着定义"转人工之后怎么做"的少得多——是按原流程手工处理,还是走另一套简化流程,处理完要不要留痕。这些没写清楚,兜底就只是一句话。

Air Canada 那个案子就是典型:机器人说错了,客户拿着截图来了,员工也知道错了,但没有任何一条流程告诉他这时候怎么办。最后只能把客户推回去,一路推到法庭上。

没有兜底路径,人即使看出问题也倾向于放行,因为放行的责任比拦下的责任小。

第三样:暂停权。

谁有权喊停,喊停之后多久生效,需要几方确认。

如果暂停一次要开三个会、签两次字,那这个权力实际上是不存在的。错误扩散的速度通常快过上报链路,等会议开完,影响范围已经不是当初那个量级了。

暂停权真能用的样子,公开报道里有个例子。2024 年 1 月,英国快递公司 DPD 的客服机器人系统更新后出了问题,被用户诱导着骂了人,还写了首俳句自称"没用的客服"。这段对话 24 小时内阅读超八十万。

DPD 当天的动作是:把 AI 那部分直接关掉。("系统更新后出现了错误,AI 元件被立即禁用。")

关掉的是 AI 那一层,原来的客服通道还在,客户照样能找到人。从出事到关停,中间没有开会。

判断口径应该写成什么样

"口径"这个词容易被写虚。落到文档上,至少包含四类可逐条核对的内容:

最后这条最容易被漏,也最要紧。默认动作建议设成"翻查"——漏判的代价通常高于多查一次,而没有明确规则时,人天然往省事的方向走。

写完之后可以做个很省事的检验:找两位业务骨干,给他们同一条 AI 输出,看判断是不是一致。不一致的地方,就是口径还没写清的地方。

灰度期的人力成本,谁出

还有件更现实的事:灰度期盯着的那个人,时间算在哪个账上。

如果这部分人力没进项目预算,他实际上是在用本职空隙做这件事。这时干预率下降可能不是因为他学会了,而是因为他没时间看了。

所以立项时把三笔账摆到桌面上:灰度期多少人天、哪个部门出、延期谁承担。这三笔账不清,"要不要继续放量"最后都会变成互相体谅,而不是基于事实的判断。

放量刻度可能从一开始就选错了

先看一组数字。2024 年初 Klarna 上线 AI 客服,官方说首月处理 230 万次对话,相当于 700 名全职客服的活,平均解决时长从 11 分钟降到 2 分钟。

很漂亮。但"处理了多少"和"接得住吗",是两件事。

灰度怎么放量,我们看到的做法里占比最高的还是按流量比例走:先放 5%,指标没问题加到 20%,再没问题放到 50%。

这个刻度本身没错,但它测的是暴露量,不是接管能力。

流量比例回答的是"让多少人碰到它",接管能力要回答的是"碰到它的人能不能自己处理"。这两个问题的答案并不总是同步。

一个更贴近接管能力的刻度,是人工干预率随规模变化

第三种情况在数据表上特别好看:人工成本低、处理速度快。但它意味着灰度已经失去了意义。

灰度是给人接管的不是给模型放权的 配图2
配图2

灰度怎么算结束

回头说 Klarna。2025 年 5 月,它的 CEO 公开表示,成本因素在决策里占的比重太大,结果是服务质量下降,公司又开始招人工客服,保证客户总能找到人。

从接管的角度看,这就是退出条件没写清楚:AI 干了 700 人的活,人就先撤了;撤早了,再请回来。

没有退出条件的灰度,很容易滑成长期并行。两套系统一起跑,谁也不敢关旧的。跑三个月还能说是过渡,跑一年就是成本结构出了问题——人力两份、维护两份、口径还要两边对齐。

结束条件建议在项目启动时就写死,至少三条:

第三条尤其重要。没有人签字的接管,等于没有人负责,最后出问题还是回到项目组。

出现这几种情况,先停下来

灰度期可以自查的五个问题

前三个没答上来,说明接管还没建立;后两个没答上来,说明灰度没有终点。

金融、医疗这类强监管场景,接管口径和暂停权还要叠加合规约束;上面这份清单只提供一个起点,具体字段需要结合自身风险与审计要求调整。

我自己判断一个系统算不算真上线,标准很土:不看它跑在哪,看出事那天谁在岗、谁有权、谁负责。

你们灰度期怎么定放量节奏?按流量比例,还是看了别的指标?有没有过"数据很好看,事后才发现人早就不看了"的时候?评论区聊聊。

关于作者

西北人,计算机专业硕士,长期在金融科技、网络安全、数字化转型和企业管理一线工作,拥有近20年从业经历。曾任商业银行科技部负责人,牵头单位网络安全"冬奥"重保工作,也是企业级AI产品 CheersAI 创始人。这里更关注一线实践里的真实问题:技术怎么进入业务,安全怎么落到组织,AI 怎么从"能用"走到"用好"。不讲空话,所有观点均来自于实战;敢于发声,均源于亲自上过场。