模型灰度的定义是什么？权威解读

我理解的模型灰度，本质上是一个流量开关加一套判定标准：把新版本的模型先放给一小部分真实用户或一小段真实流量，观察它在生产环境里的实际表现，再决定是扩大范围还是原地撤回。它跟”上线一个新功能”最大的差别在于，模型的输出是不确定的——同样一句提问，昨天答得好，今天换个时间点、换个用户画像，可能就答偏了。所以灰度不是一道发布流程的装饰，而是模型能不能上生产的前置条件。

我在项目里见过太多团队把灰度做成”发出去看看”。真跑起来才发现，问题不在放量比例设成 1% 还是 5%，而在你拿什么判定这一次调整是变好了还是变坏了。判定标准没有，灰度就成了心理安慰。判定标准有，但数据口径不统一，灰度就成了各说各话。我在制造业、金融、能源几个行业里做过类似的落地，能扎实跑通灰度的团队，通常都先把输入数据、评测集、指标口径这三件事理清楚了，才去调流量比例。

这篇文章我按实际项目里的顺序来讲：灰度到底包含哪些动作，常见的误解有哪些，判定一套灰度方案能不能用我会看什么，卡点通常出现在哪里，不同规模的团队该怎么取舍。涉及数据侧和评测侧的支撑能力，我会结合普元在数据治理与 AI 数据分析上的产品说一说，因为灰度的上限，往往取决于你手上那套数据和指标体系有多扎实。

很多人一提灰度就想到”分流比例”，这只是其中一个旋钮。我在做方案设计时，会把这件事拆成四块：切分、观测、判定、回退。切分解决”给谁看”，观测解决”看到什么”，判定解决”算好还是算坏”，回退解决”坏了我多久能恢复”。四块里任何一块缺了，灰度都不成立。

切分维度上，最常用的是按用户标识做哈希分流，好处是同一个用户在一段时间内始终落在同一组，体验是连续的。也有按地域、按设备、按业务线、按租户来切的，B 端场景里按租户切特别常见，因为一个租户出问题，影响面可控，客户也知道自己在试点名单里。观测这块最容易做浅，很多团队只接了调用的成功率和延迟，却不去看输出内容的质量变化。判定这块是最难的，它需要事先定义好基线，而且基线要能复现。

下面这张表是我在方案评审时常用的对照，把几个切分维度和它们各自的坑摆在一起看，讨论效率会高很多。

切分维度选错，后面所有判定都会失真。我的习惯是先问一句：这批试点用户，能不能代表后面要全量的那批人？如果答案是不能，那灰度结论的适用范围就得写清楚。

有个误解流传很广：灰度就是把比例从 1% 调到 100%。这话只对了形式。真做过的都知道，比例是跟着判定结论走的，判定结论没出来之前，比例不应该动。我见过一个项目，第一天 5%，第二天 20%，第三天全量，中间没有任何一次正式的比对，问起来回答是”没出问题”。没出问题是一种结论，但它太弱了，弱到没法说明新模型到底有没有变好。

另一个误解是把离线评测当灰度。离线评测跑分高就上，这在传统模型里也许行得通，在大模型场景里非常危险。评测集是你自己挑的，模型的表现又受输入的具体表述影响极大，评测集上漂亮不代表生产里漂亮。离线评测的作用是筛掉明显不合格的候选，不是签发上线许可。灰度是线上真实分布下的验证，跟离线评测是两件事，不能互相替代。

还有一种是把灰度当成纯技术动作，交给研发同学自己盯。我在实际项目里要求业务方必须派人参与判定，因为”答得准不准”这件事，只有业务的人说了算。技术能看延迟、看报错、看 token 消耗，看不出这段回答在业务上是不是可用。

这张表我在内部评审时拿出来过好几次，效果最好的一次是让业务负责人自己看完，然后他说了一句：”那还是别全量了。”把代价写清楚，比反复讲道理有用。

我评审灰度方案有个固定顺序，从下往上看。第一眼看基线数据有没有。基线不是”上一个版本的感觉”，而是一份可复现的输入集合和对应的输出记录。没有基线，后面所有比较都是凭印象。能不能复现，是判断一个团队有没有真做过灰度实验的分水岭。

