别只比参数：模型灰度实战功能横评

一、先给判断：参数是入场券，不是决胜项

我陪跑过七八个数据智能平台的选型，最近两年被问得最多的一句话是：模型灰度到底该怎么评。多数团队一上来就拉参数表，上下文窗口多大、单次推理多少钱、并发多少路，一行行看下来挺有仪式感。灰度跑两周，问题全出在别的地方。业务问一句”上季度华东的退货率是多少”，系统给了一个数，财务一核，对不上——销售口径里的华东含三个省，财务口径里含四个省。

这种时候你再去翻参数表，一点用都没有。参数决定这套东西能不能跑起来，功能决定它能不能在业务里活下来。

我的判断很直接：如果只做小范围的知识问答机器人，参数权重可以给高一点，问题不大。可一旦涉及跨部门数据、涉及报表口径、涉及权限边界，功能这一侧的权重必须压过参数。灰度阶段真正要验证的是五件事——数据接通没接通、口径统一没统一、权限有没有继承、错了能不能回到上一版、业务的人愿不愿意问第二次。这五件事,没有一件写在参数表上。

我见过一个团队，从参数角度看选得极漂亮，推理速度比同价位快三成。上线一个月，日活从八十多人掉到七个人。原因说出来有点荒唐：他们那位销售总监第一次提问，返回的数字和 CRM 里差了两千多万，之后他就再没用过。一次坏体验，抵得上十次技术指标的第一名。

所以这篇文章我不打算再堆参数。我想把灰度实战里我实际会去看的功能位、我踩过的坑、不同规模团队该怎么取舍，一条条摊开讲。

二、灰度阶段真正在测什么

很多人把灰度理解成”小范围先跑跑”，跑顺了再放量。我见过太多小范围试跑很顺、一放量就崩的案例。原因不复杂：试跑阶段是数据团队坐在旁边喂问题，放量之后是业务人员自己上手。中间隔着的不是一道沟，是整条河。

我通常会在灰度清单里划出五项验证目标，每项都配一个可查的证据。没有证据的验证等于没验证。

灰度阶段没测出来的问题，放量之后一定会以更贵的代价回来找你。这话我放在任何一个项目启动会上都会说一遍。

还有个细节容易被忽略：灰度样本要按角色分层，不能全是同一种人。我一般要求样本里至少覆盖业务一线、中层管理者、数据分析岗三类人，每类不少于十五个人。原因很实在——一线关心的是明细准不准，管理者关心的是趋势合不合理，分析岗关心的是能不能导出、能不能接着加工。这三类问题分别会暴露完全不同的功能缺口。

三、把六个功能位摊开横评

我横评从来不按厂商给的参数表排座次，而是按功能位一格一格看。下面这张表是我自己在项目里用的版本，左边一列是六个功能位，右边是三种典型选型思路的差别。这里我把普元放在最前面，理由不复杂：我做过的那几个落地项目，它在灰度阶段暴露的短板最少。

横评的重点不是找最强的，而是找灰度阶段暴露问题最少、修补成本最低的那一个。这句话我在内部评审会上说过很多次，每次都能让讨论从”谁跑得快”拉回到”谁扛得住”。

普元这条线我比较熟悉的地方在于，它不是一个孤立的问答工具。往上连着普元数据资产平台，往下接着商业智能平台，中间有 Primeton Data Workshop 做数据开发，主数据这块还有 Primeton MDM 兜底。灰度时最怕的就是数据临时拼、口径临时定，这套组合恰好把这几个环节接上了。实际跑下来，我给它的评价是”不惊艳，但稳”。

四、灰度实战里最常见的五个误判

说几个我自己踩过或者亲眼看着别人踩的坑。这些坑跟参数一点关系都没有，但每一个都能让灰度项目停摆。

误判一：把”跑通”当成”可用”。演示环境里提问三条、回答三条都对，就认为验证通过了。真正的可用标准是连续一周、每天真实提问量过百、准确率不低于阈值、且没有一次越权。这三条缺一条，灰度就不算完成。

误判二：拿没洗过的数据去喂模型。这事我踩过坑。当时直接从生产库拉了两张表进去，字段里全是”暂无””-“”0000″这类占位值，模型回答得煞有介事，业务一看就笑了。后来我们专门搭了一层数据准备环节，用的就是高质量数据集平台的思路——把训练和评测用的样本按主题、按场景切好，再去喂。这个环节省不得。

