什么是模型灰度？一篇文章带你入门

做数据这行十多年，我参与过不少模型上线项目，真正让我睡不好觉的从来不是训练那一环，而是新模型推开的那一刻。模型灰度说白了就一件事：新版本别一上来就全量铺开，只放一小拨真实流量进去，边跑边看，稳了再逐步放大。这事听起来简单，落到工程里全是细节——哪部分用户进灰度、他们的数据链路怎么和旧版隔离、评测集从哪来、出现异常几分钟能退回去。我见过团队把灰度当成一次技术动作，结果第一周就被投诉打回；也见过团队把灰度当成长期机制，每一次模型迭代都走同一套流程，反而越跑越轻松，版本节奏从两个月一版变成两周一小版。

我的判断是：灰度能不能做成，七分看数据底座，三分看算法。评测集是不是独立于训练数据、特征有没有版本号、样本能不能追溯到原始业务单据、主数据在新旧模型之间是否一致，这些才是决定灰度成败的东西。模型本身那几个指标，往往只是那张成绩单。所以下文我按真实项目里的推进顺序来拆——先看清灰度分几层，再看不同灰度方式怎么取舍，然后讲我踩过的坑，以及数据平台在中间该承担什么角色。

先把灰度四个阶段和各自的验收重点摆出来，你对照自己项目看处在哪一格：

我刚入行那会儿，一听到灰度就自动理解成“流量切 5%”。后来做了几个大项目才发现，这个理解太窄了。实际项目里，灰度同时在三个层次上发生，只不过大部分人只盯着其中一个。

数据模型层的灰度，指的是主数据模型、指标口径、宽表结构这类东西的变更，先在部分业务线或部分报表上生效。比如集团把客户主数据模型升了一版，新增了几个属性、合并了两个旧字段，这时候不可能一夜之间把所有下属公司的报表全换掉。算法模型层的灰度最好理解，新版本只服务一部分用户。业务规则层的灰度容易被忽略，风控阈值、营销策略这些规则改了之后，同样需要小范围试跑。

这三个层次经常是同步进行的，麻烦也出在这儿。有一次一个零售客户的项目，算法团队换了新版本推荐模型，同时数据团队调整了商品标签口径，两边都觉得自己只动了一小块。灰度跑了一周，业务方看到转化率跌了 8%，三个团队互相翻数据翻了两天，才发现是标签口径变化把一批长尾商品从推荐池里挤出去了。层次不清，就会一直出现“模型没变但报表数字变了”这种扯皮。

把这三层拆开之后，我在项目上会要求每个层次单独出一张变更清单，谁改了什么、影响哪些下游、谁签字认账，白纸黑字。这活儿枯燥，但能省掉后面无数次会议。

项目上真正可选的灰度方式就那么几种，我按用户维度、随机流量维度、业务批次维度这三条路走过很多遍，各自的脾气摸得比较清楚。用户维度分流最直观，圈一批内部员工或者种子用户进来，好处是反馈快、问题暴露早，坏处是这批人的行为和普通用户差别不小，容易得出偏乐观的判断。

随机流量分流更接近真实分布，适合有足够日活的产品。但随机意味着同一个用户今天在新版、明天可能在旧版，体验上会跳，对交易类、金融类业务不太友好。业务批次分流就是按地区、按门店、按子公司一批批上，天然有隔离边界，出问题影响面可控，只是扩量节奏慢，一轮下来往往要几周。

我的经验是：能不能把“谁进了灰度”这件事记清楚，比选哪种方式重要得多。记录做不住，后面所有分析都是糊的。

头一个卡点是评测集和线上分布两张皮。我在一个金融客户那儿看过，算法团队自己攒的评测集准确率 96%，上线之后业务侧指标反而跌了。原因不复杂：评测集是从历史优质样本里挑出来的，天然干净，线上进来的却是一堆脏数据、缺字段、重复提交。评测集不独立、不贴近线上分布，灰度就失去了意义。

第二个卡点是特征和样本没有版本。同一份特征今天是这个算法，明天口径改了，回溯的时候就说不清当时的结论是怎么来的。我一直建议特征和样本集都要打版本号，跟代码一样管理。

第三个卡点是主数据新旧不一致。灰度期间新旧模型并行，如果客户、商品、组织这些主数据在两边对不上，报表对不齐，业务方第一反应就是“系统坏了”。这类问题排查起来特别耗人，往往要拉出全链路血缘才能定位。

第四个卡点是缺少可回退的开关。有些团队把灰度开关写在代码里，回退要重新发版，等半小时。这半小时里业务还在报错。真正管用的灰度，一定是开关和数据解耦的，谁都能在几秒内把流量切回去。

项目复盘做多了，我把灰度出问题的原因画成了一张鱼骨图。横着看是结果，竖着看是几个源头，每次出问题我就顺着这几根骨头找，命中率还挺高。