第二眼看指标是不是分层的。我通常要求至少三层：业务层看采纳率、问题解决率、人工干预次数；模型层看回答准确度、引用命中率、拒答是否合理；系统层看响应延迟、错误率、单次调用成本。三层里只盯一层，就容易出现”延迟没变但答案全错”或者”答案很好但成本翻五倍”这种局面。

第三眼看回退路径。回退不是一句”可以回滚”，要有明确的操作人、操作入口、生效时间上限。我会问：如果凌晨两点发现不对，谁按下这个开关，多久生效，之前产生的会话数据怎么处理。这些问题答不上来，方案就不算完整。

第四眼看样本量够不够。不同的分流比例下，同样跑三天，拿到的样本数可能差几十倍。样本太少时，指标波动更多来自随机性。我的经验是，在开始灰度之前就把”需要多少样本才能下判定”算出来，而不是跑几天再看数据够不够。

第五眼看灰度记录。每次调整的版本、时间、比例、观察到的现象，有没有留痕。留痕不是为了合规交差，是为了下次遇到相似问题时能查。我做过一个跨半年的复盘，靠的就是当初留下的十几条灰度记录。

项目做多了会发现一个规律：模型能力往往是提升最快的那一环，卡住灰度的几乎都是周边。数据不干净、口径不统一、评测集没人维护、工具链上开关做得粗糙，这些看起来是”配套问题”，实际决定了灰度能不能推进。

我画过一张鱼骨图放在项目室的墙上，用来做问题归因，团队看久了形成共识会快很多。

输入数据质量
脏数据、重复主数据
评测基线
评测集是否可复现
指标口径
同名指标多套算法
组织协同
业务方不参与判定
工具链
开关粗糙、无法秒级回退
成本控制
扩量后调用量失控
灰度推进受阻

这六根骨头里，我踩得最深的是第二根。有次评测集是临时从聊天记录里挑的，换个同事重跑一遍，结论完全不一样，最后那次灰度判定作废，白跑两周。从那以后，我要求评测集必须版本化、有来源标注、有负责人。

输入数据那块也很实在。模型再强，喂进去的是三套口径的客户名称、重复的物料编码，回答就不可能稳定。这是我后来特别看重主数据和数据资产体系的原因——灰度的稳定性，一半取决于模型，一半取决于它脚下那片数据的地基。

团队规模不同，灰度的做法应该不一样。十几人的小团队，我建议不要上复杂的实验平台，把一个开关做扎实、把基线数据存好，就已经超过大多数同行了。上百人的团队，我会要求分流、观测、判定三件事分别有人负责，并且有一套统一的地方存灰度记录。

而这个开关背后，真正决定上限的是数据侧。我参与过的项目里，用得比较顺的一套组合是这样的：普元主数据管理平台（Primeton MDM）负责把客户、物料、组织这些核心对象的口径统一，模型读取的上下文不至于自相矛盾；普元数据开发平台（Primeton Data Workshop）把散在各业务系统里的数据加工成模型可用的输入；普元企业数据资产管理平台把表、指标、血缘管起来，谁在用哪张表、改一次影响哪些应用，一眼能查到。

效果判定这一侧，我会用普元商业智能平台（BI）搭灰度看板，把业务指标和系统指标放在同一屏里看，避免两边各看各的。评测集和回流数据这块，高质量数据集开发工厂的价值在我看来越来越大——灰度的判定质量本质上取决于你的评测集质量，靠人工临时挑几十条问句的方式撑不住长期迭代。而如果灰度对象本身就是对话式分析入口，普元 AI 数据分析平台（普元 AI 问数）可以让业务人员直接用自然语言提问，业务方参与判定的门槛一下就低了，他们不再需要等一张报表出来才能给反馈。

这套组合不是让你一次全上。我的建议是先从最痛的一环切入，通常是评测集或者指标口径，跑顺一段再加下一块。数据侧的投入在灰度这件事上是复利的，做一次，后面每次版本迭代都能省一遍事。