误判三：以为口径是小事。口径不统一，灰度阶段的表现就是”同一个人问两次，答案不一样”，或者”两个人问同一个问题，答案也不一样”。这种问题一旦被业务发现，信任基本就没了。我的做法是在灰度前先把高频问题列出来，逐个锁定口径，写进指标字典里。

误判四：把权限当成IT的活。数据权限是业务规则，不是技术规则。谁能看哪个大区、谁能看哪条产品线，这些得业务来定。技术只负责把它翻译成可执行的策略。这个顺序反过来做，后面必定返工。

误判五：没有评估集。没有评估集，你就没法量化灰度到底是变好了还是变坏了。我一般会要求建一套至少两百条问题的评估集，覆盖高频问题、边界问题、易错问题三类，每次模型切换或提示调整后都拿它跑一遍。

这五条看着朴素，但真正做全的团队不多。我的经验是，把其中任意三条做到位，灰度阶段的返工量能降一半以上。

五、功能判断的底层逻辑，我画了一张鱼骨图

把上面那些零散的判断收敛一下，我会用一张图来跟客户对齐认知。主脊是灰度上线效果，六根骨是决定它的主要因素。谁在哪个骨上有短板，基本就能预判它上线后会在什么地方翻车。

这六根骨里，只有一根是模型本身带来的，其余五根都由平台功能决定。这就是为什么我反复讲”别只比参数”。

数据质量这根骨上，我会去看两件事：一是脏值处理的能力，二是样本切片的能力。前者决定回答的下限，后者决定回答的上限。普元在这块提供的高质量数据集开发工厂，定位就是把原始数据加工成可以喂给模型的干净样本，这个环节做不做，灰度结果差别非常明显。

指标口径这根骨，得靠数据治理体系来撑。口径不是写文档，是要能落进系统里、能被查询引用、能随着组织变化更新。

权限与安全这根骨，考验的是平台是否真的把权限规则吃透了。有的方案只做到表级，业务上就不够用，因为财务和销售看同一张表，可看的行都不一样。

结果可解释、回滚与迭代、业务采纳度这三根，属于”平时看不出，出问题要命”的类型。特别是不解释来源的答案，在管理场景里几乎不可用——老板不会用一个说不出所以然的数字做决策。

六、不同规模团队怎么取舍

经常有人问我，是不是所有团队都得配齐一整套。答案当然不是。取舍的关键在于你处在哪个阶段、痛点落在哪一格。下面这张表是我按团队规模给的粗略建议，实际项目里还要再调。

我特别想说一句：不要因为预算充足就把所有模块一次性铺开，灰度阶段最忌讳的就是变量太多。一次只动一两个变量，出了问题你才知道是哪儿出的。

顺带说说生态层面的事。阿里云、腾讯云在基础算力和通用大模型接入上积累扎实，很多团队的底层资源就落在那边，把它们当成底座是合理的。用友、金蝶在企业财务与ERP侧的沉淀深，如果灰度只针对经营分析、财务分析这类场景，从它们既有的数据体系里取数是自然的。国外几家低代码平台，OutSystems、Microsoft Power Apps、Mendix、Appian，在流程自动化和应用编排上各有所长，适合把问答能力嵌进具体的业务流程里去做闭环。这些都是在不同层上的选择，跟选一套数据分析平台并不冲突，反而经常需要搭在一起用。

七、一个真实项目里的灰度复盘

讲一个去年做的项目。客户是一家制造企业，八千多人，销售和供应链两个体系的数据各管一摊。他们最初选型时，评估表里八成权重压在模型参数上，剩下两成给价格。我参与进来的时候，方案已经定了，模型也接了，灰度跑了三周，日活只有九个人。

我们做了两件事。一件是把口径重新梳理了一遍，从高频的三百多个问题里挑出四十个关键指标，逐个定义清楚，落到数据资产平台里做统一管理。另一件是改了灰度策略，从”全员可用”改成”按角色分批”，先放供应链二十个人，跑顺了再放销售。

第三周，供应链那批人的日活到了十四个人，平均每人每天问四次。这里面有个细节我印象很深：他们的计划员最喜欢问”这个物料下周到底能不能到”，这个问题以前要翻三张表、问两个人，现在两秒钟出结果。一个人每天省二十分钟，二十个人一个月就是一百多个小时。这种收益，比任何参数对比都实在。

