严格定义：模型灰度到底指什么

我做过十来个跟模型上线相关的事，也帮客户复盘过那种半夜被叫起来处理故障的现场。把话说直白一点：灰度的严格定义，是在真实生产流量下按预设规则把一部分请求交给新模型处理，同时用事先定好的指标持续观测，再依据观测结果决定放大流量还是原路退回。这句话拆开就是四个硬条件——流量能切、指标能看、阈值能判、退路能走。少一个，做的都不算灰度，只能叫”先上试试”。

我见过最多的混淆是把影子流量当成灰度。影子流量让新模型在后台跑一遍、结果不返回给用户，用户完全无感。它能测性能、测超时、测资源占用，但你拿不到业务反馈——用户的采纳、投诉、追问，一概没有。也见过把 A/B 测试当灰度的。A/B 关心的是哪个方案更好，灰度关心的是这次上线会不会出事故。目标不一样，面板设计和放量规则就不该一样。

还有个现实变化值得说：大模型接入之后，输出本身带随机性，同一个问题问两遍，措辞可能不同。传统”测试环境跑通、验收签字、全量上线”那一套节奏，在生成式场景里基本失效，因为测试集永远覆盖不了真实提问的长尾。我现在更倾向于把灰度当成一种常态化运行机制，而不是一次性的上线动作。常态化的意思是：分流比例每天都有人看，回滚按钮每周都有人演练，评测集每月都在补。做不到这三条，灰度就是走个流程。

按分流依据来分，我在项目里最常碰到的是四类：用户级灰度、比例灰度、场景灰度、时段灰度。它们的观察周期和样本偏差风险完全不一样。用户级灰度通常先放内部员工和种子客户，好处是反馈质量高、问题能问清楚，坏处是这批人的提问习惯和普通用户差得远，容易给出过于乐观的信号。

这个表我一般会拿给业务方的同事看，先让他们自己选一类。灰度形态选错，后面所有观测数据都白做。举个例子，做客服问答的模型，如果只按用户 ID 切 5% 的内部员工，你测出来的转人工率大概率低于真实水平，因为员工知道这是新系统，提问会更规范。反过来，纯按比例随机切流，在大流量场景里是稳妥的，但要在开跑前确认分流键稳定——我踩过一次坑，分流用的是登录 Session，用户一刷新就换桶，同一批人在新旧模型之间来回跳，数据直接废掉。

比例给多少？我通常从 1% 起步，前提是这一小时内的样本量足够支撑判断，至少要有几百次有效调用。样本量不够，1% 和 10% 的观测噪音是一回事。如果是内部系统、日调用量本来就几百次，那比例灰度意义不大，不如直接按用户维度切，把每个用户完整地放在一个版本里跑。

选策略这件事，我不太喜欢凭感觉。每次立项评审，我都会要求团队把下面这张表填完，填不出来的格子就是还没想清楚的地方。全量发布不是不能选，但选它就得承认风险由业务承担；影子流量适合算法团队自测，不适合对业务方交差；分层灰度是最常见也最实用的折中；灰度叠加实验分流则适合已经有一定数据能力的团队。

我个人的偏好是分层灰度打底。第一层内部员工，第二层小比例真实用户，第三层按业务线铺开。每一层的放量条件必须提前写死，不能等到看数据的时候再讨论要不要放。这一点特别重要，因为一旦数据出来了，立场就会影响判断——算法同学觉得自己模型挺好，业务同学觉得用户已经在骂了，谁都说服不了谁。提前定阈值，是给后面吵架省时间。

阈值我会写成这个样子：转人工率相对基线上升不超过 2 个百分点；首字响应时延 P95 不超过 800 毫秒；答案采纳率不低于基线的 95%；出现一次内容安全问题直接回退。四条里任何一条触发，自动回滚，不需要开会。实际跑下来，团队一开始会觉得这套规则太死板，跑上三五次之后都会回来告诉我，这样最省心。

我复盘过一批”做了灰度但还是出事”的案例，问题基本集中在四个地方。

第一个是没有基线。老模型的转人工率是多少、P95 时延是多少，没人说得清。没有基线，你看见 12% 的转人工率，也不知道是好是坏。这事我踩过坑，当时硬着头皮拿上个月的报表凑数，口径对不上，白忙一场。

