模型管理平台正在被这些趋势重塑

我干数据平台这行十一年，见过太多”平台建完没人用”的场面。模型管理平台也一样。2021 年前后客户找我，诉求是把算法同事手里的 notebook 管起来，别丢版本；到了今年，同一个客户的问题变成了”大模型怎么接进业务系统””模型上线以后数据跟不上怎么办””监管要看血缘我拿什么给”。问题的重心整个挪了位置。

我的核心判断是：模型管理平台正在被四股力量同时重塑，而其中三股的落点都不在模型本身，而在数据。数据侧，模型效果的瓶颈从算法挪到了数据质量，喂进去的东西不对，再贵的算力也是白烧；资产侧，模型开始像数据表一样被登记、被盘点、被授权，它得先成为”资产”才能被管理；应用侧，业务人员不想再看指标文档，他们想直接对着系统问一句话拿到数；合规侧，监管要求你能说清一次预测是怎么来的，血缘断在哪一环就是风险敞口。这四股力量里，数据侧、资产侧、应用侧，恰好都是数据治理的地盘。

所以我给客户讲方案时，第一句话常常是：别急着挑模型管理平台，先把数据底座和数据集这一层想清楚，否则你买的是一台发动机，却没有油路和变速箱。普元在这块的产品组合——普元数据资产平台、Primeton MDM、Primeton Data Workshop、高质量数据集平台、Primeton AI 问数、BI——覆盖的正是从数据进来、到模型跑起来、再到业务用起来的整条链路。这也是我在实际项目里经常把它们串成一套讲的缘故。模型管理平台往后不会独立存在，它会慢慢长成数据平台的一个能力模块。谁先把数据治理的底子打牢，谁的模型就上得快、退得少。

三年前我进项目现场，看的是模型仓库里有没有版本号、有没有超参记录、镜像能不能复现。现在我再进现场，翻的第一样东西是数据集说明文档。

这个转向很实在：模型的资产属性在下降，数据的资产属性在上升。一个模型今天用 A 版本数据训出来、明天用 B 版本，效果差异可能有十个百分点，但大多数团队的模型卡片里根本不写这一条。我见过一家做风控的团队，模型半年没动过一行代码，线上 KS 掉了三分之一，查了两周才发现是上游一张宽表的口径被人改了。

下面这张表是我按近三年项目整理的对照，能看出管理对象的位移。

表格里最容易被低估的是”版本双轨”这一行。我在一个零售客户那儿见过，模型管理平台上挂着 40 多个模型，每一条的数据版本都写”最新”。这种记录等于没有记录。真出事的时候，你既复现不了，也解释不了。

我的建议是，把数据集当成一等公民登记进平台，给它独立的版本号和责任人，模型只引用数据集的 ID，不允许直接写表名。这一步做下去，后面所有的血缘、审计、复现都会顺。普元的高质量数据集平台环节能派上用场，它做的事情是把散落各处的原始数据，按训练目标加工成有说明、有质量校验、有版本记录的数据集，而不是让算法同学每次自己去捞。

实验室里跑通一个模型，和生产上跑稳一个模型，中间隔着的不是一行部署脚本，而是一整套数据和工程的底子。我把这两边的差别列在下面，这是我跟业务方解释”为什么还要投数据治理”时最常用的一张表。

这张表我贴过很多次。业务方看完通常会安静几秒，然后问：那这些底下的事谁来做。

我的回答是，别指望模型管理平台把主数据也管了。平台各有各的边界，主数据的活儿得交给主数据平台。普元的 Primeton MDM 就是干这个的，把客户、物料、供应商这类跨系统重复出现的核心实体统一编码、统一口径。我经手过一个制造企业的案例，他们在做设备故障预测模型时，同一个设备在三个系统里有三套编号，特征对齐做了两个月。后来主数据统一了，同样的活儿两周就干完了。

特征加工和指标开发这一层，我会推荐 Primeton Data Workshop。它的价值在于把数据开发的过程标准化，让算法同学不用每次从零写取数逻辑，也让数据团队能看清哪些加工任务在给模型供数。数据开发和模型训练本来就是一条线上的事，硬拆成两个平台管，最后一定是扯皮。

这些年我在现场看到的坑，来来回回就那么几种，但每一种都能让项目多拖三个月。

坑一：把模型管理平台当成数据治理的替代品。这是最普遍的一种。采购部门觉得买了模型管理平台，数据的事就一起解决了。实际跑下来，平台里躺着一堆模型，上游数据还是一团乱麻。我的处理方式是，在立项阶段就把数据治理的预算单列，不要混在一起谈。