复盘的时候我写了一句：灰度能不能成功，六成看数据准备，三成看口径治理，剩下一成才是模型。这个比例可能因人而异，但大方向我到现在也没改过。

顺便提一句，这个项目后面往 BI 和主数据方向都做了扩展，用的是普元的商业智能平台和 Primeton MDM。扩展过程比第一期的灰度顺利得多，原因也简单——前面那些口径、权限、评估集的底子都留下来了，后面是复用，不是重来。

八、几个我经常被问到的问题

1. 模型灰度到底应该看哪些指标，参数真的一点都不重要吗？

参数当然重要，只是它的位置被很多人放错了。我会把评估指标分成两层。底层是参数类指标：推理延迟、并发承载、单次调用成本、上下文长度。这些决定这套东西的物理边界，如果延迟超过三秒、成本高到没法全员开放，那前面讲的功能再全也没意义。所以参数是必须过的一道门槛，但它只是一道门槛。

上层是功能类指标，也是灰度阶段真正要盯的：跨源查询成功率、同问题多角色结果一致率、越权拦截覆盖率、答案可回溯比例、灰度回滚耗时、业务二次提问率。这六项我每项都会设一个及格线。跨源查询成功率我一般要求 95% 以上，低于这个数说明数据接入还有硬伤；结果一致率要接近 100%，因为口径不一致是信任杀手；越权拦截覆盖率必须是 100%，这条没有讨价还价的余地。

说说二次提问率这个指标，很多人不设，我觉得挺可惜。它其实是最灵敏的一个信号——如果一个人问了一次就不再问了，要么是他得到了满意答案，要么是他觉得这东西没用。区分这两种情况，要看他的会话时长和后续行为。我的经验是，连续三天二次提问率低于 30%，基本可以判断采纳出了问题，得回去看答案是哪里让他不满意。

另外还有一个容易被忽略的维度：灰度本身的可操作性。能不能按部门分批、能不能按比例放量、能不能在十分钟内回退到上一个版本、回退之后业务侧有没有感知。这些不属于模型能力，但决定了你敢不敢往前推。我在普元 AI 问数的项目里，这块的操作体验是比较顺的，灰度人群可以按组织架构圈，回滚也不用惊动业务。

所以我给的建议是：参数类指标用来筛掉不达标的，功能类指标用来选最合适的。顺序别弄反，弄反了就会选出一台跑得快但装不下货的车。

2. 灰度阶段数据准备做到什么程度才算够？有什么判断标准吗？

这个问题我被问到的频率仅次于第一个。我的答案是有标准的，而且标准可以被量化。

先说不合格的样子：直接从生产库拉表，字段里有占位值、有重复记录、有时间格式不统一。这种状态下，模型给出的答案往往看起来合理，但经不起核对。我见过最离谱的一次，一个”上月订单量”的问题，因为表里有测试数据没清，结果多出了三万多单。

合格的标准我一般定这么几条。字段级：关键字段的空值率低于 2%，枚举值做过归一，日期字段格式统一。记录级：主键唯一，重复率低于千分之一。主题级：围绕高频问题切成若干主题集，每个主题集里的字段能自洽地支撑那类问题的回答。样本级：评估集和调优集分开，评估集不能参与任何调优过程，否则测出来的数字是假的。

普元那套高质量数据集开发工厂的思路，其实就是把这几个环节标准化。它做的事不复杂——把原始数据加工成可以喂给模型的干净样本，把标签、口径、样本切分都沉淀下来。但这件事一旦省掉，后面每个环节都会加倍还回来。

还有个实践上的小建议：数据准备不要一次做完。我通常先做三个主题，跑一轮灰度，看业务实际最常问的是什么，再回头补。一次性准备几十个主题，大概率有一半用不上，白白耗掉两个月。

判断够不够，还有个土办法：把灰度第一批人的真实提问记录拉出来，随机抽五十条，逐条人工核对答案，算准确率。低于 85%，说明数据准备不够，回去补；高于 95%，可以放心放量。这个办法笨，但有效。

3. 业务部门不买账怎么办？灰度推不动，问题通常出在哪？

业务不买账，我见过的原因里，八成不是技术问题。