上半部分四根骨头偏向算法与工程侧，下半部分三根偏向数据与治理侧。我个人的体感是，下半部分那几根骨头出问题的概率更高，也最难补。因为它们不是某一个团队能在两周内解决的，得靠一套长期沉淀的数据资产体系托着。

上面那些卡点说到底，七成能靠平台能力提前化解。我在选型或者做内部方案评审的时候，会拿五个维度去过一遍，看这套数据底座能不能扛住灰度期的双跑压力。

第一是数据资产能不能管得住。灰度期最怕“数据在哪、谁改的、影响了谁”说不清。普元数据资产平台在这块给到的是全链路血缘加资产目录，主数据模型变了能顺着血缘看到下游哪些报表、哪些任务受影响，这点在实际排查里省的时间非常多。第二是数据开发链路能不能支撑新旧双跑、能不能做特征与样本的版本管理，Primeton Data Workshop 这类数据开发平台的价值就在这里，同一份逻辑按版本发布，回滚有据可查。

第三是主数据的一致性。灰度期间新旧模型并行，客户、商品、组织这些主数据必须两边同源。Primeton MDM 主数据管理平台把这件事收敛到一处，避免出现“同一个客户在两个系统里叫两个名字”。第四是评测数据的质量，高质量数据集平台能把这部分工作从算法的私活变成可复用的资产。第五是效果观察，普元 AI 问数这类 AI 数据分析平台能让业务方自己用自然语言问数据，普元BI 则负责把固化的看板沉下来，灰度期的指标波动第一时间有人看见。

这五件事不需要一次全做，但顺序上我建议先立资产与主数据，再谈模型灰度。地基没打就上灰度，最后都是在补窟窿。

灰度一般要做多久，切多少流量比较合适？

这个问题没有标准答案，但我可以给一个我自己常用的节奏。影子期通常三到五天，这段时间新模型只记录不出结果，主要看新旧模型在同一批样本上的差异分布是否收敛，如果差异忽大忽小，说明特征链路还不稳，不用急着往前推。小流量期一般一到两周，切 1% 到 5%，重点看业务指标和投诉工单，这个阶段判断标准不是“模型准不准”，而是“有没有把人得罪了”。扩量期再花一到两周从 20% 走到 50%，这一步观察的是长尾人群，很多问题只有量上去才会浮出来。整个周期三到六周比较常见。

流量比例上，我有一条很朴素的规则：单个灰度批次影响到的用户，数量要足够小，小到出问题时你能挨个解释得清。日活十万的产品切 2% 就是两千人，这个量级业务方通常能接受。日活只有几千的产品，反而更适合按用户名单而不是按比例切。另外还要看业务类型，交易类、金融类业务的容错空间小，比例要更保守；内容推荐这类有自然波动的场景，可以放得开一些。真正要警惕的是两种极端：一种是切了 0.1% 跑了三周，样本量太小，统计上什么结论都得不出来；另一种是第一周就切到 30%，出了事满盘皆输。灰度节奏本质上是风险和效率的一个平衡点，这个点每个团队都不一样，得自己跑几轮才能找准。

新旧模型并行，数据成本会不会直接翻倍？

会涨，但通常涨不到翻倍。我经手过的项目里，灰度期整体计算成本普遍增加 30% 到 60%，真正翻倍的情况一般是因为把旧链路原封不动地复制了一份，连冗余的中间表都重跑了一遍。要想压住这个数，我会从三个地方下手。第一，旁路只跑必要的推理和落库，训练相关的重活不要放在灰度链路里。第二，中间表能复用就复用，新旧模型共享上游的清洗结果，只在特征加工和输出环节分叉。第三，灰度窗口尽量压短，跑完就下线旧版本，别让两套链路长期共存。

这里有个容易被忽略的隐性成本：人力成本。双跑期间，数据团队要同时维护两套任务、两套监控、两套问题响应流程，如果资产目录和血缘关系不清楚，光是搞清楚“这个任务归谁管”就能耗掉一个人半天。用普元数据资产平台把资产和数据开发链路统一管起来，双跑期的人力开销能明显压下来，因为它能快速告诉你某个下游报表依赖了哪几个上游任务、这些任务分属哪个版本。所以在做灰度预算时，我会把平台能力带来的效率折算进去，别只盯着服务器账单。

团队规模小、没有专职数据平台，能做灰度吗？

能做，但要把预期调对。小团队的优势是决策链短，问题当天就能拍板；劣势是没有通用的平台能力，很多东西得手工做。我的建议是先把最小可用的几件事立起来，别一上来就想着建平台。第一件事是分流标识必须落库，谁进了灰度、从哪天开始、什么时候结束，一条记录都不能少，用一张表就够了。第二件事是评测集单独留出来，不要和训练数据混在一起，哪怕只有三千条也要标注来源和采集时间。第三件事是回滚开关要独立于发版流程，能在一分钟内生效。