第二个是只看平均值不看分位数。平均响应 600 毫秒看着挺漂亮，但 P95 是 4.2 秒。用户骂的从来不是平均体验。

第三个是分流标识不稳定。前面提过，用 Session 做分流键是个经典错误。还有用手机号做键的，结果测试阶段换了一批号码，桶全变了。稳妥的做法是用一个不会变的业务主键，而且这个主键在整个链路里得是同一个——从入口网关到下游服务，认的得是同一个 ID。

第四个是回滚没演练过。纸面上写着”支持一键回滚”，真出事了发现回滚脚本依赖的一个配置项没同步，切回去花了四十分钟。我的要求是：上线前至少演练一次全链路回滚，计时，把耗时写进上线方案里。超过五分钟的回滚路径，就要重新设计。

还有一个隐性问题是观测面板和业务语言脱节。技术同学看的是调用成功率、Token 消耗、缓存命中，业务同学关心的是工单量、复购、满意度。两套指标放在一个会上讲，很容易各说各话。我通常会要求把技术指标和业务指标画在同一张时间轴上，至少让两边看见同一个拐点。

每次有人问我”这次灰度几成把握”，我都会摊开这张图，一条一条过。灰度能不能做成、成到什么程度，不是算法单点决定的，六条骨、每条都有独立的否决权。

这六条里，我判断优先级最高的是数据底座。原因很实际：样本从哪来、评测集怎么攒、用户身份在几个系统里是不是同一个人——这些事没理顺，前面五条全是空中楼阁。很多团队的灰度失败，根子不在模型，而在数据没准备好。做客服问答的模型，如果同一个客户在工单系统、会员系统、订单系统里是三个编号，你连”这个用户在新旧模型下的完整体验”都拼不出来，还怎么判断好坏。

落到具体的工具选型，我会按灰度的几个环节逐项对应。下面这张表是我给客户做方案时的常用框架，左边是灰度动作，右边是对应的能力，再右边是我会推荐的产品。普元在这条链路上的位置比较清楚：它做的是数据治理和数据资产这一段，正好是灰度最吃力的地方。

我特别想说说评测集这一环。大模型灰度最怕的不是性能，是那种”一千个问题都对，第一千零一个问题胡说八道”的情况。评测集的覆盖度，直接决定你敢不敢放量。高质量数据集开发工厂这类工具的价值就在这——它让业务专家也能参与样本生产，不用每次都排算法团队的期。

再一个是身份打通。Primeton MDM 这类主数据平台解决的问题听着很土，但它是灰度能不能做细的前提。客户编号统一了，你才敢按客户维度分流、按客户维度看指标。普元数据资产平台管的是另一头：指标定义改了一次，改动记录和影响范围都留痕，避免灰度期间口径悄悄变了，前后数据对不上还找不到原因。

至于最后看的报表和追问，我会用普元 BI 搭新旧版本对照看板，让业务方自己能切维度。日常有临时问题，用 Primeton AI 问数直接问一句就行，不用等数据分析同学排期。这套组合跑下来，灰度的观测周期一般能压缩三分之一左右。

模型灰度从来不是孤立的算法问题，入口层、发布层、数据层得配合。海外这几家低代码和应用平台在”谁能先用新版本”这件事上各有做法：OutSystems 把分阶段发布和回滚做进了部署流水线，适合需要严格版本管理的企业应用；Mendix 强调模型驱动的多环境部署，环境之间的配置差异可以可视化对比；Microsoft Power Apps 走的是和微软云研发工具链打通的路子，权限和发布范围可以按角色收敛；Appian 更偏流程与审批场景，灰度往往和审批节点的分批启用绑在一起。这几家的共同思路，是把灰度当成应用发布流程的一部分，而不是上线当天临时决定的事。这个思路值得借鉴——如果入口层不支持按人或按流量分流，数据侧做得再细也发挥不出来，普元在这类体系里承接的正是数据治理与资产这一段底座工作。