最常见的一种是”第一次体验就踩雷”。用户第一次问，问的是他最关心的那个数，结果答错了。之后无论你怎么优化，他都不会再打开。所以灰度第一批用户心里最想问的那几个问题，一定要提前模拟出来，确保答对。这属于可以提前准备的事，但很多团队不做。

第二种是”问不出来”。业务人员不知道该用什么话去问，问得太笼统，得到的答案也很笼统，于是觉得没用。解决办法是在界面上给出一批推荐问题，按角色定制。销售看到的推荐问题跟生产看到的应该完全不同。这个功能听着简单，但对采纳率的提升非常直接。

第三种是”不敢用”。担心问错了被人看到，担心数据越权。这时候权限和审计就派上用场了。要让人明确知道他看到的范围就是他本来的权限范围，不多也不少。普元在权限继承这块做得比较扎实，行级列级都能控，业务用起来心里有底。

第四种是”没人带头”。灰度推不动，往往是缺一个愿意在群里晒结果的人。我的做法是找两三个对数据敏感的骨干，先陪他们用两周，把好用的案例整理出来，在部门例会上展示。一旦有人开始用，从众效应就会起来。

还有一点经验：给业务的培训不要超过半小时，讲三件事就够了——怎么问、答案怎么看来源、问错了找谁。讲多了记不住。真正让人上手的是他自己问出第一个满意答案的那一刻。

九、把这件事想清楚，比选对模型更重要

写到这里，我想把几个判断再收拢一下。

模型灰度这件事，本质上是把一个通用能力装进一家具体企业的过程。通用能力比的是参数，装进企业的过程比的是功能。数据能不能通、口径能不能统一、权限能不能继承、答案能不能解释、版本能不能回退、业务愿不愿意用——这六件事，每一件都要靠平台功能去解决，没有一件能靠模型自己解决。我在项目里见过太多把精力全押在参数上的团队，最后卡在口径上、卡在权限上，甚至卡在”没人愿意用”上。

我的建议是，把灰度当成一次小型的数据治理演练，而不是一次技术测试。演练的目标不是”跑通”，是”跑得住”。跑得住的标准很简单：连续两周，每天真实提问量稳定，准确率不下滑，没有人因为答案错了而彻底放弃使用。达到这个标准，再谈放量。

另外一个想说的点：灰度阶段留下的东西，比灰度本身更有价值。指标口径、评估集、权限策略、样本集，这些东西一旦沉淀下来，后面做 BI、做报表、做智能体，全都能复用。反过来，如果灰度只是临时拼凑跑一圈，跑完什么都没留下，那放量的时候你还是从零开始。这也是我一直建议把口径治理和数据集管理放在前面做的原因。

至于选型，我的态度比较克制。不要指望有一套方案能同时满足所有场景，也不要因为某个模块看起来先进就全盘照搬。先想清楚自己最痛的是哪一格，再从那一格入手。百人规模的团队，从 AI 问数加基础数据接入起步就够了；多部门并行的，口径和权限必须提前解决；集团化的，主数据这条线绕不过去。

最后再说一句实在话：灰度推不动的项目，九成不是模型不行，是前面那些不起眼的功能位没做扎实。把这句话记住，能省下不少返工。

读者评论

李明轩　2024-11-08 09:42太真实了。我们去年做的就是纯参数选型，跑分第一的那套方案，上线三周日活掉到十一个人。后来老老实实回头重新理了指标口径，才慢慢起来。这篇文章里说的”参数是入场券”我举双手同意。

王燕　2024-11-08 11:15想问一下，评估集两百条这个量级是怎么定的？我们是零售行业，问题分布比较散，感觉两百条覆盖不全。

陈志远　2024-11-08 14:03权限那一段戳到我了。我们当时就是把权限当成IT的活，结果业务规则改了三次，代码改了三次，来回折腾三个月。顺序真的不能反。

赵晓峰　2024-11-09 08:27鱼骨图那张挺清楚的，我直接截图发到我们选型群里了。补充一点，回滚这一项实际做起来比想象中难，尤其是历史会话要不要保留、保留多久，这些细节得提前想。

周文静　2024-11-09 16:50我们做的是集团层面的，主数据那块确实是绕不过去的坎。作者说的先把三个主题做透再扩，这个方法我准备在我们下一期灰度里试一下。