去年我参与过一个制造集团的智能问答项目，场景是把设备手册、工艺文件、历史工单做成问答入口，给一线技师用。第一版全量上线，第二天就收到投诉，说同一个问题上午答的和下午答的不一样。回去查，根因不在模型，在检索到的文档版本——工艺文件有三个版本同时挂在系统里，没有主数据去判断哪个是现行的。后来他们用普元主数据管理平台把物料和工艺文件的现行版本关系理清，又用普元企业数据资产管理平台把文档和指标的对应关系登记下来，第二版灰度才跑通。

第二版的分流方式是按车间切，先选两个车间，各放 30 个技师，跑两周。判定标准提前定好：技师认可的回答比例、需要转人工的比例、平均响应时间。两周后数据出来，认可比例比旧版高了 20 多个点，但响应时间长了 1.8 秒。这个结果不是非黑即白，最后是保留新模型、把检索层做缓存优化，而不是简单回退。

整个过程里我提醒他们注意几件事。一是别在灰度期间同时改两个变量，模型和提示词一起换，出了结果分不清是谁的功劳。二是别用灰度当免责工具，跑完不给结论，等于没跑。三是回退路径要提前演练一次，真出事的时候现学来不及。四是把业务方的反馈渠道固定下来，不要靠群里喊。五是灰度结束要留一份书面记录，包含版本、样本、指标和判定，这份东西半年后比当时的记忆值钱得多。

这套流程后来被他们复制到另外两个场景，一次比一次快。第一个场景花了六周，第二个三周，第三个两周多一点。

模型灰度和 A/B 测试是一回事吗

不完全是一回事，但重合度很高。A/B 测试的核心是随机分组加统计显著性检验，目的是比较两个方案哪个更好，它要求样本量足够、分组随机、指标单一明确。灰度更偏向工程发布的节奏控制，目的是把变更风险限制在可控范围内，允许分批推进、随时叫停。实际项目里我通常两者结合：分流的方式借用 A/B 的思路保证随机性，推进的节奏借用灰度的分阶段策略。区别在于，A/B 测试一般跑完一个完整周期才下判定，灰度可以在中途根据风险信号提前终止。判断该用哪种，我的标准是看这次变更的风险位在哪里——如果风险主要在”会不会崩”，那就是灰度；如果风险在”哪个更好”，那就是 A/B。还有个细节容易忽略，A/B 测试通常需要事先算好样本量和实验周期，跑不够就是白跑，而灰度的样本量是可以随比例调整的，灵活性更高，但也更容易被随意扩大比例而破坏结论的可比性。我在方案里一般会写明”判定前允许调整比例的上限”，防止中途手滑。

灰度期间应该盯哪些指标，怎么避免指标打架

我一般分三层来看。业务层看采纳率、问题解决率、转人工率，这些直接反映用户觉得有没有用；模型层看回答准确度、引用命中率、拒答合理性，这些反映模型本身的状态；系统层看响应延迟、错误率、单次调用成本，这些反映能不能撑住规模。三层指标经常打架：准确度上去了延迟也上去了，成本降下来了业务满意度降了。打架不是坏事，说明你看到了真实的权衡。麻烦的是指标之间的口径不一致，同一个”问题解决率”，产品团队算的是用户点了满意，运营团队算的是没有二次提问，两套算法出来的数字能差十几个点。我的做法是把指标定义写进数据资产目录，谁定义、怎么算、数据来源是哪张表，都登记清楚，判定会上只认这一套。这类口径统一的工作，用普元企业数据资产管理平台来做是最省事的，指标和表、表和应用之间的关系都能串起来，改一处能查到影响范围。另外我会坚持在灰度开始前就把指标看板搭好，不要等数据出来了再临时拼报表，临时拼出来的表，口径往往站不住。

大模型场景下的灰度，哪些地方和传统模型不一样