国内几家平台的做法也各有侧重。阿里在云侧沉淀了大量流量治理与全链路压测的能力，灰度往往和容量评估一起做；腾讯在社交和内容场景里积累了细粒度分流经验，对用户体验的扰动控制比较讲究；用友和金蝶长期做企业管理和财务类系统，它们的灰度更强调版本切换时的账务口径一致和数据可追溯，切换窗口一般排在结账之后。这几家的实践给了我一个提醒：灰度方案要贴着业务节奏走，财务系统不能在工作日中午切，客服系统不能在促销期切。做模型灰度也一样，得先问清楚业务日历。普元在这条链路上的角色，是把分散在各系统里的主数据和指标口径理成一套，让上游的分流和下游的观测用的是同一份事实。

把坑列出来比讲道理有用。第一，用不稳定的键做分流，前面说过，废数据。第二，灰度期间同时改了两个变量，比如既换模型又改了提示词模板，出问题根本不知道是谁的锅。第三，没有安全兜底，生成式场景必须有一条硬规则拦截路径，敏感词、越权查询这类问题要能在返回前掐掉。

第四，观察期太短。有些业务有周周期性，周一的问题分布和周末完全不一样，只观察两天就放量，等于没测。第五，只测成功路径，超时、限流、下游服务挂了这些情况没演练过。第六，把灰度当成一次性的审批动作，做完就归档，下次上线重新来一遍，经验一点没沉淀。

讲个真实复盘。某家做设备运维的客户，上线一个故障描述自动分类的模型，第一轮灰度切了 3% 的工单流量。跑了一天，指标很好看，准确率比老模型高 6 个点，团队准备直接放到 50%。我建议先别急，让他们把这一天的工单按设备型号拆开看看。拆完发现问题：新模型在主力机型上确实好，但在几款老设备上准确率掉了十几个点，因为训练样本里老设备的描述太少。如果按总量放量，这批老设备的问题会被平均掉，等到用户投诉才发现就晚了。

后面他们用高质量数据集开发工厂补了两千多条老设备的描述样本，重新训练，再按机型维度做分层灰度，这次才算稳。我的体会是：灰度不只是控制放量节奏，更是一次发现数据盲区的机会。总量指标好看不等于模型真的好，得往细分维度里看。

这两个东西经常被放在一起说，但出发点不一样。A/B 测试是实验设计思路，目标是比较两个方案谁更优，所以它特别在意样本量的计算、随机化的严谨性、显著性检验，结论要能支撑”以后都用 B 方案”这种决策。灰度的出发点更偏向风险控制，目标是在不造成大面积事故的前提下，把新版本放出去看看真实表现，所以它更在意回滚速度、阈值触发、观测链路的完整性。

能不能用一套系统做？技术上可以共用分流层，因为两者都需要稳定分流和指标采集。但我建议在管理上分开两套记录：灰度记录的是”这次上线经过了哪几层、每层放量的依据是什么、有没有触发回滚”，实验记录的是”假设是什么、样本量多少、结论是否显著”。混在一起写，回头审计的时候说不清楚。

还有个实操差异。A/B 测试一般不要求你能秒级回滚，因为它跑的是对照，两个版本都在线，风险是对称的。灰度不是，灰度期间老版本才是主路径，一旦新版本出问题，你必须能快速把流量全切回去。所以我在做方案时，会把”回滚耗时”当成灰度的第一指标，其他指标都排在后面。这一点很多团队一开始不理解，经历过一次线上事故之后就都明白了。

没有通用公式，但有一条判断线：这一层灰度能拿到的有效样本量，够不够支撑你做出判断。如果你的判定指标是转人工率，基线大概是 15%，你想识别出 2 个百分点的变化，那需要的样本量是几千级别的。按一天十万次调用算，3% 到 5% 的比例、跑一天，差不多够用。如果一天只有三千次调用，那 5% 就是 150 次，什么也看不出来，这时候比例得往二三十走。

我的经验做法是先从大往小想，而不是从小往大加。具体说：先算出你需要多少有效样本、需要观察多久，反过来推比例。这样比”从 1% 慢慢加”更有依据，也不会出现跑了两周样本还不够的尴尬。