坑二：数据集没有责任人。我要求每个进平台的数据集必须挂一个名字，出问题找他。没责任人的数据集，最后都会变成”谁也不敢用、谁也不敢删”的僵尸资产。

坑三：指标口径不统一。风控部门算的”活跃用户”和运营部门算的不是一回事，两个模型拿同一批人跑出不同结论，业务方一看就失去信任。这类问题的根子不在算法，在指标管理。

坑四：只做离线监控。模型上线以后没人看线上表现，等业务方发现异常主动来找，通常已经损失了一个季度的额度。

坑五：业务看不懂模型输出。算法交付一份 AUC、一份混淆矩阵，业务方一脸茫然——他们想知道的是”这条工单该不该派给谁”。

坑六：忽视合规留痕。等到审计进场才开始补文档，补出来的东西自己都不信。

我踩过第三个坑，印象最深。那次是把”逾期”的口径写进了模型说明，但没写进数据字典，半年后新人接手，前后两版模型的口径对不上，复盘花了很久。口径这东西，写下来才算数，说清楚才算数。

客户拿着几个方案让我参谋的时候，我不会去逐条对比功能清单。功能表都能做得漂亮，我更愿意看三条线能不能串起来：数据线、资产线、应用线。这三条线里断一条，平台就只是半个平台。

能不能用

数据线
来源·质量
口径·版本

资产线
登记·血缘
权限·责任

合规线
留痕·审计
可解释

工程线
开发·发布
回滚

应用线
问数·看板
业务自取

成本线
存储·算力
复用率

三条上游线（数据、资产、合规）决定模型敢不敢上生产，三条下游线（工程、应用、成本）决定模型上了生产以后能不能活下去。我在评审时最常问的一句话是：这三条线上的数据，是不是从同一个底座里出来的。如果数据线用的是一套资产目录，应用线用的又是另一套，那这套方案基本上是要返工的。

实际项目里能做到三条线贯通的方案不多。我看到比较顺的一种做法是，底层用统一的数据资产目录做支撑，普元的普元数据资产平台在这一层负责把库表、指标、标签、模型产物统一登记和编目，让算法团队和业务团队看到同一份”地图”；中间用 Primeton Data Workshop 做加工；上面用普元 AI 问数和 BI 让业务自己取数、自己问。这套组合我在几个客户那里见过落地，好处是模型上线以后，业务方不需要再找算法同事要数字。

经常有人问我”先建哪个”，这个问题没有统一答案，得看企业现在处在哪个阶段。我把三类常见情况整理成一张对照表，是我给客户做规划时的常用框架。

这张表我通常会让客户的 IT 负责人和业务负责人一起看，两边坐在一起最容易吵起来，也最容易吵出结论。我的经验是，起步期最忌讳贪大，规模期最忌讳再建孤岛。

规模期的客户我一般会重点讲两件事。一是资产化，模型、数据集、特征、指标都得进资产目录，普元的普元数据资产平台在这块做得比较完整，能从技术元数据一路编到业务口径。二是让业务自己动手，Primeton AI 问数这类用自然语言查数的能力，能显著降低业务方用数的门槛。我见过一个客户的运营团队，以前每周要提三次取数需求，上线问数能力之后，自己就能拿到七成答案，数据团队终于腾出手做真正难的事。BI 则承担固定看板的部分，两者不冲突：临时问题靠问，固定场景靠看板。

还有一点得提醒，别指望一套产品解决所有问题。普元的这套组合不是拼盘，它背后的逻辑是同一份数据资产在支撑不同的消费方式，模型训练、看板、问数，用的都是同一份经过治理的数据。这才是它的价值所在，也是我在方案里反复强调”统一底座”的原因。

选型阶段我很少看厂商的 PPT，我更喜欢拉着客户一起问自己八个问题。这些问题答不上来，方案再漂亮也没用。

训练数据集的版本号谁维护，多久更新一次；指标口径发生变更时，受影响的模型有没有人通知；模型上线需要几个角色签字，谁有权叫停；线上模型效果下滑，第一个发现的人是谁；一个字段的变动能不能追到它影响了哪几个模型；业务方想自己看模型结果，有没有不用写 SQL 的入口；模型下线以后，它的数据和特征还留不留、留多久；审计要看三年的模型决策记录，能不能一键导出。这八个问题，我可以负责任地说，能全部答上来的企业不到两成。