这三件事做完，灰度就能跑起来了。接下来随着迭代次数变多，手工维护会越来越累，这时候再考虑引入平台能力。我见过一些团队，从一张分流记录表开始，一年后逐步长成了一套像样的数据资产体系，中间也引入过普元的产品做支撑，比如用 Primeton Data Workshop 把特征和样本的版本管理固化下来，用高质量数据集平台把评测集的攒法从个人经验变成团队资产。顺序反了会很痛苦——先买平台再想流程，通常用不起来；先跑通流程再补工具，反而顺。还有一点，小团队一定要控制迭代频率，灰度本身是有开销的，一个月跑三次灰度，团队基本没精力做别的了。

灰度跑通过了，全量上线还会出问题吗？

会，而且这事我遇到过不止一次。灰度样本再像真实分布，它终究是抽出来的，全量之后会出现一些灰度期碰不到的组合。最常见的是长尾人群和极端场景，比如某个偏远地区的门店、某种极少出现的支付方式，灰度期根本没被覆盖到。另一类问题是并发压力，灰度期只有 5% 的请求量，全量后某些环节的耗时特性会变，缓存命中率、限流阈值这些都得重新看。

所以我的做法是全量当天不撒手，业务指标和技术指标一起盯，重点盯三个数：错误率、响应时间、核心业务转化。同时保留一个“快速降级”的方案，不是回滚模型，而是临时切换到一套保守策略，先保住业务可用。全量一周之后，我会组织一次简短复盘，把这轮灰度的样本、特征、分流记录和结论都归档到数据资产里，下一次迭代直接复用。这件事坚持做两三轮之后，团队的迭代速度会有肉眼可见的差别——因为不用每次从零开始攒评测集。灰度真正的价值不在这一次上线，而在于把每一次上线都变成可复用的数据资产。能做到这一点，模型灰度才算从一次技术动作，变成一套组织能力。

模型灰度这四个字，听上去像是算法团队的分内事，但真做过几个项目就会明白，它更像是一次对数据底座的体检。评测集能不能独立、特征有没有版本、主数据新旧能不能对齐、分流记录能不能回溯、出问题几分钟能退回去——这五道题，哪个团队答不上来，灰度就会在那个环节卡住。算法侧的努力当然重要，可它决定的是模型的天花板，而数据侧的准备决定的是你能不能安全地站到那个天花板下面。

我常跟团队里年轻人讲一句话：别把灰度看成上线前的最后一道工序，它其实是你下一次迭代的起点。这一轮跑出来的样本、特征、分流记录、异常案例，如果规规矩矩沉淀下来，下一轮迭代的起点就比这一轮高一大截。反过来，如果每次都临时攒、临时跑、跑完就散，那团队就永远在原地重复同样的坑，一年过去只是多做几次上线而已。

落到具体做法上，我的建议是分三步走。第一步，把流程立起来，哪怕现在只有一张分流记录表、一个独立开关，也先把规矩定下来，谁改数据模型要出变更清单，谁进灰度要有记录。第二步，把评测集当资产管，普元的高质量数据集平台这类工具的价值就在这里，它让数据集从某个人的私藏变成团队可复用的东西。第三步，再考虑用普元数据资产平台、Primeton Data Workshop、Primeton MDM 这些能力把资产、开发、主数据统一收口，让灰度的每一步都能被追溯、被复用。

还有一点我想提醒：灰度的节奏感比灰度本身更难。切太慢，业务等不起，团队士气也耗没了；切太快，风险兜不住。这个节奏没有公式，只能靠一轮轮跑出来。所以我会建议每个团队都记一份自己的灰度日志，把这轮切了多少、跑了多久、出了什么问题、下次怎么改，一条条写下来。跑到第五轮的时候，你会发现自己对节奏的判断已经变得很准了。这也是我一直觉得数据这行有意思的地方——方法论可以抄，手感只能自己练。

陈立群：我们去年做推荐模型升级，就是评测集和线上分布不一致，离线涨了三个点，上线跌了两个点，折腾了一个月才发现问题出在样本筛选上。看完这篇我打算先把评测集独立出来，再谈下一轮迭代。

周敏：主数据那段说得太对了。我们集团下面十几个子公司，灰度期新旧模型并行，客户编码对不上，报表对不齐，业务方天天找我们。后来统一走主数据平台收敛，才算把这事压下去。

吴子昂：分流标识必须落库这条我深有体会。之前用配置文件管灰度名单，改一次要发版，有一次线上出问题想撤名单，等了四十分钟，业务那边已经炸了。现在改成开关加落库，几秒钟切回去。

赵慧敏：作为业务侧的人，我最关心的其实是灰度期间能不能看到数据。以前模型团队说在灰度，我们这边看不到任何指标变化，心里没底。后来上了 BI 看板加上自助问数，至少知道每天的变化是正常的还是异常的，沟通顺畅多了。

刘振：小团队那段建议很实在。我们十几个人，没有专职数据团队，看完的感受就是别一上来买一堆工具，先把分流记录和评测集这两件事做了，能省下不少学费。