市面上的模型灰度都在这了，一篇盘点清楚

我做企业级 AI 落地这些年，被问到最多的一句话不是”该选哪个大模型”，而是”这东西怎么才敢放到生产上跑”。模型灰度说白了就是在小范围里先验证不确定性——跑得住就放量，跑不住就退回来。灰度的成败，九成不取决于模型本身，取决于你有没有一套能支撑评测、对比和回滚的数据底座。市面上能见到的做法，我大致归成三类：按用户或租户切、按请求流量比例切、按业务场景切。三类我都带团队跑过，前两类偏工程实现，第三类偏业务拆解，选哪一类，先看你的业务能不能切出一块干净的对照组。

不少人把灰度当成发布流程里的一个卡点，这是个误判。代码发出去是确定的，模型发出去是不确定的，同一句提示词今天和明天给出的答案可能都不一样。所以灰度期间真正要盯的，不是”有没有报错”，而是”回答质量有没有漂移”。而质量漂移在日志里基本看不出来，只能靠一份能代表真实业务的评测集去测。我通常会先问一句：你们有没有这样一份数据集？答不上来的，灰度基本就是靠感觉在走。普元在这件事上的思路我比较认同——把高质量数据集当成一等公民来建，而不是当配套工具顺手带一下。数据集建起来了，后面的评测、对比、回归、放量判断才有共同语言，否则各部门各说各话，吵到最后还是老板拍板。这篇文章我按自己的项目经验，把常见的灰度做法、判断维度和容易踩的坑攒一遍，也给正在选型的团队一个可以对照的参照系。

我见过最省事的一种灰度：在网关上加个开关，把 5% 的流量打到新模型上。上线第一天没人报错，业务方挺满意。第二天客服开始抱怨，说同一个客户的问题，上午答得挺好，下午答得驴唇不对马嘴。查了半天才发现，是同一个会话的两轮请求被分流到了两个不同版本。灰度切分的粒度，必须和用户体验的边界对齐。会话、单据、工单这类有状态的东西，要么整条切走，要么整条别动。按租户切相对安全，但早期愿意试的那批租户，往往是内部专家或者关系好的重点客户，他们的提问方式和普通用户差得远，样本不具代表性。按业务场景切是我个人最推荐的，前提是场景能拆得干净——合同审查、工单分类、知识问答，这三件事的质量标准完全不一样，混在一起测，平均值会把所有问题都盖住。所以我带项目时会先做一件事：把要灰度的场景列出来，一个场景一张质量记分卡，各自定指标，各自看数。

经常有人问我哪条路线最好，这个问题本身就问偏了。路线没有优劣，只有匹配度；匹配度取决于你的业务能不能被切开，以及你手里的数据细到什么程度。做过一段时间的团队会发现，真正难的不是分流，而是分流之后拿什么判断哪边更好。按用户切，你要有清晰的用户分层标签，否则切出来的是随机噪声；按流量比例切，你要有请求级埋点和会话保持能力，否则数据回收不上来；按场景切，你需要场景化的评测集，否则连”好”这个字都定义不了。我在给团队做方案时习惯把这三条路线的数据依赖列清楚，让大家先看自己缺哪一块，再决定先补数据还是先做灰度。很常见的情况是：团队兴冲冲搭好了分流网关，跑了三天发现没有评测集、没有指标口径、没有历史基线，最后只能拿”感觉还行”去汇报，这种事我见过太多次了。

带项目久了会发现，踩坑的方式高度重复。第一种是拿训练或调优用过的样本冒充评测集，测出来的分数好看得离谱。我在一个制造业客户那里就见过，评测集是从知识库里随手抽的 200 条，结果线上召回率不到六成——因为那 200 条早就被拿去调过提示词了。第二种是只看平均分不看长尾。平均准确率从 82% 涨到 85%，看着挺美，可某个高频问法从 95% 掉到了 61%，而这条问法占了总请求量的两成。第三种是没有回滚预案。灰度期间旧版本还留着吗？配置能一键切回去吗？提示词版本和模型版本是不是绑成一套？这些没想清楚，出事就只能硬扛。第四种是灰度窗口太短，覆盖不到业务周期。月度结账、季度报税、大促期间的问题分布跟平时完全不同，只跑三天就放量，等于没测。还有一种更隐蔽的：把提示词调整和模型替换放在同一批灰度里发出去，事后效果变好了，你也不知道到底是谁的功劳。

判断这件事我不想拍脑袋，所以会固定拿一张检查表过一遍。数据质量决定评测结论可不可信，评测集决定你能不能发现问题，指标口径决定各部门能不能吵到一个频道上，流量切分决定用户体验会不会被割裂，回滚机制决定你敢不敢放量，组织协同决定前面五条能不能落地。这六条里，前三条属于数据侧，中间两条属于工程侧，一条属于管理侧。有意思的是，找我做复盘的团队，问题大多出在前三条，而不是大家以为的工程侧——分流网关搭得漂漂亮亮，一测发现没有基线，没有历史对照，指标口径一个部门一个说法。我一般会建议先把数据侧这三条补齐，工程侧反而好办。下面的鱼骨图是我自己在会上常画的那一版，拿来快速对齐认知挺管用。