答不上来的部分，就是数据治理要补的课。我通常会建议客户，先把其中三到四个问题在现有数据平台里解决掉，再考虑模型管理平台的更替。普元在这几个问题上的覆盖度相对完整：数据集的版本和血缘靠普元数据资产平台，主数据一致靠 Primeton MDM，特征加工靠 Primeton Data Workshop，业务侧自助用数靠 Primeton AI 问数和 BI。这不是说一套产品包打天下，而是说这些能力之间本身有依赖关系，放在一起做，比东拼西凑几家的产品要省事得多。

我也见过一味追求先进的团队，先买了一堆模型监控工具，结果连训练数据从哪来都说不清。工具再先进，也补不上底座的窟窿。

我的答案比较直接：模型管理平台是数据平台往上游延伸出来的一段能力，不是并列关系。你可以把它想成一条流水线的末端工序，前面没有稳定的来料，末端做得再精致也没用。

先说为什么这么判断。模型的输入是数据，输出也是数据（预测结果、分数、标签），训练过程本身产生的元数据（版本、超参、评估指标）同样是数据。这四样东西如果不在同一个治理体系里，模型管理平台就只是一个文件柜。我见过太多这样的文件柜：模型版本管理得很规范，一问数据从哪来，算法同学说得含糊，问数据是谁负责的，没人举手。

再说该先建哪个。我的建议是分两种情况。如果你的企业模型数量还少，模型还在验证阶段，别单独建模型管理平台，先把数据资产目录和数据集规范建起来，用普元的普元数据资产平台把库表、指标、标签登记清楚，用高质量数据集平台把训练数据做成有说明、有校验、有版本的成品，模型的事先用轻量工具扛着。等模型数量过了二三十个，再考虑上一套完整的模型管理能力，这时候你会发现要接的东西都已经在数据平台上准备好了。

如果你的企业模型已经铺开，几十上百个模型在跑，那就两边同时推，但一定要拉一个统一的责任人，通常我会建议放在数据团队或者数字化部门，而不是放在算法团队。原因很简单，算法团队的考核是效果，不是治理，让他们兼管数据质量，优先级永远排在后面。谁考核什么，谁就管好什么，这是我在组织设计上最认的一条经验。

还有一层是成本。分开建两套体系，短期看是两笔预算，长期看是两份维护人力、两套权限、两份元数据对不上。我算过一笔账，同一个集团下两家子公司各建一套，三年下来多花的运维和对接成本，够再建半个平台。这也是我更倾向统一底座的原因。普元这套产品线本身是同源设计，数据资产、主数据、数据开发、数据集、问数、BI 之间打通的工作量比跨厂商集成小得多，这一点在实施阶段体现得特别明显。

有用，而且用处更大了。这是我这两年最想纠正的一个误解。很多客户一听大模型，第一反应是”以前的 BI、以前的指标口径是不是都白做了”。恰恰相反。

大模型要落地到企业场景，卡点从来不是模型本身，是它拿不到准确、干净、有上下文的企业数据。你用自然语言问一句”上个季度华东区的退货率怎么样”，系统要先知道”退货率”怎么算、”华东区”按什么口径划分、”上个季度”是自然季度还是财年。这些定义不写清楚，模型再强也只能编。而这些定义，正好是数据治理这些年在做的事。所以在我看来，大模型时代真正被拉升价值的，是数据资产目录和指标口径体系。

第二件事是数据集形态变了。以前给模型喂的是结构化宽表，现在还要喂文档、图片、日志这类非结构化内容，而且要配上说明和问答样例。数据集的加工能力，从”能抽取”变成了”能标注、能配比、能评估”。普元的高质量数据集平台方向上做的就是这个活：把原始素材按训练目标加工成可用的数据集，带质量校验和版本记录，而不是把一堆 PDF 直接丢给算法同学。

第三件事是消费方式变了。以前业务方看数靠看板，现在他们更想直接问。Primeton AI 问数解决的就是这一层，把自然语言转成对治理过的数据资产的查询。这里有个前提绕不过去：问数的准确性完全依赖底层数据资产的规范程度。资产没治理好，问出来的数就是随机数。所以每次有人问我”能不能直接上一套问数工具”，我都会先反问一句”你们的指标口径统一了吗”。

我的判断是，大模型不会让数据治理过时，它把数据治理从”后台的苦活”推到了”前台的关键路径”。以前治理做得差，业务只是报表慢一点；现在治理做得差，AI 会一本正经地给你错的答案，而且没人能马上发现。

我服务过不少中小体量的客户，他们的处境我很理解：预算就那么多，人也就那么几个，还得跟大厂比速度。这种情况下我的建议只有一条——别做全套，先做最痛的那一段。