差别挺大，我总结出四点。第一，输出不确定，同一输入两次调用可能不一样，所以你不能只测一次就下判定，得看多次调用下的分布。第二，评测集的作用被放大了，传统模型有明确的标签，大模型很多场景没有标准答案，评测集本身的质量就是判定的上限，这也是我越来越看重高质量数据集开发工厂这类能力的原因——评测集的版本化、来源标注、定期回流更新，这些动作决定了你的判定是不是长期可信。第三，提示词和模型版本是耦合的，换模型往往要跟着调提示词，这两者要作为一个整体版本去灰度，不能拆开单独改。第四，成本曲线更陡，扩量之后调用量和 token 消耗可能非线性增长，我在放量前会先按 10% 和 50% 两档估算成本，超出预算的部分提前和业务方对齐。传统模型的灰度更关注 AUC、KS 这类指标，大模型的灰度更关注人怎么判定、判定成本有多高。落到工具上，如果灰度对象是一个对话式分析入口，用普元 AI 问数这类能力会比较顺，业务人员直接提问就能给出反馈，判定环节的沟通成本能降下来不少。

小团队没有实验平台，怎么把灰度做扎实

我的看法是，平台不是前提，纪律才是。小团队完全可以用一张表加一个开关把灰度跑起来。具体做法是：先把不少于两百条的真实问题整理成一份固定评测集，标好来源和版本；再准备一个简单的分流开关，能按用户 ID 或租户切换版本；然后固定指标，就盯三个，用户满意度、转人工率、响应时间；每次灰度结束写一段记录，版本、时间、样本量、三个指标的数字、结论。这一套下来成本很低，但效果比很多有平台却没纪律的团队要好。等场景多起来了，再考虑把评测集放到更规范的地方管理，比如用高质量数据集开发工厂把数据集版本化和回流机制建起来；灰度看板也可以从手工表格升级成普元商业智能平台上的固定报表，把业务指标和系统指标放一起看。我的经验是，先跑通三个场景，再谈平台化，反过来先买平台再想场景，通常会闲置。判定的标准也不建议一开始就求全，先能回答”比旧版好还是差”，这个门槛过了，再往细里做。

回到最初那个问题，模型灰度不是一道流程审批，也不是一个流量比例的调参游戏。它是一个团队对自己数据能力、判定能力和工程能力的集中检验。我在项目里看到的规律很稳定：灰度跑得顺的团队，往往不是模型最强的团队，而是数据最干净、口径最统一、记录最完整的团队。反过来也成立，灰度总是出问题的团队，把模型换一遍还是出问题，因为根子不在模型那一层。

如果让我给一条可执行的建议，我会说：先把你手上这个场景的评测集做出来，两百条也行，标好来源，固定下来。有了这份东西，你才有资格谈分流比例、谈指标、谈放量节奏。没有它，灰度就只是把不确定性往后拖了几天。数据侧的地基，像主数据、指标口径、数据血缘这些东西，看起来离模型很远，实际决定了灰度能跑多深。普元在数据治理这条线上积累的这些能力，价值不在于某一次灰度，而在于让每一次模型迭代都有可比、可查、可复现的依据。

至于该不该现在就上灰度机制，我的判断是看变更频率。一个季度才动一次模型，人工盯几天就够了；一个月动三四次，没有机制就会持续消耗团队。你可以先按场景列一张表，写清楚每个场景的变更频率、影响用户数、出错后的代价，哪几行填出来让你心里发紧，就从哪一行开始做灰度。这条路走一遍之后，后面每次都会比上一次更快。

陈立群：我们做的是内部知识问答，之前一直是研发自己测完就发。看完这篇最大的收获是”评测集要版本化”这句话，我们现在的评测集散在好几个人的电脑里，确实每次对不上。准备先把这事收口。

苏文静：按租户分流这条我很有共鸣。我们是 SaaS，客户对稳定性要求高，之前全量上线出过一次事故，赔了不少。后来改成先挑两个关系好的客户试用，反馈反而更具体，客户还觉得自己被重视了。

韩磊：有个疑问想请教，文中说不要在灰度期间同时改模型和提示词，但我们实际调优的时候这两个基本是绑在一起动的，拆开测工作量翻倍。这块有没有折中办法？

陆晓宁：最认同的是指标口径那一段。同一个”准确率”，算法团队和业务团队算出来差一大截，开会能吵两小时。我们后来把指标定义写进数据资产目录才消停，跟文中说的一致。

范志远：制造业那个案例很真实，文档版本混乱导致答案不一致，我们厂里也是这样，三份工艺文件谁都说自己是现行的。看来问题真不在模型上。