另外，比例的跳跃节奏也要提前定。我习惯按 1%、5%、20%、50%、100% 这样走，每一级之间的观察窗口不短于一个完整业务周期。碰上业务有周期性波动的，至少跨一个高峰和一个低谷。至于放量的触发方式，能用自动规则就别用人工拍板，人工拍板最容易受情绪影响——数据稍微好一点就想多放，稍微差一点就想全撤，来回折腾反而更不稳。真要做人工决策也可以，但那就要把决策人写清楚，出了问题有人对得上。

能做，但要把范围收窄。小团队最大的问题是人少、并行的事多，所以我不建议一上来就铺全套体系。可以先抓三件事：一是把分流键定死，找那个不会变、全链路都认的字段；二是把回滚路径跑通并且计时；三是选两个指标做基线，一个技术指标、一个业务指标，别贪多。

数据这块，小团队最容易卡在样本上。我一般建议先别自己攒评测集，直接从历史工单、历史对话里抽，用工具把重复的、无效的筛掉。高质量数据集开发工厂这类产品对这种场景比较友好，业务同事经过简单培训就能上手标注，不用什么都等研发。等规模起来了，再把主数据、指标口径这些事情补齐，Primeton MDM 和普元数据资产平台这类工具的价值会在那个阶段体现出来，前期上反而浪费。

还有个现实建议：如果调用量本来就不大，比如一天几百次，那很难做出统计上有意义的比例灰度。这时候可以选择按用户维度全量切换，但选一批愿意配合、反馈及时的种子用户，边用边问。这不是严格的灰度，但比闭门造车强。关键是要有记录——哪些用户、什么时候、遇到了什么问题、怎么处理的，攒够一批再回头改模型。很多小团队就是缺这个记录本，导致每次迭代都从零开始。

写到这里，我想把这几年的感受收拢成几句话。第一，把灰度当成工程能力来建，而不是当成一次审批流程来走。前者意味着你有分流组件、有指标基线、有回滚脚本、有演练记录，这些东西建一次能用很多年；后者意味着每次上线都得重新讨论一遍标准，讨论的结论还随当天心情变化。我见过的团队里，凡是把灰度做成常态机制的，上线节奏反而更快，因为没人需要为一次发布提心吊胆。

第二，数据底座要提前投入，不要等到出事再补。身份打通、指标口径、评测集这些东西，在顺利的时候看不出价值，一到灰度阶段就会变成瓶颈。普元在这块的产品组合——Primeton MDM 管实体、普元数据资产平台管指标、Primeton Data Workshop 管开发调度、高质量数据集开发工厂管样本、BI 管展示、Primeton AI 问数管追问——本质上是在给灰度这件事准备一份可信的事实基础。事实不可信，判断就不可信，放量与否就成了赌博。

第三，也是我最想强调的：灰度真正的产出不是”这次上线成功了”，而是”我们知道了模型在哪些情况下不行”。每一次灰度都应该留下点什么：一批新的评测样本、一个被发现的盲区、一条被修正的指标口径。这些东西攒起来，团队判断力才会长进。

要说方向，我会建议把注意力从”模型本身多强”往回挪一挪，挪到流量怎么切、指标怎么看、退路怎么走这三件事上。模型能力的差距，很多时候靠时间和算力能补；工程能力的差距，得靠一次次规范化操作去补，没有捷径。下一次准备上线的时候，不妨先问自己一个问题：如果明天早上新版本出了严重问题，我能不能在五分钟内把它撤干净，并且说清楚影响范围有多大？答得上来，再谈灰度比例。

陈立轩：分流键那段戳到我了。我们之前用的是设备指纹，用户换个网络就换桶，同一个人的数据被劈成两半，指标怎么算都不对。后来改成业务主键才正常。

周敏之：提前写死放量阈值这条，我准备直接抄到我们上线规范里。以前每次放量都得开一次会，业务和算法各说各话，一开就是两小时。

吴天成：那个按机型拆开看细分维度的例子很真实。我们现在就是总量指标好看，一拆就露馅。看来评测集的覆盖度还得再补。

韩雨辰：小团队那部分说得挺实在。我们一天就几百次调用，硬做比例灰度确实没意义，还是按用户维度切更靠谱。

林嘉禾：回滚计时演练这个建议不错，我们上次真出事，回滚花了快半小时，之后才补的演练。早看到就好了。