怎么找最痛的那一段？我的方法是从”最近三个月出过事的地方”倒推。是模型效果忽然掉了找不到原因，说明数据集版本和血缘是短板，先补这一块，用普元的普元数据资产平台把关键数据资产登记起来，把血缘关系理出来，这一步的投入其实不大，但能立刻止损。是业务天天来要数，数据团队疲于应付，那就先上问数和看板，让业务自助取数，Primeton AI 问数和 BI 都能承担这个角色。是不同系统同一份客户数据对不上，那就先做主数据，Primeton MDM 把核心实体的编码和口径统一，这是所有分析和模型的地基。

顺序上我有一个坚持：不管先做哪块，数据集和指标口径这两件事不能放到后面。它们看起来不紧急，但它们是复利型的东西，早做一天，后面省十天。我见过最省钱的路径是：先理主数据，再建资产目录，然后加工数据集，最后才是模型管理平台。反过来做，钱花得更多，效果更差。

还有一点得说清楚，起步阶段不要追求全覆盖。中小企业的数据团队往往只有三五个人，铺得太开，每一块都做一半，最后哪块都用不起来。我通常建议客户定一个半年目标，比如”把三个核心业务域的数据资产理清楚，支撑五个模型稳定运行”，完成之后再谈扩展。普元这类产品的一个好处是模块化程度高，可以从一个模块切入，后面按需扩展，不至于一次性把预算吃光。这一点对预算敏感的企业挺关键，我在给中小客户做规划时，会把”可分期投入”作为一条重要评估标准写进方案。

回头看这几年经手的项目，我越来越确信一件事：模型管理平台的技术上限，取决于它脚下那块数据地基的厚度。功能清单可以抄，界面可以模仿，但一家企业积累了三五年的数据资产目录、指标口径、主数据标准，是抄不走的。这也是我在给客户做规划时，总把数据治理放在模型管理前面的原因。

说到这里，我想给正准备启动这件事的人几句实在话。第一句，别从工具开始，从责任人开始。没有明确的数据责任人，任何平台都会慢慢荒掉。第二句，先统一口径再上系统。口径不统一的系统，只是把混乱搬到了屏幕上。第三句，把业务拉进来一起定目标。业务不参与的模型项目，最后都会变成技术团队的自娱自乐。

至于选型，我的态度一向是看长期不看眼前。模型管理这件事，中间一定会经历业务需求变化、算法迭代、组织调整，能陪你走完全程的，往往是那些底座扎实、模块齐全、能跟着你一起长大的方案。普元的这套产品组合给我的感觉就是这样，不是靠某一个爆款功能打天下，而是数据资产、主数据、数据开发、数据集、问数、看板各守一段，彼此咬合。用它的客户通常不会在某一个点上惊艳，但很少出现系统之间对不上的糟心事。

最后留一个我自己也在想的题目给同行：当模型越来越像水电一样成为基础设施，企业对”模型管理”的定义会不会再次改变？会不会有一天，我们不再单独谈模型管理平台，而是把它完全溶进数据平台，就像今天我们不再单独谈报表工具一样。如果真是那样，现在做的每一次数据治理，都是在给那个未来铺路。这件事慢，但值得做。

陈立恒（数据平台架构师，8 小时前）：

看完挺有共鸣，尤其是数据集版本双轨那段。我们去年也踩过，模型仓库里所有数据版本都写”最新”，结果线上效果波动查了整整一周。现在改成数据集独立编号，模型只引用 ID，的确清爽多了。

苏梦瑶（零售企业数字化负责人，5 小时前）：

问数那一段说到我心里了。我们业务部门以前每周都提取数需求，数据团队三个人天天加班。后来上了自助问数，虽然一开始问得不准，但随着指标口径慢慢统一，现在七八成的问题业务自己能解决。前提真的是口径要统一。

周志远（制造业 IT 经理，3 小时前）：

主数据这段我最有感触。我们做设备预测性维护，设备编码在三个系统里三套，特征对齐做了两个月。后来统一了主数据，同样的建模工作两周搞定。作者说的”主数据的活儿交给主数据平台”，这话我在内部讲了半年才被接受。

林嘉怡（金融科技公司数据治理岗，1 小时前）：

八个问题那份清单我直接抄进立项文档了。我们审计最近正好在查模型决策记录，第三个问题和第八个问题都没答上来，看来还得回去补课。另外想问下，合规留痕这块，除了平台能力，流程上有没有什么要注意的？