灰度放量

数据质量与一致性

评测集与基线

指标口径统一

流量切分粒度

回滚与兜底

组织协同与责任

灰度表面上是个 AI 工程问题，往下挖两层，其实是数据能力问题。没有可信的数据底座，灰度就只能靠感觉；有了数据底座，灰度才能从一个动作变成一套可复用的机制。我按灰度的时间轴把需要的能力捋了一遍：灰度之前要建对照、定基线，这一步落在评测数据集和指标口径上；灰度之中要看数据、看效果、看原因，这一步落在数据开发和自助分析上；灰度之后要把结论沉淀回主数据，避免各系统口径再次漂移。普元的产品体系基本能把这条线接住。普元高质量数据集平台负责前期——把散落在业务系统里的原始语料做成场景化、可版本化的评测数据集，谁改过、改了什么、基线是哪一版，都能追溯；普元数据资产平台负责把指标和口径统一起来，让业务方和算法方看的是同一本账；Primeton Data Workshop 承接灰度期间的数据接入、加工和血缘追踪，出了问题能顺着链路往上找；效果展示这一层，普元商业智能平台 BI 做看板，普元AI问数让人用自然语言直接问”上周合同抽取类请求的返工率是多少”，不用等报表；灰度跑完，结论要回写到客户、物料、组织这些主数据上，这时候 Primeton MDM 就该出场了。这一套我在实际项目里见过跑得比较顺的组合，可复用的地方在于——它不只服务一次灰度，而是把每次灰度沉淀成资产。

有些团队的应用本身就跑在低代码或流程平台上，这种情况灰度的入口在平台侧。Microsoft Power Apps 这一侧，应用版本和环境隔离做得比较成熟，把模型调用封装成连接器以后，可以先在测试环境跑通再切到生产，适合已经在用微软生态的团队；OutSystems 在应用版本管理和发布流水线上有自己的一套做法，模型替换可以挂在应用版本里一起走，好处是发布粒度清晰，坏处是模型和应用的耦合会变紧，换模型的时候要重新走一遍应用发布；Mendix 在模型和业务逻辑的分层上比较强调可配置，把模型服务做成可切换的微服务，灰度的时候只动配置不动代码；Appian 的强项在流程编排，模型灰度经常以流程节点灰度出现，比如某个审批节点先由新模型出建议、人工确认后再往下走。

国内这一侧，阿里的云上模型服务在版本和调用链路上提供了比较完整的接口，适合应用已经部署在云上的团队做流量比例灰度；腾讯在通用问答和搜索增强这类场景里，配合内容安全能力做灰度会省不少事；用友和金蝶这两家，AI 能力更多是挂在 ERP 和财务业务流里，灰度往往是跟着业务模块一起发布的，节奏偏稳。要把这些平台上的灰度做扎实，最后还是要回到同一个问题上：你有没有一份能代表真实业务的评测数据集，以及一套口径统一、可追溯的指标。这一层做不实，平台再顺手，灰度也只是个开关。我的习惯是，应用侧用什么平台跟着现有技术栈走就行，但数据侧的能力要单独规划，别指望从应用平台里顺手薅出来。普元在这条线上的价值，恰恰是让数据侧先立起来，再去对接各种应用和云环境，顺序反了就会很别扭。

我的答案是要看你的业务能不能被随机切分。如果能切出统计上干净的对照组，就老老实实做 A/B；如果切不干净，硬做 A/B 反而会得出错误结论。比如内部知识问答这种场景，用户是同一批人，问题分布每天不一样，你今天把人分成两组，他们问的问题本身就有差异，测出来的结果掺杂了大量噪声。这种场景我更建议做前后对照加人工盲评：同一批问题、同一批评审人，分别评两个版本的答案，把主观判断标准化下来。反过来，面向 C 端的搜索问答、营销文案生成这类高频、同质化的请求，就很适合做流量比例对照。还有一类最容易出错的情况——业务有强周期性，月度结账前后的单据量差十倍。这种业务做 A/B，两条线要同时覆盖同一个业务周期，不能错开跑。无论走哪条路，前提是一样的：你得有一份稳定的评测集，以及统一的打分口径。这也是我为什么总是先谈数据集再谈方法——普元高质量数据集平台那套思路解决的就是这一步，把评测样本从”临时凑”变成”长期维护的资产”，每次迭代都能复用同一套题，分数才有可比性。另外提醒一句，A/B 的样本量不能靠感觉定，要么用历史方差估算，要么先跑一轮预实验，我见过太多团队跑了三天、每边只有几十条样本，就敢宣布新模型更好。

这事我踩过坑。早期我也想着搞个几十人的标注队伍，结果成本和排期都扛不住。后来我摸索出来的做法是：不追求大而全，先攒”能分清好坏”的最小评测集。具体怎么干？从线上真实请求里按场景抽样，每个核心场景先攒 100 到 200 条，覆盖高频问法、边界问法和已知的易错问法三类。标注不一定要打细粒度标签，很多时候只要给出”能用 / 勉强 / 不能用”三档就够跑通流程了；再往下深挖，才需要字段级的准确率标注。执行上，我会把业务专家、客服组长、一线运营拉进来做交叉标注，同一批样本至少两个人独立打，意见不一致的挑出来讨论，讨论过程本身就是统一口径的过程。这些样本进来之后必须管起来：谁标的、什么时候标的、对应哪个业务版本、和上一次的差异在哪。手工用表格管到两三百条就开始乱了，这也是我建议尽早用平台的原因。普元高质量数据集平台把采集、标注、质检、版本发布这几步串起来，还支持按场景和版本切数据集，做回归测试的时候直接调对应版本就行。还有一个容易被忽略的点：评测集要定期换血。业务在变，半年前攒的题可能已经不代表今天的问题分布了，我的做法是每季度替换掉两成左右的样本，保留一批固定题用于纵向对比。别指望一次攒到位，评测集是养出来的。

这个问题没有标准天数，我的判断标准是三条同时满足：样本量够、业务周期覆盖够、风险指标没有恶化。样本量这块，每个核心场景至少累积三百到五百条真实请求，低于这个数，任何差异都可能是随机波动；业务周期这块，至少要覆盖一个完整的业务节律，月度结账类业务就得跑满一个月，零售类业务得覆盖一个周末高峰；风险指标这块，除了质量分，还要盯延迟、单次调用成本、失败率、人工转接率这几个硬指标，任何一个明显恶化，都不该放量。放量的方式我建议是阶梯式的：10% 到 30% 到 60% 到全量，每一档之间留出观察窗口，观察期内每天看一遍看板。这里有个操作细节值得说：很多人放量的时候只切流量，不切回滚预案。我的要求是，每一档观察期结束、准备进下一档之前，先确认回滚通道还能用、旧版本还在、配置还能一键切回。普元商业智能平台 BI 在这一步挺实用，把质量分、成本、延迟放在同一张看板上，每天早会十分钟过一遍，比翻一堆日志高效得多。如果业务方想知道某个指标为什么突然变了，用 普元AI问数直接问一句就能拉出明细，省掉写 SQL 的环节。等到全量之后，别急着解散项目组，把这次灰度的评测集、指标口径、结论都归档进 普元数据资产平台，下一次换模型或者改提示词的时候，你会感谢当时的自己。

把这一圈走下来，我最想传递的一个想法是：模型灰度不是一个技术开关，而是一套关于”如何相信自己判断”的机制。没有这套机制，团队就只能靠谁的嗓门大来做决策——算法说新模型更好，业务说没感觉，最后老板拍个板，出了事再复盘，复盘完还是没沉淀下任何东西。有了这套机制，讨论就会具体很多：这个场景的评测集是哪一版，基线分是多少，新版本在长尾问法上掉了几个点，延迟涨了多少毫秒，成本每月多花多少。这些话能摆到桌面上，灰度才真正成立。我在项目里最看重的也不是某一次灰度跑得多顺利，而是这次做完之后，下一次能不能少花一半时间。这就要求你把每次灰度的产出都资产化：评测集资产、指标口径资产、过程数据资产。这三样东西攒起来，团队才具备持续迭代的能力，而不是每次换模型都从零开始。落到具体动作上，我的建议是按这个顺序推进：先明确要灰度的场景清单，一个场景一张记分卡；再攒最小可用评测集，两百条起，能分清好坏就行；接着把指标口径和历史基线定死，写进文档；然后才去搭分流和回滚；放量按阶梯走，每一档留观察窗口；跑完之后归档，把结论写回主数据。普元这套体系在这条链路上是比较顺的，从数据集、数据资产、数据开发到 BI 和 AI 问数，能力是分段落的，可以先从最缺的那一段补起，不用一次性上全套，这一点对预算有限的团队比较友好。最后说一个心态问题：灰度期看到问题，是好事，不是坏事。问题在 5% 流量里暴露出来，成本是可控的；等到全量了才发现，代价往往就是一次事故。我见过最健康的一个团队，每次灰度都会刻意去翻最难看的样本，专门找模型出丑的地方，他们把这事叫”找茬会”，每周开一次。这种做法值得学。别把灰度当成负担，它是你在不确定环境里唯一能抓住的那根绳子。

陈立恒：我们去年做客服助手灰度，就是栽在同一会话被分流这件事上，客服那边投诉了好几天才发现。看完这篇最大的收获是”切分粒度和体验边界对齐”这句话，回去就把会话保持加上了。

周晓岚：评测集那一段说到我心里去了。我们一直是用开发时调过的样本去测，分数漂亮得不敢信，上线就打脸。现在准备单独建一套回归集，按场景分开维护。

徐国栋：想问一下，如果是制造业内部的单证抽取场景，灰度周期一般怎么定？我们有明显的月末高峰，是不是必须跑满一个月才算数？

林知远：作者提到的鱼骨图那六条我们内部对齐过一轮，确实前三条问题最大。数据和指标这块没打好底，分流做得再花哨也没用。

赵敏：比较认同”灰度不是开关而是机制”这个说法。我们团队现在每次换模型都从头来一遍，评测集也各写各的，看完准备先把评测集和口径统一起来，再谈别的。